commit e429f243df2823451c92227317e5fce5f310b674 Author: Sasha Levin Date: Fri May 20 21:46:13 2016 -0400 Linux 4.1.25 Signed-off-by: Sasha Levin commit 8de861b16d946b7c0ce246fcbb65d550c357c65c 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 631598a5c08505c92348b3907824072d0c1000ab 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 533e936848522f8394709b64fba45f657ca26f10 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 2239ca3f89e5dfb1f24e98207318d91e6c2cf0f7 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 6bdf63fe8999171e65f6b65bf837d3c5f8571da1 Author: Alex Deucher Date: Wed May 11 16:16:53 2016 -0400 drm/radeon: fix DP mode validation [ Upstream commit ff0bd441bdfbfa09d05fdba9829a0401a46635c1 ] Switch the order of the loops to walk the rates on the top so we exhaust all DP 1.1 rate/lane combinations before trying DP 1.2 rate/lane combos. This avoids selecting rates that are supported by the monitor, but not the connector leading to valid modes getting rejected. bug: https://bugs.freedesktop.org/show_bug.cgi?id=95206 Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 3a1b9a74de5c10995d1fd842e3d2344d4e826ae1 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 47348e3fcc9aeeb64d792d05c735b37b2c22fbac 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 6f24160677ab5a2783b7f1f2ea5c2a23526d494e Author: Alexander Shishkin Date: Tue May 10 16:18:33 2016 +0300 perf/core: Disable the event on a truncated AUX record [ Upstream commit 9f448cd3cbcec8995935e60b27802ae56aac8cc0 ] When the PMU driver reports a truncated AUX record, it effectively means that there is no more usable room in the event's AUX buffer (even though there may still be some room, so that perf_aux_output_begin() doesn't take action). At this point the consumer still has to be woken up and the event has to be disabled, otherwise the event will just keep spinning between perf_aux_output_begin() and perf_aux_output_end() until its context gets unscheduled. Again, for cpu-wide events this means never, so once in this condition, they will be forever losing data. Fix this by disabling the event and waking up the consumer in case of a truncated AUX record. Reported-by: Markus Metzger Signed-off-by: Alexander Shishkin Signed-off-by: Peter Zijlstra (Intel) Cc: Cc: Arnaldo Carvalho de Melo Cc: Arnaldo Carvalho de Melo Cc: Borislav Petkov Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Cc: vince@deater.net Link: http://lkml.kernel.org/r/1462886313-13660-3-git-send-email-alexander.shishkin@linux.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit e5c1c3a557c8412a9afe7bc346976e93de95c1c5 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 f9a461fc2d0ffc46b1b4372297ba051325013d11 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 41d234935fe0e793093bf98fc49d740c207f3729 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 87cc31ebd15957113ccdaaa6580264e460b2273c 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 da58c2eb0bdbfa02cd32d5c8e73ff21c7c49b601 Author: Takashi Iwai Date: Tue May 10 10:24:02 2016 +0200 ALSA: hda - Fix broken reconfig [ Upstream commit addacd801e1638f41d659cb53b9b73fc14322cb1 ] The HD-audio reconfig function got broken in the recent kernels, typically resulting in a failure like: snd_hda_intel 0000:00:1b.0: control 3:0:0:Playback Channel Map:0 is already present This is because of the code restructuring to move the PCM and control instantiation into the codec drive probe, by the commit [bcd96557bd0a: ALSA: hda - Build PCMs and controls at codec driver probe]. Although the commit above removed the calls of snd_hda_codec_build_pcms() and *_build_controls() at the controller driver probe, the similar calls in the reconfig were still left forgotten. This caused the conflicting and duplicated PCMs and controls. The fix is trivial: just remove these superfluous calls from reconfig_codec(). Fixes: bcd96557bd0a ('ALSA: hda - Build PCMs and controls at codec driver probe') Reported-by: Jochen Henneberg Cc: # v4.1+ Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 4a4c1df1af598459b550861f6bff17bfd8792295 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 6225c54e09f0f22454cc08a2526765226559ede6 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 53c60e1ab465c8032b1795a2192aa00dcedec5db 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 3f81442f44c1736e78a41afef728160f3dc9fae3 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 f1ee8222aed8d64bbf922ba9bf00dc7ac98ab63f 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 53e7d7c9357328ba627204ebf8c14773ad514f58 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 fbb78d42a4923cca5a9322ae495a6e2c1d4455f5 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 c58ca6100b3d1b9890776d9fdd8aa12352d49bc8 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 c42d74f018b072b30570856dd43ff582c4e5117e Author: Arindam Nath Date: Wed May 4 23:39:59 2016 +0530 drm/radeon: fix DP link training issue with second 4K monitor [ Upstream commit 1a738347df2ee4977459a8776fe2c62196bdcb1b ] There is an issue observed when we hotplug a second DP 4K monitor to the system. Sometimes, the link training fails for the second monitor after HPD interrupt generation. The issue happens when some queued or deferred transactions are already present on the AUX channel when we initiate a new transcation to (say) get DPCD or during link training. We set AUX_IGNORE_HPD_DISCON bit in the AUX_CONTROL register so that we can ignore any such deferred transactions when a new AUX transaction is initiated. Signed-off-by: Arindam Nath Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 60f7e3a2dc30ae39574a7c7239a9a47c08b774bd 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 2d7405bfccabafa2f0c2ecf535d251da640cfade 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 ade3716f4dff60c9aab9f71a5190615effbdf169 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 1669540814a1cf57ff50e037c5bf84f831ea4e09 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 a10c059ad73b3b84c349592e72d445d9c73a1e27 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 d15451da634fffa57e013f7c2a9f7db6c65a9a1e 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 d102342c3a8e0e791ba934cc3a43b0ed80b28938 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 3216eb22857e515aa89f594f84c0ef2a36a59b08 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 9abc9e72c77166342589d02fb7c0dcabe78d9358 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 420b214c8f04158d05bf01ea95d00b0f1592966e 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 c172113994b7feb3f1d7fa92b9e803e31d03a256 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 26ac029f2468a529bf5c9c3a5d9ef7a27376218a 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 3807acbd300b39054d45460b19067ce7ef8b1ae9 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 9ddd834043f14442b4c40ffc7b86de9e4f5f0ffe 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 cb4a26d103973231b1a4f6b4c1495f41aaeb9980 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 74e15f5d4bea6f5035641ed75c2c111a153ee7b2 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 9de27bd72b3aba88cf7847e8834cc54745ea3352 Author: Naoya Horiguchi Date: Thu Aug 6 15:47:08 2015 -0700 mm: check __PG_HWPOISON separately from PAGE_FLAGS_CHECK_AT_* [ Upstream commit f4c18e6f7b5bbb5b528b3334115806b0d76f50f9 ] The race condition addressed in commit add05cecef80 ("mm: soft-offline: don't free target page in successful page migration") was not closed completely, because that can happen not only for soft-offline, but also for hard-offline. Consider that a slab page is about to be freed into buddy pool, and then an uncorrected memory error hits the page just after entering __free_one_page(), then VM_BUG_ON_PAGE(page->flags & PAGE_FLAGS_CHECK_AT_PREP) is triggered, despite the fact that it's not necessary because the data on the affected page is not consumed. To solve it, this patch drops __PG_HWPOISON from page flag checks at allocation/free time. I think it's justified because __PG_HWPOISON flags is defined to prevent the page from being reused, and setting it outside the page's alloc-free cycle is a designed behavior (not a bug.) For recent months, I was annoyed about BUG_ON when soft-offlined page remains on lru cache list for a while, which is avoided by calling put_page() instead of putback_lru_page() in page migration's success path. This means that this patch reverts a major change from commit add05cecef80 about the new refcounting rule of soft-offlined pages, so "reuse window" revives. This will be closed by a subsequent patch. Signed-off-by: Naoya Horiguchi Cc: Andi Kleen Cc: Dean Nelson Cc: Tony Luck Cc: "Kirill A. Shutemov" Cc: Hugh Dickins Cc: David Rientjes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 6936c1672176fa8403818ff95cff1f4a972b787d Author: Naoya Horiguchi Date: Wed Jun 24 16:56:50 2015 -0700 mm: soft-offline: don't free target page in successful page migration [ Upstream commit add05cecef803f3372c5fc1d2a964171872daf9f ] Stress testing showed that soft offline events for a process iterating "mmap-pagefault-munmap" loop can trigger VM_BUG_ON(PAGE_FLAGS_CHECK_AT_PREP) in __free_one_page(): Soft offlining page 0x70fe1 at 0x70100008d000 Soft offlining page 0x705fb at 0x70300008d000 page:ffffea0001c3f840 count:0 mapcount:0 mapping: (null) index:0x2 flags: 0x1fffff80800000(hwpoison) page dumped because: VM_BUG_ON_PAGE(page->flags & ((1 << 25) - 1)) ------------[ cut here ]------------ kernel BUG at /src/linux-dev/mm/page_alloc.c:585! invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC Modules linked in: cfg80211 rfkill crc32c_intel microcode ppdev parport_pc pcspkr serio_raw virtio_balloon parport i2c_piix4 virtio_blk virtio_net ata_generic pata_acpi floppy CPU: 3 PID: 1779 Comm: test_base_madv_ Not tainted 4.0.0-v4.0-150511-1451-00009-g82360a3730e6 #139 RIP: free_pcppages_bulk+0x52a/0x6f0 Call Trace: drain_pages_zone+0x3d/0x50 drain_local_pages+0x1d/0x30 on_each_cpu_mask+0x46/0x80 drain_all_pages+0x14b/0x1e0 soft_offline_page+0x432/0x6e0 SyS_madvise+0x73c/0x780 system_call_fastpath+0x12/0x17 Code: ff 89 45 b4 48 8b 45 c0 48 83 b8 a8 00 00 00 00 0f 85 e3 fb ff ff 0f 1f 00 0f 0b 48 8b 7d 90 48 c7 c6 e8 95 a6 81 e8 e6 32 02 00 <0f> 0b 8b 45 cc 49 89 47 30 41 8b 47 18 83 f8 ff 0f 85 10 ff ff RIP [] free_pcppages_bulk+0x52a/0x6f0 RSP ---[ end trace 53926436e76d1f35 ]--- When soft offline successfully migrates page, the source page is supposed to be freed. But there is a race condition where a source page looks isolated (i.e. the refcount is 0 and the PageHWPoison is set) but somewhat linked to pcplist. Then another soft offline event calls drain_all_pages() and tries to free such hwpoisoned page, which is forbidden. This odd page state seems to happen due to the race between put_page() in putback_lru_page() and __pagevec_lru_add_fn(). But I don't want to play with tweaking drain code as done in commit 9ab3b598d2df "mm: hwpoison: drop lru_add_drain_all() in __soft_offline_page()", or to change page freeing code for this soft offline's purpose. Instead, let's think about the difference between hard offline and soft offline. There is an interesting difference in how to isolate the in-use page between these, that is, hard offline marks PageHWPoison of the target page at first, and doesn't free it by keeping its refcount 1. OTOH, soft offline tries to free the target page then marks PageHWPoison. This difference might be the source of complexity and result in bugs like the above. So making soft offline isolate with keeping refcount can be a solution for this problem. We can pass to page migration code the "reason" which shows the caller, so let's use this more to avoid calling putback_lru_page() when called from soft offline, which effectively does the isolation for soft offline. With this change, target pages of soft offline never be reused without changing migratetype, so this patch also removes the related code. Signed-off-by: Naoya Horiguchi Cc: Andi Kleen Cc: Tony Luck Cc: "Kirill A. Shutemov" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 978d733ff9e591c384d1d43d89087943a78f9605 Author: Minchan Kim Date: Thu Apr 28 16:18:38 2016 -0700 mm: vmscan: reclaim highmem zone if buffer_heads is over limit [ Upstream commit 7bf52fb891b64b8d61caf0b82060adb9db761aec ] We have been reclaimed highmem zone if buffer_heads is over limit but commit 6b4f7799c6a5 ("mm: vmscan: invoke slab shrinkers from shrink_zone()") changed the behavior so it doesn't reclaim highmem zone although buffer_heads is over the limit. This patch restores the logic. Fixes: 6b4f7799c6a5 ("mm: vmscan: invoke slab shrinkers from shrink_zone()") Signed-off-by: Minchan Kim Cc: Johannes Weiner Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 9684dc001e986b11763b30c7bd71c0091fce28f8 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 5d43a619be6f1960702daafafe87ceab415be6bc 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 5e17ef78bfd34f65f83f9fb5054843616ea1d073 Author: James Morse Date: Tue Apr 26 12:15:01 2016 +0100 ARM: cpuidle: Pass on arm_cpuidle_suspend()'s return value [ Upstream commit 625fe4f8ffc1b915248558481bb94249f6bd411c ] arm_cpuidle_suspend() may return -EOPNOTSUPP, or any value returned by the cpu_ops/cpuidle_ops suspend call. arm_enter_idle_state() doesn't update 'ret' with this value, meaning we always signal success to cpuidle_enter_state(), causing it to update the usage counters as if we succeeded. Fixes: 191de17aa3c1 ("ARM64: cpuidle: Replace cpu_suspend by the common ARM/ARM64 function") Signed-off-by: James Morse Acked-by: Lorenzo Pieralisi Acked-by: Daniel Lezcano Cc: 4.1+ # 4.1+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 5bde3f2abca17e834c4009d4fdc71e8edb6df8f0 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 3b54e5f0a5415a9a8b8618fa61d1303e2ba8add6 Author: Vitaly Prosyak Date: Thu Apr 14 13:34:03 2016 -0400 drm/radeon: fix vertical bars appear on monitor (v2) [ Upstream commit 5d5b7803c49bbb01bdf4c6e95e8314d0515b9484 ] When crtc/timing is disabled on boot the dig block should be stopped in order ignore timing from crtc, reset the steering fifo otherwise we get display corruption or hung in dp sst mode. v2: agd: fix coding style Signed-off-by: Vitaly Prosyak Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 344a144c6f7310bf40dd4a40daa4c0abb994d3c5 Author: Ville Syrjälä Date: Wed Apr 20 16:43:56 2016 +0300 drm/i915: Make RPS EI/thresholds multiple of 25 on SNB-BDW [ Upstream commit 4ea3959018d09edfa36a9e7b5ccdbd4ec4b99e49 ] Somehow my SNB GT1 (Dell XPS 8300) gets very unhappy around GPU hangs if the RPS EI/thresholds aren't suitably aligned. It seems like scheduling/timer interupts stop working somehow and things get stuck eg. in usleep_range(). I bisected the problem down to commit 8a5864377b12 ("drm/i915/skl: Restructured the gen6_set_rps_thresholds function") I observed that before all the values were at least multiples of 25, but afterwards they are not. And rounding things up to the next multiple of 25 does seem to help, so lets' do that. I also tried roundup(..., 5) but that wasn't sufficient. Also I have no idea if we might need this sort of thing on gen9+ as well. These are the original EI/thresholds: LOW_POWER GEN6_RP_UP_EI 12500 GEN6_RP_UP_THRESHOLD 11800 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 21250 BETWEEN GEN6_RP_UP_EI 10250 GEN6_RP_UP_THRESHOLD 9225 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 18750 HIGH_POWER GEN6_RP_UP_EI 8000 GEN6_RP_UP_THRESHOLD 6800 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 15000 These are after 8a5864377b12: LOW_POWER GEN6_RP_UP_EI 12500 GEN6_RP_UP_THRESHOLD 11875 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 21250 BETWEEN GEN6_RP_UP_EI 10156 GEN6_RP_UP_THRESHOLD 9140 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 18750 HIGH_POWER GEN6_RP_UP_EI 7812 GEN6_RP_UP_THRESHOLD 6640 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 15000 And these are what we have after this patch: LOW_POWER GEN6_RP_UP_EI 12500 GEN6_RP_UP_THRESHOLD 11875 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 21250 BETWEEN GEN6_RP_UP_EI 10175 GEN6_RP_UP_THRESHOLD 9150 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 18750 HIGH_POWER GEN6_RP_UP_EI 7825 GEN6_RP_UP_THRESHOLD 6650 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 15000 Cc: stable@vger.kernel.org Cc: Akash Goel Cc: Chris Wilson Testcase: igt/kms_pipe_crc_basic/hang-read-crc-pipe-B Fixes: 8a5864377b12 ("drm/i915/skl: Restructured the gen6_set_rps_thresholds function") Signed-off-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/1461159836-9108-1-git-send-email-ville.syrjala@linux.intel.com Acked-by: Chris Wilson Reviewed-by: Patrik Jakobsson (cherry picked from commit 8a292d016d1cc4938ff14b4df25328230b08a408) Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit 39161f8ab357bc5e13eca3a04828cb7aecab0f9d 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 86128809b5bf37d75b6bee83d0e83a32f9a80673 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 b61a5d5456479618426d25bec4175c011bcc9726 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 85489830a875eee4c5357b2ffa217f06676c1211 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 14794cfb6c9bcca151dbe940f3d7b9f9f818499f 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 2519c9fc644c0fc14c54518bab9440765e0ea99a 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 cdfac06ee2d5aabbe89724c6a4a3fbb1148fcc7a 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 4f1948989e9af00623bb23d321cae7bd4792002e 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 b4782b68dbabd15982bb417d1e75bdd36c4eefc6 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 35f45c8a07dbc749e3b0602f1d6def24ee8cc657 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 83619523130164cb525e35b6001755cd185055fb 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 e7e16bb686861933ff351e945432bd607fc9fa02 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 24a50739c3e4e9947f4f4a28a023c348d7bea042 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 eab51598c1b3a48f320ea66fe1e0d58b61fa6c70 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 a5d2af4cf04bd0d1a6c1cb178d4673d9ca32a298 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 e1bab7565919a5eb4765ba26f927a17898177c04 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 35d3478878eae689a9934dda6fc6f1cd55262bfd 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 81aa039171d2efee11a93714385d8d35c5ce7665 Author: Sasha Levin Date: Thu May 12 22:08:02 2016 -0400 iwlwifi: pcie: lower the debug level for RSA semaphore access [ Upstream commit 9fc515bc9e735c10cd327f05c20f5ef69474188d ] IWL_INFO is not an error but still printed by default. "can't access the RSA semaphore it is write protected" seems worrisome but it is not really a problem. CC: [4.1+] Signed-off-by: Emmanuel Grumbach Signed-off-by: Sasha Levin commit 686b2f5895f1ae7b5891e5cba3ad78e6f3346e64 Author: Sasha Levin Date: Thu May 12 22:04:35 2016 -0400 stable: remove artifact created on backport I have erroneously created a copy of said file when backporting a commit back to the tree, and have ended up commiting it. Remove it from the tree. Reported-by: Jens Rottmann Signed-off-by: Sasha Levin commit f94e3630d7cf37e59d9c8772e38d4d73fa59e59e 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 522dc09ca0451d118795e8a05c7b3717f3d1ad8b.. 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