commit 3b6aa07b936b09d38c1bfcee1e06845b968df475 Author: Sasha Levin Date: Fri May 20 21:48:04 2016 -0400 Linux 3.18.34 Signed-off-by: Sasha Levin commit d0054dc58c31c386c2b1c0f82a83e456d10292a7 Author: Linus Torvalds Date: Sat May 14 11:11:44 2016 -0700 nf_conntrack: avoid kernel pointer value leak in slab name [ Upstream commit 31b0b385f69d8d5491a4bca288e25e63f1d945d0 ] The slab name ends up being visible in the directory structure under /sys, and even if you don't have access rights to the file you can see the filenames. Just use a 64-bit counter instead of the pointer to the 'net' structure to generate a unique name. This code will go away in 4.7 when the conntrack code moves to a single kmemcache, but this is the backportable simple solution to avoiding leaking kernel pointers to user space. Fixes: 5b3501faa874 ("netfilter: nf_conntrack: per netns nf_conntrack_cachep") Signed-off-by: Linus Torvalds Acked-by: Eric Dumazet Cc: stable@vger.kernel.org Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b0efc68c6f9cb2fd22ab77f841883e7f3f9562be Author: Junxiao Bi Date: Thu May 12 15:42:18 2016 -0700 ocfs2: fix posix_acl_create deadlock [ Upstream commit c25a1e0671fbca7b2c0d0757d533bd2650d6dc0c ] Commit 702e5bc68ad2 ("ocfs2: use generic posix ACL infrastructure") refactored code to use posix_acl_create. The problem with this function is that it is not mindful of the cluster wide inode lock making it unsuitable for use with ocfs2 inode creation with ACLs. For example, when used in ocfs2_mknod, this function can cause deadlock as follows. The parent dir inode lock is taken when calling posix_acl_create -> get_acl -> ocfs2_iop_get_acl which takes the inode lock again. This can cause deadlock if there is a blocked remote lock request waiting for the lock to be downconverted. And same deadlock happened in ocfs2_reflink. This fix is to revert back using ocfs2_init_acl. Fixes: 702e5bc68ad2 ("ocfs2: use generic posix ACL infrastructure") Signed-off-by: Tariq Saeed Signed-off-by: Junxiao Bi Cc: Mark Fasheh Cc: Joel Becker Cc: Joseph Qi Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 7879a58a1c6c13501c79418b82053007ebf04f88 Author: Junxiao Bi Date: Thu May 12 15:42:15 2016 -0700 ocfs2: revert using ocfs2_acl_chmod to avoid inode cluster lock hang [ Upstream commit 5ee0fbd50fdf1c1329de8bee35ea9d7c6a81a2e0 ] Commit 743b5f1434f5 ("ocfs2: take inode lock in ocfs2_iop_set/get_acl()") introduced this issue. ocfs2_setattr called by chmod command holds cluster wide inode lock when calling posix_acl_chmod. This latter function in turn calls ocfs2_iop_get_acl and ocfs2_iop_set_acl. These two are also called directly from vfs layer for getfacl/setfacl commands and therefore acquire the cluster wide inode lock. If a remote conversion request comes after the first inode lock in ocfs2_setattr, OCFS2_LOCK_BLOCKED will be set. And this will cause the second call to inode lock from the ocfs2_iop_get_acl() to block indefinetly. The deleted version of ocfs2_acl_chmod() calls __posix_acl_chmod() which does not call back into the filesystem. Therefore, we restore ocfs2_acl_chmod(), modify it slightly for locking as needed, and use that instead. Fixes: 743b5f1434f5 ("ocfs2: take inode lock in ocfs2_iop_set/get_acl()") Signed-off-by: Tariq Saeed Signed-off-by: Junxiao Bi Cc: Mark Fasheh Cc: Joel Becker Cc: Joseph Qi Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit c0ce2224531ad6c19a62db19c0ec7575af1cfb10 Author: Dan Carpenter Date: Tue Apr 14 15:43:19 2015 -0700 ocfs2: dereferencing freed pointers in ocfs2_reflink() [ Upstream commit e073fc58dfe6a4c9b614320c1d56bb71cb213ec4 ] The code at the "out" label assumes that "default_acl" and "acl" are NULL, but actually the pointers can be NULL, unitialized, or freed. Signed-off-by: Dan Carpenter Reviewed-by: Mark Fasheh Cc: Joel Becker Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit dd76ad6b17f4ef69e0522b625070c4efbcf8183c Author: Junxiao Bi Date: Fri Dec 11 13:41:03 2015 -0800 ocfs2: fix SGID not inherited issue [ Upstream commit 854ee2e944b4daf795e32562a7d2f9e90ab5a6a8 ] Commit 8f1eb48758aa ("ocfs2: fix umask ignored issue") introduced an issue, SGID of sub dir was not inherited from its parents dir. It is because SGID is set into "inode->i_mode" in ocfs2_get_init_inode(), but is overwritten by "mode" which don't have SGID set later. Fixes: 8f1eb48758aa ("ocfs2: fix umask ignored issue") Signed-off-by: Junxiao Bi Cc: Mark Fasheh Cc: Joel Becker Acked-by: Srinivas Eeda Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 3665ecd65aad209e7c8258c207094b5006eb3d0f Author: Wanpeng Li Date: Wed May 11 17:55:18 2016 +0800 workqueue: fix rebind bound workers warning [ Upstream commit f7c17d26f43d5cc1b7a6b896cd2fa24a079739b9 ] ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at kernel/workqueue.c:4559 rebind_workers+0x1c0/0x1d0 Modules linked in: CPU: 0 PID: 16 Comm: cpuhp/0 Not tainted 4.6.0-rc4+ #31 Hardware name: IBM IBM System x3550 M4 Server -[7914IUW]-/00Y8603, BIOS -[D7E128FUS-1.40]- 07/23/2013 0000000000000000 ffff881037babb58 ffffffff8139d885 0000000000000010 0000000000000000 0000000000000000 0000000000000000 ffff881037babba8 ffffffff8108505d ffff881037ba0000 000011cf3e7d6e60 0000000000000046 Call Trace: dump_stack+0x89/0xd4 __warn+0xfd/0x120 warn_slowpath_null+0x1d/0x20 rebind_workers+0x1c0/0x1d0 workqueue_cpu_up_callback+0xf5/0x1d0 notifier_call_chain+0x64/0x90 ? trace_hardirqs_on_caller+0xf2/0x220 ? notify_prepare+0x80/0x80 __raw_notifier_call_chain+0xe/0x10 __cpu_notify+0x35/0x50 notify_down_prepare+0x5e/0x80 ? notify_prepare+0x80/0x80 cpuhp_invoke_callback+0x73/0x330 ? __schedule+0x33e/0x8a0 cpuhp_down_callbacks+0x51/0xc0 cpuhp_thread_fun+0xc1/0xf0 smpboot_thread_fn+0x159/0x2a0 ? smpboot_create_threads+0x80/0x80 kthread+0xef/0x110 ? wait_for_completion+0xf0/0x120 ? schedule_tail+0x35/0xf0 ret_from_fork+0x22/0x50 ? __init_kthread_worker+0x70/0x70 ---[ end trace eb12ae47d2382d8f ]--- notify_down_prepare: attempt to take down CPU 0 failed This bug can be reproduced by below config w/ nohz_full= all cpus: CONFIG_BOOTPARAM_HOTPLUG_CPU0=y CONFIG_DEBUG_HOTPLUG_CPU0=y CONFIG_NO_HZ_FULL=y As Thomas pointed out: | If a down prepare callback fails, then DOWN_FAILED is invoked for all | callbacks which have successfully executed DOWN_PREPARE. | | But, workqueue has actually two notifiers. One which handles | UP/DOWN_FAILED/ONLINE and one which handles DOWN_PREPARE. | | Now look at the priorities of those callbacks: | | CPU_PRI_WORKQUEUE_UP = 5 | CPU_PRI_WORKQUEUE_DOWN = -5 | | So the call order on DOWN_PREPARE is: | | CB 1 | CB ... | CB workqueue_up() -> Ignores DOWN_PREPARE | CB ... | CB X ---> Fails | | So we call up to CB X with DOWN_FAILED | | CB 1 | CB ... | CB workqueue_up() -> Handles DOWN_FAILED | CB ... | CB X-1 | | So the problem is that the workqueue stuff handles DOWN_FAILED in the up | callback, while it should do it in the down callback. Which is not a good idea | either because it wants to be called early on rollback... | | Brilliant stuff, isn't it? The hotplug rework will solve this problem because | the callbacks become symetric, but for the existing mess, we need some | workaround in the workqueue code. The boot CPU handles housekeeping duty(unbound timers, workqueues, timekeeping, ...) on behalf of full dynticks CPUs. It must remain online when nohz full is enabled. There is a priority set to every notifier_blocks: workqueue_cpu_up > tick_nohz_cpu_down > workqueue_cpu_down So tick_nohz_cpu_down callback failed when down prepare cpu 0, and notifier_blocks behind tick_nohz_cpu_down will not be called any more, which leads to workers are actually not unbound. Then hotplug state machine will fallback to undo and online cpu 0 again. Workers will be rebound unconditionally even if they are not unbound and trigger the warning in this progress. This patch fix it by catching !DISASSOCIATED to avoid rebind bound workers. Cc: Tejun Heo Cc: Lai Jiangshan Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Frédéric Weisbecker Cc: stable@vger.kernel.org Suggested-by: Lai Jiangshan Signed-off-by: Wanpeng Li Signed-off-by: Sasha Levin commit dd4b0cc4424219937bacd826884a867f9144bd20 Author: Steven Rostedt Date: Wed May 11 15:09:36 2016 -0400 tools lib traceevent: Do not reassign parg after collapse_tree() [ Upstream commit 106b816cb46ebd87408b4ed99a2e16203114daa6 ] At the end of process_filter(), collapse_tree() was changed to update the parg parameter, but the reassignment after the call wasn't removed. What happens is that the "current_op" gets modified and freed and parg is assigned to the new allocated argument. But after the call to collapse_tree(), parg is assigned again to the just freed "current_op", and this causes the tool to crash. The current_op variable must also be assigned to NULL in case of error, otherwise it will cause it to be free()ed twice. Signed-off-by: Steven Rostedt Acked-by: Namhyung Kim Cc: stable@vger.kernel.org # 3.14+ Fixes: 42d6194d133c ("tools lib traceevent: Refactor process_filter()") Link: http://lkml.kernel.org/r/20160511150936.678c18a1@gandalf.local.home Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 1b57d360ad96e2e54ddbffcb391527702a1ae86f Author: Steven Rostedt (Red Hat) Date: Tue Mar 24 09:57:57 2015 -0400 tools lib traceevent: Free filter tokens in process_filter() [ Upstream commit e1644aae4589274223c1ab9072ddbda98dd97f6a ] valgrind showed that the filter token wasn't being freed properly in process_filter(). Signed-off-by: Steven Rostedt Cc: Andrew Morton Cc: Jiri Olsa Cc: Namhyung Kim Link: http://lkml.kernel.org/r/20150324135923.817723903@goodmis.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit f6c3f874c62a34758e1532d20e97ab8ea96f7106 Author: Takashi Iwai Date: Wed May 11 17:48:00 2016 +0200 ALSA: usb-audio: Yet another Phoneix Audio device quirk [ Upstream commit 84add303ef950b8d85f54bc2248c2bc73467c329 ] Phoenix Audio has yet another device with another id (even a different vendor id, 0556:0014) that requires the same quirk for the sample rate. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=110221 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit e6a85be9157b6110833e7b14b98bc5a4daf1d462 Author: Yura Pakhuchiy Date: Sat May 7 23:53:36 2016 +0700 ALSA: hda - Fix subwoofer pin on ASUS N751 and N551 [ Upstream commit 3231e2053eaeee70bdfb216a78a30f11e88e2243 ] Subwoofer does not work out of the box on ASUS N751/N551 laptops. This patch fixes it. Patch tested on N751 laptop. N551 part is not tested, but according to [1] and [2] this laptop requires similar changes, so I included them in the patch. 1. https://github.com/honsiorovskyi/asus-n551-hda-fix 2. https://bugs.launchpad.net/ubuntu/+source/alsa-tools/+bug/1405691 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=117781 Signed-off-by: Yura Pakhuchiy Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit cb0949d6a46c50efaf6a52668bacfbdee1bf8c1a Author: Bobi Mihalca Date: Wed Mar 23 13:26:11 2016 +0200 ALSA: hda - Fix white noise on Asus N750JV headphone [ Upstream commit 9d4dc5840f93bcb002fa311693349deae7702bc5 ] For reducing the noise from the headphone output on ASUS N750JV, call the existing fixup, alc_fixup_auto_mute_via_amp(), additionally. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=115181 Signed-off-by: Bobi Mihalca Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 72251c9995841c77c7137a8206b1e09cb3fe28e6 Author: Bobi Mihalca Date: Wed Mar 23 13:23:55 2016 +0200 ALSA: hda - Asus N750JV external subwoofer fixup [ Upstream commit 70cf2cbd685e218c3ffd105d9fb6cf0f8d767481 ] ASUS N750JV needs the same fixup as N550 for enabling its subwoofer. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=115181 Signed-off-by: Bobi Mihalca Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit b86267a40aa2a57bc9fe55c901d5fa9359d9950b Author: Daniel Vetter Date: Tue May 3 10:33:01 2016 +0200 drm/i915: Bail out of pipe config compute loop on LPT [ Upstream commit 2700818ac9f935d8590715eecd7e8cadbca552b6 ] LPT is pch, so might run into the fdi bandwidth constraint (especially since it has only 2 lanes). But right now we just force pipe_bpp back to 24, resulting in a nice loop (which we bail out with a loud WARN_ON). Fix this. Cc: Chris Wilson Cc: Maarten Lankhorst References: https://bugs.freedesktop.org/show_bug.cgi?id=93477 Signed-off-by: Daniel Vetter Tested-by: Chris Wilson Signed-off-by: Maarten Lankhorst Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1462264381-7573-1-git-send-email-daniel.vetter@ffwll.ch (cherry picked from commit f58a1acc7e4a1f37d26124ce4c875c647fbcc61f) Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit ea07111f57fa7cc29337ce4bec0e46dacfd9bc73 Author: Marek Szyprowski Date: Mon May 9 09:31:47 2016 -0700 Input: max8997-haptic - fix NULL pointer dereference [ Upstream commit 6ae645d5fa385f3787bf1723639cd907fe5865e7 ] NULL pointer derefence happens when booting with DTB because the platform data for haptic device is not set in supplied data from parent MFD device. The MFD device creates only platform data (from Device Tree) for itself, not for haptic child. Unable to handle kernel NULL pointer dereference at virtual address 0000009c pgd = c0004000 [0000009c] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT SMP ARM (max8997_haptic_probe) from [] (platform_drv_probe+0x4c/0xb0) (platform_drv_probe) from [] (driver_probe_device+0x214/0x2c0) (driver_probe_device) from [] (__driver_attach+0xac/0xb0) (__driver_attach) from [] (bus_for_each_dev+0x68/0x9c) (bus_for_each_dev) from [] (bus_add_driver+0x1a0/0x218) (bus_add_driver) from [] (driver_register+0x78/0xf8) (driver_register) from [] (do_one_initcall+0x90/0x1d8) (do_one_initcall) from [] (kernel_init_freeable+0x15c/0x1fc) (kernel_init_freeable) from [] (kernel_init+0x8/0x114) (kernel_init) from [] (ret_from_fork+0x14/0x3c) Signed-off-by: Marek Szyprowski Cc: Fixes: 104594b01ce7 ("Input: add driver support for MAX8997-haptic") [k.kozlowski: Write commit message, add CC-stable] Signed-off-by: Krzysztof Kozlowski Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 0ac59955ff25e9338cc080bd7e18fa32d5e93b1f Author: Kaho Ng Date: Mon May 9 00:27:49 2016 +0800 ALSA: hda - Fix white noise on Asus UX501VW headset [ Upstream commit 2da2dc9ead232f25601404335cca13c0f722d41b ] For reducing the noise from the headset output on ASUS UX501VW, call the existing fixup, alc_fixup_headset_mode_alc668(), additionally. Thread: https://bbs.archlinux.org/viewtopic.php?id=209554 Signed-off-by: Kaho Ng Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 95d9ee033c7a1fa39c40e62918c51745b051aeba Author: Bobi Mihalca Date: Wed Mar 23 13:32:33 2016 +0200 ALSA: hda - Apply fix for white noise on Asus N550JV, too [ Upstream commit 83a9efb5b8170b7cffef4f62656656e1d8ad2ccd ] Apply the new fixup that is used for ASUS N750JV to another similar model, N500JV, too, for reducing the headphone noise. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=115181 Signed-off-by: Bobi Mihalca Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 10236ada50b3d19c76caa71229c0ba728684a970 Author: Takashi Iwai Date: Mon Jan 18 09:17:30 2016 +0100 ALSA: hda - Fix bass pin fixup for ASUS N550JX [ Upstream commit db8948e653e12b218058bb6696f4a33fa7845f64 ] ASUS N550JX (PCI SSID 1043:13df) requires the same fixup for a bass speaker output pin as other N550 models. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=110001 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit b8500fc5acce9976a6de1c60daa09f40d148f11d Author: Al Viro Date: Thu May 5 16:25:35 2016 -0400 get_rock_ridge_filename(): handle malformed NM entries [ Upstream commit 99d825822eade8d827a1817357cbf3f889a552d6 ] Payloads of NM entries are not supposed to contain NUL. When we run into such, only the part prior to the first NUL goes into the concatenation (i.e. the directory entry name being encoded by a bunch of NM entries). We do stop when the amount collected so far + the claimed amount in the current NM entry exceed 254. So far, so good, but what we return as the total length is the sum of *claimed* sizes, not the actual amount collected. And that can grow pretty large - not unlimited, since you'd need to put CE entries in between to be able to get more than the maximum that could be contained in one isofs directory entry / continuation chunk and we are stop once we'd encountered 32 CEs, but you can get about 8Kb easily. And that's what will be passed to readdir callback as the name length. 8Kb __copy_to_user() from a buffer allocated by __get_free_page() Cc: stable@vger.kernel.org # 0.98pl6+ (yes, really) Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit aa7ebd32f9cbc09ccb469701fd58f877dac349ad Author: Dmitry V. Levin Date: Wed Apr 27 04:56:11 2016 +0300 parisc: fix a bug when syscall number of tracee is __NR_Linux_syscalls [ Upstream commit f0b22d1bb2a37a665a969e95785c75a4f49d1499 ] Do not load one entry beyond the end of the syscall table when the syscall number of a traced process equals to __NR_Linux_syscalls. Similar bug with regular processes was fixed by commit 3bb457af4fa8 ("[PARISC] Fix bug when syscall nr is __NR_Linux_syscalls"). This bug was found by strace test suite. Cc: stable@vger.kernel.org Signed-off-by: Dmitry V. Levin Acked-by: Helge Deller Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 15e7e46e2f6dfdaaa9043b2ab643961ff71f0b24 Author: Helge Deller Date: Tue Jan 19 16:08:49 2016 +0100 parisc: Fix ptrace syscall number and return value modification [ Upstream commit 98e8b6c9ac9d1b1e9d1122dfa6783d5d566bb8f7 ] Mike Frysinger reported that his ptrace testcase showed strange behaviour on parisc: It was not possible to avoid a syscall and the return value of a syscall couldn't be changed. To modify a syscall number, we were missing to save the new syscall number to gr20 which is then picked up later in assembly again. The effect that the return value couldn't be changed is a side-effect of another bug in the assembly code. When a process is ptraced, userspace expects each syscall to report entrance and exit of a syscall. If a syscall number was given which doesn't exist, we jumped to the normal syscall exit code instead of informing userspace that the (non-existant) syscall exits. This unexpected behaviour confuses userspace and thus the bug was misinterpreted as if we can't change the return value. This patch fixes both problems and was tested on 64bit kernel with 32bit userspace. Signed-off-by: Helge Deller Cc: Mike Frysinger Cc: stable@vger.kernel.org # v4.0+ Tested-by: Mike Frysinger Signed-off-by: Sasha Levin commit 1d0030445d57accf1d4d7f7aa26ca0a64b9526af Author: Chen Yu Date: Fri May 6 11:33:39 2016 +0800 x86/tsc: Read all ratio bits from MSR_PLATFORM_INFO [ Upstream commit 886123fb3a8656699dff40afa0573df359abeb18 ] Currently we read the tsc radio: ratio = (MSR_PLATFORM_INFO >> 8) & 0x1f; Thus we get bit 8-12 of MSR_PLATFORM_INFO, however according to the SDM (35.5), the ratio bits are bit 8-15. Ignoring the upper bits can result in an incorrect tsc ratio, which causes the TSC calibration and the Local APIC timer frequency to be incorrect. Fix this problem by masking 0xff instead. [ tglx: Massaged changelog ] Fixes: 7da7c1561366 "x86, tsc: Add static (MSR) TSC calibration on Intel Atom SoCs" Signed-off-by: Chen Yu Cc: "Rafael J. Wysocki" Cc: stable@vger.kernel.org Cc: Bin Gao Cc: Len Brown Link: http://lkml.kernel.org/r/1462505619-5516-1-git-send-email-yu.c.chen@intel.com Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin commit d6926181fde43583fcff10d1b1e0daf4bddfda07 Author: Hugh Dickins Date: Thu May 5 16:22:15 2016 -0700 mm, cma: prevent nr_isolated_* counters from going negative [ Upstream commit 14af4a5e9b26ad251f81c174e8a43f3e179434a5 ] /proc/sys/vm/stat_refresh warns nr_isolated_anon and nr_isolated_file go increasingly negative under compaction: which would add delay when should be none, or no delay when should delay. The bug in compaction was due to a recent mmotm patch, but much older instance of the bug was also noticed in isolate_migratepages_range() which is used for CMA and gigantic hugepage allocations. The bug is caused by putback_movable_pages() in an error path decrementing the isolated counters without them being previously incremented by acct_isolated(). Fix isolate_migratepages_range() by removing the error-path putback, thus reaching acct_isolated() with migratepages still isolated, and leaving putback to caller like most other places do. Fixes: edc2ca612496 ("mm, compaction: move pageblock checks up from isolate_migratepages_range()") [vbabka@suse.cz: expanded the changelog] Signed-off-by: Hugh Dickins Signed-off-by: Vlastimil Babka Acked-by: Joonsoo Kim Cc: Michal Hocko Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit b688848a01ce5e9ce2a3d62af6e66b09dcd6f78d Author: Eric W. Biederman Date: Thu May 5 09:29:29 2016 -0500 propogate_mnt: Handle the first propogated copy being a slave [ Upstream commit 5ec0811d30378ae104f250bfc9b3640242d81e3f ] When the first propgated copy was a slave the following oops would result: > BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 > IP: [] propagate_one+0xbe/0x1c0 > PGD bacd4067 PUD bac66067 PMD 0 > Oops: 0000 [#1] SMP > Modules linked in: > CPU: 1 PID: 824 Comm: mount Not tainted 4.6.0-rc5userns+ #1523 > Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007 > task: ffff8800bb0a8000 ti: ffff8800bac3c000 task.ti: ffff8800bac3c000 > RIP: 0010:[] [] propagate_one+0xbe/0x1c0 > RSP: 0018:ffff8800bac3fd38 EFLAGS: 00010283 > RAX: 0000000000000000 RBX: ffff8800bb77ec00 RCX: 0000000000000010 > RDX: 0000000000000000 RSI: ffff8800bb58c000 RDI: ffff8800bb58c480 > RBP: ffff8800bac3fd48 R08: 0000000000000001 R09: 0000000000000000 > R10: 0000000000001ca1 R11: 0000000000001c9d R12: 0000000000000000 > R13: ffff8800ba713800 R14: ffff8800bac3fda0 R15: ffff8800bb77ec00 > FS: 00007f3c0cd9b7e0(0000) GS:ffff8800bfb00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 0000000000000010 CR3: 00000000bb79d000 CR4: 00000000000006e0 > Stack: > ffff8800bb77ec00 0000000000000000 ffff8800bac3fd88 ffffffff811fbf85 > ffff8800bac3fd98 ffff8800bb77f080 ffff8800ba713800 ffff8800bb262b40 > 0000000000000000 0000000000000000 ffff8800bac3fdd8 ffffffff811f1da0 > Call Trace: > [] propagate_mnt+0x105/0x140 > [] attach_recursive_mnt+0x120/0x1e0 > [] graft_tree+0x63/0x70 > [] do_add_mount+0x9b/0x100 > [] do_mount+0x2aa/0xdf0 > [] ? strndup_user+0x4e/0x70 > [] SyS_mount+0x75/0xc0 > [] do_syscall_64+0x4b/0xa0 > [] entry_SYSCALL64_slow_path+0x25/0x25 > Code: 00 00 75 ec 48 89 0d 02 22 22 01 8b 89 10 01 00 00 48 89 05 fd 21 22 01 39 8e 10 01 00 00 0f 84 e0 00 00 00 48 8b 80 d8 00 00 00 <48> 8b 50 10 48 89 05 df 21 22 01 48 89 15 d0 21 22 01 8b 53 30 > RIP [] propagate_one+0xbe/0x1c0 > RSP > CR2: 0000000000000010 > ---[ end trace 2725ecd95164f217 ]--- This oops happens with the namespace_sem held and can be triggered by non-root users. An all around not pleasant experience. To avoid this scenario when finding the appropriate source mount to copy stop the walk up the mnt_master chain when the first source mount is encountered. Further rewrite the walk up the last_source mnt_master chain so that it is clear what is going on. The reason why the first source mount is special is that it it's mnt_parent is not a mount in the dest_mnt propagation tree, and as such termination conditions based up on the dest_mnt mount propgation tree do not make sense. To avoid other kinds of confusion last_dest is not changed when computing last_source. last_dest is only used once in propagate_one and that is above the point of the code being modified, so changing the global variable is meaningless and confusing. Cc: stable@vger.kernel.org fixes: f2ebb3a921c1ca1e2ddd9242e95a1989a50c4c68 ("smarter propagate_mnt()") Reported-by: Tycho Andersen Reviewed-by: Seth Forshee Tested-by: Seth Forshee Signed-off-by: "Eric W. Biederman" Signed-off-by: Sasha Levin commit 66f0487aecd2515b550abc31ede08215cc3279e8 Author: Maxim Patlasov Date: Tue Feb 16 11:45:33 2016 -0800 fs/pnode.c: treat zero mnt_group_id-s as unequal [ Upstream commit 7ae8fd0351f912b075149a1e03a017be8b903b9a ] propagate_one(m) calculates "type" argument for copy_tree() like this: > if (m->mnt_group_id == last_dest->mnt_group_id) { > type = CL_MAKE_SHARED; > } else { > type = CL_SLAVE; > if (IS_MNT_SHARED(m)) > type |= CL_MAKE_SHARED; > } The "type" argument then governs clone_mnt() behavior with respect to flags and mnt_master of new mount. When we iterate through a slave group, it is possible that both current "m" and "last_dest" are not shared (although, both are slaves, i.e. have non-NULL mnt_master-s). Then the comparison above erroneously makes new mount shared and sets its mnt_master to last_source->mnt_master. The patch fixes the problem by handling zero mnt_group_id-s as though they are unequal. The similar problem exists in the implementation of "else" clause above when we have to ascend upward in the master/slave tree by calling: > last_source = last_source->mnt_master; > last_dest = last_source->mnt_parent; proper number of times. The last step is governed by "n->mnt_group_id != last_dest->mnt_group_id" condition that may lie if both are zero. The patch fixes this case in the same way as the former one. [AV: don't open-code an obvious helper...] Signed-off-by: Maxim Patlasov Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 12de322789aabf55f41ce73eb5b6a5c33fc4313e Author: Wang YanQing Date: Thu May 5 14:14:21 2016 +0100 x86/sysfb_efi: Fix valid BAR address range check [ Upstream commit c10fcb14c7afd6688c7b197a814358fecf244222 ] The code for checking whether a BAR address range is valid will break out of the loop when a start address of 0x0 is encountered. This behaviour is wrong since by breaking out of the loop we may miss the BAR that describes the EFI frame buffer in a later iteration. Because of this bug I can't use video=efifb: boot parameter to get efifb on my new ThinkPad E550 for my old linux system hard disk with 3.10 kernel. In 3.10, efifb is the only choice due to DRM/I915 not supporting the GPU. This patch also add a trivial optimization to break out after we find the frame buffer address range without testing later BARs. Signed-off-by: Wang YanQing [ Rewrote changelog. ] Signed-off-by: Matt Fleming Reviewed-by: Peter Jones Cc: Cc: Ard Biesheuvel Cc: David Herrmann Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Tomi Valkeinen Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/1462454061-21561-2-git-send-email-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 82b612eb124f25fa66a35ad8675a4320520028fa Author: Herbert Xu Date: Wed May 4 17:52:56 2016 +0800 crypto: hash - Fix page length clamping in hash walk [ Upstream commit 13f4bb78cf6a312bbdec367ba3da044b09bf0e29 ] The crypto hash walk code is broken when supplied with an offset greater than or equal to PAGE_SIZE. This patch fixes it by adjusting walk->pg and walk->offset when this happens. Cc: Reported-by: Steffen Klassert Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit cc0bcc57d1198aa6b3caea80b6341f99347d0b2d Author: Prarit Bhargava Date: Wed May 4 13:48:56 2016 +0800 ACPICA: Dispatcher: Update thread ID for recursive method calls [ Upstream commit 93d68841a23a5779cef6fb9aa0ef32e7c5bd00da ] ACPICA commit 7a3bd2d962f221809f25ddb826c9e551b916eb25 Set the mutex owner thread ID. Original patch from: Prarit Bhargava Link: https://bugzilla.kernel.org/show_bug.cgi?id=115121 Link: https://github.com/acpica/acpica/commit/7a3bd2d9 Signed-off-by: Prarit Bhargava Tested-by: Andy Lutomirski # On a Dell XPS 13 9350 Signed-off-by: Bob Moore Signed-off-by: Lv Zheng Cc: All applicable Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 015815809301024b79dce81d1313c49545027427 Author: Matt Fleming Date: Tue May 3 20:29:39 2016 +0100 MAINTAINERS: Remove asterisk from EFI directory names [ Upstream commit e8dfe6d8f6762d515fcd4f30577f7bfcf7659887 ] Mark reported that having asterisks on the end of directory names confuses get_maintainer.pl when it encounters subdirectories, and that my name does not appear when run on drivers/firmware/efi/libstub. Reported-by: Mark Rutland Signed-off-by: Matt Fleming Cc: Cc: Ard Biesheuvel Cc: Catalin Marinas Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/1462303781-8686-2-git-send-email-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 1ead743eb8ed3ccb3adf4972506201feb03bca44 Author: Alex Deucher Date: Mon May 2 18:53:27 2016 -0400 drm/radeon: make sure vertical front porch is at least 1 [ Upstream commit 3104b8128d4d646a574ed9d5b17c7d10752cd70b ] hw doesn't like a 0 value. Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit cd43d64426a965a257d470dbcc965405a0aa3c29 Author: Chunyu Hu Date: Tue May 3 19:34:34 2016 +0800 tracing: Don't display trigger file for events that can't be enabled [ Upstream commit 854145e0a8e9a05f7366d240e2f99d9c1ca6d6dd ] Currently register functions for events will be called through the 'reg' field of event class directly without any check when seting up triggers. Triggers for events that don't support register through debug fs (events under events/ftrace are for trace-cmd to read event format, and most of them don't have a register function except events/ftrace/functionx) can't be enabled at all, and an oops will be hit when setting up trigger for those events, so just not creating them is an easy way to avoid the oops. Link: http://lkml.kernel.org/r/1462275274-3911-1-git-send-email-chuhu@redhat.com Cc: stable@vger.kernel.org # 3.14+ Fixes: 85f2b08268c01 ("tracing: Add basic event trigger framework") Signed-off-by: Chunyu Hu Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit c07b2d4fbd9b8773f1dc4ed596f5d4bd82cc7217 Author: Linus Torvalds Date: Mon May 2 12:46:42 2016 -0700 Minimal fix-up of bad hashing behavior of hash_64() [ Upstream commit 689de1d6ca95b3b5bd8ee446863bf81a4883ea25 ] This is a fairly minimal fixup to the horribly bad behavior of hash_64() with certain input patterns. In particular, because the multiplicative value used for the 64-bit hash was intentionally bit-sparse (so that the multiply could be done with shifts and adds on architectures without hardware multipliers), some bits did not get spread out very much. In particular, certain fairly common bit ranges in the input (roughly bits 12-20: commonly with the most information in them when you hash things like byte offsets in files or memory that have block factors that mean that the low bits are often zero) would not necessarily show up much in the result. There's a bigger patch-series brewing to fix up things more completely, but this is the fairly minimal fix for the 64-bit hashing problem. It simply picks a much better constant multiplier, spreading the bits out a lot better. NOTE! For 32-bit architectures, the bad old hash_64() remains the same for now, since 64-bit multiplies are expensive. The bigger hashing cleanup will replace the 32-bit case with something better. The new constants were picked by George Spelvin who wrote that bigger cleanup series. I just picked out the constants and part of the comment from that series. Cc: stable@vger.kernel.org Cc: George Spelvin Cc: Thomas Gleixner Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 181fabf9b07d80984c5426a836a2ec86d2f1196e Author: Anton Blanchard Date: Sat Apr 30 08:29:27 2016 +1000 powerpc: Fix bad inline asm constraint in create_zero_mask() [ Upstream commit b4c112114aab9aff5ed4568ca5e662bb02cdfe74 ] In create_zero_mask() we have: addi %1,%2,-1 andc %1,%1,%2 popcntd %0,%1 using the "r" constraint for %2. r0 is a valid register in the "r" set, but addi X,r0,X turns it into an li: li r7,-1 andc r7,r7,r0 popcntd r4,r7 Fix this by using the "b" constraint, for which r0 is not a valid register. This was found with a kernel build using gcc trunk, narrowed down to when -frename-registers was enabled at -O2. It is just luck however that we aren't seeing this on older toolchains. Thanks to Segher for working with me to find this issue. Cc: stable@vger.kernel.org Fixes: d0cebfa650a0 ("powerpc: word-at-a-time optimization for 64-bit Little Endian") Signed-off-by: Anton Blanchard Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit c2c5d8c53238e4c497027c319095d68141802102 Author: K. Y. Srinivasan Date: Sat Apr 2 16:17:38 2016 -0700 Drivers: hv: vmbus: Fix signaling logic in hv_need_to_signal_on_read() [ Upstream commit 1db488d12894f1936360779d6ab2aede3dd7f06a ] On the consumer side, we have interrupt driven flow management of the producer. It is sufficient to base the signaling decision on the amount of space that is available to write after the read is complete. The current code samples the previous available space and uses this in making the signaling decision. This state can be stale and is unnecessary. Since the state can be stale, we end up not signaling the host (when we should) and this can result in a hang. Fix this problem by removing the unnecessary check. I would like to thank Arseney Romanenko for pointing out this issue. Also, issue a full memory barrier before making the signaling descision to correctly deal with potential reordering of the write (read index) followed by the read of pending_sz. Signed-off-by: K. Y. Srinivasan Tested-by: Dexuan Cui Cc: Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ee122c541dfb3edf8ec680fe2ac876dee6fd7e29 Author: Christopher Oo Date: Wed Aug 5 00:52:40 2015 -0700 Drivers: hv_vmbus: Fix signal to host condition [ Upstream commit a5cca686ce0ef4909deaee4ed46dd991e3a9ece4 ] Fixes a bug where previously hv_ringbuffer_read would pass in the old number of bytes available to read instead of the expected old read index when calculating when to signal to the host that the ringbuffer is empty. Since the previous write size is already saved, also changes the hv_need_to_signal_on_read to use the previously read value rather than recalculating it. Signed-off-by: Christopher Oo Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6488b39b0dc54a8528dad6bd0483b79eede0f83b Author: Vitaly Kuznetsov Date: Mon Dec 14 19:01:57 2015 -0800 Drivers: hv: ring_buffer.c: fix comment style [ Upstream commit 822f18d4d3e9d4efb4996bbe562d0f99ab82d7dd ] Convert 6+-string comments repeating function names to normal kernel-style comments and fix a couple of other comment style issues. No textual or functional changes intended. Signed-off-by: Vitaly Kuznetsov Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d6c198421db212898a96a3e34d7e526abca67a3a Author: Al Viro Date: Wed Apr 27 01:11:55 2016 -0400 atomic_open(): fix the handling of create_error [ Upstream commit 10c64cea04d3c75c306b3f990586ffb343b63287 ] * if we have a hashed negative dentry and either CREAT|EXCL on r/o filesystem, or CREAT|TRUNC on r/o filesystem, or CREAT|EXCL with failing may_o_create(), we should fail with EROFS or the error may_o_create() has returned, but not ENOENT. Which is what the current code ends up returning. * if we have CREAT|TRUNC hitting a regular file on a read-only filesystem, we can't fail with EROFS here. At the very least, not until we'd done follow_managed() - we might have a writable file (or a device, for that matter) bound on top of that one. Moreover, the code downstream will see that O_TRUNC and attempt to grab the write access (*after* following possible mount), so if we really should fail with EROFS, it will happen. No need to do that inside atomic_open(). The real logics is much simpler than what the current code is trying to do - if we decided to go for simple lookup, ended up with a negative dentry *and* had create_error set, fail with create_error. No matter whether we'd got that negative dentry from lookup_real() or had found it in dcache. Cc: stable@vger.kernel.org # v3.6+ Acked-by: Miklos Szeredi Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 65c2cfa5e503d8fdca05cd6b75b78e61b4415ae4 Author: Tony Luck Date: Fri Apr 29 15:42:25 2016 +0200 EDAC: i7core, sb_edac: Don't return NOTIFY_BAD from mce_decoder callback [ Upstream commit c4fc1956fa31003bfbe4f597e359d751568e2954 ] Both of these drivers can return NOTIFY_BAD, but this terminates processing other callbacks that were registered later on the chain. Since the driver did nothing to log the error it seems wrong to prevent other interested parties from seeing it. E.g. neither of them had even bothered to check the type of the error to see if it was a memory error before the return NOTIFY_BAD. Signed-off-by: Tony Luck Acked-by: Aristeu Rozanski Acked-by: Mauro Carvalho Chehab Cc: linux-edac Cc: Link: http://lkml.kernel.org/r/72937355dd92318d2630979666063f8a2853495b.1461864507.git.tony.luck@intel.com Signed-off-by: Borislav Petkov Signed-off-by: Sasha Levin commit 59d20caa60a784a52ad5521bbbf0e5c0cf71cf59 Author: Takashi Iwai Date: Fri Apr 29 11:20:15 2016 +0200 ALSA: usb-audio: Quirk for yet another Phoenix Audio devices (v2) [ Upstream commit 2d2c038a9999f423e820d89db2b5d7774b67ba49 ] Phoenix Audio MT202pcs (1de7:0114) and MT202exe (1de7:0013) need the same workaround as TMX320 for avoiding the firmware bug. It fixes the frequent error about the sample rate inquiries and the slow device probe as consequence. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=117321 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 5b065ca240124a69994aee170562217e2bb4c755 Author: Konstantin Khlebnikov Date: Thu Apr 28 16:18:32 2016 -0700 mm/huge_memory: replace VM_NO_THP VM_BUG_ON with actual VMA check [ Upstream commit 3486b85a29c1741db99d0c522211c82d2b7a56d0 ] Khugepaged detects own VMAs by checking vm_file and vm_ops but this way it cannot distinguish private /dev/zero mappings from other special mappings like /dev/hpet which has no vm_ops and popultes PTEs in mmap. This fixes false-positive VM_BUG_ON and prevents installing THP where they are not expected. Link: http://lkml.kernel.org/r/CACT4Y+ZmuZMV5CjSFOeXviwQdABAgT7T+StKfTqan9YDtgEi5g@mail.gmail.com Fixes: 78f11a255749 ("mm: thp: fix /dev/zero MAP_PRIVATE and vm_flags cleanups") Signed-off-by: Konstantin Khlebnikov Reported-by: Dmitry Vyukov Acked-by: Vlastimil Babka Acked-by: Kirill A. Shutemov Cc: Dmitry Vyukov Cc: Andrea Arcangeli Cc: stable Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit a34c1651ea7a55f3c0e77c80c3b27605d5a7dfea Author: Jason Gunthorpe Date: Sun Apr 10 19:13:13 2016 -0600 IB/security: Restrict use of the write() interface [ Upstream commit e6bd18f57aad1a2d1ef40e646d03ed0f2515c9e3 ] The drivers/infiniband stack uses write() as a replacement for bi-directional ioctl(). This is not safe. There are ways to trigger write calls that result in the return structure that is normally written to user space being shunted off to user specified kernel memory instead. For the immediate repair, detect and deny suspicious accesses to the write API. For long term, update the user space libraries and the kernel API to something that doesn't present the same security vulnerabilities (likely a structured ioctl() interface). The impacted uAPI interfaces are generally only available if hardware from drivers/infiniband is installed in the system. Reported-by: Jann Horn Signed-off-by: Linus Torvalds Signed-off-by: Jason Gunthorpe [ Expanded check to all known write() entry points ] Cc: stable@vger.kernel.org Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin commit c2cf8eb1284508d30f91ec4f652e18d3c40a3f15 Author: Sascha Hauer Date: Wed Apr 20 13:34:31 2016 +0000 ARM: SoCFPGA: Fix secondary CPU startup in thumb2 kernel [ Upstream commit 5616f36713ea77f57ae908bf2fef641364403c9f ] The secondary CPU starts up in ARM mode. When the kernel is compiled in thumb2 mode we have to explicitly compile the secondary startup trampoline in ARM mode, otherwise the CPU will go to Nirvana. Signed-off-by: Sascha Hauer Reported-by: Steffen Trumtrar Suggested-by: Ard Biesheuvel Cc: stable@vger.kernel.org Signed-off-by: Dinh Nguyen Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin commit 3473d3984bae7f7f3012ca46290ae0bb2433e537 Author: Imre Deak Date: Mon Apr 18 10:04:21 2016 +0300 drm/i915/ddi: Fix eDP VDD handling during booting and suspend/resume [ Upstream commit 5eaa60c7109b40f17ac81090bc8b90482da76cd1 ] The driver's VDD on/off logic assumes that whenever the VDD is on we also hold an AUX power domain reference. Since BIOS can leave the VDD on during booting and resuming and on DDI platforms we won't take a corresponding power reference, the above assumption won't hold on those platforms and an eventual delayed VDD off work will do an extraneous AUX power domain put resulting in a refcount underflow. Fix this the same way we did this for non-DDI DP encoders: commit 6d93c0c41760c0 ("drm/i915: fix VDD state tracking after system resume") At the same time call the DP encoder suspend handler the same way as the non-DDI DP encoders do to flush any pending VDD off work. Leaving the work running may cause a HW access where we don't expect this (at a point where power domains are suspended already). While at it remove an unnecessary function call indirection. This fixed for me AUX refcount underflow problems on BXT during suspend/resume. CC: Ville Syrjälä CC: stable@vger.kernel.org Signed-off-by: Imre Deak Reviewed-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/1460963062-13211-4-git-send-email-imre.deak@intel.com (cherry picked from commit bf93ba67e9c05882f05b7ca2d773cfc8bf462c2a) Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit e7251e61b00c0f2cb018482ece8d48713baae99f Author: Ville Syrjälä Date: Tue Oct 28 16:15:52 2014 +0200 drm/i915: Read out the power sequencer port assignment on resume on vlv/chv [ Upstream commit 49e6bc51bc9e22c8a433ba32a4e45a5818de3850 ] When we suspend we turn everything off so the pps should be idle, and we also (or at least should) disable all power wells which will reset the power sequencer port assignment. So when we resume all power sequencers should be in their reset state. However it's at least theoretically possible that the BIOS would touch the power seuqencer(s), so to be safe we ought to read out the current port assignment like we do at driver init time. To do that we can simply call vlv_initial_power_sequencer_setup() from the encoder ->reset() hook before calling intel_edp_panel_vdd_sanitize(). There's no danger or clobbering the pps delays since we now have those stored within intel_dp and we don't change them once initialized. This will make sure that the vdd state gets correctly tracked post-resume in case the BIOS enabled it. We need to shuffle things around a bit to get the locking right, and while at it, make intel_edp_panel_vdd_sanitize() static and move it around a bit to avoid a forward declaration. Cc: Imre Deak Signed-off-by: Ville Syrjälä Reviewed-by: Imre Deak Signed-off-by: Daniel Vetter Signed-off-by: Sasha Levin commit 625e43ab5cdd182ea89b160e8ae7008f5bc0219c Author: Michael Neuling Date: Fri Apr 22 14:57:48 2016 +1000 cxl: Keep IRQ mappings on context teardown [ Upstream commit d6776bba44d9752f6cdf640046070e71ee4bba7b ] Keep IRQ mappings on context teardown. This won't leak IRQs as if we allocate the mapping again, the generic code will give the same mapping used last time. Doing this works around a race in the generic code. Masking the interrupt introduces a race which can crash the kernel or result in IRQ that is never EOIed. The lost of EOI results in all subsequent mappings to the same HW IRQ never receiving an interrupt. We've seen this race with cxl test cases which are doing heavy context startup and teardown at the same time as heavy interrupt load. A fix to the generic code is being investigated also. Signed-off-by: Michael Neuling Cc: stable@vger.kernel.org # 3.8 Tested-by: Andrew Donnellan Acked-by: Ian Munsie Tested-by: Vaibhav Jain Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 8e1a3e4113a6e44f4dbe8e32bcdbe895529ea30a Author: Lyude Date: Wed Apr 13 16:50:18 2016 -0400 drm/dp/mst: Restore primary hub guid on resume [ Upstream commit 9dc0487d96a0396367a1451b31873482080b527f ] Some hubs are forgetful, and end up forgetting whatever GUID we set previously after we do a suspend/resume cycle. This can lead to hotplugging breaking (along with probably other things) since the hub will start sending connection notifications with the wrong GUID. As such, we need to check on resume whether or not the GUID the hub is giving us is valid. Signed-off-by: Lyude Reviewed-by: Harry Wentland Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1460580618-7421-1-git-send-email-cpaul@redhat.com Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin commit d5bcc8d3fbf61bd46cbb3ad111f84dd78f6905f1 Author: cpaul@redhat.com Date: Fri Apr 22 16:08:46 2016 -0400 drm/dp/mst: Get validated port ref in drm_dp_update_payload_part1() [ Upstream commit 263efde31f97c498e1ebad30e4d2906609d7ad6b ] We can thank KASAN for finding this, otherwise I probably would have spent hours on it. This fixes a somewhat harder to trigger kernel panic, occuring while enabling MST where the port we were currently updating the payload on would have all of it's refs dropped before we finished what we were doing: ================================================================== BUG: KASAN: use-after-free in drm_dp_update_payload_part1+0xb3f/0xdb0 [drm_kms_helper] at addr ffff8800d29de018 Read of size 4 by task Xorg/973 ============================================================================= BUG kmalloc-2048 (Tainted: G B W ): kasan: bad access detected ----------------------------------------------------------------------------- INFO: Allocated in drm_dp_add_port+0x1aa/0x1ed0 [drm_kms_helper] age=16477 cpu=0 pid=2175 ___slab_alloc+0x472/0x490 __slab_alloc+0x20/0x40 kmem_cache_alloc_trace+0x151/0x190 drm_dp_add_port+0x1aa/0x1ed0 [drm_kms_helper] drm_dp_send_link_address+0x526/0x960 [drm_kms_helper] drm_dp_check_and_send_link_address+0x1ac/0x210 [drm_kms_helper] drm_dp_mst_link_probe_work+0x77/0xd0 [drm_kms_helper] process_one_work+0x562/0x1350 worker_thread+0xd9/0x1390 kthread+0x1c5/0x260 ret_from_fork+0x22/0x40 INFO: Freed in drm_dp_free_mst_port+0x50/0x60 [drm_kms_helper] age=7521 cpu=0 pid=2175 __slab_free+0x17f/0x2d0 kfree+0x169/0x180 drm_dp_free_mst_port+0x50/0x60 [drm_kms_helper] drm_dp_destroy_connector_work+0x2b8/0x490 [drm_kms_helper] process_one_work+0x562/0x1350 worker_thread+0xd9/0x1390 kthread+0x1c5/0x260 ret_from_fork+0x22/0x40 which on this T460s, would eventually lead to kernel panics in somewhat random places later in intel_mst_enable_dp() if we got lucky enough. Signed-off-by: Lyude Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin commit c25e59bfcab671225dadd8e99b3682be1ea18b33 Author: Roman Pen Date: Tue Apr 26 13:15:35 2016 +0200 workqueue: fix ghost PENDING flag while doing MQ IO [ Upstream commit 346c09f80459a3ad97df1816d6d606169a51001a ] The bug in a workqueue leads to a stalled IO request in MQ ctx->rq_list with the following backtrace: [ 601.347452] INFO: task kworker/u129:5:1636 blocked for more than 120 seconds. [ 601.347574] Tainted: G O 4.4.5-1-storage+ #6 [ 601.347651] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 601.348142] kworker/u129:5 D ffff880803077988 0 1636 2 0x00000000 [ 601.348519] Workqueue: ibnbd_server_fileio_wq ibnbd_dev_file_submit_io_worker [ibnbd_server] [ 601.348999] ffff880803077988 ffff88080466b900 ffff8808033f9c80 ffff880803078000 [ 601.349662] ffff880807c95000 7fffffffffffffff ffffffff815b0920 ffff880803077ad0 [ 601.350333] ffff8808030779a0 ffffffff815b01d5 0000000000000000 ffff880803077a38 [ 601.350965] Call Trace: [ 601.351203] [] ? bit_wait+0x60/0x60 [ 601.351444] [] schedule+0x35/0x80 [ 601.351709] [] schedule_timeout+0x192/0x230 [ 601.351958] [] ? blk_flush_plug_list+0xc7/0x220 [ 601.352208] [] ? ktime_get+0x37/0xa0 [ 601.352446] [] ? bit_wait+0x60/0x60 [ 601.352688] [] io_schedule_timeout+0xa4/0x110 [ 601.352951] [] ? _raw_spin_unlock_irqrestore+0xe/0x10 [ 601.353196] [] bit_wait_io+0x1b/0x70 [ 601.353440] [] __wait_on_bit+0x5d/0x90 [ 601.353689] [] wait_on_page_bit+0xc0/0xd0 [ 601.353958] [] ? autoremove_wake_function+0x40/0x40 [ 601.354200] [] __filemap_fdatawait_range+0xe4/0x140 [ 601.354441] [] filemap_fdatawait_range+0x14/0x30 [ 601.354688] [] filemap_write_and_wait_range+0x3f/0x70 [ 601.354932] [] blkdev_fsync+0x1b/0x50 [ 601.355193] [] vfs_fsync_range+0x49/0xa0 [ 601.355432] [] blkdev_write_iter+0xca/0x100 [ 601.355679] [] __vfs_write+0xaa/0xe0 [ 601.355925] [] vfs_write+0xa9/0x1a0 [ 601.356164] [] kernel_write+0x38/0x50 The underlying device is a null_blk, with default parameters: queue_mode = MQ submit_queues = 1 Verification that nullb0 has something inflight: root@pserver8:~# cat /sys/block/nullb0/inflight 0 1 root@pserver8:~# find /sys/block/nullb0/mq/0/cpu* -name rq_list -print -exec cat {} \; ... /sys/block/nullb0/mq/0/cpu2/rq_list CTX pending: ffff8838038e2400 ... During debug it became clear that stalled request is always inserted in the rq_list from the following path: save_stack_trace_tsk + 34 blk_mq_insert_requests + 231 blk_mq_flush_plug_list + 281 blk_flush_plug_list + 199 wait_on_page_bit + 192 __filemap_fdatawait_range + 228 filemap_fdatawait_range + 20 filemap_write_and_wait_range + 63 blkdev_fsync + 27 vfs_fsync_range + 73 blkdev_write_iter + 202 __vfs_write + 170 vfs_write + 169 kernel_write + 56 So blk_flush_plug_list() was called with from_schedule == true. If from_schedule is true, that means that finally blk_mq_insert_requests() offloads execution of __blk_mq_run_hw_queue() and uses kblockd workqueue, i.e. it calls kblockd_schedule_delayed_work_on(). That means, that we race with another CPU, which is about to execute __blk_mq_run_hw_queue() work. Further debugging shows the following traces from different CPUs: CPU#0 CPU#1 ---------------------------------- ------------------------------- reqeust A inserted STORE hctx->ctx_map[0] bit marked kblockd_schedule...() returns 1 request B inserted STORE hctx->ctx_map[1] bit marked kblockd_schedule...() returns 0 *** WORK PENDING bit is cleared *** flush_busy_ctxs() is executed, but bit 1, set by CPU#1, is not observed As a result request B pended forever. This behaviour can be explained by speculative LOAD of hctx->ctx_map on CPU#0, which is reordered with clear of PENDING bit and executed _before_ actual STORE of bit 1 on CPU#1. The proper fix is an explicit full barrier , which guarantees that clear of PENDING bit is to be executed before all possible speculative LOADS or STORES inside actual work function. Signed-off-by: Roman Pen Cc: Gioh Kim Cc: Michael Wang Cc: Tejun Heo Cc: Jens Axboe Cc: linux-block@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 8291565d12223ebc7ef14dd4e9a284b956cd3066 Author: Conrad Kostecki Date: Tue Apr 26 10:08:10 2016 +0200 ALSA: hda - Add dock support for ThinkPad X260 [ Upstream commit 037e119738120c1cdc460c6ae33871c3000531f3 ] Fixes audio output on a ThinkPad X260, when using Lenovo CES 2013 docking station series (basic, pro, ultra). Signed-off-by: Conrad Kostecki Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 4c6a29348c5f7b692c23542c52bf26b471fee2ee Author: Shaohua Li Date: Mon Apr 25 16:52:38 2016 -0700 MD: make bio mergeable [ Upstream commit 9c573de3283af007ea11c17bde1e4568d9417328 ] blk_queue_split marks bio unmergeable, which makes sense for normal bio. But if dispatching the bio to underlayer disk, the blk_queue_split checks are invalid, hence it's possible the bio becomes mergeable. In the reported bug, this bug causes trim against raid0 performance slash https://bugzilla.kernel.org/show_bug.cgi?id=117051 Reported-and-tested-by: Park Ju Hyung Fixes: 6ac45aeb6bca(block: avoid to merge splitted bio) Cc: stable@vger.kernel.org (v4.3+) Cc: Ming Lei Cc: Neil Brown Reviewed-by: Jens Axboe Signed-off-by: Shaohua Li Signed-off-by: Sasha Levin commit 44c1efb35ee387bbef4c052803ea196aaab0012e Author: Hans Verkuil Date: Fri Apr 22 04:00:50 2016 -0300 [media] v4l2-dv-timings.h: fix polarity for 4k formats [ Upstream commit 3020ca711871fdaf0c15c8bab677a6bc302e28fe ] The VSync polarity was negative instead of positive for the 4k CEA formats. I probably copy-and-pasted these from the DMT 4k format, which does have a negative VSync polarity. Signed-off-by: Hans Verkuil Reported-by: Martin Bugge Cc: # for v4.1 and up Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 68b3d8c0190d7d3ec635704280c792f11c981f54 Author: Jasem Mutlaq Date: Tue Apr 19 10:38:27 2016 +0300 USB: serial: cp210x: add Straizona Focusers device ids [ Upstream commit 613ac23a46e10d4d4339febdd534fafadd68e059 ] Adding VID:PID for Straizona Focusers to cp210x driver. Signed-off-by: Jasem Mutlaq Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 9018dc05e2e8459099fbb3f020e5846d6ec3ef4d Author: Mike Manning Date: Mon Apr 18 12:13:23 2016 +0000 USB: serial: cp210x: add ID for Link ECU [ Upstream commit 1d377f4d690637a0121eac8701f84a0aa1e69a69 ] The Link ECU is an aftermarket ECU computer for vehicles that provides full tuning abilities as well as datalogging and displaying capabilities via the USB to Serial adapter built into the device. Signed-off-by: Mike Manning Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit bdd224bd31f34e350917f8fb41955b1373fc17a0 Author: Laszlo Ersek Date: Thu Apr 21 18:21:11 2016 +0200 efi: Fix out-of-bounds read in variable_matches() [ Upstream commit 630ba0cc7a6dbafbdee43795617c872b35cde1b4 ] The variable_matches() function can currently read "var_name[len]", for example when: - var_name[0] == 'a', - len == 1 - match_name points to the NUL-terminated string "ab". This function is supposed to accept "var_name" inputs that are not NUL-terminated (hence the "len" parameter"). Document the function, and access "var_name[*match]" only if "*match" is smaller than "len". Reported-by: Chris Wilson Signed-off-by: Laszlo Ersek Cc: Peter Jones Cc: Matthew Garrett Cc: Jason Andryuk Cc: Jani Nikula Cc: # v3.10+ Link: http://thread.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/86906 Signed-off-by: Matt Fleming Signed-off-by: Sasha Levin commit addbcc62bcbc8b38829deec23295c86013633f39 Author: Krzysztof Kozlowski Date: Mon Apr 4 14:54:59 2016 +0900 iio: ak8975: Fix NULL pointer exception on early interrupt [ Upstream commit 07d2390e36ee5b3265e9cc8305f2a106c8721e16 ] In certain probe conditions the interrupt came right after registering the handler causing a NULL pointer exception because of uninitialized waitqueue: $ udevadm trigger i2c-gpio i2c-gpio-1: using pins 143 (SDA) and 144 (SCL) i2c-gpio i2c-gpio-3: using pins 53 (SDA) and 52 (SCL) Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = e8b38000 [00000000] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM Modules linked in: snd_soc_i2s(+) i2c_gpio(+) snd_soc_idma snd_soc_s3c_dma snd_soc_core snd_pcm_dmaengine snd_pcm snd_timer snd soundcore ac97_bus spi_s3c64xx pwm_samsung dwc2 exynos_adc phy_exynos_usb2 exynosdrm exynos_rng rng_core rtc_s3c CPU: 0 PID: 717 Comm: data-provider-m Not tainted 4.6.0-rc1-next-20160401-00011-g1b8d87473b9e-dirty #101 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) (...) (__wake_up_common) from [] (__wake_up+0x38/0x4c) (__wake_up) from [] (ak8975_irq_handler+0x28/0x30) (ak8975_irq_handler) from [] (handle_irq_event_percpu+0x88/0x140) (handle_irq_event_percpu) from [] (handle_irq_event+0x44/0x68) (handle_irq_event) from [] (handle_edge_irq+0xf0/0x19c) (handle_edge_irq) from [] (generic_handle_irq+0x24/0x34) (generic_handle_irq) from [] (exynos_eint_gpio_irq+0x50/0x68) (exynos_eint_gpio_irq) from [] (handle_irq_event_percpu+0x88/0x140) (handle_irq_event_percpu) from [] (handle_irq_event+0x44/0x68) (handle_irq_event) from [] (handle_fasteoi_irq+0xb4/0x194) (handle_fasteoi_irq) from [] (generic_handle_irq+0x24/0x34) (generic_handle_irq) from [] (__handle_domain_irq+0x5c/0xb4) (__handle_domain_irq) from [] (gic_handle_irq+0x54/0x94) (gic_handle_irq) from [] (__irq_usr+0x50/0x80) The bug was reproduced on exynos4412-trats2 (with a max77693 device also using i2c-gpio) after building max77693 as a module. Cc: Fixes: 94a6d5cf7caa ("iio:ak8975 Implement data ready interrupt handling") Signed-off-by: Krzysztof Kozlowski Tested-by: Gregor Boirie Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit b1da9479174d813374efd4103ba2233e5044dcd2 Author: Jack Pham Date: Thu Apr 14 23:37:26 2016 -0700 regmap: spmi: Fix regmap_spmi_ext_read in multi-byte case [ Upstream commit dec8e8f6e6504aa3496c0f7cc10c756bb0e10f44 ] Specifically for the case of reads that use the Extended Register Read Long command, a multi-byte read operation is broken up into 8-byte chunks. However the call to spmi_ext_register_readl() is incorrectly passing 'val_size', which if greater than 8 will always fail. The argument should instead be 'len'. Fixes: c9afbb05a9ff ("regmap: spmi: support base and extended register spaces") Signed-off-by: Jack Pham Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit f9133a946b21af76708e868eb299f1f26ec82e61 Author: Srinivas Kandagatla Date: Fri Apr 1 08:52:57 2016 +0100 ata: ahci-platform: Add ports-implemented DT bindings. [ Upstream commit 17dcc37e3e847bc0e67a5b1ec52471fcc6c18682 ] On some SOCs PORTS_IMPL register value is never programmed by the firmware and left at zero value. Which means that no sata ports are available for software. AHCI driver used to cope up with this by fabricating the port_map if the PORTS_IMPL register is read zero, but recent patch broke this workaround as zero value was valid for NVMe disks. This patch adds ports-implemented DT bindings as workaround for this issue in a way that DT can can override the PORTS_IMPL register in cases where the firmware did not program it already. Fixes: 566d1827df2e ("libata: disable forced PORTS_IMPL for >= AHCI 1.3") Cc: stable@vger.kernel.org # v4.5+ Signed-off-by: Srinivas Kandagatla Acked-by: Tejun Heo Reviewed-by: Andy Gross Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 743f6ef19cd84b28f02c2fc60db6a046730c1a52 Author: Srinivas Kandagatla Date: Fri Apr 1 08:52:56 2016 +0100 libahci: save port map for forced port map [ Upstream commit 2fd0f46cb1b82587c7ae4a616d69057fb9bd0af7 ] In usecases where force_port_map is used saved_port_map is never set, resulting in not programming the PORTS_IMPL register as part of initial config. This patch fixes this by setting it to port_map even in case where force_port_map is used, making it more inline with other parts of the code. Fixes: 566d1827df2e ("libata: disable forced PORTS_IMPL for >= AHCI 1.3") Cc: stable@vger.kernel.org # v4.5+ Signed-off-by: Srinivas Kandagatla Acked-by: Tejun Heo Reviewed-by: Andy Gross Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 8486a92a0f54ec06435333258fb3e35dd8ab7430 Author: Krzysztof Kozlowski Date: Mon Mar 28 13:09:56 2016 +0900 regulator: s2mps11: Fix invalid selector mask and voltages for buck9 [ Upstream commit 3b672623079bb3e5685b8549e514f2dfaa564406 ] The buck9 regulator of S2MPS11 PMIC had incorrect vsel_mask (0xff instead of 0x1f) thus reading entire register as buck9's voltage. This effectively caused regulator core to interpret values as higher voltages than they were and then to set real voltage much lower than intended. The buck9 provides power to other regulators, including LDO13 and LDO19 which supply the MMC2 (SD card). On Odroid XU3/XU4 the lower voltage caused SD card detection errors on Odroid XU3/XU4: mmc1: card never left busy state mmc1: error -110 whilst initialising SD card During driver probe the regulator core was checking whether initial voltage matches the constraints. With incorrect vsel_mask of 0xff and default value of 0x50, the core interpreted this as 5 V which is outside of constraints (3-3.775 V). Then the regulator core was adjusting the voltage to match the constraints. With incorrect vsel_mask this new voltage mapped to a vere low voltage in the driver. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Javier Martinez Canillas Tested-by: Javier Martinez Canillas Signed-off-by: Mark Brown Cc: Signed-off-by: Sasha Levin commit 8f16cd2771581eb91ac09387fbb94ad748735d2a Author: Sugar Zhang Date: Fri Mar 18 14:54:22 2016 +0800 ASoC: rt5640: Correct the digital interface data select [ Upstream commit 653aa4645244042826f105aab1be3d01b3d493ca ] this patch corrects the interface adc/dac control register definition according to datasheet. Signed-off-by: Sugar Zhang Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 39ad49c725b892cc54878da2ddd7a7b418d21893 Author: Tejun Heo Date: Mon May 16 09:33:01 2016 +0300 timers: Use proper base migration in add_timer_on() [ Upstream commit 22b886dd1018093920c4250dee2a9a3cb7cff7b8 ] Regardless of the previous CPU a timer was on, add_timer_on() currently simply sets timer->flags to the new CPU. As the caller must be seeing the timer as idle, this is locally fine, but the timer leaving the old base while unlocked can lead to race conditions as follows. Let's say timer was on cpu 0. cpu 0 cpu 1 ----------------------------------------------------------------------------- del_timer(timer) succeeds del_timer(timer) lock_timer_base(timer) locks cpu_0_base add_timer_on(timer, 1) spin_lock(&cpu_1_base->lock) timer->flags set to cpu_1_base operates on @timer operates on @timer This triggered with mod_delayed_work_on() which contains "if (del_timer()) add_timer_on()" sequence eventually leading to the following oops. BUG: unable to handle kernel NULL pointer dereference at (null) IP: [] detach_if_pending+0x69/0x1a0 ... Workqueue: wqthrash wqthrash_workfunc [wqthrash] task: ffff8800172ca680 ti: ffff8800172d0000 task.ti: ffff8800172d0000 RIP: 0010:[] [] detach_if_pending+0x69/0x1a0 ... Call Trace: [] del_timer+0x44/0x60 [] try_to_grab_pending+0xb6/0x160 [] mod_delayed_work_on+0x33/0x80 [] wqthrash_workfunc+0x61/0x90 [wqthrash] [] process_one_work+0x1e8/0x650 [] worker_thread+0x4e/0x450 [] kthread+0xef/0x110 [] ret_from_fork+0x3f/0x70 Fix it by updating add_timer_on() to perform proper migration as __mod_timer() does. Reported-and-tested-by: Jeff Layton Signed-off-by: Tejun Heo Cc: Chris Worley Cc: bfields@fieldses.org Cc: Michael Skralivetsky Cc: Trond Myklebust Cc: Shaohua Li Cc: Jeff Layton Cc: kernel-team@fb.com Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/20151029103113.2f893924@tlielax.poochiereds.net Link: http://lkml.kernel.org/r/20151104171533.GI5749@mtj.duckdns.org Signed-off-by: Thomas Gleixner Signed-off-by: Konstantin Khlebnikov ( backport for 3.18 ) Signed-off-by: Sasha Levin commit 65b49b662365b54d3c372734a8591b404a43397f Author: Greg Kroah-Hartman Date: Sat Feb 20 14:19:34 2016 -0800 Revert "usb: hub: do not clear BOS field during reset device" This reverts commit f9b3d78ac42bda9cd30e4c6d0149dba7067c402c. Tony writes: This upstream commit is causing an oops: d8f00cd685f5 ("usb: hub: do not clear BOS field during reset device") This patch has already been included in several -stable kernels. Here are the affected kernels: 4.5.0-rc4 (current git) 4.4.2 4.3.6 (currently in review) 4.1.18 3.18.27 3.14.61 How to reproduce the problem: Boot kernel with slub debugging enabled (otherwise memory corruption will cause random oopses later instead of immediately) Plug in USB 3.0 disk to xhci USB 3.0 port dd if=/dev/sdc of=/dev/null bs=65536 (where /dev/sdc is the USB 3.0 disk) Unplug USB cable while dd is still going Oops is immediate: Reported-by: Tony Battersby Signed-off-by: Sasha Levin