aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2017-04-11drm/i915: Don't call synchronize_rcu_expedited under struct_mutexJoonas Lahtinen1-10/+16
Only call synchronize_rcu_expedited after unlocking struct_mutex to avoid deadlock because the workqueues depend on struct_mutex. >From original patch by Andrea: synchronize_rcu/synchronize_sched/synchronize_rcu_expedited() will hang until its own workqueues are run. The i915 gem workqueues will wait on the struct_mutex to be released. So we cannot wait for a quiescent state using those rcu primitives while holding the struct_mutex or it creates a circular lock dependency resulting in kernel hangs (which is reproducible but goes undetected by lockdep). kswapd0 D 0 700 2 0x00000000 Call Trace: ? __schedule+0x1a5/0x660 ? schedule+0x36/0x80 ? _synchronize_rcu_expedited.constprop.65+0x2ef/0x300 ? wake_up_bit+0x20/0x20 ? rcu_stall_kick_kthreads.part.54+0xc0/0xc0 ? rcu_exp_wait_wake+0x530/0x530 ? i915_gem_shrink+0x34b/0x4b0 ? i915_gem_shrinker_scan+0x7c/0x90 ? i915_gem_shrinker_scan+0x7c/0x90 ? shrink_slab.part.61.constprop.72+0x1c1/0x3a0 ? shrink_zone+0x154/0x160 ? kswapd+0x40a/0x720 ? kthread+0xf4/0x130 ? try_to_free_pages+0x450/0x450 ? kthread_create_on_node+0x40/0x40 ? ret_from_fork+0x23/0x30 plasmashell D 0 4657 4614 0x00000000 Call Trace: ? __schedule+0x1a5/0x660 ? schedule+0x36/0x80 ? schedule_preempt_disabled+0xe/0x10 ? __mutex_lock.isra.4+0x1c9/0x790 ? i915_gem_close_object+0x26/0xc0 ? i915_gem_close_object+0x26/0xc0 ? drm_gem_object_release_handle+0x48/0x90 ? drm_gem_handle_delete+0x50/0x80 ? drm_ioctl+0x1fa/0x420 ? drm_gem_handle_create+0x40/0x40 ? pipe_write+0x391/0x410 ? __vfs_write+0xc6/0x120 ? do_vfs_ioctl+0x8b/0x5d0 ? SyS_ioctl+0x3b/0x70 ? entry_SYSCALL_64_fastpath+0x13/0x94 kworker/0:0 D 0 29186 2 0x00000000 Workqueue: events __i915_gem_free_work Call Trace: ? __schedule+0x1a5/0x660 ? schedule+0x36/0x80 ? schedule_preempt_disabled+0xe/0x10 ? __mutex_lock.isra.4+0x1c9/0x790 ? del_timer_sync+0x44/0x50 ? update_curr+0x57/0x110 ? __i915_gem_free_objects+0x31/0x300 ? __i915_gem_free_objects+0x31/0x300 ? __i915_gem_free_work+0x2d/0x40 ? process_one_work+0x13a/0x3b0 ? worker_thread+0x4a/0x460 ? kthread+0xf4/0x130 ? process_one_work+0x3b0/0x3b0 ? kthread_create_on_node+0x40/0x40 ? ret_from_fork+0x23/0x30 Fixes: 3d3d18f086cd ("drm/i915: Avoid rcu_barrier() from reclaim paths (shrinker)") Reported-by: Andrea Arcangeli <[email protected]> Signed-off-by: Joonas Lahtinen <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Jani Nikula <[email protected]> Reviewed-by: Chris Wilson <[email protected]> (cherry picked from commit 8f612d055183545070ca1009ac2eb1f2e044cc20) Signed-off-by: Jani Nikula <[email protected]>
2017-04-11drm/i915: Suspend GuC prior to GPU Reset during GEM suspendSagar Arun Kamble2-2/+2
i915 is currently doing a full GPU reset at the end of i915_gem_suspend() followed by GuC suspend in i915_drm_suspend(). This GPU reset clobbers the GuC, causing the suspend request to then fail, leaving the GuC in an undefined state. We need to tell the GuC to suspend before we do the direct intel_gpu_reset(). v2: Commit message update. (Chris, Daniele) Fixes: 1c777c5d1dcd ("drm/i915/hsw: Fix GPU hang during resume from S3-devices state") Cc: Jeff McGee <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Imre Deak <[email protected]> Cc: Mika Kuoppala <[email protected]> Signed-off-by: Sagar Arun Kamble <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Daniele Ceraolo Spurio <[email protected]> Acked-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> (cherry picked from commit fd08923384385400101c71ac0d21d37d6b23b00d) Signed-off-by: Jani Nikula <[email protected]>
2017-04-11Merge tag 'gvt-fixes-2017-04-07' of https://github.com/01org/gvt-linux into ↵Jani Nikula1-1/+2
drm-intel-fixes gvt-fixes-2017-04-07 - execlist csb initial read ptr fix (Min) Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-04-11Revert "HID: rmi: Handle all Synaptics touchpads using hid-rmi"Jiri Kosina1-2/+1
This reverts commit 279967a65b320d174a507498aea7d44db3fee7f4. Multiple regressions [1] [2] [3] have been reported. The hid-rmi support would have to fixed and redone in 4.11+. [1] http://lkml.kernel.org/r/[email protected] [2] http://lkml.kernel.org/r/[email protected] [3] https://bugzilla.kernel.org/show_bug.cgi?id=195287 Reported-by: Cameron Gutman <[email protected]> Reported-by: Gabriele Mazzotta <[email protected]> Reported-by: Lorenzo J. Lucchini <[email protected]> Reported-by: Thorsten Leemhuis <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2017-04-11pinctrl: cherryview: Add a quirk to make Acer Chromebook keyboard work againMika Westerberg1-2/+24
After commit 47c950d10202 ("pinctrl: cherryview: Do not add all southwest and north GPIOs to IRQ domain") the driver does not add all GPIOs to the irqdomain. The reason for that is that those GPIOs cannot generate IRQs at all, only GPEs (General Purpose Events). This causes Linux virtual IRQ numbering to change. However, it seems some CYAN Chromebooks, including Acer Chromebook hardcodes these Linux IRQ numbers in the ACPI tables of the machine. Since the numbering is different now, the IRQ meant for keyboard does not match the Linux virtual IRQ number anymore making the keyboard non-functional. Work this around by adding special quirk just for these machines where we add back all GPIOs to the irqdomain. Rest of the Cherryview/Braswell based machines will not be affected by the change. Link: https://bugzilla.kernel.org/show_bug.cgi?id=194945 Fixes: 47c950d10202 ("pinctrl: cherryview: Do not add all southwest and north GPIOs to IRQ domain") Reported-by: Adam S Levy <[email protected]> Signed-off-by: Mika Westerberg <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2017-04-11x86/intel_rdt: Fix locking in rdtgroup_schemata_write()Jiri Olsa1-1/+1
The schemata lock is released before freeing the resource's temporary tmp_cbms allocation. That's racy versus another write which allocates and uses new temporary storage, resulting in memory leaks, freeing in use memory, double a free or any combination of those. Move the unlock after the release code. Fixes: 60ec2440c63d ("x86/intel_rdt: Add schemata file") Signed-off-by: Jiri Olsa <[email protected]> Cc: Fenghua Yu <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Mike Galbraith <[email protected]> Cc: Shaohua Li <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2017-04-11x86/debug: Fix the printk() debug output of signal_fault(), do_trap() and ↵Markus Trippelsdorf2-3/+3
do_general_protection() Since commit: 4bcc595ccd80 "printk: reinstate KERN_CONT for printing" ... the debug output of signal_fault(), do_trap() and do_general_protection() looks garbled, e.g.: traps: conftest[9335] trap invalid opcode ip:400428 sp:7ffeaba1b0d8 error:0 in conftest[400000+1000] (note the unintended line break.) Fix the bug by adding KERN_CONTs. Signed-off-by: Markus Trippelsdorf <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Signed-off-by: Ingo Molnar <[email protected]>
2017-04-10CIFS: store results of cifs_reopen_file to avoid infinite waitGermano Percossi1-3/+3
This fixes Continuous Availability when errors during file reopen are encountered. cifs_user_readv and cifs_user_writev would wait for ever if results of cifs_reopen_file are not stored and for later inspection. In fact, results are checked and, in case of errors, a chain of function calls leading to reads and writes to be scheduled in a separate thread is skipped. These threads will wake up the corresponding waiters once reads and writes are done. However, given the return value is not stored, when rc is checked for errors a previous one (always zero) is inspected instead. This leads to pending reads/writes added to the list, making cifs_user_readv and cifs_user_writev wait for ever. Signed-off-by: Germano Percossi <[email protected]> Reviewed-by: Pavel Shilovsky <[email protected]> CC: Stable <[email protected]> Signed-off-by: Steve French <[email protected]>
2017-04-10CIFS: remove bad_network_name flagGermano Percossi2-6/+0
STATUS_BAD_NETWORK_NAME can be received during node failover, causing the flag to be set and making the reconnect thread always unsuccessful, thereafter. Once the only place where it is set is removed, the remaining bits are rendered moot. Removing it does not prevent "mount" from failing when a non existent share is passed. What happens when the share really ceases to exist while the share is mounted is undefined now as much as it was before. Signed-off-by: Germano Percossi <[email protected]> Reviewed-by: Pavel Shilovsky <[email protected]> CC: Stable <[email protected]> Signed-off-by: Steve French <[email protected]>
2017-04-10CIFS: reconnect thread reschedule itselfGermano Percossi1-1/+9
In case of error, smb2_reconnect_server reschedule itself with a delay, to avoid being too aggressive. Signed-off-by: Germano Percossi <[email protected]> Reviewed-by: Pavel Shilovsky <[email protected]> CC: Stable <[email protected]> Signed-off-by: Steve French <[email protected]>
2017-04-10CIFS: handle guest access errors to Windows sharesMark Syms1-0/+3
Commit 1a967d6c9b39c226be1b45f13acd4d8a5ab3dc44 ("correctly to anonymous authentication for the NTLM(v2) authentication") introduces a regression in handling errors related to attempting a guest connection to a Windows share which requires authentication. This should result in a permission denied error but actually causes the kernel module to enter a never-ending loop trying to follow a DFS referal which doesn't exist. The base cause of this is the failure now occurs later in the process during tree connect and not at the session setup setup and all errors in tree connect are interpreted as needing to follow the DFS paths which isn't in this case correct. So, check the returned error against EACCES and fail if this is returned error. Feedback from Aurelien: PS> net user guest /activate:no PS> mkdir C:\guestshare PS> icacls C:\guestshare /grant 'Everyone:(OI)(CI)F' PS> new-smbshare -name guestshare -path C:\guestshare -fullaccess Everyone I've tested v3.10, v4.4, master, master+your patch using default options (empty or no user "NU") and user=abc (U). NT_LOGON_FAILURE in session setup: LF This is what you seem to have in 3.10. NT_ACCESS_DENIED in tree connect to the share: AD This is what you get before your infinite loop. | NU U -------------------------------- 3.10 | LF LF 4.4 | LF LF master | AD LF master+patch | AD LF No infinite DFS loop :( All these issues result in mount failing very fast with permission denied. I guess it could be from either the Windows version or the share/folder ACL. A deeper analysis of the packets might reveal more. In any case I did not notice any issues for on a basic DFS setup with the patch so I don't think it introduced any regressions, which is probably all that matters. It still bothers me a little I couldn't hit the bug. I've included kernel output w/ debugging output and network capture of my tests if anyone want to have a look at it. (master+patch = ml-guestfix). Signed-off-by: Mark Syms <[email protected]> Reviewed-by: Aurelien Aptel <[email protected]> Tested-by: Aurelien Aptel <[email protected]> Acked-by: Pavel Shilovsky <[email protected]> Signed-off-by: Steve French <[email protected]>
2017-04-10CIFS: Fix null pointer deref during read resp processingPavel Shilovsky3-11/+11
Currently during receiving a read response mid->resp_buf can be NULL when it is being passed to cifs_discard_remaining_data() from cifs_readv_discard(). Fix it by always passing server->smallbuf instead and initializing mid->resp_buf at the end of read response processing. Signed-off-by: Pavel Shilovsky <[email protected]> CC: Stable <[email protected]> Acked-by: Sachin Prabhu <[email protected]> Signed-off-by: Steve French <[email protected]>
2017-04-10Input: xpad - add support for Razer Wildcat gamepadCameron Gutman1-0/+2
Cc: [email protected] Signed-off-by: Cameron Gutman <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>
2017-04-10libnvdimm: band aid btt vs clear poison lockingDan Williams1-1/+9
The following warning results from holding a lane spinlock, preempt_disable(), or the btt map spinlock and then trying to take the reconfig_mutex to walk the poison list and potentially add new entries. BUG: sleeping function called from invalid context at kernel/locking/mutex.c:747 in_atomic(): 1, irqs_disabled(): 0, pid: 17159, name: dd [..] Call Trace: dump_stack+0x85/0xc8 ___might_sleep+0x184/0x250 __might_sleep+0x4a/0x90 __mutex_lock+0x58/0x9b0 ? nvdimm_bus_lock+0x21/0x30 [libnvdimm] ? __nvdimm_bus_badblocks_clear+0x2f/0x60 [libnvdimm] ? acpi_nfit_forget_poison+0x79/0x80 [nfit] ? _raw_spin_unlock+0x27/0x40 mutex_lock_nested+0x1b/0x20 nvdimm_bus_lock+0x21/0x30 [libnvdimm] nvdimm_forget_poison+0x25/0x50 [libnvdimm] nvdimm_clear_poison+0x106/0x140 [libnvdimm] nsio_rw_bytes+0x164/0x270 [libnvdimm] btt_write_pg+0x1de/0x3e0 [nd_btt] ? blk_queue_enter+0x30/0x290 btt_make_request+0x11a/0x310 [nd_btt] ? blk_queue_enter+0xb7/0x290 ? blk_queue_enter+0x30/0x290 generic_make_request+0x118/0x3b0 As a minimal fix, disable error clearing when the BTT is enabled for the namespace. For the final fix a larger rework of the poison list locking is needed. Note that this is not a problem in the blk case since that path never calls nvdimm_clear_poison(). Cc: <[email protected]> Fixes: 82bf1037f2ca ("libnvdimm: check and clear poison before writing to pmem") Cc: Dave Jiang <[email protected]> [jeff: dynamically disable error clearing in the btt case] Suggested-by: Jeff Moyer <[email protected]> Reviewed-by: Jeff Moyer <[email protected]> Reported-by: Vishal Verma <[email protected]> Signed-off-by: Dan Williams <[email protected]>
2017-04-10libnvdimm: fix reconfig_mutex, mmap_sem, and jbd2_handle lockdep splatDan Williams1-0/+6
Holding the reconfig_mutex over a potential userspace fault sets up a lockdep dependency chain between filesystem-DAX and the libnvdimm ioctl path. Move the user access outside of the lock. [ INFO: possible circular locking dependency detected ] 4.11.0-rc3+ #13 Tainted: G W O ------------------------------------------------------- fallocate/16656 is trying to acquire lock: (&nvdimm_bus->reconfig_mutex){+.+.+.}, at: [<ffffffffa00080b1>] nvdimm_bus_lock+0x21/0x30 [libnvdimm] but task is already holding lock: (jbd2_handle){++++..}, at: [<ffffffff813b4944>] start_this_handle+0x104/0x460 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (jbd2_handle){++++..}: lock_acquire+0xbd/0x200 start_this_handle+0x16a/0x460 jbd2__journal_start+0xe9/0x2d0 __ext4_journal_start_sb+0x89/0x1c0 ext4_dirty_inode+0x32/0x70 __mark_inode_dirty+0x235/0x670 generic_update_time+0x87/0xd0 touch_atime+0xa9/0xd0 ext4_file_mmap+0x90/0xb0 mmap_region+0x370/0x5b0 do_mmap+0x415/0x4f0 vm_mmap_pgoff+0xd7/0x120 SyS_mmap_pgoff+0x1c5/0x290 SyS_mmap+0x22/0x30 entry_SYSCALL_64_fastpath+0x1f/0xc2 -> #1 (&mm->mmap_sem){++++++}: lock_acquire+0xbd/0x200 __might_fault+0x70/0xa0 __nd_ioctl+0x683/0x720 [libnvdimm] nvdimm_ioctl+0x8b/0xe0 [libnvdimm] do_vfs_ioctl+0xa8/0x740 SyS_ioctl+0x79/0x90 do_syscall_64+0x6c/0x200 return_from_SYSCALL_64+0x0/0x7a -> #0 (&nvdimm_bus->reconfig_mutex){+.+.+.}: __lock_acquire+0x16b6/0x1730 lock_acquire+0xbd/0x200 __mutex_lock+0x88/0x9b0 mutex_lock_nested+0x1b/0x20 nvdimm_bus_lock+0x21/0x30 [libnvdimm] nvdimm_forget_poison+0x25/0x50 [libnvdimm] nvdimm_clear_poison+0x106/0x140 [libnvdimm] pmem_do_bvec+0x1c2/0x2b0 [nd_pmem] pmem_make_request+0xf9/0x270 [nd_pmem] generic_make_request+0x118/0x3b0 submit_bio+0x75/0x150 Cc: <[email protected]> Fixes: 62232e45f4a2 ("libnvdimm: control (ioctl) messages for nvdimm_bus and nvdimm devices") Cc: Dave Jiang <[email protected]> Reported-by: Vishal Verma <[email protected]> Signed-off-by: Dan Williams <[email protected]>
2017-04-11sata_via: Enable hotplug only on VT6421Ondrej Zary1-8/+10
Commit 57e5568fda27 ("sata_via: Implement hotplug for VT6421") adds hotplug IRQ handler for VT6421 but enables hotplug on all chips. This is a bug because it causes "irq xx: nobody cared" error on VT6420 when hot-(un)plugging a drive: [ 381.839948] irq 20: nobody cared (try booting with the "irqpoll" option) [ 381.840014] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.0-rc5+ #148 [ 381.840066] Hardware name: P4VM800/P4VM800, BIOS P1.60 05/29/2006 [ 381.840117] Call Trace: [ 381.840167] <IRQ> [ 381.840225] ? dump_stack+0x44/0x58 [ 381.840278] ? __report_bad_irq+0x14/0x97 [ 381.840327] ? handle_edge_irq+0xa5/0xa5 [ 381.840376] ? note_interrupt+0x155/0x1cf [ 381.840426] ? handle_edge_irq+0xa5/0xa5 [ 381.840474] ? handle_irq_event_percpu+0x32/0x38 [ 381.840524] ? handle_irq_event+0x1f/0x38 [ 381.840573] ? handle_fasteoi_irq+0x69/0xb8 [ 381.840625] ? handle_irq+0x4f/0x5d [ 381.840672] </IRQ> [ 381.840726] ? do_IRQ+0x2e/0x8b [ 381.840782] ? common_interrupt+0x2c/0x34 [ 381.840836] ? mwait_idle+0x60/0x82 [ 381.840892] ? arch_cpu_idle+0x6/0x7 [ 381.840949] ? do_idle+0x96/0x18e [ 381.841002] ? cpu_startup_entry+0x16/0x1a [ 381.841057] ? start_kernel+0x319/0x31c [ 381.841111] ? startup_32_smp+0x166/0x168 [ 381.841165] handlers: [ 381.841219] [<c12a7263>] ata_bmdma_interrupt [ 381.841274] Disabling IRQ #20 Seems that VT6420 can do hotplug too (there's no documentation) but the comments say that SCR register access (required for detecting hotplug events) can cause problems on these chips. For now, just keep hotplug disabled on anything other than VT6421. Signed-off-by: Ondrej Zary <[email protected]> Signed-off-by: Tejun Heo <[email protected]>
2017-04-11cgroup: avoid attaching a cgroup root to two different superblocksZefan Li1-1/+1
Run this: touch file0 for ((; ;)) { mount -t cpuset xxx file0 } And this concurrently: touch file1 for ((; ;)) { mount -t cpuset xxx file1 } We'll trigger a warning like this: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 4675 at lib/percpu-refcount.c:317 percpu_ref_kill_and_confirm+0x92/0xb0 percpu_ref_kill_and_confirm called more than once on css_release! CPU: 1 PID: 4675 Comm: mount Not tainted 4.11.0-rc5+ #5 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007 Call Trace: dump_stack+0x63/0x84 __warn+0xd1/0xf0 warn_slowpath_fmt+0x5f/0x80 percpu_ref_kill_and_confirm+0x92/0xb0 cgroup_kill_sb+0x95/0xb0 deactivate_locked_super+0x43/0x70 deactivate_super+0x46/0x60 ... ---[ end trace a79f61c2a2633700 ]--- Here's a race: Thread A Thread B cgroup1_mount() # alloc a new cgroup root cgroup_setup_root() cgroup1_mount() # no sb yet, returns NULL kernfs_pin_sb() # but succeeds in getting the refcnt, # so re-use cgroup root percpu_ref_tryget_live() # alloc sb with cgroup root cgroup_do_mount() cgroup_kill_sb() # alloc another sb with same root cgroup_do_mount() cgroup_kill_sb() We end up using the same cgroup root for two different superblocks, so percpu_ref_kill() will be called twice on the same root when the two superblocks are destroyed. We should fix to make sure the superblock pinning is really successful. Cc: [email protected] # 3.16+ Reported-by: Dmitry Vyukov <[email protected]> Signed-off-by: Zefan Li <[email protected]> Signed-off-by: Tejun Heo <[email protected]>
2017-04-11virtio-pci: Remove affinity hint before freeing the interruptMarc Zyngier1-3/+6
virtio-pci registers a per-vq affinity hint when using MSIX, but fails to remove it when freeing the interrupt, resulting in this type of splat: [ 31.111202] WARNING: CPU: 0 PID: 2823 at kernel/irq/manage.c:1503 __free_irq+0x2c4/0x2c8 [ 31.114689] Modules linked in: [ 31.116101] CPU: 0 PID: 2823 Comm: kexec Not tainted 4.10.0+ #6941 [ 31.118911] Hardware name: Generic DT based system [ 31.121319] [<c022fb78>] (unwind_backtrace) from [<c0229d8c>] (show_stack+0x18/0x1c) [ 31.125017] [<c0229d8c>] (show_stack) from [<c05192f4>] (dump_stack+0x84/0x98) [ 31.128427] [<c05192f4>] (dump_stack) from [<c023d940>] (__warn+0xf4/0x10c) [ 31.131910] [<c023d940>] (__warn) from [<c023da20>] (warn_slowpath_null+0x28/0x30) [ 31.135543] [<c023da20>] (warn_slowpath_null) from [<c0290238>] (__free_irq+0x2c4/0x2c8) [ 31.139355] [<c0290238>] (__free_irq) from [<c02902d0>] (free_irq+0x44/0x78) [ 31.142909] [<c02902d0>] (free_irq) from [<c059d3a8>] (vp_del_vqs+0x68/0x1c0) [ 31.146299] [<c059d3a8>] (vp_del_vqs) from [<c056ca4c>] (pci_device_shutdown+0x3c/0x78) The obvious fix is to drop the affinity hint before freeing the interrupt. Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>
2017-04-11Revert "virtio_pci: remove struct virtio_pci_vq_info"Michael S. Tsirkin4-43/+122
This reverts commit 5c34d002dcc7a6dd665a19d098b4f4cd5501ba1a. Conflicts: drivers/virtio/virtio_pci_common.c The cleanup seems to be one of the changes that broke hybernation for some users. We are still not sure why but revert helps. This reverts the cleanup changes but keeps the affinity support. Tested-by: Mike Galbraith <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>
2017-04-11Revert "virtio_pci: use shared interrupts for virtqueues"Michael S. Tsirkin2-112/+148
This reverts commit 07ec51480b5eb1233f8c1b0f5d7a7c8d1247c507. Conflicts: drivers/virtio/virtio_pci_common.c Unfortunately the idea does not work with threadirqs as more than 32 queues can then map to a single interrupts. Further, the cleanup seems to be one of the changes that broke hybernation for some users. We are still not sure why but revert helps. This reverts the cleanup changes but keeps the affinity support. Tested-by: Mike Galbraith <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>
2017-04-11Revert "virtio_pci: don't duplicate the msix_enable flag in struct pci_dev"Michael S. Tsirkin5-5/+8
This reverts commit 53a020c661741f3b87ad3ac6fa545088aaebac9b. The cleanup seems to be one of the changes that broke hybernation for some users. We are still not sure why but revert helps. Tested-by: Mike Galbraith <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>
2017-04-11Revert "virtio_pci: simplify MSI-X setup"Michael S. Tsirkin1-17/+15
This reverts commit 52a61516125fa9a21b3bdf4f90928308e2e5573f. Conflicts: drivers/virtio/virtio_pci_common.c The cleanup seems to be one of the changes that broke hybernation for some users. We are still not sure why but revert helps. This reverts the cleanup changes but keeps the affinity support. Tested-by: Mike Galbraith <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>
2017-04-10Revert "virtio_pci: fix out of bound access for msix_names"Michael S. Tsirkin1-5/+4
This reverts commit de85ec8b07f82c8c84de7687f769e74bf4c26a1e. Follow-up patches will revert 07ec51480b5e ("virtio_pci: use shared interrupts for virtqueues") that triggered the problem so no need for this one anymore. Tested-by: Mike Galbraith <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>
2017-04-10Merge branch 'linus' of ↵Linus Torvalds3-47/+22
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fixes from Herbert Xu: "This fixes a number of bugs in the caam driver: - device creation fails after release - error-path NULL-pointer dereference - spurious hardware error in RNG deinstantiation" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: caam - fix RNG deinstantiation error checking crypto: caam - fix invalid dereference in caam_rsa_init_tfm() crypto: caam - fix JR platform device subsequent (re)creations
2017-04-10x86/vdso: Plug race between mapping and ELF header setupThomas Gleixner1-1/+1
The vsyscall32 sysctl can racy against a concurrent fork when it switches from disabled to enabled: arch_setup_additional_pages() if (vdso32_enabled) --> No mapping sysctl.vsysscall32() --> vdso32_enabled = true create_elf_tables() ARCH_DLINFO_IA32 if (vdso32_enabled) { --> Add VDSO entry with NULL pointer Make ARCH_DLINFO_IA32 check whether the VDSO mapping has been set up for the newly forked process or not. Signed-off-by: Thomas Gleixner <[email protected]> Acked-by: Andy Lutomirski <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Mathias Krause <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2017-04-10x86/vdso: Ensure vdso32_enabled gets set to valid values onlyMathias Krause1-2/+9
vdso_enabled can be set to arbitrary integer values via the kernel command line 'vdso32=' parameter or via 'sysctl abi.vsyscall32'. load_vdso32() only maps VDSO if vdso_enabled == 1, but ARCH_DLINFO_IA32 merily checks for vdso_enabled != 0. As a consequence the AT_SYSINFO_EHDR auxiliary vector for the VDSO_ENTRY is emitted with a NULL pointer which causes a segfault when the application tries to use the VDSO. Restrict the valid arguments on the command line and the sysctl to 0 and 1. Fixes: b0b49f2673f0 ("x86, vdso: Remove compat vdso support") Signed-off-by: Mathias Krause <[email protected]> Acked-by: Andy Lutomirski <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: [email protected] Cc: Roland McGrath <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2017-04-10audit: make sure we don't let the retry queue grow without boundsPaul Moore1-35/+32
The retry queue is intended to provide a temporary buffer in the case of transient errors when communicating with auditd, it is not meant as a long life queue, that functionality is provided by the hold queue. This patch fixes a problem identified by Seth where the retry queue could grow uncontrollably if an auditd instance did not connect to the kernel to drain the queues. This commit fixes this by doing the following: * Make sure we always call auditd_reset() if we decide the connection with audit is really dead. There were some cases in kauditd_hold_skb() where we did not reset the connection, this patch relocates the reset calls to kauditd_thread() so all the error conditions are caught and the connection reset. As a side effect, this means we could move auditd_reset() and get rid of the forward definition at the top of kernel/audit.c. * We never checked the status of the auditd connection when processing the main audit queue which meant that the retry queue could grow unchecked. This patch adds a call to auditd_reset() after the main queue has been processed if auditd is not connected, the auditd_reset() call will make sure the retry and hold queues are correctly managed/flushed so that the retry queue remains reasonable. Cc: <[email protected]> # 4.10.x-: 5b52330bbfe6 Reported-by: Seth Forshee <[email protected]> Signed-off-by: Paul Moore <[email protected]>
2017-04-10pinctrl: samsung: Add missing part for PINCFG_TYPE_DRV of Exynos5433Chanwoo Choi2-51/+40
The commit 1259feddd0f8("pinctrl: samsung: Fix the width of PINCFG_TYPE_DRV bitfields for Exynos5433") already fixed the different width of PINCFG_TYPE_DRV from previous Exynos SoC. However wrong merge conflict resolution was chosen in commit 7f36f5d11cda ("Merge tag 'v4.10-rc6' into devel") effectively dropping the changes for PINCFG_TYPE_DRV. Re-do them here. The macro EXYNOS_PIN_BANK_EINTW is no longer used so remove it. Fixes: 7f36f5d11cda ("Merge tag 'v4.10-rc6' into devel") Signed-off-by: Chanwoo Choi <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2017-04-09tcp: clear saved_syn in tcp_disconnect()Eric Dumazet1-0/+1
In the (very unlikely) case a passive socket becomes a listener, we do not want to duplicate its saved SYN headers. This would lead to double frees, use after free, and please hackers and various fuzzers Tested: 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 setsockopt(3, IPPROTO_TCP, TCP_SAVE_SYN, [1], 4) = 0 +0 fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 +0 bind(3, ..., ...) = 0 +0 listen(3, 5) = 0 +0 < S 0:0(0) win 32972 <mss 1460,nop,wscale 7> +0 > S. 0:0(0) ack 1 <...> +.1 < . 1:1(0) ack 1 win 257 +0 accept(3, ..., ...) = 4 +0 connect(4, AF_UNSPEC, ...) = 0 +0 close(3) = 0 +0 bind(4, ..., ...) = 0 +0 listen(4, 5) = 0 +0 < S 0:0(0) win 32972 <mss 1460,nop,wscale 7> +0 > S. 0:0(0) ack 1 <...> +.1 < . 1:1(0) ack 1 win 257 Fixes: cd8ae85299d5 ("tcp: provide SYN headers for passive connections") Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-04-09nvme-fc: Fix sqsize wrong assignment based on ctrl MQES capabilitySagi Grimberg1-1/+1
both our sqsize and the controller MQES cap are a 0 based value, so making it 1 based is wrong. Reported-by: Trapp, Darren <[email protected]> Reported-by: Daniel Verkamp <[email protected]> Signed-off-by: Sagi Grimberg <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2017-04-09nvme-rdma: Fix sqsize wrong assignment based on ctrl MQES capabilitySagi Grimberg1-1/+1
both our sqsize and the controller MQES cap are a 0 based value, so making it 1 based is wrong. Reported-by: Trapp, Darren <[email protected]> Reported-by: Daniel Verkamp <[email protected]> Signed-off-by: Sagi Grimberg <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2017-04-09nvme-loop: Fix sqsize wrong assignment based on ctrl MQES capabilitySagi Grimberg1-1/+1
both our sqsize and the controller MQES cap are a 0 based value, so making it 1 based is wrong. Reported-by: Trapp, Darren <[email protected]> Reported-by: Daniel Verkamp <[email protected]> Signed-off-by: Sagi Grimberg <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2017-04-09Linux 4.11-rc6Linus Torvalds1-1/+1
2017-04-09Merge branch 'for-next' of git://git.samba.org/sfrench/cifs-2.6Linus Torvalds13-90/+268
Pull CIFS fixes from Steve French: "This is a set of CIFS/SMB3 fixes for stable. There is another set of four SMB3 reconnect fixes for stable in progress but they are still being reviewed/tested, so didn't want to wait any longer to send these five below" * 'for-next' of git://git.samba.org/sfrench/cifs-2.6: Reset TreeId to zero on SMB2 TREE_CONNECT CIFS: Fix build failure with smb2 Introduce cifs_copy_file_range() SMB3: Rename clone_range to copychunk_range Handle mismatched open calls
2017-04-09Merge branch 'fixes' of git://git.armlinux.org.uk/~rmk/linux-armLinus Torvalds4-16/+69
Pull ARM fixes from Russell King: "A number of ARM fixes: - prevent oopses caused by dma_get_sgtable() and declared DMA coherent memory - fix boot failure on nommu caused by ID_PFR1 access - a number of kprobes fixes from Jon Medhurst and Masami Hiramatsu" * 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm: ARM: 8665/1: nommu: access ID_PFR1 only if CPUID scheme ARM: dma-mapping: disallow dma_get_sgtable() for non-kernel managed memory arm: kprobes: Align stack to 8-bytes in test code arm: kprobes: Fix the return address of multiple kretprobes arm: kprobes: Skip single-stepping in recursing path if possible arm: kprobes: Allow to handle reentered kprobe on single-stepping
2017-04-09Merge tag 'driver-core-4.11-rc6' of ↵Linus Torvalds3-5/+14
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core fixes from Greg KH: "Here are 3 small fixes for 4.11-rc6. One resolves a reported issue with sysfs files that NeilBrown found, one is a documenatation fix for the stable kernel rules, and the last is a small MAINTAINERS file update for kernfs" * tag 'driver-core-4.11-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: MAINTAINERS: separate out kernfs maintainership sysfs: be careful of error returns from ops->show() Documentation: stable-kernel-rules: fix stable-tag format
2017-04-09Merge tag 'staging-4.11-rc6' of ↵Linus Torvalds7-7/+31
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging Pull staging/IIO driver rfixes from Greg KH: "Here are a number of small IIO and staging driver fixes for 4.11-rc6. Nothing big here, just iio fixes for reported issues, and an ashmem fix for a very old bug that has been reported by a number of Android vendors" * tag 'staging-4.11-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: staging: android: ashmem: lseek failed due to no FMODE_LSEEK. iio: hid-sensor-attributes: Fix sensor property setting failure. iio: accel: hid-sensor-accel-3d: Fix duplicate scan index error iio: core: Fix IIO_VAL_FRACTIONAL_LOG2 for negative values iio: st_pressure: initialize lps22hb bootime iio: bmg160: reset chip when probing iio: cros_ec_sensors: Fix return value to get raw and calibbias data.
2017-04-09Merge branch 'for-linus' of ↵Linus Torvalds14-61/+120
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs Pull VFS fixes from Al Viro: "statx followup fixes and a fix for stack-smashing on alpha" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: alpha: fix stack smashing in old_adjtimex(2) statx: Include a mask for stx_attributes in struct statx statx: Reserve the top bit of the mask for future struct expansion xfs: report crtime and attribute flags to statx ext4: Add statx support statx: optimize copy of struct statx to userspace statx: remove incorrect part of vfs_statx() comment statx: reject unknown flags when using NULL path Documentation/filesystems: fix documentation for ->getattr()
2017-04-08netfilter: nf_ct_expect: use proper RCU list traversal/update APIsLiping Zhang2-5/+5
We should use proper RCU list APIs to manipulate help->expectations, as we can dump the conntrack's expectations via nfnetlink, i.e. in ctnetlink_exp_ct_dump_table(), where only rcu_read_lock is acquired. So for list traversal, use hlist_for_each_entry_rcu; for list add/del, use hlist_add_head_rcu and hlist_del_rcu. Signed-off-by: Liping Zhang <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
2017-04-08netfilter: ctnetlink: skip dumping expect when nfct_help(ct) is NULLLiping Zhang1-0/+6
For IPCTNL_MSG_EXP_GET, if the CTA_EXPECT_MASTER attr is specified, then the NLM_F_DUMP request will dump the expectations related to this connection tracking. But we forget to check whether the conntrack has nf_conn_help or not, so if nfct_help(ct) is NULL, oops will happen: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: ctnetlink_exp_ct_dump_table+0xf9/0x1e0 [nf_conntrack_netlink] Call Trace: ? ctnetlink_exp_ct_dump_table+0x75/0x1e0 [nf_conntrack_netlink] netlink_dump+0x124/0x2a0 __netlink_dump_start+0x161/0x190 ctnetlink_dump_exp_ct+0x16c/0x1bc [nf_conntrack_netlink] ? ctnetlink_exp_fill_info.constprop.33+0xf0/0xf0 [nf_conntrack_netlink] ? ctnetlink_glue_seqadj+0x20/0x20 [nf_conntrack_netlink] ctnetlink_get_expect+0x32e/0x370 [nf_conntrack_netlink] ? debug_lockdep_rcu_enabled+0x1d/0x20 nfnetlink_rcv_msg+0x60a/0x6a9 [nfnetlink] ? nfnetlink_rcv_msg+0x1b9/0x6a9 [nfnetlink] [...] Signed-off-by: Liping Zhang <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
2017-04-08netfilter: make it safer during the inet6_dev->addr_list traversalLiping Zhang2-1/+6
inet6_dev->addr_list is protected by inet6_dev->lock, so only using rcu_read_lock is not enough, we should acquire read_lock_bh(&idev->lock) before the inet6_dev->addr_list traversal. Signed-off-by: Liping Zhang <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
2017-04-08netfilter: ctnetlink: make it safer when checking the ct helper nameLiping Zhang1-5/+10
One CPU is doing ctnetlink_change_helper(), while another CPU is doing unhelp() at the same time. So even if help->helper is not NULL at first, the later statement strcmp(help->helper->name, ...) may still access the NULL pointer. So we must use rcu_read_lock and rcu_dereference to avoid such _bad_ thing happen. Fixes: f95d7a46bc57 ("netfilter: ctnetlink: Fix regression in CTA_HELP processing") Signed-off-by: Liping Zhang <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
2017-04-08netfilter: helper: Add the rcu lock when call __nf_conntrack_helper_findGao Feng2-7/+20
When invoke __nf_conntrack_helper_find, it needs the rcu lock to protect the helper module which would not be unloaded. Now there are two caller nf_conntrack_helper_try_module_get and ctnetlink_create_expect which don't hold rcu lock. And the other callers left like ctnetlink_change_helper, ctnetlink_create_conntrack, and ctnetlink_glue_attach_expect, they already hold the rcu lock or spin_lock_bh. Remove the rcu lock in functions nf_ct_helper_expectfn_find_by_name and nf_ct_helper_expectfn_find_by_symbol. Because they return one pointer which needs rcu lock, so their caller should hold the rcu lock, not in these two functions. Signed-off-by: Gao Feng <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
2017-04-08netfilter: ctnetlink: using bit to represent the ct eventLiping Zhang1-2/+2
Otherwise, creating a new conntrack via nfnetlink: # conntrack -I -p udp -s 1.1.1.1 -d 2.2.2.2 -t 10 --sport 10 --dport 20 will emit the wrong ct events(where UPDATE should be NEW): # conntrack -E [UPDATE] udp 17 10 src=1.1.1.1 dst=2.2.2.2 sport=10 dport=20 [UNREPLIED] src=2.2.2.2 dst=1.1.1.1 sport=20 dport=10 mark=0 Signed-off-by: Liping Zhang <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
2017-04-08netfilter: xt_TCPMSS: add more sanity tests on tcph->doffEric Dumazet1-1/+5
Denys provided an awesome KASAN report pointing to an use after free in xt_TCPMSS I have provided three patches to fix this issue, either in xt_TCPMSS or in xt_tcpudp.c. It seems xt_TCPMSS patch has the smallest possible impact. Signed-off-by: Eric Dumazet <[email protected]> Reported-by: Denys Fedoryshchenko <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
2017-04-08Merge branch 'for-linus' of git://git.kernel.dk/linux-blockLinus Torvalds15-164/+281
Pull block fixes from Jens Axboe: "Here's a pull request for 4.11-rc, fixing a set of issues mostly centered around the new scheduling framework. These have been brewing for a while, but split up into what we absolutely need in 4.11, and what we can defer until 4.12. These are well tested, on both single queue and multiqueue setups, and with and without shared tags. They fix several hangs that have happened in testing. This is obviously larger than I would have preferred at this point in time, but I don't think we can shave much off this and still get the desired results. In detail, this pull request contains: - a set of five fixes for NVMe, mostly from Christoph and one from Roland. - a series from Bart, fixing issues with dm-mq and SCSI shared tags and scheduling. Note that one of those patches commit messages may read like an optimization, but it is in fact an important fix for queue restarts in particular. - a series from Omar, most importantly fixing a hang with multiple hardware queues when we fail to get a driver tag. Another important fix in there is for resizing hardware queues, which nbd does when handling multiple sockets for one connection. - fixing an imbalance in putting the ctx for hctx request allocations from Minchan" * 'for-linus' of git://git.kernel.dk/linux-block: blk-mq: Restart a single queue if tag sets are shared dm rq: Avoid that request processing stalls sporadically scsi: Avoid that SCSI queues get stuck blk-mq: Introduce blk_mq_delay_run_hw_queue() blk-mq: remap queues when adding/removing hardware queues blk-mq-sched: fix crash in switch error path blk-mq-sched: set up scheduler tags when bringing up new queues blk-mq-sched: refactor scheduler initialization blk-mq: use the right hctx when getting a driver tag fails nvmet: fix byte swap in nvmet_parse_io_cmd nvmet: fix byte swap in nvmet_execute_write_zeroes nvmet: add missing byte swap in nvmet_get_smart_log nvme: add missing byte swap in nvme_setup_discard nvme: Correct NVMF enum values to match NVMe-oF rev 1.0 block: do not put mq context in blk_mq_alloc_request_hctx
2017-04-08Merge tag 'pinctrl-v4.11-4' of ↵Linus Torvalds7-42/+83
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control fix from Linus Walleij: "This late fix for pin control is hopefully the last I send this cycle. The problem was detected early in the v4.11 release cycle and there has been some back and forth on how to solve it. Sadly the proper fix arrives late, but at least not too late. An issue was detected with pin control on the Freescale i.MX after the refactorings for more general group and function handling. We now have the proper fix for this" * tag 'pinctrl-v4.11-4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: pinctrl: core: Fix pinctrl_register_and_init() with pinctrl_enable()
2017-04-08Merge tag 'powerpc-4.11-7' of ↵Linus Torvalds6-17/+43
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc fixes from Michael Ellerman: "Some more powerpc fixes for 4.11: Headed to stable: - disable HFSCR[TM] if TM is not supported, fixes a potential host kernel crash triggered by a hostile guest, but only in configurations that no one uses - don't try to fix up misaligned load-with-reservation instructions - fix flush_(d|i)cache_range() called from modules on little endian kernels - add missing global TLB invalidate if cxl is active - fix missing preempt_disable() in crc32c-vpmsum And a fix for selftests build changes that went in this release: - selftests/powerpc: Fix standalone powerpc build Thanks to: Benjamin Herrenschmidt, Frederic Barrat, Oliver O'Halloran, Paul Mackerras" * tag 'powerpc-4.11-7' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/crypto/crc32c-vpmsum: Fix missing preempt_disable() powerpc/mm: Add missing global TLB invalidate if cxl is active powerpc/64: Fix flush_(d|i)cache_range() called from modules powerpc: Don't try to fix up misaligned load-with-reservation instructions powerpc: Disable HFSCR[TM] if TM is not supported selftests/powerpc: Fix standalone powerpc build
2017-04-08mm/mempolicy.c: fix error handling in set_mempolicy and mbind.Chris Salls1-12/+8
In the case that compat_get_bitmap fails we do not want to copy the bitmap to the user as it will contain uninitialized stack data and leak sensitive data. Signed-off-by: Chris Salls <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2017-04-08sysctl: report EINVAL if value is larger than UINT_MAX for proc_douintvecLiping Zhang1-0/+2
Currently, inputting the following command will succeed but actually the value will be truncated: # echo 0x12ffffffff > /proc/sys/net/ipv4/tcp_notsent_lowat This is not friendly to the user, so instead, we should report error when the value is larger than UINT_MAX. Fixes: e7d316a02f68 ("sysctl: handle error writing UINT_MAX to u32 fields") Signed-off-by: Liping Zhang <[email protected]> Cc: Subash Abhinov Kasiviswanathan <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Eric W. Biederman <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.