OSDN Git Service
Nicholas Bellinger [Sat, 3 Jun 2017 12:35:47 +0000 (05:35 -0700)]
iscsi-target: Fix delayed logout processing greater than SECONDS_FOR_LOGOUT_COMP
commit
105fa2f44e504c830697b0c794822112d79808dc upstream.
This patch fixes a BUG() in iscsit_close_session() that could be
triggered when iscsit_logout_post_handler() execution from within
tx thread context was not run for more than SECONDS_FOR_LOGOUT_COMP
(15 seconds), and the TCP connection didn't already close before
then forcing tx thread context to automatically exit.
This would manifest itself during explicit logout as:
[33206.974254] 1 connection(s) still exist for iSCSI session to iqn.1993-08.org.debian:01:
3f5523242179
[33206.980184] INFO: NMI handler (kgdb_nmi_handler) took too long to run: 2100.772 msecs
[33209.078643] ------------[ cut here ]------------
[33209.078646] kernel BUG at drivers/target/iscsi/iscsi_target.c:4346!
Normally when explicit logout attempt fails, the tx thread context
exits and iscsit_close_connection() from rx thread context does the
extra cleanup once it detects conn->conn_logout_remove has not been
cleared by the logout type specific post handlers.
To address this special case, if the logout post handler in tx thread
context detects conn->tx_thread_active has already been cleared, simply
return and exit in order for existing iscsit_close_connection()
logic from rx thread context do failed logout cleanup.
Reported-by: Bart Van Assche <bart.vanassche@sandisk.com>
Tested-by: Bart Van Assche <bart.vanassche@sandisk.com>
Cc: Mike Christie <mchristi@redhat.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Sagi Grimberg <sagig@mellanox.com>
Tested-by: Gary Guo <ghg@datera.io>
Tested-by: Chu Yuan Lin <cyl@datera.io>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicholas Bellinger [Thu, 25 May 2017 04:47:09 +0000 (21:47 -0700)]
iscsi-target: Fix initial login PDU asynchronous socket close OOPs
commit
25cdda95fda78d22d44157da15aa7ea34be3c804 upstream.
This patch fixes a OOPs originally introduced by:
commit
bb048357dad6d604520c91586334c9c230366a14
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date: Thu Sep 5 14:54:04 2013 -0700
iscsi-target: Add sk->sk_state_change to cleanup after TCP failure
which would trigger a NULL pointer dereference when a TCP connection
was closed asynchronously via iscsi_target_sk_state_change(), but only
when the initial PDU processing in iscsi_target_do_login() from iscsi_np
process context was blocked waiting for backend I/O to complete.
To address this issue, this patch makes the following changes.
First, it introduces some common helper functions used for checking
socket closing state, checking login_flags, and atomically checking
socket closing state + setting login_flags.
Second, it introduces a LOGIN_FLAGS_INITIAL_PDU bit to know when a TCP
connection has dropped via iscsi_target_sk_state_change(), but the
initial PDU processing within iscsi_target_do_login() in iscsi_np
context is still running. For this case, it sets LOGIN_FLAGS_CLOSED,
but doesn't invoke schedule_delayed_work().
The original NULL pointer dereference case reported by MNC is now handled
by iscsi_target_do_login() doing a iscsi_target_sk_check_close() before
transitioning to FFP to determine when the socket has already closed,
or iscsi_target_start_negotiation() if the login needs to exchange
more PDUs (eg: iscsi_target_do_login returned 0) but the socket has
closed. For both of these cases, the cleanup up of remaining connection
resources will occur in iscsi_target_start_negotiation() from iscsi_np
process context once the failure is detected.
Finally, to handle to case where iscsi_target_sk_state_change() is
called after the initial PDU procesing is complete, it now invokes
conn->login_work -> iscsi_target_do_login_rx() to perform cleanup once
existing iscsi_target_sk_check_close() checks detect connection failure.
For this case, the cleanup of remaining connection resources will occur
in iscsi_target_do_login_rx() from delayed workqueue process context
once the failure is detected.
Reported-by: Mike Christie <mchristi@redhat.com>
Reviewed-by: Mike Christie <mchristi@redhat.com>
Tested-by: Mike Christie <mchristi@redhat.com>
Cc: Mike Christie <mchristi@redhat.com>
Reported-by: Hannes Reinecke <hare@suse.com>
Cc: Hannes Reinecke <hare@suse.com>
Cc: Sagi Grimberg <sagi@grimberg.me>
Cc: Varun Prakash <varun@chelsio.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicholas Bellinger [Sun, 28 Feb 2016 02:15:46 +0000 (18:15 -0800)]
iscsi-target: Fix early sk_data_ready LOGIN_FLAGS_READY race
commit
8f0dfb3d8b1120c61f6e2cc3729290db10772b2d upstream.
There is a iscsi-target/tcp login race in LOGIN_FLAGS_READY
state assignment that can result in frequent errors during
iscsi discovery:
"iSCSI Login negotiation failed."
To address this bug, move the initial LOGIN_FLAGS_READY
assignment ahead of iscsi_target_do_login() when handling
the initial iscsi_target_start_negotiation() request PDU
during connection login.
As iscsi_target_do_login_rx() work_struct callback is
clearing LOGIN_FLAGS_READ_ACTIVE after subsequent calls
to iscsi_target_do_login(), the early sk_data_ready
ahead of the first iscsi_target_do_login() expects
LOGIN_FLAGS_READY to also be set for the initial
login request PDU.
As reported by Maged, this was first obsered using an
MSFT initiator running across multiple VMWare host
virtual machines with iscsi-target/tcp.
Reported-by: Maged Mokhtar <mmokhtar@binarykinetics.com>
Tested-by: Maged Mokhtar <mmokhtar@binarykinetics.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiang Yi [Tue, 16 May 2017 09:57:55 +0000 (17:57 +0800)]
iscsi-target: Always wait for kthread_should_stop() before kthread exit
commit
5e0cf5e6c43b9e19fc0284f69e5cd2b4a47523b0 upstream.
There are three timing problems in the kthread usages of iscsi_target_mod:
- np_thread of struct iscsi_np
- rx_thread and tx_thread of struct iscsi_conn
In iscsit_close_connection(), it calls
send_sig(SIGINT, conn->tx_thread, 1);
kthread_stop(conn->tx_thread);
In conn->tx_thread, which is iscsi_target_tx_thread(), when it receive
SIGINT the kthread will exit without checking the return value of
kthread_should_stop().
So if iscsi_target_tx_thread() exit right between send_sig(SIGINT...)
and kthread_stop(...), the kthread_stop() will try to stop an already
stopped kthread.
This is invalid according to the documentation of kthread_stop().
(Fix -ECONNRESET logout handling in iscsi_target_tx_thread and
early iscsi_target_rx_thread failure case - nab)
Signed-off-by: Jiang Yi <jiangyilism@gmail.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicholas Bellinger [Mon, 27 Mar 2017 23:12:43 +0000 (16:12 -0700)]
target: Avoid mappedlun symlink creation during lun shutdown
commit
49cb77e297dc611a1b795cfeb79452b3002bd331 upstream.
This patch closes a race between se_lun deletion during configfs
unlink in target_fabric_port_unlink() -> core_dev_del_lun()
-> core_tpg_remove_lun(), when transport_clear_lun_ref() blocks
waiting for percpu_ref RCU grace period to finish, but a new
NodeACL mappedlun is added before the RCU grace period has
completed.
This can happen in target_fabric_mappedlun_link() because it
only checks for se_lun->lun_se_dev, which is not cleared until
after transport_clear_lun_ref() percpu_ref RCU grace period
finishes.
This bug originally manifested as NULL pointer dereference
OOPsen in target_stat_scsi_att_intr_port_show_attr_dev() on
v4.1.y code, because it dereferences lun->lun_se_dev without
a explicit NULL pointer check.
In post v4.1 code with target-core RCU conversion, the code
in target_stat_scsi_att_intr_port_show_attr_dev() no longer
uses se_lun->lun_se_dev, but the same race still exists.
To address the bug, go ahead and set se_lun>lun_shutdown as
early as possible in core_tpg_remove_lun(), and ensure new
NodeACL mappedlun creation in target_fabric_mappedlun_link()
fails during se_lun shutdown.
Reported-by: James Shen <jcs@datera.io>
Cc: James Shen <jcs@datera.io>
Tested-by: James Shen <jcs@datera.io>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Prabhakar Lad [Thu, 20 Jul 2017 12:02:09 +0000 (08:02 -0400)]
media: platform: davinci: return -EINVAL for VPFE_CMD_S_CCDC_RAW_PARAMS ioctl
commit
da05d52d2f0f6bd61094a0cd045fed94bf7d673a upstream.
this patch makes sure VPFE_CMD_S_CCDC_RAW_PARAMS ioctl no longer works
for vpfe_capture driver with a minimal patch suitable for backporting.
- This ioctl was never in public api and was only defined in kernel header.
- The function set_params constantly mixes up pointers and phys_addr_t
numbers.
- This is part of a 'VPFE_CMD_S_CCDC_RAW_PARAMS' ioctl command that is
described as an 'experimental ioctl that will change in future kernels'.
- The code to allocate the table never gets called after we copy_from_user
the user input over the kernel settings, and then compare them
for inequality.
- We then go on to use an address provided by user space as both the
__user pointer for input and pass it through phys_to_virt to come up
with a kernel pointer to copy the data to. This looks like a trivially
exploitable root hole.
Due to these reasons we make sure this ioctl now returns -EINVAL and backport
this patch as far as possible.
Fixes:
5f15fbb68fd7 ("V4L/DVB (12251): v4l: dm644x ccdc module for vpfe capture driver")
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gregory CLEMENT [Wed, 12 Jul 2017 11:23:11 +0000 (13:23 +0200)]
ARM: dts: armada-38x: Fix irq type for pca955
commit
8d4514173211586c6238629b1ef1e071927735f5 upstream.
As written in the datasheet the PCA955 can only handle low level irq and
not edge irq.
Without this fix the interrupt is not usable for pca955: the gpio-pca953x
driver already set the irq type as low level which is incompatible with
edge type, then the kernel prevents using the interrupt:
"irq: type mismatch, failed to map hwirq-18 for
/soc/internal-regs/gpio@18100!"
Fixes:
928413bd859c ("ARM: mvebu: Add Armada 388 General Purpose
Development Board support")
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jerry Lee [Sun, 6 Aug 2017 05:18:31 +0000 (01:18 -0400)]
ext4: fix overflow caused by missing cast in ext4_resize_fs()
commit
aec51758ce10a9c847a62a48a168f8c804c6e053 upstream.
On a 32-bit platform, the value of n_blcoks_count may be wrong during
the file system is resized to size larger than 2^32 blocks. This may
caused the superblock being corrupted with zero blocks count.
Fixes:
1c6bd7173d66
Signed-off-by: Jerry Lee <jerrylee@qnap.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Sat, 5 Aug 2017 21:43:24 +0000 (17:43 -0400)]
ext4: fix SEEK_HOLE/SEEK_DATA for blocksize < pagesize
commit
fcf5ea10992fbac3c7473a1db33d56a139333cd1 upstream.
ext4_find_unwritten_pgoff() does not properly handle a situation when
starting index is in the middle of a page and blocksize < pagesize. The
following command shows the bug on filesystem with 1k blocksize:
xfs_io -f -c "falloc 0 4k" \
-c "pwrite 1k 1k" \
-c "pwrite 3k 1k" \
-c "seek -a -r 0" foo
In this example, neither lseek(fd, 1024, SEEK_HOLE) nor lseek(fd, 2048,
SEEK_DATA) will return the correct result.
Fix the problem by neglecting buffers in a page before starting offset.
Reported-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Josh Poimboeuf [Tue, 25 Oct 2016 14:51:14 +0000 (09:51 -0500)]
mm/page_alloc: Remove kernel address exposure in free_reserved_area()
commit
adb1fe9ae2ee6ef6bc10f3d5a588020e7664dfa7 upstream.
Linus suggested we try to remove some of the low-hanging fruit related
to kernel address exposure in dmesg. The only leaks I see on my local
system are:
Freeing SMP alternatives memory: 32K (
ffffffff9e309000 -
ffffffff9e311000)
Freeing initrd memory: 10588K (
ffffa0b736b42000 -
ffffa0b737599000)
Freeing unused kernel memory: 3592K (
ffffffff9df87000 -
ffffffff9e309000)
Freeing unused kernel memory: 1352K (
ffffa0b7288ae000 -
ffffa0b728a00000)
Freeing unused kernel memory: 632K (
ffffa0b728d62000 -
ffffa0b728e00000)
Linus says:
"I suspect we should just remove [the addresses in the 'Freeing'
messages]. I'm sure they are useful in theory, but I suspect they
were more useful back when the whole "free init memory" was
originally done.
These days, if we have a use-after-free, I suspect the init-mem
situation is the easiest situation by far. Compared to all the dynamic
allocations which are much more likely to show it anyway. So having
debug output for that case is likely not all that productive."
With this patch the freeing messages now look like this:
Freeing SMP alternatives memory: 32K
Freeing initrd memory: 10588K
Freeing unused kernel memory: 3592K
Freeing unused kernel memory: 1352K
Freeing unused kernel memory: 632K
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/6836ff90c45b71d38e5d4405aec56fa9e5d1d4b2.1477405374.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Kees Cook <keescook@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wanpeng Li [Tue, 1 Aug 2017 12:20:03 +0000 (05:20 -0700)]
KVM: async_pf: make rcu irq exit if not triggered from idle task
commit
337c017ccdf2653d0040099433fc1a2b1beb5926 upstream.
WARNING: CPU: 5 PID: 1242 at kernel/rcu/tree_plugin.h:323 rcu_note_context_switch+0x207/0x6b0
CPU: 5 PID: 1242 Comm: unity-settings- Not tainted 4.13.0-rc2+ #1
RIP: 0010:rcu_note_context_switch+0x207/0x6b0
Call Trace:
__schedule+0xda/0xba0
? kvm_async_pf_task_wait+0x1b2/0x270
schedule+0x40/0x90
kvm_async_pf_task_wait+0x1cc/0x270
? prepare_to_swait+0x22/0x70
do_async_page_fault+0x77/0xb0
? do_async_page_fault+0x77/0xb0
async_page_fault+0x28/0x30
RIP: 0010:__d_lookup_rcu+0x90/0x1e0
I encounter this when trying to stress the async page fault in L1 guest w/
L2 guests running.
Commit
9b132fbe5419 (Add rcu user eqs exception hooks for async page
fault) adds rcu_irq_enter/exit() to kvm_async_pf_task_wait() to exit cpu
idle eqs when needed, to protect the code that needs use rcu. However,
we need to call the pair even if the function calls schedule(), as seen
from the above backtrace.
This patch fixes it by informing the RCU subsystem exit/enter the irq
towards/away from idle for both n.halted and !n.halted.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Banajit Goswami [Sat, 15 Jul 2017 06:15:05 +0000 (23:15 -0700)]
ASoC: do not close shared backend dailink
commit
b1cd2e34c69a2f3988786af451b6e17967c293a0 upstream.
Multiple frontend dailinks may be connected to a backend
dailink at the same time. When one of frontend dailinks is
closed, the associated backend dailink should not be closed
if it is connected to other active frontend dailinks. Change
ensures that backend dailink is closed only after all
connected frontend dailinks are closed.
Signed-off-by: Gopikrishnaiah Anandan <agopik@codeaurora.org>
Signed-off-by: Banajit Goswami <bgoswami@codeaurora.org>
Signed-off-by: Patrick Lai <plai@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sergei A. Trusov [Wed, 2 Aug 2017 10:23:48 +0000 (20:23 +1000)]
ALSA: hda - Fix speaker output from VAIO VPCL14M1R
commit
3f3c371421e601fa93b6cb7fb52da9ad59ec90b4 upstream.
Sony VAIO VPCL14M1R needs the quirk to make the speaker working properly.
Tested-by: Dmitriy <mexx400@yandex.ru>
Signed-off-by: Sergei A. Trusov <sergei.a.trusov@ya.ru>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tejun Heo [Tue, 18 Jul 2017 22:41:52 +0000 (18:41 -0400)]
workqueue: restore WQ_UNBOUND/max_active==1 to be ordered
commit
5c0338c68706be53b3dc472e4308961c36e4ece1 upstream.
The combination of WQ_UNBOUND and max_active == 1 used to imply
ordered execution. After NUMA affinity
4c16bd327c74 ("workqueue:
implement NUMA affinity for unbound workqueues"), this is no longer
true due to per-node worker pools.
While the right way to create an ordered workqueue is
alloc_ordered_workqueue(), the documentation has been misleading for a
long time and people do use WQ_UNBOUND and max_active == 1 for ordered
workqueues which can lead to subtle bugs which are very difficult to
trigger.
It's unlikely that we'd see noticeable performance impact by enforcing
ordering on WQ_UNBOUND / max_active == 1 workqueues. Let's
automatically set __WQ_ORDERED for those workqueues.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Christoph Hellwig <hch@infradead.org>
Reported-by: Alexei Potashnik <alexei@purestorage.com>
Fixes:
4c16bd327c74 ("workqueue: implement NUMA affinity for unbound workqueues")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Wed, 19 Jul 2017 10:06:41 +0000 (13:06 +0300)]
libata: array underflow in ata_find_dev()
commit
59a5e266c3f5c1567508888dd61a45b86daed0fa upstream.
My static checker complains that "devno" can be negative, meaning that
we read before the start of the loop. I've looked at the code, and I
think the warning is right. This come from /proc so it's root only or
it would be quite a quite a serious bug. The call tree looks like this:
proc_scsi_write() <- gets id and channel from simple_strtoul()
-> scsi_add_single_device() <- calls shost->transportt->user_scan()
-> ata_scsi_user_scan()
-> ata_find_dev()
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Mon, 7 Aug 2017 02:20:47 +0000 (19:20 -0700)]
Linux 4.4.80
Patrick Lai [Sun, 1 Jan 2017 06:44:39 +0000 (22:44 -0800)]
ASoC: dpcm: Avoid putting stream state to STOP when FE stream is paused
[ Upstream commit
9f169b9f52a4afccdab7a7d2311b0c53a78a1e6b ]
When multiple front-ends are using the same back-end, putting state of a
front-end to STOP state upon receiving pause command will result in backend
stream getting released by DPCM framework unintentionally. In order to
avoid backend to be released when another active front-end stream is
present, put the stream state to PAUSED state instead of STOP state.
Signed-off-by: Patrick Lai <plai@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Burak Ok [Wed, 21 Dec 2016 13:45:53 +0000 (14:45 +0100)]
scsi: snic: Return error code on memory allocation failure
[ Upstream commit
0371adcdaca92912baaa3256ed13e058a016e62d ]
If a call to mempool_create_slab_pool() in snic_probe() returns NULL,
return -ENOMEM to indicate failure. mempool_creat_slab_pool() only fails
if it cannot allocate memory.
https://bugzilla.kernel.org/show_bug.cgi?id=189061
Reported-by: bianpan2010@ruc.edu.cn
Signed-off-by: Burak Ok <burak-kernel@bur0k.de>
Signed-off-by: Andreas Schaertl <andreas.schaertl@fau.de>
Acked-by: Narsimhulu Musini <nmusini@cisco.com>
Reviewed-by: Ewan D. Milne <emilne@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Satish Kharat [Wed, 14 Dec 2016 21:20:41 +0000 (13:20 -0800)]
scsi: fnic: Avoid sending reset to firmware when another reset is in progress
[ Upstream commit
9698b6f473555a722bf81a3371998427d5d27bde ]
This fix is to avoid calling fnic_fw_reset_handler through
fnic_host_reset when a finc reset is alreay in progress.
Signed-off-by: Satish Kharat <satishkh@cisco.com>
Signed-off-by: Sesidhar Baddela <sebaddel@cisco.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiri Kosina [Thu, 5 Jan 2017 13:25:59 +0000 (14:25 +0100)]
HID: ignore Petzl USB headlamp
[ Upstream commit
08f9572671c8047e7234cbf150869aa3c3d59a97 ]
This headlamp contains a dummy HID descriptor which pretends to be
a mouse-like device, but can't be used as a mouse at all.
Reported-by: Lukas Ocilka <lukas.ocilka@suse.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ioan-Adrian Ratiu [Wed, 4 Jan 2017 22:37:47 +0000 (00:37 +0200)]
ALSA: usb-audio: test EP_FLAG_RUNNING at urb completion
[ Upstream commit
13a6c8328e6056932dc680e447d4c5e8ad9add17 ]
Testing EP_FLAG_RUNNING in snd_complete_urb() before running the completion
logic allows us to save a few cpu cycles by returning early, skipping the
pending urb in case the stream was stopped; the stop logic handles the urb
and sets the completion callbacks to NULL.
Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sergei Shtylyov [Wed, 4 Jan 2017 20:10:23 +0000 (23:10 +0300)]
sh_eth: enable RX descriptor word 0 shift on SH7734
[ Upstream commit
71eae1ca77fd6be218d8a952d97bba827e56516d ]
The RX descriptor word 0 on SH7734 has the RFS[9:0] field in bits 16-25
(bits 0-15 usually used for that are occupied by the packet checksum).
Thus we need to set the 'shift_rd0' field in the SH7734 SoC data...
Fixes:
f0e81fecd4f8 ("net: sh_eth: Add support SH7734")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Schultz [Wed, 4 Jan 2017 16:18:10 +0000 (16:18 +0000)]
nvmem: imx-ocotp: Fix wrong register size
[ Upstream commit
14ba972842f9e84e6d3264bc0302101b8a792288 ]
All i.MX6 SoCs have an OCOTP Controller with 4kbit fuses. The i.MX6SL is
an exception and has only 2kbit fuses.
In the TRM for the i.MX6DQ (IMX6QDRM - Rev 2, 06/2014) the fuses size is
described in chapter 46.1.1 with:
"32-bit word restricted program and read to 4Kbits of eFuse OTP(512x8)."
In the TRM for the i.MX6SL (IMX6SLRM - Rev 2, 06/2015) the fuses size is
described in chapter 34.1.1 with:
"32-bit word restricted program and read to 2 kbit of eFuse OTP(128x8)."
Since the Freescale Linux kernel OCOTP driver works with a fuses size of
2 kbit for the i.MX6SL, it looks like the TRM is wrong and the formula
to calculate the correct fuses size has to be 256x8.
Signed-off-by: Daniel Schultz <d.schultz@phytec.de>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark Rutland [Tue, 3 Jan 2017 14:27:26 +0000 (14:27 +0000)]
arm64: mm: fix show_pte KERN_CONT fallout
[ Upstream commit
6ef4fb387d50fa8f3bffdffc868b57e981cdd709 ]
Recent changes made KERN_CONT mandatory for continued lines. In the
absence of KERN_CONT, a newline may be implicit inserted by the core
printk code.
In show_pte, we (erroneously) use printk without KERN_CONT for continued
prints, resulting in output being split across a number of lines, and
not matching the intended output, e.g.
[
ff000000000000] *pgd=
00000009f511b003
, *pud=
00000009f4a80003
, *pmd=
0000000000000000
Fix this by using pr_cont() for all the continuations.
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arvind Yadav [Tue, 3 Jan 2017 11:56:46 +0000 (17:26 +0530)]
vfio-pci: Handle error from pci_iomap
[ Upstream commit
e19f32da5ded958238eac1bbe001192acef191a2 ]
Here, pci_iomap can fail, handle this case release selected
pci regions and return -ENOMEM.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arvind Yadav [Tue, 13 Dec 2016 08:20:52 +0000 (13:50 +0530)]
video: fbdev: cobalt_lcdfb: Handle return NULL error from devm_ioremap
[ Upstream commit
4dcd19bfabaee8f9f4bcf203afba09b98ccbaf76 ]
Here, If devm_ioremap will fail. It will return NULL.
Kernel can run into a NULL-pointer dereference.
This error check will avoid NULL pointer dereference.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Acked-by: Yoichi Yuasa <yuasa@linux-mips.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arnaldo Carvalho de Melo [Tue, 3 Jan 2017 18:19:21 +0000 (15:19 -0300)]
perf symbols: Robustify reading of build-id from sysfs
[ Upstream commit
7934c98a6e04028eb34c1293bfb5a6b0ab630b66 ]
Markus reported that perf segfaults when reading /sys/kernel/notes from
a kernel linked with GNU gold, due to what looks like a gold bug, so do
some bounds checking to avoid crashing in that case.
Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Link: http://lkml.kernel.org/r/20161219161821.GA294@x4
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-ryhgs6a6jxvz207j2636w31c@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arnaldo Carvalho de Melo [Tue, 3 Jan 2017 15:03:59 +0000 (12:03 -0300)]
perf tools: Install tools/lib/traceevent plugins with install-bin
[ Upstream commit
30a9c6444810429aa2b7cbfbd453ce339baaadbf ]
Those are binaries as well, so should be installed by:
make -C tools/perf install-bin'
too.
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Daniel Bristot de Oliveira <bristot@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/n/tip-3841b37u05evxrs1igkyu6ks@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steffen Klassert [Tue, 14 Feb 2017 06:43:56 +0000 (07:43 +0100)]
xfrm: Don't use sk_family for socket policy lookups
commit
4c86d77743a54fb2d8a4d18a037a074c892bb3be upstream.
On IPv4-mapped IPv6 addresses sk_family is AF_INET6,
but the flow informations are created based on AF_INET.
So the routing set up 'struct flowi4' but we try to
access 'struct flowi6' what leads to an out of bounds
access. Fix this by using the family we get with the
dst_entry, like we do it for the standard policy lookup.
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Tested-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Bristot de Oliveira [Tue, 3 Jan 2017 11:42:42 +0000 (12:42 +0100)]
tools lib traceevent: Fix prev/next_prio for deadline tasks
[ Upstream commit
074859184d770824f4437dca716bdeb625ae8b1c ]
Currently, the sched:sched_switch tracepoint reports deadline tasks with
priority -1. But when reading the trace via perf script I've got the
following output:
# ./d & # (d is a deadline task, see [1])
# perf record -e sched:sched_switch -a sleep 1
# perf script
...
swapper 0 [000] 2146.962441: sched:sched_switch: swapper/0:0 [120] R ==> d:2593 [
4294967295]
d 2593 [000] 2146.972472: sched:sched_switch: d:2593 [
4294967295] R ==> g:2590 [
4294967295]
The task d reports the wrong priority [
4294967295]. This happens because
the "int prio" is stored in an unsigned long long val. Although it is
set as a %lld, as int is shorter than unsigned long long,
trace_seq_printf prints it as a positive number.
The fix is just to cast the val as an int, and print it as a %d,
as in the sched:sched_switch tracepoint's "format".
The output with the fix is:
# ./d &
# perf record -e sched:sched_switch -a sleep 1
# perf script
...
swapper 0 [000] 4306.374037: sched:sched_switch: swapper/0:0 [120] R ==> d:10941 [-1]
d 10941 [000] 4306.383823: sched:sched_switch: d:10941 [-1] R ==> swapper/0:0 [120]
[1] d.c
---
#include <stdio.h>
#include <unistd.h>
#include <sys/syscall.h>
#include <linux/types.h>
#include <linux/sched.h>
struct sched_attr {
__u32 size, sched_policy;
__u64 sched_flags;
__s32 sched_nice;
__u32 sched_priority;
__u64 sched_runtime, sched_deadline, sched_period;
};
int sched_setattr(pid_t pid, const struct sched_attr *attr, unsigned int flags)
{
return syscall(__NR_sched_setattr, pid, attr, flags);
}
int main(void)
{
struct sched_attr attr = {
.size = sizeof(attr),
.sched_policy = SCHED_DEADLINE, /* This creates a 10ms/30ms reservation */
.sched_runtime = 10 * 1000 * 1000,
.sched_period = attr.sched_deadline = 30 * 1000 * 1000,
};
if (sched_setattr(0, &attr, 0) < 0) {
perror("sched_setattr");
return -1;
}
for(;;);
}
---
Committer notes:
Got the program from the provided URL, http://bristot.me/lkml/d.c,
trimmed it and included in the cset log above, so that we have
everything needed to test it in one place.
Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Daniel Bristot de Oliveira <bristot@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/866ef75bcebf670ae91c6a96daa63597ba981f0d.1483443552.git.bristot@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Liu Bo [Fri, 23 Dec 2016 01:13:54 +0000 (17:13 -0800)]
Btrfs: adjust outstanding_extents counter properly when dio write is split
[ Upstream commit
c2931667c83ded6504b3857e99cc45b21fa496fb ]
Currently how btrfs dio deals with split dio write is not good
enough if dio write is split into several segments due to the
lack of contiguous space, a large dio write like 'dd bs=1G count=1'
can end up with incorrect outstanding_extents counter and endio
would complain loudly with an assertion.
This fixes the problem by compensating the outstanding_extents
counter in inode if a large dio write gets split.
Reported-by: Anand Jain <anand.jain@oracle.com>
Tested-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Lechner [Mon, 2 Jan 2017 23:28:39 +0000 (17:28 -0600)]
usb: gadget: Fix copy/pasted error message
[ Upstream commit
43aef5c2ca90535b3227e97e71604291875444ed ]
This fixes an error message that was probably copied and pasted. The same
message is used for both the in and out endpoints, so it makes it impossible
to know which one actually failed because both cases say "IN".
Make the out endpoint error message say "OUT".
Signed-off-by: David Lechner <david@lechnology.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rafael J. Wysocki [Fri, 30 Dec 2016 01:27:31 +0000 (02:27 +0100)]
ACPI / scan: Prefer devices without _HID/_CID for _ADR matching
[ Upstream commit
c2a6bbaf0c5f90463a7011a295bbdb7e33c80b51 ]
The way acpi_find_child_device() works currently is that, if there
are two (or more) devices with the same _ADR value in the same
namespace scope (which is not specifically allowed by the spec and
the OS behavior in that case is not defined), the first one of them
found to be present (with the help of _STA) will be returned.
This covers the majority of cases, but is not sufficient if some of
the devices in question have a _HID (or _CID) returning some valid
ACPI/PNP device IDs (which is disallowed by the spec) and the
ASL writers' expectation appears to be that the OS will match
devices without a valid ACPI/PNP device ID against a given bus
address first.
To cover this special case as well, modify find_child_checks()
to prefer devices without ACPI/PNP device IDs over devices that
have them.
Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Krzysztof Kozlowski [Thu, 29 Dec 2016 12:41:05 +0000 (14:41 +0200)]
ARM: s3c2410_defconfig: Fix invalid values for NF_CT_PROTO_*
[ Upstream commit
3ef01c968fbfb21c2f16281445d30a865ee4412c ]
NF_CT_PROTO_DCCP/SCTP/UDPLITE were switched from tristate to boolean so
defconfig needs to be adjusted to silence warnings:
warning: symbol value 'm' invalid for NF_CT_PROTO_DCCP
warning: symbol value 'm' invalid for NF_CT_PROTO_SCTP
warning: symbol value 'm' invalid for NF_CT_PROTO_UDPLITE
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Moritz Fischer [Thu, 22 Dec 2016 17:19:25 +0000 (09:19 -0800)]
ARM64: zynqmp: Fix i2c node's compatible string
[ Upstream commit
c415f9e8304a1d235ef118d912f374ee2e46c45d ]
The Zynq Ultrascale MP uses version 1.4 of the Cadence IP core
which fixes some silicon bugs that needed software workarounds
in Version 1.0 that was used on Zynq systems.
Signed-off-by: Moritz Fischer <mdf@kernel.org>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Sören Brinkmann <soren.brinkmann@xilinx.com>
Cc: Rob Herring <robh+dt@kernel.org>
Acked-by: Sören Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michal Simek [Tue, 15 Nov 2016 13:53:13 +0000 (14:53 +0100)]
ARM64: zynqmp: Fix W=1 dtc 1.4 warnings
[ Upstream commit
4ea2a6be9565455f152c12f80222af1582ede0c7 ]
The patch removes these warnings reported by dtc 1.4:
Warning (unit_address_vs_reg): Node /amba_apu has a reg or ranges
property, but no unit name
Warning (unit_address_vs_reg): Node /memory has a reg or ranges
property, but no unit name
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christophe JAILLET [Mon, 19 Dec 2016 05:33:51 +0000 (06:33 +0100)]
dmaengine: ti-dma-crossbar: Add some 'of_node_put()' in error path.
[ Upstream commit
75bdc7f31a3a6e9a12e218b31a44a1f54a91554c ]
Add some missing 'of_node_put()' in early exit error path.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Jiang [Tue, 13 Dec 2016 18:15:27 +0000 (11:15 -0700)]
dmaengine: ioatdma: workaround SKX ioatdma version
[ Upstream commit
34a31f0af84158955a9747fb5c6712da5bbb5331 ]
The Skylake ioatdma is technically CBDMA 3.2+ and contains the same hardware
bits with some additional 3.3 features, but it's not really 3.3 where the
driver is concerned.
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Jiang [Tue, 13 Dec 2016 18:15:21 +0000 (11:15 -0700)]
dmaengine: ioatdma: Add Skylake PCI Dev ID
[ Upstream commit
1594c18fd297a8edcc72bc4b161f3f52603ebb92 ]
Adding Skylake Xeon PCI device ids for ioatdma and related bits.
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stafford Horne [Wed, 14 Dec 2016 12:27:57 +0000 (21:27 +0900)]
openrisc: Add _text symbol to fix ksym build error
[ Upstream commit
086cc1c31a0ec075dac02425367c871bb65bc2c9 ]
The build robot reports:
.tmp_kallsyms1.o: In function `kallsyms_relative_base':
>> (.rodata+0x8a18): undefined reference to `_text'
This is when using 'make alldefconfig'. Adding this _text symbol to mark
the start of the kernel as in other architecture fixes this.
Signed-off-by: Stafford Horne <shorne@gmail.com>
Acked-by: Jonas Bonn <jonas@southpole.se>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stefan Wahren [Tue, 27 Dec 2016 18:29:57 +0000 (18:29 +0000)]
irqchip/mxs: Enable SKIP_SET_WAKE and MASK_ON_SUSPEND
[ Upstream commit
88e20c74ee020f9e0c99dfce0dd9aa61c3f0cca0 ]
The ICOLL controller doesn't provide any facility to configure the
wakeup sources. That's the reason why this implementation lacks
the irq_set_wake implementation. But this prevent us from properly
entering power management states like "suspend to idle".
So enable the flags IRQCHIP_SKIP_SET_WAKE and
IRQCHIP_MASK_ON_SUSPEND to let the irqchip core allows and handles
the power management.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Link: https://lkml.kernel.org/r/1482863397-11400-1-git-send-email-stefan.wahren@i2se.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
John Hsu [Tue, 20 Dec 2016 04:03:09 +0000 (12:03 +0800)]
ASoC: nau8825: fix invalid configuration in Pre-Scalar of FLL
[ Upstream commit
a1792cda51300e15b03549cccf0b09f3be82e697 ]
The clk_ref_div is not configured in the correct position of the
register. The patch fixes that clk_ref_div, Pre-Scalar, is assigned
the wrong value.
Signed-off-by: John Hsu <KCHSU0@nuvoton.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Phil Reid [Thu, 22 Dec 2016 09:18:12 +0000 (17:18 +0800)]
spi: dw: Make debugfs name unique between instances
[ Upstream commit
13288bdf4adbaa6bd1267f10044c1bc25d90ce7f ]
Some system have multiple dw devices. Currently the driver uses a
fixed name for the debugfs dir. Append dev name to the debugfs dir
name to make it unique.
Signed-off-by: Phil Reid <preid@electromag.com.au>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Ujfalusi [Fri, 23 Dec 2016 09:21:10 +0000 (11:21 +0200)]
ASoC: tlv320aic3x: Mark the RESET register as volatile
[ Upstream commit
63c3194b82530bd71fd49db84eb7ab656b8d404a ]
The RESET register only have one self clearing bit and it should not be
cached. If it is cached, when we sync the registers back to the chip we
will initiate a software reset as well, which is not desirable.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Strashko, Grygorii [Thu, 8 Dec 2016 23:33:10 +0000 (17:33 -0600)]
irqchip/keystone: Fix "scheduling while atomic" on rt
[ Upstream commit
2f884e6e688a0deb69e6c9552e51aef8b7e3f5f1 ]
The below call chain generates "scheduling while atomic" backtrace and
causes system crash when Keystone 2 IRQ chip driver is used with RT-kernel:
gic_handle_irq()
|-__handle_domain_irq()
|-generic_handle_irq()
|-keystone_irq_handler()
|-regmap_read()
|-regmap_lock_spinlock()
|-rt_spin_lock()
The reason is that Keystone driver dispatches IRQ using chained IRQ handler
and accesses I/O memory through syscon->regmap(mmio) which is implemented
as fast_io regmap and uses regular spinlocks for synchronization, but
spinlocks transformed to rt_mutexes on RT.
Hence, convert Keystone 2 IRQ driver to use generic irq handler instead of
chained IRQ handler. This way it will be compatible with RT kernel where it
will be forced thread IRQ handler while in non-RT kernel it still will be
executed in HW IRQ context.
Cc: Suman Anna <s-anna@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Tested-by: Suman Anna <s-anna@ti.com>
Link: https://lkml.kernel.org/r/20161208233310.10329-1-grygorii.strashko@ti.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arnd Bergmann [Fri, 30 Dec 2016 15:13:47 +0000 (08:13 -0700)]
vfio-pci: use 32-bit comparisons for register address for gcc-4.5
[ Upstream commit
45e869714489431625c569d21fc952428d761476 ]
Using ancient compilers (gcc-4.5 or older) on ARM, we get a link
failure with the vfio-pci driver:
ERROR: "__aeabi_lcmp" [drivers/vfio/pci/vfio-pci.ko] undefined!
The reason is that the compiler tries to do a comparison of
a 64-bit range. This changes it to convert to a 32-bit number
explicitly first, as newer compilers do for themselves.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jordan Crouse [Tue, 20 Dec 2016 15:54:31 +0000 (08:54 -0700)]
drm/msm: Verify that MSM_SUBMIT_BO_FLAGS are set
[ Upstream commit
a6cb3b864b21b7345f824a4faa12b723c8aaf099 ]
For every submission buffer object one of MSM_SUBMIT_BO_WRITE
and MSM_SUBMIT_BO_READ must be set (and nothing else). If we
allowed zero then the buffer object would never get queued to
be unreferenced.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jordan Crouse [Tue, 20 Dec 2016 15:54:29 +0000 (08:54 -0700)]
drm/msm: Ensure that the hardware write pointer is valid
[ Upstream commit
88b333b0ed790f9433ff542b163bf972953b74d3 ]
Currently the value written to CP_RB_WPTR is calculated on the fly as
(rb->next - rb->start). But as the code is designed rb->next is wrapped
before writing the commands so if a series of commands happened to
fit perfectly in the ringbuffer, rb->next would end up being equal to
rb->size / 4 and thus result in an out of bounds address to CP_RB_WPTR.
The easiest way to fix this is to mask WPTR when writing it to the
hardware; it makes the hardware happy and the rest of the ringbuffer
math appears to work and there isn't any point in upsetting anything.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
[squash in is_power_of_2() check]
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Leon Romanovsky [Thu, 29 Dec 2016 16:37:11 +0000 (18:37 +0200)]
net/mlx4: Remove BUG_ON from ICM allocation routine
[ Upstream commit
c1d5f8ff80ea84768f5fae1ca9d1abfbb5e6bbaa ]
This patch removes BUG_ON() macro from mlx4_alloc_icm_coherent()
by checking DMA address alignment in advance and performing proper
folding in case of error.
Fixes:
5b0bf5e25efe ("mlx4_core: Support ICM tables in coherent memory")
Reported-by: Ozgur Karatas <okaratas@member.fsf.org>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Zheng Li [Wed, 28 Dec 2016 15:23:46 +0000 (23:23 +0800)]
ipv6: Should use consistent conditional judgement for ip6 fragment between __ip6_append_data and ip6_finish_output
[ Upstream commit
e4c5e13aa45c23692e4acf56f0b3533f328199b2 ]
There is an inconsistent conditional judgement between __ip6_append_data
and ip6_finish_output functions, the variable length in __ip6_append_data
just include the length of application's payload and udp6 header, don't
include the length of ipv6 header, but in ip6_finish_output use
(skb->len > ip6_skb_dst_mtu(skb)) as judgement, and skb->len include the
length of ipv6 header.
That causes some particular application's udp6 payloads whose length are
between (MTU - IPv6 Header) and MTU were fragmented by ip6_fragment even
though the rst->dev support UFO feature.
Add the length of ipv6 header to length in __ip6_append_data to keep
consistent conditional judgement as ip6_finish_output for ip6 fragment.
Signed-off-by: Zheng Li <james.z.li@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pali Rohár [Wed, 14 Dec 2016 21:29:44 +0000 (22:29 +0100)]
ARM: dts: n900: Mark eMMC slot with no-sdio and no-sd flags
[ Upstream commit
4cf48f1d7520a4d325af58eded4d8090e1b40be7 ]
Trying to initialize eMMC slot as SDIO or SD cause failure in n900 port of
qemu. eMMC itself is not detected and is not working.
Real Nokia N900 harware does not have this problem. As eMMC is really not
SDIO or SD based such change is harmless and will fix support for qemu.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chun-Hao Lin [Tue, 27 Dec 2016 08:29:43 +0000 (16:29 +0800)]
r8169: add support for RTL8168 series add-on card.
[ Upstream commit
610c908773d30907c950ca3b2ee8ac4b2813537b ]
This chip is the same as RTL8168, but its device id is 0x8161.
Signed-off-by: Chun-Hao Lin <hau@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Gleixner [Mon, 26 Dec 2016 21:58:20 +0000 (22:58 +0100)]
x86/mce/AMD: Make the init code more robust
[ Upstream commit
0dad3a3014a0b9e72521ff44f17e0054f43dcdea ]
If mce_device_init() fails then the mce device pointer is NULL and the
AMD mce code happily dereferences it.
Add a sanity check.
Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stefan Berger [Mon, 29 Feb 2016 13:53:02 +0000 (08:53 -0500)]
tpm: Replace device number bitmap with IDR
commit
15516788e581eb32ec1c50e5f00aba3faf95d817 upstream.
Replace the device number bitmap with IDR. Extend the number of devices we
can create to 64k.
Since an IDR allows us to associate a pointer with an ID, we use this now
to rewrite tpm_chip_find_get() to simply look up the chip pointer by the
given device ID.
Protect the IDR calls with a mutex.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Reviewed-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jarkko Sakkinen [Tue, 20 Jun 2017 09:38:02 +0000 (11:38 +0200)]
tpm: fix a kernel memory leak in tpm-sysfs.c
commit
13b47cfcfc60495cde216eef4c01040d76174cbe upstream.
While cleaning up sysfs callback that prints EK we discovered a kernel
memory leak. This commit fixes the issue by zeroing the buffer used for
TPM command/response.
The leak happen when we use either tpm_vtpm_proxy, tpm_ibmvtpm or
xen-tpmfront.
Fixes:
0883743825e3 ("TPM: sysfs functions consolidation")
Reported-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Tested-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Juergen Gross [Thu, 18 May 2017 15:28:49 +0000 (17:28 +0200)]
xen/blkback: don't use xen_blkif_get() in xen-blkback kthread
commit
a24fa22ce22ae302b3bf8f7008896d52d5d57b8d upstream.
There is no need to use xen_blkif_get()/xen_blkif_put() in the kthread
of xen-blkback. Thread stopping is synchronous and using the blkif
reference counting in the kthread will avoid to ever let the reference
count drop to zero at the end of an I/O running concurrent to
disconnecting and multiple rings.
Setting ring->xenblkd to NULL after stopping the kthread isn't needed
as the kthread does this already.
Signed-off-by: Juergen Gross <jgross@suse.com>
Tested-by: Steven Haigh <netwiz@crc.id.au>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Juergen Gross [Thu, 18 May 2017 15:28:48 +0000 (17:28 +0200)]
xen/blkback: don't free be structure too early
commit
71df1d7ccad1c36f7321d6b3b48f2ea42681c363 upstream.
The be structure must not be freed when freeing the blkif structure
isn't done. Otherwise a use-after-free of be when unmapping the ring
used for communicating with the frontend will occur in case of a
late call of xenblk_disconnect() (e.g. due to an I/O still active
when trying to disconnect).
Signed-off-by: Juergen Gross <jgross@suse.com>
Tested-by: Steven Haigh <netwiz@crc.id.au>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wanpeng Li [Mon, 13 Jun 2016 10:32:45 +0000 (18:32 +0800)]
sched/cputime: Fix prev steal time accouting during CPU hotplug
commit
3d89e5478bf550a50c99e93adf659369798263b0 upstream.
Commit:
e9532e69b8d1 ("sched/cputime: Fix steal time accounting vs. CPU hotplug")
... set rq->prev_* to 0 after a CPU hotplug comes back, in order to
fix the case where (after CPU hotplug) steal time is smaller than
rq->prev_steal_time.
However, this should never happen. Steal time was only smaller because of the
KVM-specific bug fixed by the previous patch. Worse, the previous patch
triggers a bug on CPU hot-unplug/plug operation: because
rq->prev_steal_time is cleared, all of the CPU's past steal time will be
accounted again on hot-plug.
Since the root cause has been fixed, we can just revert commit
e9532e69b8d1.
Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: 'commit
e9532e69b8d1 ("sched/cputime: Fix steal time accounting vs. CPU hotplug")'
Link: http://lkml.kernel.org/r/1465813966-3116-3-git-send-email-wanpeng.li@hotmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Andres Oportus <andresoportus@google.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Fri, 3 Feb 2017 22:29:42 +0000 (14:29 -0800)]
net: skb_needs_check() accepts CHECKSUM_NONE for tx
commit
6e7bc478c9a006c701c14476ec9d389a484b4864 upstream.
My recent change missed fact that UFO would perform a complete
UDP checksum before segmenting in frags.
In this case skb->ip_summed is set to CHECKSUM_NONE.
We need to add this valid case to skb_needs_check()
Fixes:
b2504a5dbef3 ("net: reduce skb_warn_bad_offload() noise")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kees Cook [Mon, 6 Mar 2017 06:08:58 +0000 (22:08 -0800)]
pstore: Use dynamic spinlock initializer
commit
e9a330c4289f2ba1ca4bf98c2b430ab165a8931b upstream.
The per-prz spinlock should be using the dynamic initializer so that
lockdep can correctly track it. Without this, under lockdep, we get a
warning at boot that the lock is in non-static memory.
Fixes:
109704492ef6 ("pstore: Make spinlock per zone instead of global")
Fixes:
76d5692a5803 ("pstore: Correctly initialize spinlock and flags")
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kees Cook [Thu, 9 Feb 2017 23:43:44 +0000 (15:43 -0800)]
pstore: Correctly initialize spinlock and flags
commit
76d5692a58031696e282384cbd893832bc92bd76 upstream.
The ram backend wasn't always initializing its spinlock correctly. Since
it was coming from kzalloc memory, though, it was harmless on
architectures that initialize unlocked spinlocks to 0 (at least x86 and
ARM). This also fixes a possibly ignored flag setting too.
When running under CONFIG_DEBUG_SPINLOCK, the following Oops was visible:
[ 0.760836] persistent_ram: found existing buffer, size 29988, start 29988
[ 0.765112] persistent_ram: found existing buffer, size 30105, start 30105
[ 0.769435] persistent_ram: found existing buffer, size 118542, start 118542
[ 0.785960] persistent_ram: found existing buffer, size 0, start 0
[ 0.786098] persistent_ram: found existing buffer, size 0, start 0
[ 0.786131] pstore: using zlib compression
[ 0.790716] BUG: spinlock bad magic on CPU#0, swapper/0/1
[ 0.790729] lock: 0xffffffc0d1ca9bb0, .magic:
00000000, .owner: <none>/-1, .owner_cpu: 0
[ 0.790742] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc2+ #913
[ 0.790747] Hardware name: Google Kevin (DT)
[ 0.790750] Call trace:
[ 0.790768] [<
ffffff900808ae88>] dump_backtrace+0x0/0x2bc
[ 0.790780] [<
ffffff900808b164>] show_stack+0x20/0x28
[ 0.790794] [<
ffffff9008460ee0>] dump_stack+0xa4/0xcc
[ 0.790809] [<
ffffff9008113cfc>] spin_dump+0xe0/0xf0
[ 0.790821] [<
ffffff9008113d3c>] spin_bug+0x30/0x3c
[ 0.790834] [<
ffffff9008113e28>] do_raw_spin_lock+0x50/0x1b8
[ 0.790846] [<
ffffff9008a2d2ec>] _raw_spin_lock_irqsave+0x54/0x6c
[ 0.790862] [<
ffffff90083ac3b4>] buffer_size_add+0x48/0xcc
[ 0.790875] [<
ffffff90083acb34>] persistent_ram_write+0x60/0x11c
[ 0.790888] [<
ffffff90083aab1c>] ramoops_pstore_write_buf+0xd4/0x2a4
[ 0.790900] [<
ffffff90083a9d3c>] pstore_console_write+0xf0/0x134
[ 0.790912] [<
ffffff900811c304>] console_unlock+0x48c/0x5e8
[ 0.790923] [<
ffffff900811da18>] register_console+0x3b0/0x4d4
[ 0.790935] [<
ffffff90083aa7d0>] pstore_register+0x1a8/0x234
[ 0.790947] [<
ffffff90083ac250>] ramoops_probe+0x6b8/0x7d4
[ 0.790961] [<
ffffff90085ca548>] platform_drv_probe+0x7c/0xd0
[ 0.790972] [<
ffffff90085c76ac>] driver_probe_device+0x1b4/0x3bc
[ 0.790982] [<
ffffff90085c7ac8>] __device_attach_driver+0xc8/0xf4
[ 0.790996] [<
ffffff90085c4bfc>] bus_for_each_drv+0xb4/0xe4
[ 0.791006] [<
ffffff90085c7414>] __device_attach+0xd0/0x158
[ 0.791016] [<
ffffff90085c7b18>] device_initial_probe+0x24/0x30
[ 0.791026] [<
ffffff90085c648c>] bus_probe_device+0x50/0xe4
[ 0.791038] [<
ffffff90085c35b8>] device_add+0x3a4/0x76c
[ 0.791051] [<
ffffff90087d0e84>] of_device_add+0x74/0x84
[ 0.791062] [<
ffffff90087d19b8>] of_platform_device_create_pdata+0xc0/0x100
[ 0.791073] [<
ffffff90087d1a2c>] of_platform_device_create+0x34/0x40
[ 0.791086] [<
ffffff900903c910>] of_platform_default_populate_init+0x58/0x78
[ 0.791097] [<
ffffff90080831fc>] do_one_initcall+0x88/0x160
[ 0.791109] [<
ffffff90090010ac>] kernel_init_freeable+0x264/0x31c
[ 0.791123] [<
ffffff9008a25bd0>] kernel_init+0x18/0x11c
[ 0.791133] [<
ffffff9008082ec0>] ret_from_fork+0x10/0x50
[ 0.793717] console [pstore-1] enabled
[ 0.797845] pstore: Registered ramoops as persistent store backend
[ 0.804647] ramoops: attached 0x100000@0xf7edc000, ecc: 0/0
Fixes:
663deb47880f ("pstore: Allow prz to control need for locking")
Fixes:
109704492ef6 ("pstore: Make spinlock per zone instead of global")
Reported-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Joel Fernandes [Thu, 20 Oct 2016 07:34:01 +0000 (00:34 -0700)]
pstore: Allow prz to control need for locking
commit
663deb47880f2283809669563c5a52ac7c6aef1a upstream.
In preparation of not locking at all for certain buffers depending on if
there's contention, make locking optional depending on the initialization
of the prz.
Signed-off-by: Joel Fernandes <joelaf@google.com>
[kees: moved locking flag into prz instead of via caller arguments]
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mike Manning [Fri, 27 May 2016 16:45:07 +0000 (17:45 +0100)]
vlan: Propagate MAC address to VLANs
commit
308453aa9156a3b8ee382c0949befb507a32b0c1 upstream.
The MAC address of the physical interface is only copied to the VLAN
when it is first created, resulting in an inconsistency after MAC
address changes of only newly created VLANs having an up-to-date MAC.
The VLANs should continue inheriting the MAC address of the physical
interface until the VLAN MAC address is explicitly set to any value.
This allows IPv6 EUI64 addresses for the VLAN to reflect any changes
to the MAC of the physical interface and thus for DAD to behave as
expected.
Signed-off-by: Mike Manning <mmanning@brocade.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linus Torvalds [Thu, 14 Apr 2016 19:05:37 +0000 (12:05 -0700)]
/proc/iomem: only expose physical resource addresses to privileged users
commit
51d7b120418e99d6b3bf8df9eb3cc31e8171dee4 upstream.
In commit
c4004b02f8e5b ("x86: remove the kernel code/data/bss resources
from /proc/iomem") I was hoping to remove the phyiscal kernel address
data from /proc/iomem entirely, but that had to be reverted because some
system programs actually use it.
This limits all the detailed resource information to properly
credentialed users instead.
[sumits: this is used in Ubuntu as a fix for CVE-2015-8944]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linus Torvalds [Thu, 14 Apr 2016 18:22:00 +0000 (11:22 -0700)]
Make file credentials available to the seqfile interfaces
commit
34dbbcdbf63360661ff7bda6c5f52f99ac515f92 upstream.
A lot of seqfile users seem to be using things like %pK that uses the
credentials of the current process, but that is actually completely
wrong for filesystem interfaces.
The unix semantics for permission checking files is to check permissions
at _open_ time, not at read or write time, and that is not just a small
detail: passing off stdin/stdout/stderr to a suid application and making
the actual IO happen in privileged context is a classic exploit
technique.
So if we want to be able to look at permissions at read time, we need to
use the file open credentials, not the current ones. Normal file
accesses can just use "f_cred" (or any of the helper functions that do
that, like file_ns_capable()), but the seqfile interfaces do not have
any such options.
It turns out that seq_file _does_ save away the user_ns information of
the file, though. Since user_ns is just part of the full credential
information, replace that special case with saving off the cred pointer
instead, and suddenly seq_file has all the permission information it
needs.
[sumits: this is used in Ubuntu as a fix for CVE-2015-8944]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrzej Hajda [Thu, 5 Jan 2017 12:34:07 +0000 (10:34 -0200)]
v4l: s5c73m3: fix negation operator
commit
a2370ba2752538404e363346b339869c9973aeac upstream.
Bool values should be negated using logical operators. Using bitwise operators
results in unexpected and possibly incorrect results.
Reported-by: David Binderman <dcb314@hotmail.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Al Viro [Fri, 7 Jul 2017 18:51:19 +0000 (14:51 -0400)]
dentry name snapshots
commit
49d31c2f389acfe83417083e1208422b4091cd9e upstream.
take_dentry_name_snapshot() takes a safe snapshot of dentry name;
if the name is a short one, it gets copied into caller-supplied
structure, otherwise an extra reference to external name is grabbed
(those are never modified). In either case the pointer to stable
string is stored into the same structure.
dentry must be held by the caller of take_dentry_name_snapshot(),
but may be freely dropped afterwards - the snapshot will stay
until destroyed by release_dentry_name_snapshot().
Intended use:
struct name_snapshot s;
take_dentry_name_snapshot(&s, dentry);
...
access s.name
...
release_dentry_name_snapshot(&s);
Replaces fsnotify_oldname_...(), gets used in fsnotify to obtain the name
to pass down with event.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Valentin Vidic [Fri, 5 May 2017 19:07:33 +0000 (21:07 +0200)]
ipmi/watchdog: fix watchdog timeout set on reboot
commit
860f01e96981a68553f3ca49f574ff14fe955e72 upstream.
systemd by default starts watchdog on reboot and sets the timer to
ShutdownWatchdogSec=10min. Reboot handler in ipmi_watchdog than reduces
the timer to 120s which is not enough time to boot a Xen machine with
a lot of RAM. As a result the machine is rebooted the second time
during the long run of (XEN) Scrubbing Free RAM.....
Fix this by setting the timer to 120s only if it was previously
set to a low value.
Signed-off-by: Valentin Vidic <Valentin.Vidic@CARNet.hr>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vishal Verma [Thu, 29 Jun 2017 22:59:11 +0000 (16:59 -0600)]
libnvdimm, btt: fix btt_rw_page not returning errors
commit
c13c43d54f2c6a3be1c675766778ac1ad8dfbfcc upstream.
btt_rw_page was not propagating errors frm btt_do_bvec, resulting in any
IO errors via the rw_page path going unnoticed. the pmem driver recently
fixed this in
e10624f pmem: fail io-requests to known bad blocks
but same problem in BTT went neglected.
Fixes:
5212e11fde4d ("nd_btt: atomic sector updates")
Cc: Toshi Kani <toshi.kani@hpe.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ismail, Mustafa [Fri, 14 Jul 2017 14:41:30 +0000 (09:41 -0500)]
RDMA/uverbs: Fix the check for port number
commit
5a7a88f1b488e4ee49eb3d5b82612d4d9ffdf2c3 upstream.
The port number is only valid if IB_QP_PORT is set in the mask.
So only check port number if it is valid to prevent modify_qp from
failing due to an invalid port number.
Fixes:
5ecce4c9b17b("Check port number supplied by user verbs cmds")
Reviewed-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com>
Tested-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sudeep Holla [Fri, 14 Jul 2017 10:51:48 +0000 (11:51 +0100)]
PM / Domains: defer dev_pm_domain_set() until genpd->attach_dev succeeds if present
commit
975e83cfb8dc16e7a2fdc58188c77c0c605876c2 upstream.
If the genpd->attach_dev or genpd->power_on fails, genpd_dev_pm_attach
may return -EPROBE_DEFER initially. However genpd_alloc_dev_data sets
the PM domain for the device unconditionally.
When subsequent attempts are made to call genpd_dev_pm_attach, it may
return -EEXISTS checking dev->pm_domain without re-attempting to call
attach_dev or power_on.
platform_drv_probe then attempts to call drv->probe as the return value
-EEXIST != -EPROBE_DEFER, which may end up in a situation where the
device is accessed without it's power domain switched on.
Fixes:
f104e1e5ef57 (PM / Domains: Re-order initialization of generic_pm_domain_data)
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Konstantin Khlebnikov [Wed, 8 Feb 2017 11:27:27 +0000 (14:27 +0300)]
sched/cgroup: Move sched_online_group() back into css_online() to fix crash
commit
96b777452d8881480fd5be50112f791c17db4b6b upstream.
Commit:
2f5177f0fd7e ("sched/cgroup: Fix/cleanup cgroup teardown/init")
.. moved sched_online_group() from css_online() to css_alloc().
It exposes half-baked task group into global lists before initializing
generic cgroup stuff.
LTP testcase (third in cgroup_regression_test) written for testing
similar race in kernels 2.6.26-2.6.28 easily triggers this oops:
BUG: unable to handle kernel NULL pointer dereference at
0000000000000008
IP: kernfs_path_from_node_locked+0x260/0x320
CPU: 1 PID: 30346 Comm: cat Not tainted 4.10.0-rc5-test #4
Call Trace:
? kernfs_path_from_node+0x4f/0x60
kernfs_path_from_node+0x3e/0x60
print_rt_rq+0x44/0x2b0
print_rt_stats+0x7a/0xd0
print_cpu+0x2fc/0xe80
? __might_sleep+0x4a/0x80
sched_debug_show+0x17/0x30
seq_read+0xf2/0x3b0
proc_reg_read+0x42/0x70
__vfs_read+0x28/0x130
? security_file_permission+0x9b/0xc0
? rw_verify_area+0x4e/0xb0
vfs_read+0xa5/0x170
SyS_read+0x46/0xa0
entry_SYSCALL_64_fastpath+0x1e/0xad
Here the task group is already linked into the global RCU-protected 'task_groups'
list, but the css->cgroup pointer is still NULL.
This patch reverts this chunk and moves online back to css_online().
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes:
2f5177f0fd7e ("sched/cgroup: Fix/cleanup cgroup teardown/init")
Link: http://lkml.kernel.org/r/148655324740.424917.5302984537258726349.stgit@buzz
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oliver Neukum [Wed, 17 Aug 2016 13:51:56 +0000 (15:51 +0200)]
kaweth: fix oops upon failed memory allocation
commit
575ced7f8090c1a4e91e2daf8da9352a6a1fc7a7 upstream.
Just return an error upon failure.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oliver Neukum [Wed, 17 Aug 2016 13:51:55 +0000 (15:51 +0200)]
kaweth: fix firmware download
commit
60bcabd080f53561efa9288be45c128feda1a8bb upstream.
This fixes the oops discovered by the Umap2 project and Alan Stern.
The intf member needs to be set before the firmware is downloaded.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Calvin Owens [Fri, 18 Mar 2016 19:45:42 +0000 (12:45 -0700)]
mpt3sas: Don't overreach ioc->reply_post[] during initialization
commit
5ec8a1753bc29efa7e4b1391d691c9c719b30257 upstream.
In _base_make_ioc_operational(), we walk ioc->reply_queue_list and pull
a pointer out of successive elements of ioc->reply_post[] for each entry
in that list if RDPQ is enabled.
Since the code pulls the pointer for the next iteration at the bottom of
the loop, it triggers the a KASAN dump on the final iteration:
BUG: KASAN: slab-out-of-bounds in _base_make_ioc_operational+0x47b7/0x47e0 [mpt3sas] at addr
ffff880754816ab0
Read of size 8 by task modprobe/305
<snip>
Call Trace:
[<
ffffffff81dfc591>] dump_stack+0x4d/0x6c
[<
ffffffff814c9689>] print_trailer+0xf9/0x150
[<
ffffffff814ceda4>] object_err+0x34/0x40
[<
ffffffff814d1231>] kasan_report_error+0x221/0x530
[<
ffffffff814d1673>] __asan_report_load8_noabort+0x43/0x50
[<
ffffffffa0043637>] _base_make_ioc_operational+0x47b7/0x47e0 [mpt3sas]
[<
ffffffffa0049a51>] mpt3sas_base_attach+0x1991/0x2120 [mpt3sas]
[<
ffffffffa0053c93>] _scsih_probe+0xeb3/0x16b0 [mpt3sas]
[<
ffffffff81ebd047>] local_pci_probe+0xc7/0x170
[<
ffffffff81ebf2cf>] pci_device_probe+0x20f/0x290
[<
ffffffff820d50cd>] really_probe+0x17d/0x600
[<
ffffffff820d56a3>] __driver_attach+0x153/0x190
[<
ffffffff820cffac>] bus_for_each_dev+0x11c/0x1a0
[<
ffffffff820d421d>] driver_attach+0x3d/0x50
[<
ffffffff820d378a>] bus_add_driver+0x44a/0x5f0
[<
ffffffff820d666c>] driver_register+0x18c/0x3b0
[<
ffffffff81ebcb76>] __pci_register_driver+0x156/0x200
[<
ffffffffa00c8135>] _mpt3sas_init+0x135/0x1000 [mpt3sas]
[<
ffffffff81000423>] do_one_initcall+0x113/0x2b0
[<
ffffffff813caa5a>] do_init_module+0x1d0/0x4d8
[<
ffffffff81273909>] load_module+0x6729/0x8dc0
[<
ffffffff81276123>] SYSC_init_module+0x183/0x1a0
[<
ffffffff8127625e>] SyS_init_module+0xe/0x10
[<
ffffffff828fe7d7>] entry_SYSCALL_64_fastpath+0x12/0x6a
Fix this by pulling the value at the beginning of the loop.
Signed-off-by: Calvin Owens <calvinowens@fb.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Jens Axboe <axboe@fb.com>
Acked-by: Chaitra Basappa <chaitra.basappa@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sudeep Holla [Tue, 21 Mar 2017 11:30:16 +0000 (11:30 +0000)]
mailbox: handle empty message in tx_tick
commit
cb710ab1d8a23f68ff8f45aedf3e552bb90e70de upstream.
We already check if the message is empty before calling the client
tx_done callback. Calling completion on a wait event is also invalid
if the message is empty.
This patch moves the existing empty message check earlier.
Fixes:
2b6d83e2b8b7 ("mailbox: Introduce framework for mailbox")
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sudeep Holla [Tue, 21 Mar 2017 11:30:15 +0000 (11:30 +0000)]
mailbox: skip complete wait event if timer expired
commit
cc6eeaa3029a6dbcb4ad41b1f92876483bd88965 upstream.
If a wait_for_completion_timeout() call returns due to a timeout,
complete() can get called after returning from the wait which is
incorrect and can cause subsequent transmissions on a channel to fail.
Since the wait_for_completion_timeout() sees the completion variable
is non-zero caused by the erroneous/spurious complete() call, and
it immediately returns without waiting for the time as expected by the
client.
This patch fixes the issue by skipping complete() call for the timer
expiry.
Fixes:
2b6d83e2b8b7 ("mailbox: Introduce framework for mailbox")
Reported-by: Alexey Klimov <alexey.klimov@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sudeep Holla [Tue, 21 Mar 2017 11:30:14 +0000 (11:30 +0000)]
mailbox: always wait in mbox_send_message for blocking Tx mode
commit
c61b781ee084e69855477d23dd33e7e6caad652c upstream.
There exists a race when msg_submit return immediately as there was an
active request being processed which may have completed just before it's
checked again in mbox_send_message. This will result in return to the
caller without waiting in mbox_send_message even when it's blocking Tx.
This patch fixes the issue by waiting for the completion always if Tx
is in blocking mode.
Fixes:
2b6d83e2b8b7 ("mailbox: Introduce framework for mailbox")
Reported-by: Alexey Klimov <alexey.klimov@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Reviewed-by: Alexey Klimov <alexey.klimov@arm.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lior David [Wed, 23 Nov 2016 14:06:41 +0000 (16:06 +0200)]
wil6210: fix deadlock when using fw_no_recovery option
commit
dfb5b098e0f40b68aa07f2ec55f4dd762efefbfa upstream.
When FW crashes with no_fw_recovery option, driver
waits for manual recovery with wil->mutex held, this
can easily create deadlocks.
Fix the problem by moving the wait outside the lock.
Signed-off-by: Lior David <qca_liord@qca.qualcomm.com>
Signed-off-by: Maya Erez <qca_merez@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michal Kazior [Mon, 14 Nov 2016 13:25:23 +0000 (14:25 +0100)]
ath10k: fix null deref on wmi-tlv when trying spectral scan
commit
18ae68fff392e445af3c2d8be9bef8a16e1c72a7 upstream.
WMI ops wrappers did not properly check for null
function pointers for spectral scan. This caused
null dereference crash with WMI-TLV based firmware
which doesn't implement spectral scan.
The crash could be triggered with:
ip link set dev wlan0 up
echo background > /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan_ctl
The crash looked like this:
[ 168.031989] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 168.037406] IP: [< (null)>] (null)
[ 168.040395] PGD
cdd4067 PUD
fa0f067 PMD 0
[ 168.043303] Oops: 0010 [#1] SMP
[ 168.045377] Modules linked in: ath10k_pci(O) ath10k_core(O) ath mac80211 cfg80211 [last unloaded: cfg80211]
[ 168.051560] CPU: 1 PID: 1380 Comm: bash Tainted: G W O 4.8.0 #78
[ 168.054336] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[ 168.059183] task:
ffff88000c460c00 task.stack:
ffff88000d4bc000
[ 168.061736] RIP: 0010:[<
0000000000000000>] [< (null)>] (null)
...
[ 168.100620] Call Trace:
[ 168.101910] [<
ffffffffa03b9566>] ? ath10k_spectral_scan_config+0x96/0x200 [ath10k_core]
[ 168.104871] [<
ffffffff811386e2>] ? filemap_fault+0xb2/0x4a0
[ 168.106696] [<
ffffffffa03b97e6>] write_file_spec_scan_ctl+0x116/0x280 [ath10k_core]
[ 168.109618] [<
ffffffff812da3a1>] full_proxy_write+0x51/0x80
[ 168.111443] [<
ffffffff811957b8>] __vfs_write+0x28/0x120
[ 168.113090] [<
ffffffff812f1a2d>] ? security_file_permission+0x3d/0xc0
[ 168.114932] [<
ffffffff8109b912>] ? percpu_down_read+0x12/0x60
[ 168.116680] [<
ffffffff811965f8>] vfs_write+0xb8/0x1a0
[ 168.118293] [<
ffffffff81197966>] SyS_write+0x46/0xa0
[ 168.119912] [<
ffffffff818f2972>] entry_SYSCALL_64_fastpath+0x1a/0xa4
[ 168.121737] Code: Bad RIP value.
[ 168.123318] RIP [< (null)>] (null)
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Annie Cherkaev [Sat, 15 Jul 2017 21:08:58 +0000 (15:08 -0600)]
isdn/i4l: fix buffer overflow
commit
9f5af546e6acc30f075828cb58c7f09665033967 upstream.
This fixes a potential buffer overflow in isdn_net.c caused by an
unbounded strcpy.
[ ISDN seems to be effectively unmaintained, and the I4L driver in
particular is long deprecated, but in case somebody uses this..
- Linus ]
Signed-off-by: Jiten Thakkar <jitenmt@gmail.com>
Signed-off-by: Annie Cherkaev <annie.cherk@gmail.com>
Cc: Karsten Keil <isdn@linux-pingi.de>
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jia-Ju Bai [Wed, 31 May 2017 01:40:11 +0000 (09:40 +0800)]
isdn: Fix a sleep-in-atomic bug
commit
e8f4ae85439f34bec3b0ab69223a41809dab28c9 upstream.
The driver may sleep under a spin lock, the function call path is:
isdn_ppp_mp_receive (acquire the lock)
isdn_ppp_mp_reassembly
isdn_ppp_push_higher
isdn_ppp_decompress
isdn_ppp_ccp_reset_trans
isdn_ppp_ccp_reset_alloc_state
kzalloc(GFP_KERNEL) --> may sleep
To fixed it, the "GFP_KERNEL" is replaced with "GFP_ATOMIC".
Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Fainelli [Sun, 5 Mar 2017 20:34:49 +0000 (12:34 -0800)]
net: phy: Do not perform software reset for Generic PHY
commit
0878fff1f42c18e448ab5b8b4f6a3eb32365b5b6 upstream.
The Generic PHY driver is a catch-all PHY driver and it should preserve
whatever prior initialization has been done by boot loader or firmware
agents. For specific PHY device configuration it is expected that a
specialized PHY driver would take over that role.
Resetting the generic PHY was a bad idea that has lead to several
complaints and downstream workarounds e.g: in OpenWrt/LEDE so restore
the behavior prior to
87aa9f9c61ad ("net: phy: consolidate PHY
reset in phy_init_hw()").
Reported-by: Felix Fietkau <nbd@nbd.name>
Fixes:
87aa9f9c61ad ("net: phy: consolidate PHY reset in phy_init_hw()")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sudip Mukherjee [Tue, 20 Dec 2016 21:09:04 +0000 (21:09 +0000)]
nfc: fdp: fix NULL pointer dereference
commit
b6355fb3f5f40bbce165847d277e64896cab8f95 upstream.
We are checking phy after dereferencing it. We can print the debug
information after checking it. If phy is NULL then we will get a good
stack trace to tell us that we are in this irq handler.
Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Brian Foster [Tue, 8 Nov 2016 01:54:14 +0000 (12:54 +1100)]
xfs: don't BUG() on mixed direct and mapped I/O
commit
04197b341f23b908193308b8d63d17ff23232598 upstream.
We've had reports of generic/095 causing XFS to BUG() in
__xfs_get_blocks() due to the existence of delalloc blocks on a
direct I/O read. generic/095 issues a mix of various types of I/O,
including direct and memory mapped I/O to a single file. This is
clearly not supported behavior and is known to lead to such
problems. E.g., the lack of exclusion between the direct I/O and
write fault paths means that a write fault can allocate delalloc
blocks in a region of a file that was previously a hole after the
direct read has attempted to flush/inval the file range, but before
it actually reads the block mapping. In turn, the direct read
discovers a delalloc extent and cannot proceed.
While the appropriate solution here is to not mix direct and memory
mapped I/O to the same regions of the same file, the current
BUG_ON() behavior is probably overkill as it can crash the entire
system. Instead, localize the failure to the I/O in question by
returning an error for a direct I/O that cannot be handled safely
due to delalloc blocks. Be careful to allow the case of a direct
write to post-eof delalloc blocks. This can occur due to speculative
preallocation and is safe as post-eof blocks are not accompanied by
dirty pages in pagecache (conversely, preallocation within eof must
have been zeroed, and thus dirtied, before the inode size could have
been increased beyond said blocks).
Finally, provide an additional warning if a direct I/O write occurs
while the file is memory mapped. This may not catch all problematic
scenarios, but provides a hint that some known-to-be-problematic I/O
methods are in use.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Acked-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Adrian Hunter [Fri, 26 May 2017 08:17:07 +0000 (11:17 +0300)]
perf intel-pt: Ensure never to set 'last_ip' when packet 'count' is zero
commit
f952eaceb089b691eba7c4e13686e742a8f26bf5 upstream.
Intel PT uses IP compression based on the last IP. For decoding purposes,
'last IP' is not updated when a branch target has been suppressed, which is
indicated by IPBytes == 0. IPBytes is stored in the packet 'count', so
ensure never to set 'last_ip' when packet 'count' is zero.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Link: http://lkml.kernel.org/r/1495786658-18063-7-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Adrian Hunter [Fri, 26 May 2017 08:17:08 +0000 (11:17 +0300)]
perf intel-pt: Use FUP always when scanning for an IP
commit
622b7a47b843c78626f40c1d1aeef8483383fba2 upstream.
The decoder will try to use branch packets to find an IP to start decoding
or to recover from errors. Currently the FUP packet is used only in the
case of an overflow, however there is no reason for that to be a special
case. So just use FUP always when scanning for an IP.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Link: http://lkml.kernel.org/r/1495786658-18063-8-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Adrian Hunter [Fri, 26 May 2017 08:17:06 +0000 (11:17 +0300)]
perf intel-pt: Fix last_ip usage
commit
ee14ac0ef6827cd6f9a572cc83dd0191ea17812c upstream.
Intel PT uses IP compression based on the last IP. For decoding
purposes, 'last IP' is considered to be reset to zero whenever there is
a synchronization packet (PSB). The decoder wasn't doing that, and was
treating the zero value to mean that there was no last IP, whereas
compression can be done against the zero value. Fix by setting last_ip
to zero when a PSB is received and keep track of have_last_ip.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Link: http://lkml.kernel.org/r/1495786658-18063-6-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Adrian Hunter [Wed, 20 Jul 2016 09:00:06 +0000 (12:00 +0300)]
perf intel-pt: Fix ip compression
commit
e1717e0485af4f47fc4da1e979ac817f9ad61b0f upstream.
The June 2015 Intel SDM introduced IP Compression types 4 and 6. Refer
to section 36.4.2.2 Target IP (TIP) Packet - IP Compression.
Existing Intel PT packet decoder did not support type 4, and got type 6
wrong. Because type 3 and type 4 have the same number of bytes, the
packet 'count' has been changed from being the number of ip bytes to
being the type code. That allows the Intel PT decoder to correctly
decide whether to sign-extend or use the last ip. However that also
meant the code had to be adjusted in a number of places.
Currently hardware is not using the new compression types, so this fix
has no effect on existing hardware.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Link: http://lkml.kernel.org/r/1469005206-3049-1-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Laurent Pinchart [Tue, 18 Oct 2016 21:51:35 +0000 (00:51 +0300)]
drm: rcar-du: Simplify and fix probe error handling
commit
4f7b0d263833928e947e172eff2d2997179c5cb9 upstream.
It isn't safe to call drm_dev_unregister() without first initializing
mode setting with drm_mode_config_init(). This leads to a crash if
either IO memory can't be remapped or vblank initialization fails.
Fix this by reordering the initialization sequence. Move vblank
initialization after the drm_mode_config_init() call, and move IO
remapping before drm_dev_alloc() to avoid the need to perform clean up
in case of failure.
While at it remove the explicit drm_vblank_cleanup() call from
rcar_du_remove() as the drm_dev_unregister() function already cleans up
vblank.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: thongsyho <thong.ho.px@rvc.renesas.com>
Signed-off-by: Nhan Nguyen <nhan.nguyen.yb@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Laurent Pinchart [Mon, 28 Sep 2015 15:39:53 +0000 (18:39 +0300)]
drm: rcar-du: Perform initialization/cleanup at probe/remove time
commit
c1d4b38c93069dca6b419a3b88907e01e2c3abf7 upstream.
The drm driver .load() operation is prone to race conditions as it
initializes the driver after registering the device nodes. Its usage is
deprecated, inline it in the probe function and call drm_dev_alloc() and
drm_dev_register() explicitly.
For consistency inline the .unload() handler in the remove function as
well.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thong Ho <thong.ho.px@rvc.renesas.com>
Signed-off-by: Nhan Nguyen <nhan.nguyen.yb@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Vetter [Mon, 25 Jan 2016 21:16:51 +0000 (22:16 +0100)]
drm/rcar: Nuke preclose hook
commit
0a346629f5304a8390004a91e8d4f1206b87792b upstream.
Again since the drm core takes care of event unlinking/disarming this
is now just needless code.
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453756616-28942-10-git-send-email-daniel.vetter@ffwll.ch
Signed-off-by: Nhan Nguyen <nhan.nguyen.yb@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cheah Kok Cheong [Fri, 30 Dec 2016 11:25:52 +0000 (19:25 +0800)]
Staging: comedi: comedi_fops: Avoid orphaned proc entry
commit
bf279ece37d2a3eaaa9813fcd7a1d8a81eb29c20 upstream.
Move comedi_proc_init to the end to avoid orphaned proc entry
if module loading failed.
Signed-off-by: Cheah Kok Cheong <thrust73@gmail.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Thu, 3 Aug 2017 19:26:04 +0000 (12:26 -0700)]
Revert "powerpc/numa: Fix percpu allocations to be NUMA aware"
This reverts commit
8c92870bdbf20b5fa5150a2c8bf53ab498516b24 which is
commit
ba4a648f12f4cd0a8003dd229b6ca8a53348ee4b upstream.
Michal Hocko writes:
JFYI. We have encountered a regression after applying this patch on a
large ppc machine. While the patch is the right thing to do it doesn't
work well with the current vmalloc area size on ppc and large machines
where NUMA nodes are very far from each other. Just for the reference
the boot fails on such a machine with bunch of warning preceeding it.
See http://lkml.kernel.org/r/
20170724134240.GL25221@dhcp22.suse.cz
It seems the right thing to do is to enlarge the vmalloc space on ppc
but this is not the case in the upstream kernel yet AFAIK. It is also
questionable whether that is a stable material but I will decision on
you here.
We have reverted this patch from our 4.4 based kernel.
Newer kernels do not have enlarged vmalloc space yet AFAIK so they won't
work properly eiter. This bug is quite rare though because you need a
specific HW configuration to trigger the issue - namely NUMA nodes have
to be far away from each other in the physical memory space.
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paul Mackerras [Fri, 16 Jun 2017 01:53:19 +0000 (11:53 +1000)]
KVM: PPC: Book3S HV: Save/restore host values of debug registers
commit
7ceaa6dcd8c6f59588428cec37f3c8093dd1011f upstream.
At present, HV KVM on POWER8 and POWER9 machines loses any instruction
or data breakpoint set in the host whenever a guest is run.
Instruction breakpoints are currently only used by xmon, but ptrace
and the perf_event subsystem can set data breakpoints as well as xmon.
To fix this, we save the host values of the debug registers (CIABR,
DAWR and DAWRX) before entering the guest and restore them on exit.
To provide space to save them in the stack frame, we expand the stack
frame allocated by kvmppc_hv_entry() from 112 to 144 bytes.
[paulus@ozlabs.org - Adjusted stack offsets since we aren't saving
POWER9-specific registers.]
Fixes:
b005255e12a3 ("KVM: PPC: Book3S HV: Context-switch new POWER8 SPRs", 2014-01-08)
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paul Mackerras [Mon, 31 Jul 2017 00:43:37 +0000 (10:43 +1000)]
KVM: PPC: Book3S HV: Reload HTM registers explicitly
Commit
46a704f8409f ("KVM: PPC: Book3S HV: Preserve userspace HTM
state properly", 2017-06-15) added code which assumes that the kernel
is able to handle a TM (transactional memory) unavailable interrupt
from userspace by reloading the TM-related registers and enabling TM
for the process. That ability was added in the 4.9 kernel; earlier
kernel versions simply panic on getting the TM unavailable interrupt.
Since commit
46a704f8409f has been backported to the 4.4 stable tree
as commit
824b9506e4f2, 4.4.75 and subsequent versions are vulnerable
to a userspace-triggerable panic.
This patch fixes the problem by explicitly reloading the TM-related
registers before returning to userspace, rather than disabling TM
for the process.
Commit
46a704f8409f also failed to enable TM for the kernel, leading
to a TM unavailable interrupt in the kernel, causing an oops. This
fixes that problem too, by enabling TM before accessing the TM
registers. That problem is fixed upstream by the patch "KVM: PPC:
Book3S HV: Enable TM before accessing TM registers".
Fixes:
824b9506e4f2 ("KVM: PPC: Book3S HV: Preserve userspace HTM state properly")
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paul Mackerras [Thu, 15 Jun 2017 05:43:17 +0000 (15:43 +1000)]
KVM: PPC: Book3S HV: Restore critical SPRs to host values on guest exit
commit
4c3bb4ccd074e1a0552078c0bf94c662367a1658 upstream.
This restores several special-purpose registers (SPRs) to sane values
on guest exit that were missed before.
TAR and VRSAVE are readable and writable by userspace, and we need to
save and restore them to prevent the guest from potentially affecting
userspace execution (not that TAR or VRSAVE are used by any known
program that run uses the KVM_RUN ioctl). We save/restore these
in kvmppc_vcpu_run_hv() rather than on every guest entry/exit.
FSCR affects userspace execution in that it can prohibit access to
certain facilities by userspace. We restore it to the normal value
for the task on exit from the KVM_RUN ioctl.
IAMR is normally 0, and is restored to 0 on guest exit. However,
with a radix host on POWER9, it is set to a value that prevents the
kernel from executing user-accessible memory. On POWER9, we save
IAMR on guest entry and restore it on guest exit to the saved value
rather than 0. On POWER8 we continue to set it to 0 on guest exit.
PSPB is normally 0. We restore it to 0 on guest exit to prevent
userspace taking advantage of the guest having set it non-zero
(which would allow userspace to set its SMT priority to high).
UAMOR is normally 0. We restore it to 0 on guest exit to prevent
the AMR from being used as a covert channel between userspace
processes, since the AMR is not context-switched at present.
[paulus@ozlabs.org - removed IAMR bits that are only needed on POWER9;
adjusted FSCR save/restore for lack of fscr field in thread_struct.]
Fixes:
b005255e12a3 ("KVM: PPC: Book3S HV: Context-switch new POWER8 SPRs", 2014-01-08)
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paul Mackerras [Tue, 6 Jun 2017 06:47:22 +0000 (16:47 +1000)]
KVM: PPC: Book3S HV: Context-switch EBB registers properly
commit
ca8efa1df1d15a1795a2da57f9f6aada6ed6b946 upstream.
This adds code to save the values of three SPRs (special-purpose
registers) used by userspace to control event-based branches (EBBs),
which are essentially interrupts that get delivered directly to
userspace. These registers are loaded up with guest values when
entering the guest, and their values are saved when exiting the
guest, but we were not saving the host values and restoring them
before going back to userspace.
On POWER8 this would only affect userspace programs which explicitly
request the use of EBBs and also use the KVM_RUN ioctl, since the
only source of EBBs on POWER8 is the PMU, and there is an explicit
enable bit in the PMU registers (and those PMU registers do get
properly context-switched between host and guest). On POWER9 there
is provision for externally-generated EBBs, and these are not subject
to the control in the PMU registers.
Since these registers only affect userspace, we can save them when
we first come in from userspace and restore them before returning to
userspace, rather than saving/restoring the host values on every
guest entry/exit. Similarly, we don't need to worry about their
values on offline secondary threads since they execute in the context
of the idle task, which never executes in userspace.
Fixes:
b005255e12a3 ("KVM: PPC: Book3S HV: Context-switch new POWER8 SPRs", 2014-01-08)
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ben Skeggs [Tue, 25 Jul 2017 01:06:47 +0000 (11:06 +1000)]
drm/nouveau/bar/gf100: fix access to upper half of BAR2
commit
38bcb208f60924a031b9f809f7cd252ea4a94e5f upstream.
Bit 30 being set causes the upper half of BAR2 to stay in physical mode,
mapped over the end of VRAM, even when the rest of the BAR has been set
to virtual mode.
We inherited our initial value from RM, but I'm not aware of any reason
we need to keep it that way.
This fixes severe GPU hang/lockup issues revealed by Wayland on F26.
Shout-out to NVIDIA for the quick response with the potential cause!
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sinclair Yeh [Tue, 18 Jul 2017 06:28:36 +0000 (23:28 -0700)]
drm/vmwgfx: Fix gcc-7.1.1 warning
commit
fcfffdd8f98ac305285dca568b5065ef86be6458 upstream.
The current code does not look correct, and the reason for it is
probably lost. Since this now generates a compiler warning,
fix it to what makes sense.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>