CVE-2017-18079

commit 13df91dbc06ed4323cf8bbc956ec9a0098f1361e Author: Greg Kroah-Hartman Date: Thu Jul 27 15:10:39 2017 -0700 Linux 4.12.4 commit baa11d76d15783e132e34957ab9f205373e9b9c5 Author: Wanpeng Li Date: Sun Jul 9 00:40:28 2017 -0700 sched/cputime: Don’t use smp_processor_id() in preemptible context commit 0e4097c3354e2f5a5ad8affd9dc7f7f7d00bb6b9 upstream. Recent kernels trigger this warning: BUG: using smp_processor_id() in preemptible [00000000] code: 99-trinity/181 caller is debug_smp_processor_id+0x17/0x19 CPU: 0 PID: 181 Comm: 99-trinity Not tainted 4.12.0-01059-g2a42eb9 #1 Call Trace: dump_stack+0x82/0xb8 check_preemption_disabled() debug_smp_processor_id() vtime_delta() task_cputime() thread_group_cputime() thread_group_cputime_adjusted() wait_consider_task() do_wait() SYSC_wait4() do_syscall_64() entry_SYSCALL64_slow_path() As Frederic pointed out: | Although those sched_clock_cpu() things seem to only matter when the | sched_clock() is unstable. And that stability is a condition for nohz_full | to work anyway. So probably sched_clock() alone would be enough. This patch fixes it by replacing sched_clock_cpu() with sched_clock() to avoid calling smp_processor_id() in a preemptible context. Reported-by: Xiaolong Ye Signed-off-by: Wanpeng Li Cc: Frederic Weisbecker Cc: Linus Torvalds Cc: Luiz Capitulino Cc: Peter Zijlstra Cc: Rik van Riel Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/[email protected] [ Prettified the changelog. ] Signed-off-by: Ingo Molnar Signed-off-by: Mel Gorman Signed-off-by: Greg Kroah-Hartman commit ccb1fe49efed135f58d9cd85600694a75e97d14f Author: Greg Hackmann Date: Tue Jul 25 12:42:46 2017 -0700 alarmtimer: don’t rate limit one-shot timers Commit ff86bf0c65f1 (“alarmtimer: Rate limit periodic intervals”) sets a minimum bound on the alarm timer interval. This minimum bound shouldn’t be applied if the interval is 0. Otherwise, one-shot timers will be converted into periodic ones. This patch is specific to 4.11.y and 4.12.y. Older -stable trees have a slightly different patch, and 4.13-rc2 isn’t impacted due to a later refactoring. Fixes: ff86bf0c65f1 (“alarmtimer: Rate limit periodic intervals”) Reported-by: Ben Fennema Signed-off-by: Greg Hackmann Cc: John Stultz Reviewed-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 2de3bd0323818f5878f6bb6fa3f60ffacbe3aa47 Author: Thomas Gleixner Date: Tue Jul 11 22:06:24 2017 +0200 smp/hotplug: Replace BUG_ON and react useful commit dea1d0f5f1284e3defee4b8484d9fc230686cd42 upstream. The move of the unpark functions to the control thread moved the BUG_ON() there as well. While it made some sense in the idle thread of the upcoming CPU, it’s bogus to crash the control thread on the already online CPU, especially as the function has a return value and the callsite is prepared to handle an error return. Replace it with a WARN_ON_ONCE() and return a proper error code. Fixes: 9cd4f1a4e7a8 (“smp/hotplug: Move unparking of percpu threads to the control CPU”) Rightfully-ranted-at-by: Linux Torvalds Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 8e5772cd2c0aa7e2bc10d29fc45e10b5bfdc795a Author: Thomas Gleixner Date: Tue Jul 4 22:20:23 2017 +0200 smp/hotplug: Move unparking of percpu threads to the control CPU commit 9cd4f1a4e7a858849e889a081a99adff83e08e4c upstream. Vikram reported the following backtrace: BUG: scheduling while atomic: swapper/7/0/0x00000002 CPU: 7 PID: 0 Comm: swapper/7 Not tainted 4.9.32-perf+ #680 schedule schedule_hrtimeout_range_clock schedule_hrtimeout wait_task_inactive __kthread_bind_mask __kthread_bind __kthread_unpark kthread_unpark cpuhp_online_idle cpu_startup_entry secondary_start_kernel He analyzed correctly that a parked cpu hotplug thread of an offlined CPU was still on the runqueue when the CPU came back online and tried to unpark it. This causes the thread which invoked kthread_unpark() to call wait_task_inactive() and subsequently schedule() with preemption disabled. His proposed workaround was to “make sure” that a parked thread has scheduled out when the CPU goes offline, so the situation cannot happen. But that’s still wrong because the root cause is not the fact that the percpu thread is still on the runqueue and neither that preemption is disabled, which could be simply solved by enabling preemption before calling kthread_unpark(). The real issue is that the calling thread is the idle task of the upcoming CPU, which is not supposed to call anything which might sleep. The moron, who wrote that code, missed completely that kthread_unpark() might end up in schedule(). The solution is simpler than expected. The thread which controls the hotplug operation is waiting for the CPU to call complete() on the hotplug state completion. So the idle task of the upcoming CPU can set its state to CPUHP_AP_ONLINE_IDLE and invoke complete(). This in turn wakes the control task on a different CPU, which then can safely do the unpark and kick the now unparked hotplug thread of the upcoming CPU to complete the bringup to the final target state. Control CPU AP bringup_cpu(); __cpu_up() ------------> bringup_ap(); bringup_wait_for_ap() wait_for_completion(); cpuhp_online_idle(); <------------ complete(); unpark(AP->stopper); unpark(AP->hotplugthread); while(1) do_idle(); kick(AP->hotplugthread); wait_for_completion(); hotplug_thread() run_online_callbacks(); complete(); Fixes: 8df3e07e7f21 (“cpu/hotplug: Let upcoming cpu bring itself fully up”) Reported-by: Vikram Mulukutla Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra Cc: Sebastian Sewior Cc: Rusty Russell Cc: Tejun Heo Cc: Andrew Morton Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1707042218020.2131@nanos Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 991344678778f93a7a7dfb0f70c2d69a1c1d42d9 Author: Gabriel Krisman Bertazi Date: Wed Jun 28 18:06:05 2017 -0300 drm/i915: reintroduce VLV/CHV PFI programming power domain workaround commit 9c75b185274b7766fe69c2e73607c1ed780b284b upstream. There are still cases on these platforms where an attempt is made to configure the CDCLK while the power domain is off, like when coming back from a suspend. So the workaround below is still needed. This effectively reverts commit 63ff30442519 (“drm/i915: Nuke the VLV/CHV PFI programming power domain workaround”). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101517 Suggested-by: Ville Syrjälä Signed-off-by: Gabriel Krisman Bertazi Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Ville Syrjälä Signed-off-by: Ville Syrjälä (cherry picked from commit 886015a0ad43c7fc034b23ea4614ba39162f9ddd) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 5c5f5877a18bfc5c61b8ad565b2a5ab6ab1d79e0 Author: [email protected] Date: Tue Jun 27 23:09:41 2017 +0530 drm/i915: Hold RPM wakelock while initializing OA buffer commit 04941829b0049d2446c7042ab9686dd057d809a6 upstream. OA buffer initialization involves access to HW registers to set the OA base, head and tail. Ensure device is awake while setting these. With this, all oa.ops are covered under RPM and forcewake wakelock. Cc: Lionel Landwerlin Signed-off-by: Sagar Arun Kamble Reviewed-by: Lionel Landwerlin Signed-off-by: Maarten Lankhorst Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Fixes: d79651522e89c (“drm/i915: Enable i915 perf stream for Haswell OA unit”) (cherry picked from commit 987f8c444aa2c33d98e7030d0c5f0a5325cc84ea) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 76c8933ae213319eacf3aa654ab6b6f4c83fbda1 Author: Chris Wilson Date: Thu Jun 22 17:02:11 2017 +0100 drm/i915/fbdev: Check for existence of ifbdev->vma before operations commit 7581d5ca2bb269cfc2ce2d0cb489aac513167f6b upstream. Commit fabef825626d (“drm/i915: Drop struct_mutex around frontbuffer flushes”) adds a dependency to ifbdev->vma when flushing the framebufer, but the checks are only against the existence of the ifbdev->fb and not against ifbdev->vma. This leaves a window of opportunity where we may try to operate on the fbdev prior to it being probed (thanks to asynchronous booting). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101534 Fixes: fabef825626d (“drm/i915: Drop struct_mutex around frontbuffer flushes”) Signed-off-by: Chris Wilson Cc: Joonas Lahtinen Cc: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Tvrtko Ursulin (cherry picked from commit 15727ed0d944ce1dec8b9e1082dd3df29a0fdf44) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit ab78ac460dfbc4c129a10677164abec31deda7f7 Author: Chunyu Hu Date: Thu Jul 20 18:36:09 2017 +0800 tracing: Fix kmemleak in instance_rmdir commit db9108e054700c96322b0f0028546aa4e643cf0b upstream. Hit the kmemleak when executing instance_rmdir, it forgot releasing mem of tracing_cpumask. With this fix, the warn does not appear any more. unreferenced object 0xffff93a8dfaa7c18 (size 8): comm "mkdir", pid 1436, jiffies 4294763622 (age 9134.308s) hex dump (first 8 bytes): ff ff ff ff ff ff ff ff … backtrace: [] kmemleak_alloc+0x4a/0xa0 [] __kmalloc_node+0xf1/0x280 [] alloc_cpumask_var_node+0x23/0x30 [] alloc_cpumask_var+0xe/0x10 [] instance_mkdir+0x90/0x240 [] tracefs_syscall_mkdir+0x40/0x70 [] vfs_mkdir+0x109/0x1b0 [] SyS_mkdir+0xd0/0x100 [] do_syscall_64+0x67/0x150 [] return_from_SYSCALL_64+0x0/0x6a [] 0xffffffffffffffff Link: http://lkml.kernel.org/r/[email protected] Fixes: ccfe9e42e451 (“tracing: Make tracing_cpumask available for all instances”) Signed-off-by: Chunyu Hu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit f564ff0c792c69569c5fceb896c6eefe2040e625 Author: Sudeep Holla Date: Fri Jul 14 11:51:48 2017 +0100 PM / Domains: defer dev_pm_domain_set() until genpd->attach_dev succeeds if present commit 975e83cfb8dc16e7a2fdc58188c77c0c605876c2 upstream. If the genpd->attach_dev or genpd->power_on fails, genpd_dev_pm_attach may return -EPROBE_DEFER initially. However genpd_alloc_dev_data sets the PM domain for the device unconditionally. When subsequent attempts are made to call genpd_dev_pm_attach, it may return -EEXISTS checking dev->pm_domain without re-attempting to call attach_dev or power_on. platform_drv_probe then attempts to call drv->probe as the return value -EEXIST != -EPROBE_DEFER, which may end up in a situation where the device is accessed without it’s power domain switched on. Fixes: f104e1e5ef57 (PM / Domains: Re-order initialization of generic_pm_domain_data) Signed-off-by: Sudeep Holla Acked-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 42b81d8977928b39c8a64113f986dac7dc60efa6 Author: Philipp Zabel Date: Mon Jun 12 17:54:29 2017 +0200 drm/imx: parallel-display: Accept drm_of_find_panel_or_bridge failure commit 799ee2970485dc206c3bf347d6e6827c04d5e4f9 upstream. The parallel panel driver should continue to work without having an endpoint linking to an panel in DT for backwards compatibility. With the recent switch to drm_of_find_panel_or_bridge, an absent panel results in a failure with -ENODEV error return code. To restore the old behaviour, ignore the -ENODEV return code. Reported-by: Nikita Yushchenko Fixes: ebc944613567 (“drm: convert drivers to use drm_of_find_panel_or_bridge”) Tested-by: Chris Healy Signed-off-by: Philipp Zabel Signed-off-by: Greg Kroah-Hartman commit 00d803c345ceb58243e2301a37f5f5ee1c493614 Author: Dan Williams Date: Tue Jul 18 17:49:14 2017 -0700 device-dax: fix sysfs duplicate warnings commit bbb3be170ac2891526ad07b18af7db226879a8e7 upstream. Fix warnings of the form… WARNING: CPU: 10 PID: 4983 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x62/0x80 sysfs: cannot create duplicate filename ‘/class/dax/dax12.0’ Call Trace: dump_stack+0x63/0x86 __warn+0xcb/0xf0 warn_slowpath_fmt+0x5a/0x80 ? kernfs_path_from_node+0x4f/0x60 sysfs_warn_dup+0x62/0x80 sysfs_do_create_link_sd.isra.2+0x97/0xb0 sysfs_create_link+0x25/0x40 device_add+0x266/0x630 devm_create_dax_dev+0x2cf/0x340 [dax] dax_pmem_probe+0x1f5/0x26e [dax_pmem] nvdimm_bus_probe+0x71/0x120 …by reusing the namespace id for the device-dax instance name. Now that we have decided that there will never by more than one device-dax instance per libnvdimm-namespace parent device [1], we can directly reuse the namepace ids. There are some possible follow-on cleanups, but those are saved for a later patch to simplify the -stable backport. [1]: https://lists.01.org/pipermail/linux-nvdimm/2016-December/008266.html Fixes: 98a29c39dc68 (“libnvdimm, namespace: allow creation of multiple pmem…”) Cc: Jeff Moyer Reported-by: Dariusz Dokupil Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 474216905bd995945d82378299cdc96e055c8398 Author: Jan Kara Date: Thu Jun 22 09:32:49 2017 +0200 reiserfs: Don’t clear SGID when inheriting ACLs commit 6883cd7f68245e43e91e5ee583b7550abf14523f upstream. When new directory ‘DIR1’ is created in a directory ‘DIR0’ with SGID bit set, DIR1 is expected to have SGID bit set (and owning group equal to the owning group of ‘DIR0’). However when ‘DIR0’ also has some default ACLs that ‘DIR1’ inherits, setting these ACLs will result in SGID bit on ‘DIR1’ to get cleared if user is not member of the owning group. Fix the problem by moving posix_acl_update_mode() out of __reiserfs_set_acl() into reiserfs_set_acl(). That way the function will not be called when inheriting ACLs which is what we want as it prevents SGID bit clearing and the mode has been properly set by posix_acl_create() anyway. Fixes: 073931017b49d9458aa351605b43a7e34598caef CC: [email protected] Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 114253ddc745bb72f9cc4342064f0efe2a16f649 Author: Bjorn Andersson Date: Thu Jun 29 14:46:44 2017 -0700 spmi: Include OF based modalias in device uevent commit d50daa2af2618dab6d21634e65a5fbcf4ae437d6 upstream. Include the OF-based modalias in the uevent sent when registering SPMI devices, so that user space has a chance to autoload the kernel module for the device. Tested-by: Rob Clark Reported-by: Rob Clark Reviewed-by: Stephen Boyd Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 6c8c343fa75f5ce748bb233c6abe5b038b67637c Author: Srinivas Pandruvada Date: Thu Jul 13 15:03:51 2017 -0700 cpufreq: intel_pstate: Correct the busy calculation for KNL commit 6e34e1f23d780978da65968327cbba6d7013a73f upstream. The busy percent calculated for the Knights Landing (KNL) platform is 1024 times smaller than the correct busy value. This causes performance to get stuck at the lowest ratio. The scaling algorithm used for KNL is performance-based, but it still looks at the CPU load to set the scaled busy factor to 0 when the load is less than 1 percent. In this case, since the computed load is 1024x smaller than it should be, the scaled busy factor will always be 0, irrespective of CPU business. This needs a fix similar to the turbostat one in commit b2b34dfe4d9a (tools/power turbostat: KNL workaround for %Busy and Avg_MHz). For this reason, add one more callback to processor-specific callbacks to specify an MPERF multiplier represented by a number of bit positions to shift the value of that register to the left to copmensate for its rate difference with respect to the TSC. This shift value is used during CPU busy calculations. Fixes: ffb810563c (intel_pstate: Avoid getting stuck in high P-states when idle) Reported-and-tested-by: Artem Bityutskiy Signed-off-by: Srinivas Pandruvada [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 5116f5e2e05cf506ee0bdd66740cd63dc725bd49 Author: Stephen Hemminger Date: Sun Jun 25 12:47:46 2017 -0700 vmbus: re-enable channel tasklet commit 6463a4571ceefc43908df4b016d8d5d8b8e85357 upstream. This problem shows up in 4.11 when netvsc driver is removed and reloaded. The problem is that the channel is closed during module removal and the tasklet for processing responses is disabled. When module is reloaded the channel is reopened but the tasklet is marked as disabled. The fix is to re-enable tasklet at the end of close which gets it back to the initial state. The issue is less urgent in 4.12 since network driver now uses NAPI and not the tasklet; and other VMBUS devices are rarely unloaded/reloaded. Fixes: dad72a1d2844 (“vmbus: remove hv_event_tasklet_disable/enable”) Signed-off-by: Stephen Hemminger Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman commit 5e87c475152fadf49f9582e99dc5e7a4e77a8650 Author: Prarit Bhargava Date: Wed May 31 13:32:00 2017 -0400 acpi/nfit: Fix memory corruption/Unregister mce decoder on failure commit 7e700d2c59e5853c9126642976b4f5768f64c9b3 upstream. nfit_init() calls nfit_mce_register() on module load. When the module load fails the nfit mce decoder is not unregistered. The module’s memory is freed leaving the decoder chain referencing junk. This will cause panics as future registrations will reference the free’d memory. Unregister the nfit mce decoder on module init failure. [v2]: register and then unregister mce handler to avoid losing mce events [v3]: also cleanup nfit workqueue Fixes: 6839a6d96f4e (“nfit: do an ARS scrub on hitting a latent media error”) Cc: “Rafael J. Wysocki” Cc: Len Brown Cc: Vishal Verma Cc: “Lee, Chun-Yi” Cc: Linda Knippers Cc: [email protected] Acked-by: Jeff Moyer Signed-off-by: Prarit Bhargava Reviewed-by: Vishal Verma Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 054728d3bbe4a3047e91a4ff4f66298c4baf6462 Author: Christoph Lameter Date: Wed Jul 12 14:33:11 2017 -0700 kernel/fork.c: virtually mapped stacks: do not disable interrupts commit 112166f88cf83dd11486cf1818672d42b540865b upstream. The reason to disable interrupts seems to be to avoid switching to a different processor while handling per cpu data using individual loads and stores. If we use per cpu RMV primitives we will not have to disable interrupts. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Christoph Lameter Cc: Andy Lutomirski Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Mel Gorman Signed-off-by: Greg Kroah-Hartman commit 2541b3c861bc58ac4e01edfa4bb035421ff23501 Author: Nikolay Borisov Date: Wed Jul 12 14:37:51 2017 -0700 writeback: rework wb_[dec|inc]_stat family of functions commit 3e8f399da490e6ac20a3cfd6aa404c9aa961a9a2 upstream. Currently the writeback statistics code uses a percpu counters to hold various statistics. Furthermore we have 2 families of functions - those which disable local irq and those which doesn’t and whose names begin with double underscore. However, they both end up calling __add_wb_stats which in turn calls percpu_counter_add_batch which is already irq-safe. Exploiting this fact allows to eliminated the __wb_* functions since they don’t add any further protection than we already have. Furthermore, refactor the wb_* function to call __add_wb_stat directly without the irq-disabling dance. This will likely result in better runtime of code which deals with modifying the stat counters. While at it also document why percpu_counter_add_batch is in fact preempt and irq-safe since at least 3 people got confused. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Nikolay Borisov Acked-by: Tejun Heo Reviewed-by: Jan Kara Cc: Josef Bacik Cc: Mel Gorman Cc: Jeff Layton Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Mel Gorman Signed-off-by: Greg Kroah-Hartman commit 60958be79d5845e2e00f81cd256443e376194b0f Author: Nikolay Borisov Date: Tue Jun 20 21:01:20 2017 +0300 percpu_counter: Rename __percpu_counter_add to percpu_counter_add_batch commit 104b4e5139fe384431ac11c3b8a6cf4a529edf4a upstream. Currently, percpu_counter_add is a wrapper around __percpu_counter_add which is preempt safe due to explicit calls to preempt_disable. Given how __ prefix is used in percpu related interfaces, the naming unfortunately creates the false sense that __percpu_counter_add is less safe than percpu_counter_add. In terms of context-safety, they’re equivalent. The only difference is that the __ version takes a batch parameter. Make this a bit more explicit by just renaming __percpu_counter_add to percpu_counter_add_batch. This patch doesn’t cause any functional changes. tj: Minor updates to patch description for clarity. Cosmetic indentation updates. Signed-off-by: Nikolay Borisov Signed-off-by: Tejun Heo Cc: Chris Mason Cc: Josef Bacik Cc: David Sterba Cc: Darrick J. Wong Cc: Jan Kara Cc: Jens Axboe Cc: [email protected] Cc: “David S. Miller” Signed-off-by: Mel Gorman Signed-off-by: Greg Kroah-Hartman commit fa7333486ea06d0f7c3078449aa9f9e069ef2d50 Author: Jeffrey Hugo Date: Wed Jun 7 13:18:57 2017 -0600 sched/fair: Fix load_balance() affinity redo path commit 65a4433aebe36c8c6abeb69b99ef00274b971c6c upstream. If load_balance() fails to migrate any tasks because all tasks were affined, load_balance() removes the source CPU from consideration and attempts to redo and balance among the new subset of CPUs. There is a bug in this code path where the algorithm considers all active CPUs in the system (minus the source that was just masked out). This is not valid for two reasons: some active CPUs may not be in the current scheduling domain and one of the active CPUs is dst_cpu. These CPUs should not be considered, as we cannot pull load from them. Instead of failing out of load_balance(), we may end up redoing the search with no valid CPUs and incorrectly concluding the domain is balanced. Additionally, if the group_imbalance flag was just set, it may also be incorrectly unset, thus the flag will not be seen by other CPUs in future load_balance() runs as that algorithm intends. Fix the check by removing CPUs not in the current domain and the dst_cpu from considertation, thus limiting the evaluation to valid remaining CPUs from which load might be migrated. Co-authored-by: Austin Christ Co-authored-by: Dietmar Eggemann Tested-by: Tyler Baicar Signed-off-by: Jeffrey Hugo Acked-by: Peter Zijlstra Cc: Austin Christ Cc: Dietmar Eggemann Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Timur Tabi Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar Signed-off-by: Mel Gorman Signed-off-by: Greg Kroah-Hartman commit 8e44a3517763a89e1135024eab12ef3b24819dc0 Author: Wanpeng Li Date: Thu Jun 29 19:15:11 2017 +0200 sched/cputime: Accumulate vtime on top of nsec clocksource commit 2a42eb9594a1480b4ead9e036e06ee1290e5fa6d upstream. Currently the cputime source used by vtime is jiffies. When we cross a context boundary and jiffies have changed since the last snapshot, the pending cputime is accounted to the switching out context. This system works ok if the ticks are not aligned across CPUs. If they instead are aligned (ie: all fire at the same time) and the CPUs run in userspace, the jiffies change is only observed on tick exit and therefore the user cputime is accounted as system cputime. This is because the CPU that maintains timekeeping fires its tick at the same time as the others. It updates jiffies in the middle of the tick and the other CPUs see that update on IRQ exit: CPU 0 (timekeeper) CPU 1 ------------------- ------------- jiffies = N … run in userspace for a jiffy tick entry tick entry (sees jiffies = N) set jiffies = N + 1 tick exit tick exit (sees jiffies = N + 1) account 1 jiffy as stime Fix this with using a nanosec clock source instead of jiffies. The cputime is then accumulated and flushed everytime the pending delta reaches a jiffy in order to mitigate the accounting overhead. [ fweisbec: changelog, rebase on struct vtime, field renames, add delta on cputime readers, keep idle vtime as-is (low overhead accounting), harmonize clock sources. ] Suggested-by: Thomas Gleixner Reported-by: Luiz Capitulino Tested-by: Luiz Capitulino Signed-off-by: Wanpeng Li Signed-off-by: Frederic Weisbecker Reviewed-by: Thomas Gleixner Acked-by: Rik van Riel Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Wanpeng Li Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar Signed-off-by: Mel Gorman Signed-off-by: Greg Kroah-Hartman commit a1d04e8a110288917a4f4ac14370cb9f06c36500 Author: Frederic Weisbecker Date: Thu Jun 29 19:15:10 2017 +0200 sched/cputime: Move the vtime task fields to their own struct commit bac5b6b6b11560f323e71d0ebac4061cfe5f56c0 upstream. We are about to add vtime accumulation fields to the task struct. Let’s avoid more bloatification and gather vtime information to their own struct. Tested-by: Luiz Capitulino Signed-off-by: Frederic Weisbecker Reviewed-by: Thomas Gleixner Acked-by: Rik van Riel Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Wanpeng Li Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar Signed-off-by: Mel Gorman Signed-off-by: Greg Kroah-Hartman commit 7d546b63c820089b08941ae9e5b63147fad211ee Author: Frederic Weisbecker Date: Thu Jun 29 19:15:09 2017 +0200 sched/cputime: Rename vtime fields commit 60a9ce57e7c5ac1df3a39fb941022bbfa40c0862 upstream. The current “snapshot” based naming on vtime fields suggests we record some past event but that’s a low level picture of their actual purpose which comes out blurry. The real point of these fields is to run a basic state machine that tracks down cputime entry while switching between contexts. So lets reflect that with more meaningful names. Tested-by: Luiz Capitulino Signed-off-by: Frederic Weisbecker Reviewed-by: Thomas Gleixner Acked-by: Rik van Riel Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Wanpeng Li Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar Signed-off-by: Mel Gorman Signed-off-by: Greg Kroah-Hartman commit 09b43d8df3119e309e8842782f9acf39a9ab4872 Author: Frederic Weisbecker Date: Thu Jun 29 19:15:08 2017 +0200 sched/cputime: Always set tsk->vtime_snap_whence after accounting vtime commit 9fa57cf5a5c4aed1e45879b335fe433048709327 upstream. Even though it doesn’t have functional consequences, setting the task’s new context state after we actually accounted the pending vtime from the old context state makes more sense from a review perspective. vtime_user_exit() is the only function that doesn’t follow that rule and that can bug the reviewer for a little while until he realizes there is no reason for this special case. Tested-by: Luiz Capitulino Signed-off-by: Frederic Weisbecker Reviewed-by: Thomas Gleixner Acked-by: Rik van Riel Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Wanpeng Li Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar Signed-off-by: Mel Gorman Signed-off-by: Greg Kroah-Hartman commit 6bb15a0824ffdae94f60556bb433719d167e2fac Author: Frederic Weisbecker Date: Thu Jun 29 19:15:07 2017 +0200 vtime, sched/cputime: Remove vtime_account_user() commit 1c3eda01a79b8e9237d91c52c5a75b20983f47c6 upstream. It’s an unnecessary function between vtime_user_exit() and account_user_time(). Tested-by: Luiz Capitulino Signed-off-by: Frederic Weisbecker Reviewed-by: Thomas Gleixner Acked-by: Rik van Riel Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Wanpeng Li Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar Signed-off-by: Mel Gorman Signed-off-by: Greg Kroah-Hartman commit 35632493c3547ca8b2a9b469862b89ecd234525f Author: Jan Kara Date: Wed Jun 21 15:02:47 2017 +0200 hfsplus: Don’t clear SGID when inheriting ACLs commit 84969465ddc4f8aeb3b993123b571aa01c5f2683 upstream. When new directory ‘DIR1’ is created in a directory ‘DIR0’ with SGID bit set, DIR1 is expected to have SGID bit set (and owning group equal to the owning group of ‘DIR0’). However when ‘DIR0’ also has some default ACLs that ‘DIR1’ inherits, setting these ACLs will result in SGID bit on ‘DIR1’ to get cleared if user is not member of the owning group. Fix the problem by creating __hfsplus_set_posix_acl() function that does not call posix_acl_update_mode() and use it when inheriting ACLs. That prevents SGID bit clearing and the mode has been properly set by posix_acl_create() anyway. Fixes: 073931017b49d9458aa351605b43a7e34598caef Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 6107c06645d63b13252e7b85669251f10d2bb8f3 Author: Bart Van Assche Date: Mon Apr 24 15:15:28 2017 -0700 mlx5: Avoid that mlx5_ib_sg_to_klms() overflows the klms[] array commit 99975cd4fda52974a767aa44fe0b1a8f74950d9d upstream. ib_map_mr_sg() can pass an SG-list to .map_mr_sg() that is larger than what fits into a single MR. .map_mr_sg() must not attempt to map more SG-list elements than what fits into a single MR. Hence make sure that mlx5_ib_sg_to_klms() does not write outside the MR klms[] array. Fixes: b005d3164713 (“mlx5: Add arbitrary sg list support”) Signed-off-by: Bart Van Assche Reviewed-by: Max Gurtovoy Cc: Sagi Grimberg Cc: Leon Romanovsky Cc: Israel Rukshin Acked-by: Leon Romanovsky Reviewed-by: Sagi Grimberg Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 442edd0e17fbf3540eb9491290d00067d16f5db2 Author: Maarten Lankhorst Date: Mon Jun 26 10:33:49 2017 +0200 drm/i915: Make DP-MST connector info work commit 50740024bc393b608f7e391ac35e70f33938dd24 upstream. Commit 9a148a96fc3a (“drm/i915/debugfs: add dp mst info”) adds support for DP-MST to intel_connector_info, but forgot to remove the early return for DP-MST. Remove it, and print out MST connectors directly. Fixes: 9a148a96fc3a (“drm/i915/debugfs: add dp mst info”) Cc: Dhinakaran Pandiyan Cc: Libin Yang Signed-off-by: Maarten Lankhorst Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Dhinakaran Pandiyan (cherry picked from commit 77d1f615c78a73a04254fa2bff07ee9fa27145d9) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 255758f79390097c94c9dc2695991e4662041547 Author: Imre Deak Date: Wed Jul 19 16:46:32 2017 +0300 drm/mst: Avoid processing partially received up/down message transactions commit 636c4c3e762b62aa93632c645ca65879285b16e3 upstream. Currently we may process up/down message transactions containing uninitialized data. This can happen if there was an error during the reception of any message in the transaction, but we happened to receive the last message correctly with the end-of-message flag set. To avoid this abort the reception of the transaction when the first error is detected, rejecting any messages until a message with the start-of-message flag is received (which will start a new transaction). This is also what the DP 1.4 spec 2.11.8.2 calls for in this case. In addtion this also prevents receiving bogus transactions without the first message with the the start-of-message flag set. v2: - unchanged v3: - git add the part that actually skips messages after an error in drm_dp_sideband_msg_build() Cc: Dave Airlie Cc: Lyude Cc: Daniel Vetter Signed-off-by: Imre Deak Reviewed-by: Lyude Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman commit 4c5cea159d3f6c5da6f23761e46efc230c81338b Author: Imre Deak Date: Wed Jul 19 14:43:29 2017 +0300 drm/mst: Avoid dereferencing a NULL mstb in drm_dp_mst_handle_up_req() commit 7f8b3987da54cb4d41ad2545cd4d7958b9a36bdf upstream. In case of an unknown broadcast message is sent mstb will remain unset, so check for this. Cc: Dave Airlie Cc: Lyude Cc: Daniel Vetter Signed-off-by: Imre Deak Reviewed-by: Lyude Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman commit 9bacd42b1cc6a52e2ce5f7a69c17e336af69a47d Author: Imre Deak Date: Wed Jul 19 14:43:28 2017 +0300 drm/mst: Fix error handling during MST sideband message reception commit 448421b5e93b9177c5698f0cf6f5e72d2995eeca upstream. Handle any error due to partial reads, timeouts etc. to avoid parsing uninitialized data subsequently. Also bail out if the parsing itself fails. Cc: Dave Airlie Cc: Lyude Cc: Daniel Vetter Signed-off-by: Imre Deak Reviewed-by: Lyude Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman commit 47c671637bacd85e201f8734dfd5bc3d24ec2e5d Author: Ismail, Mustafa Date: Fri Jul 14 09:41:31 2017 -0500 RDMA/core: Initialize port_num in qp_attr commit a62ab66b13a0f9bcb17b7b761f6670941ed5cd62 upstream. Initialize the port_num for iWARP in rdma_init_qp_attr. Fixes: 5ecce4c9b17b(“Check port number supplied by user verbs cmds”) Reviewed-by: Steve Wise Signed-off-by: Mustafa Ismail Tested-by: Mike Marciniszyn Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 11e6c231c7d009525f3a99cb1c5b9bb2d894f652 Author: Ismail, Mustafa Date: Fri Jul 14 09:41:30 2017 -0500 RDMA/uverbs: Fix the check for port number commit 5a7a88f1b488e4ee49eb3d5b82612d4d9ffdf2c3 upstream. The port number is only valid if IB_QP_PORT is set in the mask. So only check port number if it is valid to prevent modify_qp from failing due to an invalid port number. Fixes: 5ecce4c9b17b(“Check port number supplied by user verbs cmds”) Reviewed-by: Steve Wise Signed-off-by: Mustafa Ismail Tested-by: Mike Marciniszyn Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 6823b31afd1091dbf66311f7adc6f44fd53ea514 Author: Yan, Zheng Date: Thu Jul 6 11:12:21 2017 +0800 ceph: fix race in concurrent readdir commit 84583cfb973c4313955c6231cc9cb3772d280b15 upstream. For a large directory, program needs to issue multiple readdir syscalls to get all dentries. When there are multiple programs read the directory concurrently. Following sequence of events can happen. - program calls readdir with pos = 2. ceph sends readdir request to mds. The reply contains N1 entries. ceph adds these N1 entries to readdir cache. - program calls readdir with pos = N1+2. The readdir is satisfied by the readdir cache, N2 entries are returned. (Other program calls readdir in the middle, which fills the cache) - program calls readdir with pos = N1+N2+2. ceph sends readdir request to mds. The reply contains N3 entries and it reaches directory end. ceph adds these N3 entries to the readdir cache and marks directory complete. The second readdir call does not update fi->readdir_cache_idx. ceph add the last N3 entries to wrong places. Signed-off-by: “Yan, Zheng” Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 3002c15f57be5e6cbcc8df55ee49964d9052ae4d Author: Arnd Bergmann Date: Sat Jul 15 11:32:08 2017 -0400 staging: lustre: ko2iblnd: check copy_from_iter/copy_to_iter return code commit 566e1ce22e04426fa52328b2adcdf1df49acd98e upstream. We now get a helpful warning for code that calls copy_{from,to}_iter without checking the return value, introduced by commit aa28de275a24 (“iov_iter/hardening: move object size checks to inlined part”). drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c: In function ‘kiblnd_send’: drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c:1643:2: error: ignoring return value of ‘copy_from_iter’, declared with attribute warn_unused_result [-Werror=unused-result] drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c: In function ‘kiblnd_recv’: drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c:1744:3: error: ignoring return value of ‘copy_to_iter’, declared with attribute warn_unused_result [-Werror=unused-result] In case we get short copies here, we may get incorrect behavior. I’ve added failure handling for both rx and tx now, returning -EFAULT as expected. Signed-off-by: Arnd Bergmann Signed-off-by: James Simmons Signed-off-by: Greg Kroah-Hartman commit 6bab0b74fc7ac35870e74ca8ea4f3633ecebeb55 Author: Teddy Wang Date: Fri Jun 30 21:57:43 2017 +0100 staging: sm750fb: avoid conflicting vesafb commit 740c433ec35187b45abe08bb6c45a321a791be8e upstream. If vesafb is enabled in the config then /dev/fb0 is created by vesa and this sm750 driver gets fb1, fb2. But we need to be fb0 and fb1 to effectively work with xorg. So if it has been alloted fb1, then try to remove the other fb0. In the previous send, why #ifdef is used was asked. https://lkml.org/lkml/2017/6/25/57 Answered at: https://lkml.org/lkml/2017/6/25/69 Also pasting here for reference. ‘Did a quick research into "why". The patch d8801e4df91e (“x86/PCI: Set IORESOURCE_ROM_SHADOW only for the default VGA device”) has started setting IORESOURCE_ROM_SHADOW in flags for a default VGA device and that is being done only for x86. And so, we will need that #ifdef to check IORESOURCE_ROM_SHADOW as that needs to be checked only for a x86 and not for other arch.’ Signed-off-by: Teddy Wang Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman commit 592761a080cacb7e37477dd9bb1eb0a8a8849d97 Author: Ian Abbott Date: Fri Jun 30 12:02:18 2017 +0100 staging: comedi: ni_mio_common: fix AO timer off-by-one regression commit 15d5193104a457d5151840247e3bce561c42e3e9 upstream. As reported by Éric Piel on the Comedi mailing list (see ), the analog output asynchronous commands are running too fast with a period 50 ns shorter than it should be. This affects all boards with AO command support that are supported by the "ni_pcimio", "ni_atmio", and “ni_mio_cs” drivers. This is a regression bug introduced by commit 080e6795cba3 (“staging: comedi: ni_mio_common: Cleans up/clarifies ni_ao_cmd”), specifically, this line in `ni_ao_cmd_set_update()`: /* following line: N-1 per STC */ ni_stc_writel(dev, trigvar - 1, NISTC_AO_UI_LOADA_REG); The `trigvar` variable value comes from a call to `ni_ns_to_timer()` which converts a timer period in nanoseconds to a hardware divisor value. The function already reduces the divisor by 1 as required by the hardware, so the above line should not reduce it further by 1. Fix it by replacing `trigvar` by `trigvar - 1` in the above line, and remove the misleading comment. Reported-by: Éric Piel Fixes: 080e6795cba3 (“staging: comedi: ni_mio_common: Cleans up/clarifies ni_ao_cmd”) Cc: Éric Piel Cc: Spencer E. Olson Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman commit f49f1f5f65793b18be223d480839e6325cb12346 Author: Michael Gugino Date: Mon Jul 17 13:29:09 2017 -0400 staging: rtl8188eu: add TL-WN722N v2 support commit 5a1d4c5dd4eb2f1f8a9b30e61762f3b3b564df70 upstream. Add support for USB Device TP-Link TL-WN722N v2. VendorID: 0x2357, ProductID: 0x010c Signed-off-by: Michael Gugino Signed-off-by: Greg Kroah-Hartman commit 964b720f3cead6c0947e519bce7e96b17d3ef1ff Author: Ingo Molnar Date: Tue Jul 11 10:56:54 2017 +0200 Revert “perf/core: Drop kernel samples even though :u is specified” commit 6a8a75f3235724c5941a33e287b2f98966ad14c5 upstream. This reverts commit cc1582c231ea041fbc68861dfaf957eaf902b829. This commit introduced a regression that broke rr-project, which uses sampling events to receive a signal on overflow (but does not care about the contents of the sample). These signals are critical to the correct operation of rr. There’s been some back and forth about how to fix it - but to not keep applications in limbo queue up a revert. Reported-by: Kyle Huey Acked-by: Kyle Huey Acked-by: Peter Zijlstra Cc: Jin Yao Cc: Vince Weaver Cc: Linus Torvalds Cc: Will Deacon Cc: Arnaldo Carvalho de Melo Cc: Alexander Shishkin Cc: Stephane Eranian Cc: Namhyung Kim Cc: Jiri Olsa Link: http://lkml.kernel.org/r/20170628105600.GC5981@leverpostej Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 371e6d8b85ef23665958d84307bc0fddc5a6a867 Author: Alexander Shishkin Date: Tue Jul 18 14:08:34 2017 +0300 perf/core: Fix scheduling regression of pinned groups commit 3bda69c1c3993a2bddbae01397d12bfef6054011 upstream. Vince Weaver reported: > I was tracking down some regressions in my perf_event_test testsuite. > Some of the tests broke in the 4.11-rc1 timeframe. > > I’ve bisected one of them, this report is about > tests/overflow/simul_oneshot_group_overflow > This test creates an event group containing two sampling events, set > to overflow to a signal handler (which disables and then refreshes the > event). > > On a good kernel you get the following: > Event perf::instructions with period 1000000 > Event perf::instructions with period 2000000 > fd 3 overflows: 946 (perf::instructions/1000000) > fd 4 overflows: 473 (perf::instructions/2000000) > Ending counts: > Count 0: 946379875 > Count 1: 946365218 > > With the broken kernels you get: > Event perf::instructions with period 1000000 > Event perf::instructions with period 2000000 > fd 3 overflows: 938 (perf::instructions/1000000) > fd 4 overflows: 318 (perf::instructions/2000000) > Ending counts: > Count 0: 946373080 > Count 1: 653373058 The root cause of the bug is that the following commit: 487f05e18a (“perf/core: Optimize event rescheduling on active contexts”) erronously assumed that event’s ‘pinned’ setting determines whether the event belongs to a pinned group or not, but in fact, it’s the group leader’s pinned state that matters. This was discovered by Vince in the test case described above, where two instruction counters are grouped, the group leader is pinned, but the other event is not; in the regressed case the counters were off by 33% (the difference between events’ periods), but should be the same within the error margin. Fix the problem by looking at the group leader’s pinning. Reported-by: Vince Weaver Tested-by: Vince Weaver Signed-off-by: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Fixes: 487f05e18a (“perf/core: Optimize event rescheduling on active contexts”) Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 74671ea542bedc00cfac73e865c28ebde962d0a6 Author: Jin Yao Date: Thu Jun 8 14:01:44 2017 +0800 perf annotate: Fix broken arrow at row 0 connecting jmp instruction to its target commit 80f62589fa52f530cffc50e78c0b5a2ae572d61e upstream. When the jump instruction is displayed at the row 0 in annotate view, the arrow is broken. An example: 16.86 │ ┌──je 82 0.01 │ movsd (%rsp),%xmm0 │ movsd 0x8(%rsp),%xmm4 │ movsd 0x8(%rsp),%xmm1 │ movsd (%rsp),%xmm3 │ divsd %xmm4,%xmm0 │ divsd %xmm3,%xmm1 │ movsd (%rsp),%xmm2 │ addsd %xmm1,%xmm0 │ addsd %xmm2,%xmm0 │ movsd %xmm0,(%rsp) │82: sub $0x1,%ebx 83.03 │ ↑ jne 38 │ add $0x10,%rsp │ xor %eax,%eax │ pop %rbx │ ← retq The patch increments the row number before checking with 0. Signed-off-by: Yao Jin Tested-by: Arnaldo Carvalho de Melo Cc: Alexander Shishkin Cc: Andi Kleen Cc: Jiri Olsa Cc: Kan Liang Cc: Peter Zijlstra Fixes: 944e1abed9e1 (“perf ui browser: Add method to draw up/down arrow line”) Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit b05b92bcf45ec86a02c94aa6f34a0c5eb4179bab Author: Nicholas Bellinger Date: Thu Jun 29 22:21:31 2017 -0700 iser-target: Avoid isert_conn->cm_id dereference in isert_login_recv_done commit fce50a2fa4e9c6e103915c351b6d4a98661341d6 upstream. This patch fixes a NULL pointer dereference in isert_login_recv_done() of isert_conn->cm_id due to isert_cma_handler() -> isert_connect_error() resetting isert_conn->cm_id = NULL during a failed login attempt. As per Sagi, we will always see the completion of all recv wrs posted on the qp (given that we assigned a ->done handler), this is a FLUSH error completion, we just don’t get to verify that because we deref NULL before. The issue here, was the assumption that dereferencing the connection cm_id is always safe, which is not true since: commit 4a579da2586bd3b79b025947ea24ede2bbfede62 Author: Sagi Grimberg Date: Sun Mar 29 15:52:04 2015 +0300 iser-target: Fix possible deadlock in RDMA_CM connection error As I see it, we have a direct reference to the isert_device from isert_conn which is the one-liner fix that we actually need like we do in isert_rdma_read_done() and isert_rdma_write_done(). Reported-by: Andrea Righi Tested-by: Andrea Righi Reviewed-by: Sagi Grimberg Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 0cc3c70dcfc1d6a047ebb07529cfbd87adc23e81 Author: Jiang Yi Date: Sun Jun 25 12:28:50 2017 -0700 target: Fix COMPARE_AND_WRITE caw_sem leak during se_cmd quiesce commit 1d6ef276594a781686058802996e09c8550fd767 upstream. This patch addresses a COMPARE_AND_WRITE se_device->caw_sem leak, that would be triggered during normal se_cmd shutdown or abort via __transport_wait_for_tasks(). This would occur because target_complete_cmd() would catch this early and do complete_all(&cmd->t_transport_stop_comp), but since target_complete_ok_work() or target_complete_failure_work() are never called to invoke se_cmd->transport_complete_callback(), the COMPARE_AND_WRITE specific callbacks never release caw_sem. To address this special case, go ahead and release caw_sem directly from target_complete_cmd(). (Remove ‘&& success’ from check, to release caw_sem regardless of scsi_status - nab) Signed-off-by: Jiang Yi Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit cb22c668c465aa968ab1e948f98103d12332ed2f Author: Jan Kara Date: Tue Jun 13 16:20:25 2017 +0200 udf: Fix deadlock between writeback and udf_setsize() commit f2e95355891153f66d4156bf3a142c6489cd78c6 upstream. udf_setsize() called truncate_setsize() with i_data_sem held. Thus truncate_pagecache() called from truncate_setsize() could lock a page under i_data_sem which can deadlock as page lock ranks below i_data_sem - e. g. writeback can hold page lock and try to acquire i_data_sem to map a block. Fix the problem by moving truncate_setsize() calls from under i_data_sem. It is safe for us to change i_size without holding i_data_sem as all the places that depend on i_size being stable already hold inode_lock. Fixes: 7e49b6f2480cb9a9e7322a91592e56a5c85361f5 Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 47a493225854537bf98e11502b9dcc25ed634c6b Author: Jan Kara Date: Tue Jun 13 15:54:58 2017 +0200 udf: Fix races with i_size changes during readpage commit 9795e0e8ac0d6a3ee092f1b555b284b57feef99e upstream. __udf_adinicb_readpage() uses i_size several times. When truncate changes i_size while the function is running, it can observe several different values and thus e.g. expose uninitialized parts of page to userspace. Also use i_size_read() in the function since it does not hold inode_lock. Since i_size is guaranteed to be small, this cannot really cause any issues even on 32-bit archs but let’s be careful. Fixes: 9c2fc0de1a6e638fe58c354a463f544f42a90a09 Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 9968e8105914ba437b98dd19200092537dfeb23b Author: NeilBrown Date: Wed Jul 5 12:22:20 2017 +1000 NFS: only invalidate dentrys that are clearly invalid. commit cc89684c9a265828ce061037f1f79f4a68ccd3f7 upstream. Since commit bafc9b754f75 (“vfs: More precise tests in d_invalidate”) in v3.18, a return of ‘0’ from ->d_revalidate() will cause the dentry to be invalidated even if it has filesystems mounted on or it or on a descendant. The mounted filesystem is unmounted. This means we need to be careful not to return 0 unless the directory referred to truly is invalid. So -ESTALE or -ENOENT should invalidate the directory. Other errors such a -EPERM or -ERESTARTSYS should be returned from ->d_revalidate() so they are propagated to the caller. A particular problem can be demonstrated by: 1/ mount an NFS filesystem using NFSv3 on /mnt 2/ mount any other filesystem on /mnt/foo 3/ ls /mnt/foo 4/ turn off network, or otherwise make the server unable to respond 5/ ls /mnt/foo & 6/ cat /proc/$!/stack # note that nfs_lookup_revalidate is in the call stack 7/ kill -9 $! # this results in -ERESTARTSYS being returned 8/ observe that /mnt/foo has been unmounted. This patch changes nfs_lookup_revalidate() to only treat -ESTALE from nfs_lookup_verify_inode() and -ESTALE or -ENOENT from ->lookup() as indicating an invalid inode. Other errors are returned. Also nfs_check_inode_attributes() is changed to return -ESTALE rather than -EIO. This is consistent with the error returned in similar circumstances from nfs_update_inode(). As this bug allows any user to unmount a filesystem mounted on an NFS filesystem, this fix is suitable for stable kernels. Fixes: bafc9b754f75 (“vfs: More precise tests in d_invalidate”) Signed-off-by: NeilBrown Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 86eadfc25a845dd8d1cff80557a362ac58f7c607 Author: Olga Kornievskaia Date: Fri Jun 23 10:26:58 2017 -0400 PNFS fix EACCESS on commit to DS handling commit a0bc01e0f1fa39702b5244b3bac699bea0d4f413 upstream. Commit fabbbee0eb0f “PNFS fix fallback to MDS if got error on commit to DS” moved the pnfs_set_lo_fail() to unhandled errors which was not correct and lead to a kernel oops on umount. Instead, fix the original EACCESS on commit to DS error by getting the new layout and re-doing the IO. Fixes: fabbbee0eb0f (“PNFS fix fallback to MDS if got error on commit to DS”) Signed-off-by: Olga Kornievskaia Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit be7e79fe053e76d385e8f3abe4666a566f3a62cb Author: Benjamin Coddington Date: Fri Jun 9 11:03:23 2017 -0400 NFS: Fix initialization of nfs_page_array->npages commit 2eb3aea7d9c43325a12df312adfc7fb25bbd636b upstream. Commit 8ef9b0b9e1c0 open-coded nfs_pgarray_set(), and left out the initialization of the nfs_page_array’s npages. This mistake didn’t show up until testing with block layouts, and there shows that all pNFS reads return -EIO. Fixes: 8ef9b0b9e1c0 (“NFS: move nfs_pgarray_set() to open code”) Signed-off-by: Benjamin Coddington Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 7956cddeaebf7422c9aa949665a7a39cbb2bea0b Author: NeilBrown Date: Wed Jul 19 14:05:01 2017 +1000 net/sunrpc/xprt_sock: fix regression in connection error reporting. commit 3ffbc1d65583394be12801655781dd2b079ce169 upstream. Commit 3d4762639dd3 (“tcp: remove poll() flakes when receiving RST”) in v4.12 changed the order in which ->sk_state_change() and ->sk_error_report() are called when a socket is shut down - sk_state_change() is now called first. This causes xs_tcp_state_change() -> xs_sock_mark_closed() -> xprt_disconnect_done() to wake all pending tasked with -EAGAIN. When the ->sk_error_report() callback arrives, it is too late to pass the error on, and it is lost. As easy way to demonstrate the problem caused is to try to start rpc.nfsd while rcpbind isn’t running. nfsd will attempt a tcp connection to rpcbind. A ECONNREFUSED error is returned, but sunrpc code loses the error and keeps retrying. If it saw the ECONNREFUSED, it would abort. To fix this, handle the sk->sk_err in the TCP_CLOSE branch of xs_tcp_state_change(). Fixes: 3d4762639dd3 (“tcp: remove poll() flakes when receiving RST”) Signed-off-by: NeilBrown Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 41509dbadbecd846a597d8d0442dc3b6982f0361 Author: Jason A. Donenfeld Date: Sat Jun 10 04:59:07 2017 +0200 sunrpc: use constant time memory comparison for mac commit 15a8b93fd5690de017ce665382ea45e5d61811a4 upstream. Otherwise, we enable a MAC forgery via timing attack. Signed-off-by: Jason A. Donenfeld Cc: “J. Bruce Fields” Cc: Jeff Layton Cc: Trond Myklebust Cc: Anna Schumaker Cc: [email protected] Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 8eeee16d7808986327532a5608103f25afbbbb86 Author: Moni Shoua Date: Tue May 23 10:48:44 2017 +0300 IB/core: Namespace is mandatory input for address resolution commit bebb2a473a43c8f84a8210687d1cbdde503046d7 upstream. In function addr_resolve() the namespace is a required input parameter and not an output. It is passed later for searching the routing table and device addresses. Also, it shouldn’t be copied back to the caller. Fixes: 565edd1d5555 (‘IB/addr: Pass network namespace as a parameter’) Signed-off-by: Moni Shoua Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit adbb45552715930e206e4a7674e9c6559c2299dc Author: Vladimir Neyelov Date: Sun May 21 19:17:31 2017 +0300 IB/iser: Fix connection teardown race condition commit c8c16d3bae967f1c7af541e8d016e5c51e4f010a upstream. Under heavy iser target(scst) start/stop stress during login/logout on iser intitiator side happened trace call provided below. The function iscsi_iser_slave_alloc iser_conn pointer could be NULL, due to the fact that function iscsi_iser_conn_stop can be called before and free iser connection. Let’s protect that flow by introducing global mutex. BUG: unable to handle kernel paging request at 0000000000001018 IP: [] iscsi_iser_slave_alloc+0x1e/0x50 [ib_iser] Call Trace: ? scsi_alloc_sdev+0x242/0x300 scsi_probe_and_add_lun+0x9e1/0xea0 ? kfree_const+0x21/0x30 ? kobject_set_name_vargs+0x76/0x90 ? __pm_runtime_resume+0x5b/0x70 __scsi_scan_target+0xf6/0x250 scsi_scan_target+0xea/0x100 iscsi_user_scan_session.part.13+0x101/0x130 [scsi_transport_iscsi] ? iscsi_user_scan_session.part.13+0x130/0x130 [scsi_transport_iscsi] iscsi_user_scan_session+0x1e/0x30 [scsi_transport_iscsi] device_for_each_child+0x50/0x90 iscsi_user_scan+0x44/0x60 [scsi_transport_iscsi] store_scan+0xa8/0x100 ? common_file_perm+0x5d/0x1c0 dev_attr_store+0x18/0x30 sysfs_kf_write+0x37/0x40 kernfs_fop_write+0x12c/0x1c0 __vfs_write+0x18/0x40 vfs_write+0xb5/0x1a0 SyS_write+0x55/0xc0 Fixes: 318d311e8f01 (“iser: Accept arbitrary sg lists mapping if the device supports it”) Signed-off-by: Vladimir Neyelov Signed-off-by: Leon Romanovsky Reviewed-by: Sagi Grimberg Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 6c0d8c2a408402f2d83a41b141efc2e5e8e604c4 Author: Chen Hong Date: Sun Jul 2 15:11:10 2017 -0700 Input: i8042 - fix crash at boot time commit 340d394a789518018f834ff70f7534fc463d3226 upstream. The driver checks port->exists twice in i8042_interrupt(), first when trying to assign temporary “serio” variable, and second time when deciding whether it should call serio_interrupt(). The value of port->exists may change between the 2 checks, and we may end up calling serio_interrupt() with a NULL pointer: BUG: unable to handle kernel NULL pointer dereference at 0000000000000050 IP: [] _spin_lock_irqsave+0x1f/0x40 PGD 0 Oops: 0002 [#1] SMP last sysfs file: CPU 0 Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.32-358.el6.x86_64 #1 QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:[] [] _spin_lock_irqsave+0x1f/0x40 RSP: 0018:ffff880028203cc0 EFLAGS: 00010082 RAX: 0000000000010000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000282 RSI: 0000000000000098 RDI: 0000000000000050 RBP: ffff880028203cc0 R08: ffff88013e79c000 R09: ffff880028203ee0 R10: 0000000000000298 R11: 0000000000000282 R12: 0000000000000050 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000098 FS: 0000000000000000(0000) GS:ffff880028200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 0000000000000050 CR3: 0000000001a85000 CR4: 00000000001407f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process swapper (pid: 1, threadinfo ffff88013e79c000, task ffff88013e79b500) Stack: ffff880028203d00 ffffffff813de186 ffffffffffffff02 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000098 ffff880028203d70 ffffffff813e0162 ffff880028203d20 ffffffff8103b8ac Call Trace: [] serio_interrupt+0x36/0xa0 [] i8042_interrupt+0x132/0x3a0 [] ? kvm_clock_read+0x1c/0x20 [] ? kvm_clock_get_cycles+0x9/0x10 [] handle_IRQ_event+0x60/0x170 [] ? kvm_guest_apic_eoi_write+0x44/0x50 [] handle_edge_irq+0xde/0x180 [] handle_irq+0x49/0xa0 [] do_IRQ+0x6c/0xf0 [] ret_from_intr+0x0/0x11 [] ? __do_softirq+0x73/0x1e0 [] ? hrtimer_interrupt+0x14b/0x260 [] ? call_softirq+0x1c/0x30 [] ? do_softirq+0x65/0xa0 [] ? irq_exit+0x85/0x90 [] ? smp_apic_timer_interrupt+0x70/0x9b [] ? apic_timer_interrupt+0x13/0x20 To avoid the issue let’s change the second check to test whether serio is NULL or not. Also, let’s take i8042_lock in i8042_start() and i8042_stop() instead of trying to be overly smart and using memory barriers. Signed-off-by: Chen Hong [dtor: take lock in i8042_start()/i8042_stop()] Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 165ec230ca5a247d369e7ed60550a089a42ce922 Author: Maciej W. Rozycki Date: Fri Jun 16 00:15:22 2017 +0100 MIPS: Fix a typo: s/preset/present/ in r2-to-r6 emulation error message commit 27fe2200dad2de8207a694024a7b9037dff1b280 upstream. This is a user-visible message, so we want it to be spelled correctly. Fixes: 5f9f41c474be (“MIPS: kernel: Prepare the JR instruction for emulation on MIPS R6”) Signed-off-by: Maciej W. Rozycki Cc: James Hogan Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/16400/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 9f8928117cce5081a806799d6d09c7b38b4342f6 Author: Maciej W. Rozycki Date: Fri Jun 16 00:14:12 2017 +0100 MIPS: Send SIGILL for R6 branches in `__compute_return_epc_for_insn’ commit a60b1a5bf88a250f1a77977c0224e502c901c77b upstream. Fix: * commit 8467ca0122e2 (“MIPS: Emulate the new MIPS R6 branch compact (BC) instruction”), * commit 84fef630127a (“MIPS: Emulate the new MIPS R6 BALC instruction”), * commit 69b9a2fd05a3 (“MIPS: Emulate the new MIPS R6 BEQZC and JIC instructions”), * commit 28d6f93d201d (“MIPS: Emulate the new MIPS R6 BNEZC and JIALC instructions”), * commit c893ce38b265 (“MIPS: Emulate the new MIPS R6 BOVC, BEQC and BEQZALC instructions”) and send SIGILL rather than returning -SIGILL for R6 branch and jump instructions. Returning -SIGILL is never correct as the API defines this function’s result upon error to be -EFAULT and a signal actually issued. Fixes: 8467ca0122e2 (“MIPS: Emulate the new MIPS R6 branch compact (BC) instruction”) Fixes: 84fef630127a (“MIPS: Emulate the new MIPS R6 BALC instruction”) Fixes: 69b9a2fd05a3 (“MIPS: Emulate the new MIPS R6 BEQZC and JIC instructions”) Fixes: 28d6f93d201d (“MIPS: Emulate the new MIPS R6 BNEZC and JIALC instructions”) Fixes: c893ce38b265 (“MIPS: Emulate the new MIPS R6 BOVC, BEQC and BEQZALC instructions”) Signed-off-by: Maciej W. Rozycki Cc: James Hogan Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/16399/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 4b632ba1ce7e7da15ed03ac25c2dc2c5eabe6cae Author: Maciej W. Rozycki Date: Fri Jun 16 00:12:53 2017 +0100 MIPS: Send SIGILL for linked branches in `__compute_return_epc_for_insn’ commit fef40be6da856afead4177aaa9d869a66fb3381f upstream. Fix commit 319824eabc3f (“MIPS: kernel: branch: Do not emulate the branch likelies on MIPS R6”) and also send SIGILL rather than returning -SIGILL for BLTZAL, BLTZALL, BGEZAL and BGEZALL instruction encodings no longer supported in R6, except where emulated. Returning -SIGILL is never correct as the API defines this function’s result upon error to be -EFAULT and a signal actually issued. Fixes: 319824eabc3f (“MIPS: kernel: branch: Do not emulate the branch likelies on MIPS R6”) Signed-off-by: Maciej W. Rozycki Cc: James Hogan Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/16398/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 398cba727d18e84afa7211e6a2d090aee673dcbd Author: Maciej W. Rozycki Date: Fri Jun 16 00:09:23 2017 +0100 MIPS: Rename `sigill_r6’ to `sigill_r2r6’ in `__compute_return_epc_for_insn’ commit 1f4edde422961397cf4470b347958c13c6a740bb upstream. Use the more accurate `sigill_r2r6’ name for the label used in the case of sending SIGILL in the absence of the instruction emulator for an earlier ISA level instruction that has been removed as from the R6 ISA, so that the `sigill_r6’ name is freed for the situation where an R6 instruction is not supposed to be interpreted, because the executing processor does not support the R6 ISA. Signed-off-by: Maciej W. Rozycki Cc: James Hogan Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/16397/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit ba8c4afd162b8921ce146069be65018d82fe0ffd Author: Maciej W. Rozycki Date: Fri Jun 16 00:08:29 2017 +0100 MIPS: Send SIGILL for BPOSGE32 in `__compute_return_epc_for_insn’ commit 7b82c1058ac1f8f8b9f2b8786b1f710a57a870a8 upstream. Fix commit e50c0a8fa60d (“Support the MIPS32 / MIPS64 DSP ASE.”) and send SIGILL rather than SIGBUS whenever an unimplemented BPOSGE32 DSP ASE instruction has been encountered in `__compute_return_epc_for_insn’ as our Reserved Instruction exception handler would in response to an attempt to actually execute the instruction. Sending SIGBUS only makes sense for the unaligned PC case, since moved to `__compute_return_epc’. Adjust function documentation accordingly, correct formatting and use `pr_info’ rather than `printk’ as the other exit path already does. Fixes: e50c0a8fa60d (“Support the MIPS32 / MIPS64 DSP ASE.”) Signed-off-by: Maciej W. Rozycki Cc: James Hogan Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/16396/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit d08b3602c71070d4a50a498f8021c4f623b0a61d Author: Maciej W. Rozycki Date: Fri Jun 16 00:05:08 2017 +0100 MIPS: math-emu: Prevent wrong ISA mode instruction emulation commit 13769ebad0c42738831787e27c7c7f982e7da579 upstream. Terminate FPU emulation immediately whenever an ISA mode switch has been observed. This is so that we do not interpret machine code in the wrong mode, for example when a regular MIPS FPU instruction has been placed in a delay slot of a jump that switches into the MIPS16 mode, as with the following code (taken from a GCC test suite case): 00400650 : 400650: 3c020100 lui v0,0x100 400654: 03e00008 jr ra 400658: 44c2f800 ctc1 v0,c1_fcsr 40065c: 00000000 nop […] 004012d0 <__libc_csu_init>: 4012d0: f000 6a02 li v0,2 4012d4: f150 0b1c la v1,3f9430 <_DYNAMIC-0x6df0> 4012d8: f400 3240 sll v0,16 4012dc: e269 addu v0,v1 4012de: 659a move gp,v0 4012e0: f00c 64f6 save a0-a2,48,ra,s0-s1 4012e4: 673c move s1,gp 4012e6: f010 9978 lw v1,-32744(s1) 4012ea: d204 sw v0,16(sp) 4012ec: eb40 jalr v1 4012ee: 653b move t9,v1 4012f0: f010 997c lw v1,-32740(s1) 4012f4: f030 9920 lw s1,-32736(s1) 4012f8: e32f subu v1,s1 4012fa: 326b sra v0,v1,2 4012fc: d206 sw v0,24(sp) 4012fe: 220c beqz v0,401318 <__libc_csu_init+0x48> 401300: 6800 li s0,0 401302: 99e0 lw a3,0(s1) 401304: 4801 addiu s0,1 401306: 960e lw a2,56(sp) 401308: 4904 addiu s1,4 40130a: 950d lw a1,52(sp) 40130c: 940c lw a0,48(sp) 40130e: ef40 jalr a3 401310: 653f move t9,a3 401312: 9206 lw v0,24(sp) 401314: ea0a cmp v0,s0 401316: 61f5 btnez 401302 <__libc_csu_init+0x32> 401318: 6476 restore 48,ra,s0-s1 40131a: e8a0 jrc ra Here `set_fast_math’ is called from `40130e’ (`40130f’ with the ISA bit) and emulation triggers for the CTC1 instruction. As it is in a jump delay slot emulation continues from `401312’ (`401313’ with the ISA bit). However we have no path to handle MIPS16 FPU code emulation, because there are no MIPS16 FPU instructions. So the default emulation path is taken, interpreting a 32-bit word fetched by `get_user’ from `401313’ as a regular MIPS instruction, which is: 401313: f5ea0a92 sdc1 $f10,2706(t7) This makes the FPU emulator proceed with the supposed SDC1 instruction and consequently makes the program considered here terminate with SIGSEGV. A similar although less severe issue exists with pure-microMIPS processors in the case where similarly an FPU instruction is emulated in a delay slot of a register jump that (incorrectly) switches into the regular MIPS mode. A subsequent instruction fetch from the jump’s target is supposed to cause an Address Error exception, however instead we proceed with regular MIPS FPU emulation. For simplicity then, always terminate the emulation loop whenever a mode change is detected, denoted by an ISA mode bit flip. As from commit 377cb1b6c16a (“MIPS: Disable MIPS16/microMIPS crap for platforms not supporting these ASEs.”) the result of `get_isa16_mode’ can be hardcoded to 0, so we need to examine the ISA mode bit by hand. This complements commit 102cedc32a6e (“MIPS: microMIPS: Floating point support.”) which added JALX decoding to FPU emulation. Fixes: 102cedc32a6e (“MIPS: microMIPS: Floating point support.”) Signed-off-by: Maciej W. Rozycki Cc: James Hogan Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/16393/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit e6f5164e9dc6a74aa6a87d00ac12b36c94072a7c Author: Maciej W. Rozycki Date: Fri Jun 16 00:07:34 2017 +0100 MIPS: Fix unaligned PC interpretation in `compute_return_epc’ commit 11a3799dbeb620bf0400b1fda5cc2c6bea55f20a upstream. Fix a regression introduced with commit fb6883e5809c (“MIPS: microMIPS: Support handling of delay slots.”) and defer to `__compute_return_epc’ if the ISA bit is set in EPC with non-MIPS16, non-microMIPS hardware, which will then arrange for a SIGBUS due to an unaligned instruction reference. Returning EPC here is never correct as the API defines this function’s result to be either a negative error code on failure or one of 0 and BRANCH_LIKELY_TAKEN on success. Fixes: fb6883e5809c (“MIPS: microMIPS: Support handling of delay slots.”) Signed-off-by: Maciej W. Rozycki Cc: James Hogan Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/16395/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit aa55f60181455ddfb6eb10af9ea07aa1879304ea Author: Maciej W. Rozycki Date: Fri Jun 16 00:06:19 2017 +0100 MIPS: Actually decode JALX in `__compute_return_epc_for_insn’ commit a9db101b735a9d49295326ae41f610f6da62b08c upstream. Complement commit fb6883e5809c (“MIPS: microMIPS: Support handling of delay slots.”) and actually decode the regular MIPS JALX major instruction opcode, the handling of which has been added with the said commit for EPC calculation in `__compute_return_epc_for_insn’. Fixes: fb6883e5809c (“MIPS: microMIPS: Support handling of delay slots.”) Signed-off-by: Maciej W. Rozycki Cc: James Hogan Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/16394/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit af0a820b702bdc65cf5b69a5ad66921ff0f395de Author: James Hogan Date: Wed May 31 16:19:48 2017 +0100 MIPS: Save static registers before sysmips commit 49955d84cd9ccdca5a16a495e448e1a06fad9e49 upstream. The MIPS sysmips system call handler may return directly from the MIPS_ATOMIC_SET case (mips_atomic_set()) to syscall_exit. This path restores the static (callee saved) registers, however they won’t have been saved on entry to the system call. Use the save_static_function() macro to create a __sys_sysmips wrapper function which saves the static registers before calling sys_sysmips, so that the correct static register state is restored by syscall_exit. Fixes: f1e39a4a616c (“MIPS: Rewrite sysmips(MIPS_ATOMIC_SET, …) in C with inline assembler”) Signed-off-by: James Hogan Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/16149/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit a3628492ad416a430b713803e4a2e74bda3ad079 Author: Maciej W. Rozycki Date: Sat Jul 8 23:24:44 2017 +0100 MIPS: Fix MIPS I ISA /proc/cpuinfo reporting commit e5f5a5b06e51a36f6ddf31a4a485358263953a3d upstream. Correct a commit 515a6393dbac (“MIPS: kernel: proc: Add MIPS R6 support to /proc/cpuinfo”) regression that caused MIPS I systems to show no ISA levels supported in /proc/cpuinfo, e.g.: system type : Digital DECstation 2100/3100 machine : Unknown processor : 0 cpu model : R3000 V2.0 FPU V2.0 BogoMIPS : 10.69 wait instruction : no microsecond timers : no tlb_entries : 64 extra interrupt vector : no hardware watchpoint : no isa : ASEs implemented : shadow register sets : 1 kscratch registers : 0 package : 0 core : 0 VCED exceptions : not available VCEI exceptions : not available and similarly exclude `mips1’ from the ISA list for any processors below MIPSr1. This is because the condition to show `mips1’ on has been made `cpu_has_mips_r1’ rather than newly-introduced `cpu_has_mips_1’. Use the correct condition then. Fixes: 515a6393dbac (“MIPS: kernel: proc: Add MIPS R6 support to /proc/cpuinfo”) Signed-off-by: Maciej W. Rozycki Reviewed-by: James Hogan Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/16758/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit add5830302906758cc97f01bc1bfa0065d405379 Author: Seunghun Han Date: Tue Jul 18 18:20:44 2017 +0900 x86/ioapic: Pass the correct data to unmask_ioapic_irq() commit e708e35ba6d89ff785b225cd07dcccab04fa954a upstream. One of the rarely executed code pathes in check_timer() calls unmask_ioapic_irq() passing irq_get_chip_data(0) as argument. That’s wrong as unmask_ioapic_irq() expects a pointer to the irq data of interrupt 0. irq_get_chip_data(0) returns NULL, so the following dereference in unmask_ioapic_irq() causes a kernel panic. The issue went unnoticed in the first place because irq_get_chip_data() returns a void pointer so the compiler cannot do a type check on the argument. The code path was added for machines with broken configuration, but it seems that those machines are either not running current kernels or simply do not longer exist. Hand in irq_get_irq_data(0) as argument which provides the correct data. [ tglx: Rewrote changelog ] Fixes: 4467715a44cc (“x86/irq: Move irq_cfg.irq_2_pin into io_apic.c”) Signed-off-by: Seunghun Han Signed-off-by: Thomas Gleixner Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 464c38d4b9365fb013c568a391a7c89b7148d72a Author: Seunghun Han Date: Tue Jul 18 20:03:51 2017 +0900 x86/acpi: Prevent out of bound access caused by broken ACPI tables commit dad5ab0db8deac535d03e3fe3d8f2892173fa6a4 upstream. The bus_irq argument of mp_override_legacy_irq() is used as the index into the isa_irq_to_gsi[] array. The bus_irq argument originates from ACPI_MADT_TYPE_IO_APIC and ACPI_MADT_TYPE_INTERRUPT items in the ACPI tables, but is nowhere sanity checked. That allows broken or malicious ACPI tables to overwrite memory, which might cause malfunction, panic or arbitrary code execution. Add a sanity check and emit a warning when that triggers. [ tglx: Added warning and rewrote changelog ] Signed-off-by: Seunghun Han Signed-off-by: Thomas Gleixner Cc: [email protected] Cc: “Rafael J. Wysocki” Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit e6da6d162ce5b052f4481d4b5d6aee9c94cfd60a Author: Lv Zheng Date: Wed Jul 12 11:09:17 2017 +0800 Revert “ACPI / EC: Enable event freeze mode…” to fix a regression commit 9c40f956ce9b331493347d1b3cb7e384f7dc0581 upstream. On Lenovo ThinkPad X1 Carbon - the 5th Generation, enabling an earlier EC event freezing timing causes acpitz-virtual-0 to report a stuck 48C temparature. And with EC firmware revisioned as 1.14, without reverting back to old EC event freezing timing, the fan still blows up after a system resume. This reverts the culprit change so that the regression can be fixed without upgrading the EC firmware. Fixes: d30283057ecd (ACPI / EC: Enable event freeze mode to improve event handling) Link: https://bugzilla.kernel.org/show_bug.cgi?id=191181#c168 Tested-by: Damjan Georgievski Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 5f4556a4e0d27f651e427e2ab06972d3548a0426 Author: Lv Zheng Date: Wed Jul 12 11:09:09 2017 +0800 ACPI / EC: Drop EC noirq hooks to fix a regression commit 662591461c4b9a1e3b9b159dbf37648a585ebaae upstream. According to bug reports, although the busy polling mode can make noirq stages execute faster, it causes abnormal fan blowing up after system resume (see the first link below for a video demonstration) on Lenovo ThinkPad X1 Carbon - the 5th Generation. The problem can be fixed by upgrading the EC firmware on that machine. However, many reporters confirm that the problem can be fixed by stopping busy polling during suspend/resume and for some of them upgrading the EC firmware is not an option. For this reason, drop the noirq stage hooks from the EC driver to fix the regression. Fixes: c3a696b6e8f8 (ACPI / EC: Use busy polling mode when GPE is not enabled) Link: https://youtu.be/9NQ9x-Jm99Q Link: https://bugzilla.kernel.org/show_bug.cgi?id=196129 Reported-by: Andreas Lindhe Tested-by: Gjorgji Jankovski Tested-by: Damjan Georgievski Tested-by: Fernando Chaves Tested-by: Tomislav Ivek Tested-by: Denis P. Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit cc66888fbf58faf603358db6fe31bc9a03ce0416 Author: Richard Weinberger Date: Mon Jun 26 13:49:04 2017 +0200 ubifs: Set double hash cookie also for RENAME_EXCHANGE commit a6664433d383eeb71cbdeb9aea2c66eeea76e742 upstream. We developed RENAME_EXCHANGE and UBIFS_FLG_DOUBLE_HASH more or less in parallel and this case was forgotten. :-( Fixes: d63d61c16972 (“ubifs: Implement UBIFS_FLG_DOUBLE_HASH”) Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit cd152e6e347c6c6311877e40a75eee37cf00be43 Author: David Gstir Date: Wed May 17 13:36:16 2017 +0200 ubifs: Don’t encrypt special files on creation commit f34e87f58dabc31eb69f61cf4a79e951d4176743 upstream. When a new inode is created, we check if the containing folder has a encryption policy set and inherit that. This should however only be done for regular files, links and subdirectories. Not for sockes fifos etc. Fixes: d475a507457b (“ubifs: Add skeleton for fscrypto”) Signed-off-by: David Gstir Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 53f10329dd0e56015ea2d4d839d33b38b3ee68d0 Author: Richard Weinberger Date: Fri Jun 16 16:21:44 2017 +0200 ubifs: Don’t leak kernel memory to the MTD commit 4acadda74ff8b949c448c0282765ae747e088c87 upstream. When UBIFS prepares data structures which will be written to the MTD it ensues that their lengths are multiple of 8. Since it uses kmalloc() the padded bytes are left uninitialized and we leak a few bytes of kernel memory to the MTD. To make sure that all bytes are initialized, let’s switch to kzalloc(). Kzalloc() is fine in this case because the buffers are not huge and in the IO path the performance bottleneck is anyway the MTD. Fixes: 1e51764a3c2a (“UBIFS: add new flash file system”) Signed-off-by: Richard Weinberger Reviewed-by: Boris Brezillon Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit caffe745a1e508f2e5840568451eaef101bfa430 Author: Richard Weinberger Date: Wed May 17 00:20:27 2017 +0200 ubifs: Correctly evict xattr inodes commit 272eda8298dc82eb411ece82bbb2c62911087b24 upstream. UBIFS handles extended attributes just like files, as consequence of that, they also have inodes. Therefore UBIFS does all the inode machinery also for xattrs. Since new inodes have i_nlink of 1, a file or xattr inode will be evicted if i_nlink goes down to 0 after an unlink. UBIFS assumes this model also for xattrs, which is not correct. One can create a file “foo” with xattr "user.test". By reading “user.test” an inode will be created, and by deleting “user.test” it will get evicted later. The assumption breaks if the file "foo", which hosts the xattrs, will be removed. VFS nor UBIFS does not remove each xattr via ubifs_xattr_remove(), it just removes the host inode from the TNC and all underlying xattr nodes too and the inode will remain in the cache and wastes memory. To solve this problem, remove xattr inodes from the VFS inode cache in ubifs_xattr_remove() to make sure that they get evicted. Fixes: 1e51764a3c2ac05a (“UBIFS: add new flash file system”) Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 012e56c5e4662b6c91db4c0651399a9d83ede77f Author: Boris Brezillon Date: Wed May 17 10:47:50 2017 +0200 mtd: nand: tango: Fix incorrect use of SEQIN command commit a186493237a9d8559997c2f97c33c4716d602fd2 upstream. SEQIN is supposed to be used when one wants to start programming a page. What we want here is just to change the column within the page, which is done with the RNDIN command. Fixes: 6956e2385a16 (“mtd: nand: add tango NAND flash controller support”) Signed-off-by: Boris Brezillon Acked-by: Marc Gonzalez Signed-off-by: Greg Kroah-Hartman commit 6b7483630f431c8e773f457e6ee87c8844031b71 Author: James Hogan Date: Thu Jun 29 10:12:34 2017 +0100 MIPS: Negate error syscall return in trace commit 4f32a39d49b25eaa66d2420f1f03d371ea4cd906 upstream. The sys_exit trace event takes a single return value for the system call, which MIPS passes the value of the $v0 (result) register, however MIPS returns positive error codes in $v0 with $a3 specifying that $v0 contains an error code. As a result erroring system calls are traced returning positive error numbers that can’t always be distinguished from success. Use regs_return_value() to negate the error code if $a3 is set. Fixes: 1d7bf993e073 (“MIPS: ftrace: Add support for syscall tracepoints.”) Signed-off-by: James Hogan Cc: Steven Rostedt Cc: Ingo Molnar Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/16651/ Acked-by: Steven Rostedt (VMware) Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit f5dc58618d76476591d34d6f7b67b76a7376e730 Author: James Hogan Date: Wed May 31 16:19:49 2017 +0100 MIPS: Fix mips_atomic_set() with EVA commit 4915e1b043d6286928207b1f6968197b50407294 upstream. EVA linked loads (LLE) and conditional stores (SCE) should be used on EVA kernels for the MIPS_ATOMIC_SET operation of the sysmips system call, or else the atomic set will apply to the kernel view of the virtual address space (potentially unmapped on EVA kernels) rather than the user view (TLB mapped). Signed-off-by: James Hogan Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/16151/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit e742bca1a23d3fd7c966e569a199304b420a66e1 Author: James Hogan Date: Wed May 31 16:19:47 2017 +0100 MIPS: Fix mips_atomic_set() retry condition commit 2ec420b26f7b6ff332393f0bb5a7d245f7ad87f0 upstream. The inline asm retry check in the MIPS_ATOMIC_SET operation of the sysmips system call has been backwards since commit f1e39a4a616c (“MIPS: Rewrite sysmips(MIPS_ATOMIC_SET, …) in C with inline assembler”) merged in v2.6.32, resulting in the non R10000_LLSC_WAR case retrying until the operation was inatomic, before returning the new value that was probably just written multiple times instead of the old value. Invert the branch condition to fix that particular issue. Fixes: f1e39a4a616c (“MIPS: Rewrite sysmips(MIPS_ATOMIC_SET, …) in C with inline assembler”) Signed-off-by: James Hogan Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/16148/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 82823554d21b8389c58246b1d8ecb5f06bc0877e Author: Maarten Lankhorst Date: Thu Jun 29 13:59:54 2017 +0200 drm/atomic: Add missing drm_atomic_state_clear to atomic_remove_fb commit 4086d90cffb8f48400d51fbab575fe50458512e3 upstream. All atomic state should be cleared when drm_modeset_backoff() is called, because it drops all locks and the state becomes invalid. The call to drm_atomic_state_clear was missing in atomic_remove_fb, so add the missing call there. Signed-off-by: Maarten Lankhorst Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Daniel Vetter Fixes: db8f6403e88a (“drm: Convert drm_framebuffer_remove to atomic, v4.”) Signed-off-by: Greg Kroah-Hartman commit 254084986a8a30b2b56979da9ddd32dc211c0b2e Author: Chuanxiao Dong Date: Mon Jun 26 15:20:50 2017 +0800 drm/i915/gvt: Fix inconsistent locks holding sequence commit f16bd3dda2c8bf6699e808cd9cc540cfab10e60e upstream. There are two kinds of locking sequence. One is in the thread which is started by vfio ioctl to do the iommu unmapping. The locking sequence is: down_read(&group_lock) ----> mutex_lock(&cached_lock) The other is in the vfio release thread which will unpin all the cached pages. The lock sequence is: mutex_lock(&cached_lock) —> down_read(&group_lock) And, the cache_lock is used to protect the rb tree of the cache node and doing vfio unpin doesn’t require this lock. Move the vfio unpin out of the cache_lock protected region. v2: - use for style instead of do{}while(1). (Zhenyu) Fixes: f30437c5e7bf (“drm/i915/gvt: add KVMGT support”) Signed-off-by: Chuanxiao Dong Cc: Zhenyu Wang Signed-off-by: Zhenyu Wang Signed-off-by: Greg Kroah-Hartman commit 6dbeea7da557039d234b56045ee6966fd0410900 Author: Robin Murphy Date: Mon Jun 19 16:41:56 2017 +0100 iommu/arm-smmu: Plumb in new ACPI identifiers commit 84c24379a783c514e5ff7c8fc8a21cf8d64fd05f upstream. Revision C of IORT now allows us to identify ARM MMU-401 and the Cavium ThunderX implementation. Wire them up so that we can probe these models once firmware starts using the new codes in place of generic ones, and so that the appropriate features and quirks get enabled when we do. For the sake of backports and mitigating sychronisation problems with the ACPICA headers, we’ll carry a backup copy of the new definitions locally for the short term to make life simpler. Acked-by: Robert Richter Tested-by: Robert Richter Signed-off-by: Robin Murphy Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 57c2c7dfa049e5a4ab473b1dee8283f39fc6cafd Author: Dan Carpenter Date: Wed Jul 12 10:35:57 2017 +0300 ftrace: Fix uninitialized variable in match_records() commit 2e028c4fe12907f226b8221815f16c2486ad3aa7 upstream. My static checker complains that if “func” is NULL then “clear_filter” is uninitialized. This seems like it could be true, although it’s possible something subtle is happening that I haven’t seen. kernel/trace/ftrace.c:3844 match_records() error: uninitialized symbol 'clear_filter’. Link: http://lkml.kernel.org/r/20170712073556.h6tkpjcdzjaozozs@mwanda Fixes: f0a3b154bd7 (“ftrace: Clarify code for mod command”) Signed-off-by: Dan Carpenter Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 3ea54f661fe397cba602a69d9d69891dc0ca702a Author: Marta Rybczynska Date: Tue Jun 6 13:27:21 2017 +0200 nvme-rdma: remove race conditions from IB signalling commit 5e599d73c1c1816af07f94ddba879499aa39b43c upstream. This patch improves the way the RDMA IB signalling is done by using atomic operations for the signalling variable. This avoids race conditions on sig_count. The signalling interval changes slightly and is now the largest power of two not larger than queue depth / 2. ilog() usage idea by Bart Van Assche. Signed-off-by: Marta Rybczynska Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit 5a5e706f1168ef66cd2a36e3a6460063d9380759 Author: Alex Williamson Date: Fri Jul 7 15:37:38 2017 -0600 vfio: Remove unnecessary uses of vfio_container.group_lock commit 7f56c30bd0a232822aca38d288da475613bdff9b upstream. The original intent of vfio_container.group_lock is to protect vfio_container.group_list, however over time it’s become a crutch to prevent changes in container composition any time we call into the iommu driver backend. This introduces problems when we start to have more complex interactions, for example when a user’s DMA unmap request triggers a notification to an mdev vendor driver, who responds by attempting to unpin mappings within that request, re-entering the iommu backend. We incorrectly assume that the use of read-locks here allow for this nested locking behavior, but a poorly timed write-lock could in fact trigger a deadlock. The current use of group_lock seems to fall into the trap of locking code, not data. Correct that by removing uses of group_lock that are not directly related to group_list. Note that the vfio type1 iommu backend has its own mutex, vfio_iommu.lock, which it uses to protect itself for each of these interfaces anyway. The group_lock appears to be a redundancy for these interfaces and type1 even goes so far as to release its mutex to allow for exactly the re-entrant code path above. Reported-by: Chuanxiao Dong Signed-off-by: Alex Williamson Acked-by: Alexey Kardashevskiy Signed-off-by: Greg Kroah-Hartman commit 9ffc6fc6c2add85e06921f6f26b0204bfc407016 Author: Alex Williamson Date: Wed Jun 28 13:50:05 2017 -0600 vfio: New external user group/file match commit 5d6dee80a1e94cc284d03e06d930e60e8d3ecf7d upstream. At the point where the kvm-vfio pseudo device wants to release its vfio group reference, we can’t always acquire a new reference to make that happen. The group can be in a state where we wouldn’t allow a new reference to be added. This new helper function allows a caller to match a file to a group to facilitate this. Given a file and group, report if they match. Thus the caller needs to already have a group reference to match to the file. This allows the deletion of a group without acquiring a new reference. Signed-off-by: Alex Williamson Reviewed-by: Eric Auger Reviewed-by: Paolo Bonzini Tested-by: Eric Auger Signed-off-by: Greg Kroah-Hartman commit 4fb3d76fcac31d2f9423bb8021030ac22bc552ec Author: Alex Williamson Date: Mon Jun 19 09:10:32 2017 -0600 vfio: Fix group release deadlock commit 811642d8d8a82c0cce8dc2debfdaf23c5a144839 upstream. If vfio_iommu_group_notifier() acquires a group reference and that reference becomes the last reference to the group, then vfio_group_put introduces a deadlock code path where we’re trying to unregister from the iommu notifier chain from within a callout of that chain. Use a work_struct to release this reference asynchronously. Signed-off-by: Alex Williamson Reviewed-by: Eric Auger Tested-by: Eric Auger Signed-off-by: Greg Kroah-Hartman commit 72ec4c2f63204a41b4e559940d82f02e981f89e4 Author: Ville Syrjälä Date: Mon Jun 26 23:30:51 2017 +0300 drm/i915: Disable MSI for all pre-gen5 commit ce3f7163e4ce8fd583dcb36b6ee6b81fd1b419ae upstream. We have pretty clear evidence that MSIs are getting lost on g4x and somehow the interrupt logic doesn’t seem to recover from that state even if we try hard to clear the IIR. Disabling IER around the normal IIR clearing in the irq handler isn’t sufficient to avoid this, so the problem really seems to be further up the interrupt chain. This should guarantee that there’s always an edge if any IIR bits are set after the interrupt handler is done, which should normally guarantee that the CPU interrupt is generated. That approach seems to work perfectly on VLV/CHV, but apparently not on g4x. MSI is documented to be broken on 965gm at least. The chipset spec says MSI is defeatured because interrupts can be delayed or lost, which fits well with what we’re seeing on g4x. Previously we’ve already disabled GMBUS interrupts on g4x because somehow GMBUS manages to raise legacy interrupts even when MSI is enabled. Since there’s such widespread MSI breakahge all over in the pre-gen5 land let’s just give up on MSI on these platforms. Seqno reporting might be negatively affected by this since the legcy interrupts aren’t guaranteed to be ordered with the seqno writes, whereas MSI interrupts may be? But an occasioanlly missed seqno seems like a small price to pay for generally working interrupts. Cc: Diego Viola Tested-by: Diego Viola Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101261 Signed-off-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Daniel Vetter (cherry picked from commit e38c2da01f76cca82b59ca612529b81df82a7cc7) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 7d47d0b933827469b3338607cff56dd8306d0564 Author: Hawking Zhang Date: Tue Jun 6 16:25:44 2017 +0800 drm/amd/powerplay: fix memory leak in cz_hwmgr backend commit b1e8b9c5b19c58e3159c2acc77167f4a4c74621f upstream. vddc_dep_on_dal_pwrl is allocated and initialized in cz_hwmgr_backend_init Thus free the memory in cz_hwmgr_backend_fini Signed-off-by: Hawking Zhang Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 98cc417e0b95d8cf2baeba5a2159d46be2e0941c Author: Amir Goldstein Date: Tue Jul 11 15:58:35 2017 +0300 ovl: fix random return value on mount commit 8fc646b44385ff0a9853f6590497e43049eeb311 upstream. On failure to prepare_creds(), mount fails with a random return value, as err was last set to an integer cast of a valid lower mnt pointer or set to 0 if inodes index feature is enabled. Reported-by: Dan Carpenter Fixes: 3fe6e52f0626 (“ovl: override creds with the ones from …”) Signed-off-by: Amir Goldstein Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit aedd116d5a5993cb5ece0eeecb97f828413e742a Author: Amir Goldstein Date: Tue Jul 11 15:58:34 2017 +0300 ovl: mark parent impure on ovl_link() commit ea3dad18dc5f778cfd931311a91a9315aa0065a3 upstream. When linking a file with copy up origin into a new parent, mark the new parent dir "impure". Fixes: ee1d6d37b6b8 (“ovl: mark upper dir with type origin entries “impure"”) Signed-off-by: Amir Goldstein Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 6a2c416963bc43ca5513770624b78be80561f800 Author: Dan Carpenter Date: Mon Jul 17 11:34:23 2017 +0300 serial: sh-sci: Uninitialized variables in sysfs files commit 4ab3c51e0540ba8464fe34d84cc35821bb77ae92 upstream. The kstrtol() function returns -ERANGE as well as -EINVAL so these tests are not enough. It’s not a super serious bug, but my static checker correctly complains that the “r” variable might be used uninitialized. Fixes: 5d23188a473d (“serial: sh-sci: make RX FIFO parameters tunable via sysfs”) Signed-off-by: Dan Carpenter Signed-off-by: Greg Kroah-Hartman commit bc6ff930b39ce2d5e8d122211b92480564ab0b7e Author: Dan Carpenter Date: Mon Jul 17 11:12:38 2017 +0300 serial: st-asc: Potential error pointer dereference commit 2b01bfaeb41e1563322448d9b392ac924cbf22ef upstream. It looks like we intended to return an error code here, because we dereference “ascport->pinctrl” on the next lines. Fixes: 6929cb00a501 (“serial: st-asc: Read in all Pinctrl states”) Signed-off-by: Dan Carpenter Acked-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 893425c7201c6029d855219d14746841c8592cba Author: Jaegeuk Kim Date: Tue Jul 11 14:56:49 2017 -0700 f2fs: Don’t clear SGID when inheriting ACLs commit c925dc162f770578ff4a65ec9b08270382dba9e6 upstream. This patch copies commit b7f8a09f80: “btrfs: Don’t clear SGID when inheriting ACLs” written by Jan. Fixes: 073931017b49d9458aa351605b43a7e34598caef Signed-off-by: Jan Kara Reviewed-by: Chao Yu Reviewed-by: Jan Kara Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 65483db1a6492c52698c72f7010f83e7fd755e7d Author: Chao Yu Date: Fri Jul 7 14:10:15 2017 +0800 f2fs: use spin_{,un}lock_irq{save,restore} commit d1aa245354ae4605d1183f542ed8d45811c439f6 upstream. generic/361 reports below warning, this is because: once, there is someone entering into critical region of sbi.cp_lock, if write_end_io. f2fs_stop_checkpoint is invoked from an triggered IRQ, we will encounter deadlock. So this patch changes to use spin_{,un}lock_irq{save,restore} to create critical region without IRQ enabled to avoid potential deadlock. irq event stamp: 83391573 loop: Write error at byte offset 438729728, length 1024. hardirqs last enabled at (83391573): [] restore_all+0xf/0x65 hardirqs last disabled at (83391572): [] reschedule_interrupt+0x30/0x3c loop: Write error at byte offset 438860288, length 1536. softirqs last enabled at (83389244): [] __do_softirq+0x1ae/0x476 softirqs last disabled at (83389237): [] do_softirq_own_stack+0x2c/0x40 loop: Write error at byte offset 438990848, length 2048. ================================ WARNING: inconsistent lock state 4.12.0-rc2+ #30 Tainted: G O -------------------------------- inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. xfs_io/7959 [HC1[1]:SC0[0]:HE0:SE1] takes: (&(&sbi->cp_lock)->rlock){?.+…}, at: [] f2fs_stop_checkpoint+0x1c/0x50 [f2fs] {HARDIRQ-ON-W} state was registered at: __lock_acquire+0x527/0x7b0 lock_acquire+0xae/0x220 _raw_spin_lock+0x42/0x50 do_checkpoint+0x165/0x9e0 [f2fs] write_checkpoint+0x33f/0x740 [f2fs] __f2fs_sync_fs+0x92/0x1f0 [f2fs] f2fs_sync_fs+0x12/0x20 [f2fs] sync_filesystem+0x67/0x80 generic_shutdown_super+0x27/0x100 kill_block_super+0x22/0x50 kill_f2fs_super+0x3a/0x40 [f2fs] deactivate_locked_super+0x3d/0x70 deactivate_super+0x40/0x60 cleanup_mnt+0x39/0x70 __cleanup_mnt+0x10/0x20 task_work_run+0x69/0x80 exit_to_usermode_loop+0x57/0x85 do_fast_syscall_32+0x18c/0x1b0 entry_SYSENTER_32+0x4c/0x7b irq event stamp: 1957420 hardirqs last enabled at (1957419): [] _raw_spin_unlock_irq+0x27/0x50 hardirqs last disabled at (1957420): [] call_function_single_interrupt+0x30/0x3c softirqs last enabled at (1953784): [] __do_softirq+0x1ae/0x476 softirqs last disabled at (1953773): [] do_softirq_own_stack+0x2c/0x40 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(&sbi->cp_lock)->rlock); lock(&(&sbi->cp_lock)->rlock); *** DEADLOCK *** 2 locks held by xfs_io/7959: #0: (sb_writers#13){.+.+.+}, at: [] vfs_write+0x16a/0x190 #1: (&sb->s_type->i_mutex_key#16){+.+.+.}, at: [] f2fs_file_write_iter+0x25/0x140 [f2fs] stack backtrace: CPU: 2 PID: 7959 Comm: xfs_io Tainted: G O 4.12.0-rc2+ #30 Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 Call Trace: dump_stack+0x5f/0x92 print_usage_bug+0x1d3/0x1dd ? check_usage_backwards+0xe0/0xe0 mark_lock+0x23d/0x280 __lock_acquire+0x699/0x7b0 ? __this_cpu_preempt_check+0xf/0x20 ? trace_hardirqs_off_caller+0x91/0xe0 lock_acquire+0xae/0x220 ? f2fs_stop_checkpoint+0x1c/0x50 [f2fs] _raw_spin_lock+0x42/0x50 ? f2fs_stop_checkpoint+0x1c/0x50 [f2fs] f2fs_stop_checkpoint+0x1c/0x50 [f2fs] f2fs_write_end_io+0x147/0x150 [f2fs] bio_endio+0x7a/0x1e0 blk_update_request+0xad/0x410 blk_mq_end_request+0x16/0x60 lo_complete_rq+0x3c/0x70 __blk_mq_complete_request_remote+0x11/0x20 flush_smp_call_function_queue+0x6d/0x120 ? debug_smp_processor_id+0x12/0x20 generic_smp_call_function_single_interrupt+0x12/0x30 smp_call_function_single_interrupt+0x25/0x40 call_function_single_interrupt+0x37/0x3c EIP: _raw_spin_unlock_irq+0x2d/0x50 EFLAGS: 00000296 CPU: 2 EAX: 00000001 EBX: d2ccc51c ECX: 00000001 EDX: c1aacebd ESI: 00000000 EDI: 00000000 EBP: c96c9d1c ESP: c96c9d18 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 ? inherit_task_group.isra.98.part.99+0x6b/0xb0 __add_to_page_cache_locked+0x1d4/0x290 add_to_page_cache_lru+0x38/0xb0 pagecache_get_page+0x8e/0x200 f2fs_write_begin+0x96/0xf00 [f2fs] ? trace_hardirqs_on_caller+0xdd/0x1c0 ? current_time+0x17/0x50 ? trace_hardirqs_on+0xb/0x10 generic_perform_write+0xa9/0x170 __generic_file_write_iter+0x1a2/0x1f0 ? f2fs_preallocate_blocks+0x137/0x160 [f2fs] f2fs_file_write_iter+0x6e/0x140 [f2fs] ? __lock_acquire+0x429/0x7b0 __vfs_write+0xc1/0x140 vfs_write+0x9b/0x190 SyS_pwrite64+0x63/0xa0 do_fast_syscall_32+0xa1/0x1b0 entry_SYSENTER_32+0x4c/0x7b EIP: 0xb7786c61 EFLAGS: 00000293 CPU: 2 EAX: ffffffda EBX: 00000003 ECX: 08416000 EDX: 00001000 ESI: 18b24000 EDI: 00000000 EBP: 00000003 ESP: bf9b36b0 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b Fixes: aaec2b1d1879 (“f2fs: introduce cp_lock to protect updating of ckpt_flags”) Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit d0f0ccf8f4c246f36ff06c9b409f9cae1630bea6 Author: Jin Qian Date: Thu Jun 1 11:18:30 2017 -0700 f2fs: sanity check size of nat and sit cache commit 21d3f8e1c3b7996ce239ab6fa82e9f7a8c47d84d upstream. Make sure number of entires doesn’t exceed max journal size. Signed-off-by: Jin Qian Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit dca54568b79d67bb736ea9dc272c460d4a488c0b Author: Damien Le Moal Date: Fri May 26 17:04:40 2017 +0900 f2fs: Do not issue small discards in LFS mode commit acfd2810c75b0625897fc119a2d3a9c26cc0e405 upstream. clear_prefree_segments() issues small discards after discarding full segments. These small discards may not be section aligned, so not zone aligned on a zoned block device, causing __f2fs_iissue_discard_zone() to fail. Fix this by not issuing small discards for a volume mounted with the BLKZONED feature enabled. Signed-off-by: Damien Le Moal Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 4567789d3343fd56ff5b1afa096634ff89d0d670 Author: Jaegeuk Kim Date: Wed May 17 10:36:58 2017 -0700 f2fs: try to freeze in gc and discard threads commit 1d7be2708277edfef95171d52fb65ee26eaa076b upstream. This allows to freeze gc and discard threads. Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 55df2e68c21714444fc3056c5636531ee9d1bc58 Author: Jin Qian Date: Mon May 15 10:45:08 2017 -0700 f2fs: sanity check checkpoint segno and blkoff commit 15d3042a937c13f5d9244241c7a9c8416ff6e82a upstream. Make sure segno and blkoff read from raw image are valid. Signed-off-by: Jin Qian [Jaegeuk Kim: adjust minor coding style] Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 378560b8c2b3560263b6b56a4d5fe8d2b4931f0e Author: Chao Yu Date: Fri May 19 23:46:44 2017 +0800 f2fs: wake up all waiters in f2fs_submit_discard_endio commit e31b98215779e66a490471c6ad886ae231316699 upstream. There could be more than one waiter waiting discard IO completion, so we need use complete_all() instead of complete() in f2fs_submit_discard_endio to avoid hungtask. Fixes: ec9895add2c5 (“f2fs: don’t hold cmd_lock during waiting discard command”) Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 9aabcf47906df581f57a9c5b3e617e0c18b3fd7a Author: Jaegeuk Kim Date: Tue May 16 13:20:16 2017 -0700 f2fs: load inode’s flag from disk commit 93607124c5450148e592c3d18ac533b4e5f25b8b upstream. This patch fixes missing inode flag loaded from disk, reported by Tom. [tom@localhost ~]$ sudo mount /dev/loop0 /mnt/ [tom@localhost ~]$ sudo chown tom:tom /mnt/ [tom@localhost ~]$ touch /mnt/testfile [tom@localhost ~]$ sudo chattr +i /mnt/testfile [tom@localhost ~]$ echo test > /mnt/testfile bash: /mnt/testfile: Operation not permitted [tom@localhost ~]$ rm /mnt/testfile rm: cannot remove '/mnt/testfile’: Operation not permitted [tom@localhost ~]$ sudo umount /mnt/ [tom@localhost ~]$ sudo mount /dev/loop0 /mnt/ [tom@localhost ~]$ lsattr /mnt/testfile ----i-------------- /mnt/testfile [tom@localhost ~]$ echo test > /mnt/testfile [tom@localhost ~]$ rm /mnt/testfile [tom@localhost ~]$ sudo umount /mnt/ Reported-by: Tom Yan Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit ac7e0a9e3c7f2aa7f59e6d12869829960f6cbefc Author: Pavel Shilovsky Date: Sat Jul 8 14:32:00 2017 -0700 CIFS: Reconnect expired SMB sessions commit 511c54a2f69195b28afb9dd119f03787b1625bb4 upstream. According to the MS-SMB2 spec (3.2.5.1.6) once the client receives STATUS_NETWORK_SESSION_EXPIRED error code from a server it should reconnect the current SMB session. Currently the client doesn’t do that. This can result in subsequent client requests failing by the server. The patch adds an additional logic to the demultiplex thread to identify expired sessions and reconnect them. Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 7350fbef5cfa0e03e9b4a7bd1b4980945946f988 Author: Jan Kara Date: Mon Jun 26 08:48:18 2017 -0700 xfs: Don’t clear SGID when inheriting ACLs commit 8ba358756aa08414fa9e65a1a41d28304ed6fd7f upstream. When new directory ‘DIR1’ is created in a directory ‘DIR0’ with SGID bit set, DIR1 is expected to have SGID bit set (and owning group equal to the owning group of ‘DIR0’). However when ‘DIR0’ also has some default ACLs that ‘DIR1’ inherits, setting these ACLs will result in SGID bit on ‘DIR1’ to get cleared if user is not member of the owning group. Fix the problem by calling __xfs_set_acl() instead of xfs_set_acl() when setting up inode in xfs_generic_create(). That prevents SGID bit clearing and mode is properly set by posix_acl_create() anyway. We also reorder arguments of __xfs_set_acl() to match the ordering of xfs_set_acl() to make things consistent. Fixes: 073931017b49d9458aa351605b43a7e34598caef CC: Darrick J. Wong CC: [email protected] Signed-off-by: Jan Kara Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman commit d4a0964c5ce2bd46a288234c1edf7eec5da56ade Author: Corey Minyard Date: Fri Jun 30 07:18:08 2017 -0500 ipmi:ssif: Add missing unlock in error branch commit 4495ec6d770e1bca7a04e93ac453ab6720c56c5d upstream. When getting flags, a response to a different message would result in a deadlock because of a missing unlock. Add that unlock and a comment. Found by static analysis. Reported-by: Dan Carpenter Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman commit 65acfd381d4fa5d2dbb328a52db2013b9367e614 Author: Tony Camuso Date: Mon Jun 19 13:17:33 2017 -0400 ipmi: use rcu lock around call to intf->handlers->sender() commit cdea46566bb21ce309725a024208322a409055cc upstream. A vendor with a system having more than 128 CPUs occasionally encounters the following crash during shutdown. This is not an easily reproduceable event, but the vendor was able to provide the following analysis of the crash, which exhibits the same footprint each time. crash> bt PID: 0 TASK: ffff88017c70ce70 CPU: 5 COMMAND: “swapper/5” #0 [ffff88085c143ac8] machine_kexec at ffffffff81059c8b #1 [ffff88085c143b28] __crash_kexec at ffffffff811052e2 #2 [ffff88085c143bf8] crash_kexec at ffffffff811053d0 #3 [ffff88085c143c10] oops_end at ffffffff8168ef88 #4 [ffff88085c143c38] no_context at ffffffff8167ebb3 #5 [ffff88085c143c88] __bad_area_nosemaphore at ffffffff8167ec49 #6 [ffff88085c143cd0] bad_area_nosemaphore at ffffffff8167edb3 #7 [ffff88085c143ce0] __do_page_fault at ffffffff81691d1e #8 [ffff88085c143d40] do_page_fault at ffffffff81691ec5 #9 [ffff88085c143d70] page_fault at ffffffff8168e188 [exception RIP: unknown or invalid address] RIP: ffffffffa053c800 RSP: ffff88085c143e28 RFLAGS: 00010206 RAX: ffff88017c72bfd8 RBX: ffff88017a8dc000 RCX: ffff8810588b5ac8 RDX: ffff8810588b5a00 RSI: ffffffffa053c800 RDI: ffff8810588b5a00 RBP: ffff88085c143e58 R8: ffff88017c70d408 R9: ffff88017a8dc000 R10: 0000000000000002 R11: ffff88085c143da0 R12: ffff8810588b5ac8 R13: 0000000000000100 R14: ffffffffa053c800 R15: ffff8810588b5a00 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 [exception RIP: cpuidle_enter_state+82] RIP: ffffffff81514192 RSP: ffff88017c72be50 RFLAGS: 00000202 RAX: 0000001e4c3c6f16 RBX: 000000000000f8a0 RCX: 0000000000000018 RDX: 0000000225c17d03 RSI: ffff88017c72bfd8 RDI: 0000001e4c3c6f16 RBP: ffff88017c72be78 R8: 000000000000237e R9: 0000000000000018 R10: 0000000000002494 R11: 0000000000000001 R12: ffff88017c72be20 R13: ffff88085c14f8e0 R14: 0000000000000082 R15: 0000001e4c3bb400 ORIG_RAX: ffffffffffffff10 CS: 0010 SS: 0018 This is the corresponding stack trace It has crashed because the area pointed with RIP extracted from timer element is already removed during a shutdown process. The function is smi_timeout(). And we think ffff8810588b5a00 in RDX is a parameter struct smi_info crash> rd ffff8810588b5a00 20 ffff8810588b5a00: ffff8810588b6000 0000000000000000 .`.X… ffff8810588b5a10: ffff880853264400 ffffffffa05417e0 .D&S…T… ffff8810588b5a20: 24a024a000000000 0000000000000000 …$.$… ffff8810588b5a30: 0000000000000000 0000000000000000 … ffff8810588b5a30: 0000000000000000 0000000000000000 … ffff8810588b5a40: ffffffffa053a040 ffffffffa053a060 @.S…`.S… ffff8810588b5a50: 0000000000000000 0000000100000001 … ffff8810588b5a60: 0000000000000000 0000000000000e00 … ffff8810588b5a70: ffffffffa053a580 ffffffffa053a6e0 …S…S… ffff8810588b5a80: ffffffffa053a4a0 ffffffffa053a250 …S…P.S… ffff8810588b5a90: 0000000500000002 0000000000000000 … Unfortunately the top of this area is already detroyed by someone. But because of two reasonns we think this is struct smi_info 1) The address included in between ffff8810588b5a70 and ffff8810588b5a80: are inside of ipmi_si_intf.c see crash> module ffff88085779d2c0 2) We’ve found the area which point this. It is offset 0x68 of ffff880859df4000 crash> rd ffff880859df4000 100 ffff880859df4000: 0000000000000000 0000000000000001 … ffff880859df4010: ffffffffa0535290 dead000000000200 .RS… ffff880859df4020: ffff880859df4020 ffff880859df4020 @.Y… @.Y… ffff880859df4030: 0000000000000002 0000000000100010 … ffff880859df4040: ffff880859df4040 ffff880859df4040 @@.Y…@@.Y… ffff880859df4050: 0000000000000000 0000000000000000 … ffff880859df4060: 0000000000000000 ffff8810588b5a00 …Z.X… ffff880859df4070: 0000000000000001 ffff880859df4078 …[email protected]… If we regards it as struct ipmi_smi in shutdown process it looks consistent. The remedy for this apparent race is affixed below. Signed-off-by: Tony Camuso Signed-off-by: Greg Kroah-Hartman This was first introduced in 7ea0ed2b5be817 ipmi: Make the message handler easier to use for SMI interfaces where some code was moved outside of the rcu_read_lock() and the lock was not added. Signed-off-by: Corey Minyard commit 719829d19c0ce215ff9b4f0b76c845bfa8cca64d Author: Eric Anholt Date: Mon Apr 10 18:44:13 2017 -0700 drm/etnaviv: Expose our reservation object when exporting a dmabuf. commit 8555137e26618490cbeb12c243818539875d12f4 upstream. Without this, polling on the dma-buf (and presumably other devices synchronizing against our rendering) would return immediately, even while the BO was busy. Signed-off-by: Eric Anholt Cc: Lucas Stach Cc: Russell King Cc: Christian Gmeiner Cc: [email protected] Signed-off-by: Lucas Stach Signed-off-by: Greg Kroah-Hartman commit cb5634ea103cfb60994a7acd4129126b01e684bd Author: John Brooks Date: Mon Jul 3 14:05:34 2017 -0400 drm/ttm: Fix use-after-free in ttm_bo_clean_mm commit 8046e1955465e3f24e9154d0f2a2e0a8e3f8dccf upstream. We unref the man->move fence in ttm_bo_clean_mm() and then call ttm_bo_force_list_clean() which waits on it, except the refcount is now zero so a warning is generated (or worse): [149492.279301] refcount_t: increment on 0; use-after-free. [149492.279309] ------------[ cut here ]------------ [149492.279315] WARNING: CPU: 3 PID: 18726 at lib/refcount.c:150 refcount_inc+0x2b/0x30 [149492.279315] Modules linked in: vhost_net vhost tun x86_pkg_temp_thermal crc32_pclmul ghash_clmulni_intel efivarfs amdgpu( -) i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm [149492.279326] CPU: 3 PID: 18726 Comm: rmmod Not tainted 4.12.0-rc5-drm-next-4.13-ttmpatch+ #1 [149492.279326] Hardware name: Gigabyte Technology Co., Ltd. Z97X-UD3H-BK/Z97X-UD3H-BK-CF, BIOS F6 06/17/2014 [149492.279327] task: ffff8804ddfedcc0 task.stack: ffffc90008d20000 [149492.279329] RIP: 0010:refcount_inc+0x2b/0x30 [149492.279330] RSP: 0018:ffffc90008d23c30 EFLAGS: 00010286 [149492.279331] RAX: 000000000000002b RBX: 0000000000000170 RCX: 0000000000000000 [149492.279331] RDX: 0000000000000000 RSI: ffff88051ecccbe8 RDI: ffff88051ecccbe8 [149492.279332] RBP: ffffc90008d23c30 R08: 0000000000000001 R09: 00000000000003ee [149492.279333] R10: ffffc90008d23bb0 R11: 00000000000003ee R12: ffff88043aaac960 [149492.279333] R13: ffff8805005e28a8 R14: 0000000000000002 R15: ffff88050115e178 [149492.279334] FS: 00007fc540168700(0000) GS:ffff88051ecc0000(0000) knlGS:0000000000000000 [149492.279335] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [149492.279336] CR2: 00007fc3e8654140 CR3: 000000027ba77000 CR4: 00000000001426e0 [149492.279337] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [149492.279337] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [149492.279338] Call Trace: [149492.279345] ttm_bo_force_list_clean+0xb9/0x110 [ttm] [149492.279348] ttm_bo_clean_mm+0x7a/0xe0 [ttm] [149492.279375] amdgpu_ttm_fini+0xc9/0x1f0 [amdgpu] [149492.279392] amdgpu_bo_fini+0x12/0x40 [amdgpu] [149492.279415] gmc_v7_0_sw_fini+0x32/0x40 [amdgpu] [149492.279430] amdgpu_fini+0x2c9/0x490 [amdgpu] [149492.279445] amdgpu_device_fini+0x58/0x1b0 [amdgpu] [149492.279461] amdgpu_driver_unload_kms+0x4f/0xa0 [amdgpu] [149492.279470] drm_dev_unregister+0x3c/0xe0 [drm] [149492.279485] amdgpu_pci_remove+0x19/0x30 [amdgpu] [149492.279487] pci_device_remove+0x39/0xc0 [149492.279490] device_release_driver_internal+0x155/0x210 [149492.279491] driver_detach+0x38/0x70 [149492.279493] bus_remove_driver+0x4c/0xa0 [149492.279494] driver_unregister+0x2c/0x40 [149492.279496] pci_unregister_driver+0x21/0x90 [149492.279520] amdgpu_exit+0x15/0x406 [amdgpu] [149492.279523] SyS_delete_module+0x1a8/0x270 [149492.279525] ? exit_to_usermode_loop+0x92/0xa0 [149492.279528] entry_SYSCALL_64_fastpath+0x13/0x94 [149492.279529] RIP: 0033:0x7fc53fcb68e7 [149492.279529] RSP: 002b:00007ffcfbfaabb8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 [149492.279531] RAX: ffffffffffffffda RBX: 0000563117adb200 RCX: 00007fc53fcb68e7 [149492.279531] RDX: 000000000000000a RSI: 0000000000000800 RDI: 0000563117adb268 [149492.279532] RBP: 0000000000000003 R08: 0000000000000000 R09: 1999999999999999 [149492.279533] R10: 0000000000000883 R11: 0000000000000206 R12: 00007ffcfbfa9ba0 [149492.279533] R13: 0000000000000000 R14: 0000000000000000 R15: 0000563117adb200 [149492.279534] Code: 55 48 89 e5 e8 77 fe ff ff 84 c0 74 02 5d c3 80 3d 40 f2 a4 00 00 75 f5 48 c7 c7 20 3c ca 81 c6 05 30 f2 a4 00 01 e8 91 f0 d7 ff <0f> ff 5d c3 90 55 48 89 fe bf 01 00 00 00 48 89 e5 e8 9f fe ff [149492.279557] —[ end trace 2d4e0ffcb66a1016 ]— Unref the fence *after* waiting for it. v2: Set man->move to NULL after dropping the last ref (Christian König) Fixes: aff98ba1fdb8 (drm/ttm: wait for eviction in ttm_bo_force_list_clean) Signed-off-by: John Brooks Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 011a0006ae96813b38d5371caebc20c572f4491c Author: Mario Kleiner Date: Fri Jul 7 04:57:04 2017 +0200 drm/radeon: Fix eDP for single-display iMac10,1 (v2) commit 564d8a2cf3abf16575af48bdc3e86e92ee8a617d upstream. The late 2009, 27 inch Apple iMac10,1 has an internal eDP display and an external Mini- Displayport output, driven by a DCE-3.2, RV730 Radeon Mobility HD-4670. The machine worked fine in a dual-display setup with eDP panel + externally connected HDMI or DVI-D digital display sink, connected via MiniDP to DVI or HDMI adapter. However, booting the machine single-display with only eDP panel results in a completely black display - even backlight powering off, as soon as the radeon modesetting driver loads. This patch fixes the single dispay eDP case by assigning encoders based on dig->linkb, similar to DCE-4+. While this should not be generally necessary (Alex: “…atom on normal boards should be able to handle any mapping.”), Apple seems to use some special routing here. One remaining problem not solved by this patch is that an external Minidisplayport->DP sink does still not work on iMac10,1, whereas external DVI and HDMI sinks continue to work. The problem affects at least all tested kernels since Linux 3.13 - didn’t test earlier kernels, so backporting to stable probably makes sense. v2: With the original patch from 2016, Alex was worried it will break other DCE3.2 systems. Use dmi_match() to apply this special encoder assignment only for the Apple iMac 10,1 from late 2009. Signed-off-by: Mario Kleiner Cc: Alex Deucher Cc: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit b123162f81c38cf836880a873a50084e9b49789a Author: Alex Deucher Date: Thu May 11 13:14:14 2017 -0400 drm/radeon/ci: disable mclk switching for high refresh rates (v2) commit ab03d9fe508f4e2914a8f4a9eef1b21051cacd0f upstream. Even if the vblank period would allow it, it still seems to be problematic on some cards. v2: fix logic inversion (Nils) bug: https://bugs.freedesktop.org/show_bug.cgi?id=96868 Acked-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit e97b3dc369175bee085af28d756870029a4a13d8 Author: John Brooks Date: Mon Jul 3 14:05:35 2017 -0400 drm/amdgpu: Don’t call amd_powerplay_destroy() if we don’t have powerplay commit 7bc7b7777ee0e3b3d995aebaf26a462d5a23e3d7 upstream. amd_powerplay_destroy() expects a handle pointing to a struct pp_instance. On chips without PowerPlay, pp_handle points to a struct amdgpu_device. The resulting attempt to kfree() fields of the wrong struct ends in fire: [ 91.560405] BUG: unable to handle kernel paging request at ffffebe000000620 [ 91.560414] IP: kfree+0x57/0x160 [ 91.560416] PGD 0 [ 91.560416] P4D 0 [ 91.560420] Oops: 0000 [#1] SMP [ 91.560422] Modules linked in: tun x86_pkg_temp_thermal crc32_pclmul ghash_clmulni_intel efivarfs amdgpu(-) i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm [ 91.560438] CPU: 6 PID: 3598 Comm: rmmod Not tainted 4.12.0-rc5-drm-next-4.13-ttmpatch+ #1 [ 91.560443] Hardware name: Gigabyte Technology Co., Ltd. Z97X-UD3H-BK/Z97X-UD3H-BK-CF, BIOS F6 06/17/2014 [ 91.560448] task: ffff8805063d6a00 task.stack: ffffc90003400000 [ 91.560451] RIP: 0010:kfree+0x57/0x160 [ 91.560454] RSP: 0018:ffffc90003403cc0 EFLAGS: 00010286 [ 91.560457] RAX: 000077ff80000000 RBX: 00000000000186a0 RCX: 0000000180400035 [ 91.560460] RDX: 0000000180400036 RSI: ffffea001418e740 RDI: ffffea0000000000 [ 91.560463] RBP: ffffc90003403cd8 R08: 000000000639d201 R09: 0000000180400035 [ 91.560467] R10: ffffebe000000600 R11: 0000000000000300 R12: ffff880500530030 [ 91.560470] R13: ffffffffa01e70fc R14: 00000000ffffffff R15: ffff880500530000 [ 91.560473] FS: 00007f7e500c3700(0000) GS:ffff88051ed80000(0000) knlGS:0000000000000000 [ 91.560478] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 91.560480] CR2: ffffebe000000620 CR3: 0000000503103000 CR4: 00000000001406e0 [ 91.560483] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 91.560487] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 91.560489] Call Trace: [ 91.560530] amd_powerplay_destroy+0x1c/0x60 [amdgpu] [ 91.560558] amdgpu_pp_late_fini+0x44/0x60 [amdgpu] [ 91.560575] amdgpu_fini+0x254/0x490 [amdgpu] [ 91.560593] amdgpu_device_fini+0x58/0x1b0 [amdgpu] [ 91.560610] amdgpu_driver_unload_kms+0x4f/0xa0 [amdgpu] [ 91.560622] drm_dev_unregister+0x3c/0xe0 [drm] [ 91.560638] amdgpu_pci_remove+0x19/0x30 [amdgpu] [ 91.560643] pci_device_remove+0x39/0xc0 [ 91.560648] device_release_driver_internal+0x155/0x210 [ 91.560651] driver_detach+0x38/0x70 [ 91.560655] bus_remove_driver+0x4c/0xa0 [ 91.560658] driver_unregister+0x2c/0x40 [ 91.560662] pci_unregister_driver+0x21/0x90 [ 91.560689] amdgpu_exit+0x15/0x406 [amdgpu] [ 91.560694] SyS_delete_module+0x1a8/0x270 [ 91.560698] ? exit_to_usermode_loop+0x92/0xa0 [ 91.560702] entry_SYSCALL_64_fastpath+0x13/0x94 [ 91.560705] RIP: 0033:0x7f7e4fc118e7 [ 91.560708] RSP: 002b:00007fff978ca118 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 [ 91.560713] RAX: ffffffffffffffda RBX: 000055afe21bc200 RCX: 00007f7e4fc118e7 [ 91.560716] RDX: 000000000000000a RSI: 0000000000000800 RDI: 000055afe21bc268 [ 91.560719] RBP: 0000000000000003 R08: 0000000000000000 R09: 1999999999999999 [ 91.560722] R10: 0000000000000883 R11: 0000000000000206 R12: 00007fff978c9100 [ 91.560725] R13: 0000000000000000 R14: 0000000000000000 R15: 000055afe21bc200 [ 91.560728] Code: 00 00 00 80 ff 77 00 00 48 bf 00 00 00 00 00 ea ff ff 49 01 da 48 0f 42 05 57 33 bd 00 49 01 c2 49 c1 ea 0c 49 c1 e2 06 49 01 fa <49> 8b 42 20 48 8d 78 ff a8 01 4c 0f 45 d7 49 8b 52 20 48 8d 42 [ 91.560759] RIP: kfree+0x57/0x160 RSP: ffffc90003403cc0 [ 91.560761] CR2: ffffebe000000620 [ 91.560765] —[ end trace 08a9f3cd82223c1d ]— Fixes: 1c8638024846 (drm/amd/powerplay: refine powerplay interface.) Signed-off-by: John Brooks Acked-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 3738cd036503673e320d7886515ce4c68e7a1bb7 Author: Huang Rui Date: Thu Jun 29 14:21:49 2017 +0800 drm/amdgpu: fix the memory corruption on S3 commit 67bef0f7908a3a6b10e5a29d8e8c09e27f90c9f8 upstream. psp->cmd will be used on resume phase, so we can not free it on hw_init. Otherwise, a memory corruption will be triggered. Signed-off-by: Huang Rui Reviewed-by: Christian König Tested-by: Xiaojie Yuan Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 9a0b375b0b33b2631331f1e1f3e89265d2d47beb Author: Tom St Denis Date: Tue May 23 11:35:22 2017 -0400 drm/amd/amdgpu: Return error if initiating read out of range on vram commit 9156e723301c0a7a7def4cde820e018ce791b842 upstream. If you initiate a read that is out of the VRAM address space return ENXIO instead of 0. Reads that begin below that point will read upto the VRAM limit as before. Signed-off-by: Tom St Denis Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit f64c0826e5c96e649545404067a3d703f8b9089c Author: Alex Deucher Date: Fri Jun 30 09:58:34 2017 -0400 drm/amdgpu/cgs: always set reference clock in mode_info commit 73cc90798ff765341a1d9c2cfe18153ab231c9bb upstream. It’s relevent regardless of whether there are displays enabled. Fixes garbage values for ref clock in powerplay leading to incorrect fan speed reporting when displays are disabled. bug: https://bugs.freedesktop.org/show_bug.cgi?id=101653 Acked-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 2dc1889ebf8501b0edf125e89a30e1cf3744a2a7 Author: Alex Deucher Date: Thu Jun 29 16:08:49 2017 -0400 drm/amdgpu: fix vblank_time when displays are off commit beb3777682d5c296cc15a2a424f5a7a98476def0 upstream. If the displays are off, set the vblank time to max to make sure mclk switching is enabled. Avoid mclk getting set to high when no displays are attached. bug: https://bugs.freedesktop.org/show_bug.cgi?id=101528 fixes: 09be4a5219 (drm/amd/powerplay/smu7: add vblank check for mclk switching (v2)) Reviewed-by: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 4a0b18552ce3563c1f4de7abfd09a68c69208413 Author: Alex Deucher Date: Wed May 31 10:05:04 2017 -0400 drm/amdgpu/gfx8: drop per-APU CU limits commit 943c05bdb53da273c43ec44eec37c6a70409b5e9 upstream. Always use the max for the family rather than the per sku limits. This makes sure the mask is always the max size to avoid reporting the wrong number of CUs. Reviewed-by: Alex Xie Reviewed-by: Andres Rodriguez Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit eee9c161990ffddad5a79d9ab55b71a2eb90d069 Author: Jiri Olsa Date: Thu Jun 29 11:38:11 2017 +0200 s390/syscalls: Fix out of bounds arguments access commit c46fc0424ced3fb71208e72bd597d91b9169a781 upstream. Zorro reported following crash while having enabled syscall tracing (CONFIG_FTRACE_SYSCALLS): Unable to handle kernel pointer dereference at virtual … Oops: 0011 [#1] SMP DEBUG_PAGEALLOC SNIP Call Trace: ([<000000000024d79c>] ftrace_syscall_enter+0xec/0x1d8) [<00000000001099c6>] do_syscall_trace_enter+0x236/0x2f8 [<0000000000730f1c>] sysc_tracesys+0x1a/0x32 [<000003fffcf946a2>] 0x3fffcf946a2 INFO: lockdep is turned off. Last Breaking-Event-Address: [<000000000022dd44>] rb_event_data+0x34/0x40 —[ end trace 8c795f86b1b3f7b9 ]— The crash happens in syscall_get_arguments function for syscalls with zero arguments, that will try to access first argument (args[0]) in event entry, but it’s not allocated. Bail out of there are no arguments. Reported-by: Zorro Lang Signed-off-by: Jiri Olsa Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 25b43a867f56eba19c23cae8e296f8dd3b7fe951 Author: Xiao Ni Date: Wed Jul 5 17:34:04 2017 +0800 Raid5 should update rdev->sectors after reshape commit b5d27718f38843a74552e9a93d32e2391fd3999f upstream. The raid5 md device is created by the disks which we don’t use the total size. For example, the size of the device is 5G and it just uses 3G of the devices to create one raid5 device. Then change the chunksize and wait reshape to finish. After reshape finishing stop the raid and assemble it again. It fails. mdadm -CR /dev/md0 -l5 -n3 /dev/loop[0-2] --size=3G --chunk=32 --assume-clean mdadm /dev/md0 --grow --chunk=64 wait reshape to finish mdadm -S /dev/md0 mdadm -As The error messages: [197519.814302] md: loop1 does not have a valid v1.2 superblock, not importing! [197519.821686] md: md_import_device returned -22 After reshape the data offset is changed. It selects backwards direction in this condition. In function super_1_load it compares the available space of the underlying device with sb->data_size. The new data offset gets bigger after reshape. So super_1_load returns -EINVAL. rdev->sectors is updated in md_finish_reshape. Then sb->data_size is set in super_1_sync based on rdev->sectors. So add md_finish_reshape in end_reshape. Signed-off-by: Xiao Ni Acked-by: Guoqing Jiang Signed-off-by: Shaohua Li Signed-off-by: Greg Kroah-Hartman commit 47f1b42a07b1e26c2d61a0785559d0f8434110f0 Author: Heinz Mauelshagen Date: Fri Jun 30 15:45:58 2017 +0200 dm raid: stop using BUG() in __rdev_sectors() commit 4d49f1b4a1fcab16b6dd1c79ef14f2b6531d50a6 upstream. Return 0 rather than BUG() if __rdev_sectors() fails and catch invalid rdev size in the constructor. Reported-by: Hannes Reinecke Signed-off-by: Heinz Mauelshagen Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit ee31ec07eea961b01f1d6f04a95742035b6a137c Author: Jan Kara Date: Wed Jun 21 14:34:15 2017 +0200 ext2: Don’t clear SGID when inheriting ACLs commit a992f2d38e4ce17b8c7d1f7f67b2de0eebdea069 upstream. When new directory ‘DIR1’ is created in a directory ‘DIR0’ with SGID bit set, DIR1 is expected to have SGID bit set (and owning group equal to the owning group of ‘DIR0’). However when ‘DIR0’ also has some default ACLs that ‘DIR1’ inherits, setting these ACLs will result in SGID bit on ‘DIR1’ to get cleared if user is not member of the owning group. Fix the problem by creating __ext2_set_acl() function that does not call posix_acl_update_mode() and use it when inheriting ACLs. That prevents SGID bit clearing and the mode has been properly set by posix_acl_create() anyway. Fixes: 073931017b49d9458aa351605b43a7e34598caef CC: [email protected] Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 08196c1c964f5af84907092ed62d598637aef49c Author: Toshi Kani Date: Fri Jul 7 17:44:26 2017 -0600 libnvdimm: fix badblock range handling of ARS range commit 4e3f0701f25ab194c5362576b1146a1e6cc6c2e7 upstream. __add_badblock_range() does not account sector alignment when it sets 'num_sectors’. Therefore, an ARS error record range spanning across two sectors is set to a single sector length, which leaves the 2nd sector unprotected. Change __add_badblock_range() to set ‘num_sectors’ properly. Fixes: 0caeef63e6d2 (“libnvdimm: Add a poison list and export badblocks”) Signed-off-by: Toshi Kani Reviewed-by: Vishal Verma Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit e01c81e80de1f35c93e8d6ed33a5709905a791b9 Author: Vishal Verma Date: Fri Jun 30 18:32:52 2017 -0600 libnvdimm: fix the clear-error check in nsio_rw_bytes commit 7e5a21dfe5524a85705d3bc7b540c849cc13e9a1 upstream. A leftover from the ‘bandaid’ fix that disabled BTT error clearing in rw_bytes resulted in an incorrect check. After we converted these checks over to use the NVDIMM_IO_ATOMIC flag, the ndns->claim check was both redundant, and incorrect. Remove it. Fixes: 3ae3d67ba705 (“libnvdimm: add an atomic vs process context flag to rw_bytes”) Cc: Dave Jiang Cc: Dan Williams Signed-off-by: Vishal Verma Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit c32101126084eac88e0b75465cd25506765915cd Author: Vishal Verma Date: Thu Jun 29 16:59:11 2017 -0600 libnvdimm, btt: fix btt_rw_page not returning errors commit c13c43d54f2c6a3be1c675766778ac1ad8dfbfcc upstream. btt_rw_page was not propagating errors frm btt_do_bvec, resulting in any IO errors via the rw_page path going unnoticed. the pmem driver recently fixed this in e10624f pmem: fail io-requests to known bad blocks but same problem in BTT went neglected. Fixes: 5212e11fde4d (“nd_btt: atomic sector updates”) Cc: Toshi Kani Cc: Dan Williams Cc: Jeff Moyer Signed-off-by: Vishal Verma Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit e6259c4a46e4782616485a2e94dee1e48c062386 Author: Yasunori Goto Date: Thu Jun 15 14:04:16 2017 +0900 tools/testing/nvdimm: fix nfit_test buffer overflow commit a117699c6c4a4b1b4e90ed51e393590986567cb4 upstream. The root cause of panic is the num_pm of nfit_test1 is wrong. Though 1 is specified for num_pm at nfit_test_init(), it must be 2, because nfit_test1->spa_set[] array has 2 elements. Since the array is smaller than expected, the driver breaks other area. (it is often the link list of devres). As a result, panic occurs like the following example. CPU: 4 PID: 2233 Comm: lt-libndctl Tainted: G O 4.12.0-rc1+ #12 RIP: 0010:__list_del_entry_valid+0x6c/0xa0 Call Trace: release_nodes+0x76/0x260 devres_release_all+0x3c/0x50 device_release_driver_internal+0x159/0x200 device_release_driver+0x12/0x20 bus_remove_device+0xfd/0x170 device_del+0x1e8/0x330 platform_device_del+0x28/0x90 platform_device_unregister+0x12/0x30 nfit_test_exit+0x2a/0x93b [nfit_test] Signed-off-by: Yasunori Goto Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit d6226fc782f7959d8cb8642c6eb3589dbf65ad01 Author: David Härdeman Date: Thu Apr 27 17:33:58 2017 -0300 rc-core: fix input repeat handling commit b2aceb739b5af6a8abc5ea6ab9e6a0409a3b5b1d upstream. The call to input_register_device() needs to take place before the repeat parameters are set or the input subsystem repeat handling will be disabled (as was already noted in the comments in that function). Signed-off-by: David Härdeman Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 735c17ded9fb6cb37c3f92226e063cfbe754c64c Author: Devin Heitmueller Date: Sat Sep 20 09:23:44 2014 -0300 cx88: Fix regression in initial video standard setting commit 4e0973a918b9a42e217093f078e04a61e5dd95a5 upstream. Setting initial standard at the top of cx8800_initdev would cause the first call to cx88_set_tvnorm() to return without programming any registers (leaving the driver saying it’s set to NTSC but the hardware isn’t programmed). Even worse, any subsequent attempt to explicitly set it to NTSC-M will return success but actually fail to program the underlying registers unless first changing the standard to something other than NTSC-M. Set the initial standard later in the process, and make sure the field is zero at the beginning to ensure that the call always goes through. This regression was introduced in the following commit: commit ccd6f1d488e7 ("[media] cx88: move width, height and field to core struct”) Author: Hans Verkuil [media] cx88: move width, height and field to core struct Signed-off-by: Devin Heitmueller Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit dc1e0c2be5519f05b335e05d66a05ad6361ddb57 Author: Marek Marczykowski-Górecki Date: Mon Jun 26 14:49:46 2017 +0200 x86/xen: allow userspace access during hypercalls commit c54590cac51db8ab5fd30156bdaba34af915e629 upstream. Userspace application can do a hypercall through /dev/xen/privcmd, and some for some hypercalls argument is a pointers to user-provided structure. When SMAP is supported and enabled, hypervisor can’t access. So, lets allow it. The same applies to HYPERVISOR_dm_op, where additionally privcmd driver carefully verify buffer addresses. Signed-off-by: Marek Marczykowski-Górecki Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit a2bfc67530653eca8484b393d71b7042efc26e1c Author: NeilBrown Date: Mon Jun 5 16:49:39 2017 +1000 md: fix deadlock between mddev_suspend() and md_write_start() commit cc27b0c78c79680d128dbac79de0d40556d041bb upstream. If mddev_suspend() races with md_write_start() we can deadlock with mddev_suspend() waiting for the request that is currently in md_write_start() to complete the ->make_request() call, and md_write_start() waiting for the metadata to be updated to mark the array as 'dirty’. As metadata updates done by md_check_recovery() only happen then the mddev_lock() can be claimed, and as mddev_suspend() is often called with the lock held, these threads wait indefinitely for each other. We fix this by having md_write_start() abort if mddev_suspend() is happening, and ->make_request() aborts if md_write_start() aborted. md_make_request() can detect this abort, decrease the ->active_io count, and wait for mddev_suspend(). Reported-by: Nix Fix: 68866e425be2(MD: no sync IO while suspended) Signed-off-by: NeilBrown Signed-off-by: Shaohua Li Signed-off-by: Greg Kroah-Hartman commit 8d73fe66b5a640b793fdf13491b5cac12882be7e Author: Mikulas Patocka Date: Wed Jun 7 19:05:31 2017 -0400 md: don’t use flush_signals in userspace processes commit f9c79bc05a2a91f4fba8bfd653579e066714b1ec upstream. The function flush_signals clears all pending signals for the process. It may be used by kernel threads when we need to prepare a kernel thread for responding to signals. However using this function for an userspaces processes is incorrect - clearing signals without the program expecting it can cause misbehavior. The raid1 and raid5 code uses flush_signals in its request routine because it wants to prepare for an interruptible wait. This patch drops flush_signals and uses sigprocmask instead to block all signals (including SIGKILL) around the schedule() call. The signals are not lost, but the schedule() call won’t respond to them. Signed-off-by: Mikulas Patocka Acked-by: NeilBrown Signed-off-by: Shaohua Li Signed-off-by: Greg Kroah-Hartman commit b110a29f98663548bdd190653c4cdfa0f66b8f9a Author: Dmitry Torokhov Date: Tue Jul 11 10:02:18 2017 -0700 HID: multitouch: do not blindly set EV_KEY or EV_ABS bits commit 4cf56a89c696e66d10612b43b7e95852611e76c2 upstream. Now that input core insists on having dev->absinfo when device claims to generate EV_ABS in its dev->evbit, we should not be blindly setting that bit. The code in question might have been needed before input_set_abs_params() started setting EV_ABS in device’s evbit, but not anymore, and is now breaking devices such as SMART SPNL-6075 Touchscreen. Fixes: 6ecfe51b4082 (“Input: refuse to register absolute devices …”) Reported-by: Matthias Fend Tested-by: Matthias Fend Reviewed-by: Benjamin Tissoires Signed-off-by: Dmitry Torokhov Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 971443b0d31a8dd28c654696edb7c05ed8d11361 Author: Yoshihiro Shimoda Date: Wed Jul 19 16:16:55 2017 +0900 usb: renesas_usbhs: gadget: disable all eps when the driver stops commit b8b9c974afee685789fcbb191b52d1790be3608c upstream. A gadget driver will not disable eps immediately when ->disconnect() is called. But, since this driver assumes all eps stop after the ->disconnect(), unexpected behavior happens (especially in system suspend). So, this patch disables all eps in usbhsg_try_stop(). After disabling eps by renesas_usbhs driver, since some functions will be called by both a gadget and renesas_usbhs driver, renesas_usbhs driver should protect uep->pipe. To protect uep->pipe easily, this patch adds a new lock in struct usbhsg_uep. Fixes: 2f98382dc (“usb: renesas_usbhs: Add Renesas USBHS Gadget”) Signed-off-by: Yoshihiro Shimoda Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit d0cacd6618e8c56e0406d0b61fb1ed8222ca61cc Author: Yoshihiro Shimoda Date: Wed Jul 19 16:16:54 2017 +0900 usb: renesas_usbhs: fix usbhsc_resume() for !USBHSF_RUNTIME_PWCTRL commit 59a0879a0e17b2e43ecdc5e3299da85b8410d7ce upstream. This patch fixes an issue that some registers may be not initialized after resume if the USBHSF_RUNTIME_PWCTRL is not set. Otherwise, if a cable is not connected, the driver will not enable INTENB0.VBSE after resume. And then, the driver cannot detect the VBUS. Fixes: ca8a282a5373 (“usb: gadget: renesas_usbhs: add suspend/resume support”) Signed-off-by: Yoshihiro Shimoda Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit c007b2838322d83f563f3869de39492a3e29292b Author: Johan Hovold Date: Wed Jul 12 15:08:39 2017 +0200 USB: cdc-acm: add device-id for quirky printer commit fe855789d605590e57f9cd968d85ecce46f5c3fd upstream. Add device-id entry for DATECS FP-2000 fiscal printer needing the NO_UNION_NORMAL quirk. Reported-by: Anton Avramov Signed-off-by: Johan Hovold Acked-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit 2aee5d17a575bfebcc19a672a7478f14f186c6d7 Author: Colin Ian King Date: Thu Jul 6 16:06:32 2017 +0100 usb: storage: return on error to avoid a null pointer dereference commit 446230f52a5bef593554510302465eabab45a372 upstream. When us->extra is null the driver is not initialized, however, a later call to osd200_scsi_to_ata is made that dereferences us->extra, causing a null pointer dereference. The code currently detects and reports that the driver is not initialized; add a return to avoid the subsequent dereference issue in this check. Thanks to Alan Stern for pointing out that srb->result needs setting to DID_ERROR << 16 Detected by CoverityScan, CID#100308 (“Dereference after null check”) Signed-off-by: Colin Ian King Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 2f110d39a3e049f707c9d7f539b7bc997c83d2ef Author: Devin Heitmueller Date: Fri Apr 21 13:28:37 2017 -0300 mxl111sf: Fix driver to use heap allocate buffers for USB messages commit d90b336f3f652ff0441e631a06236f785581c8f7 upstream. The recent changes in 4.9 to mandate USB buffers be heap allocated broke this driver, which was allocating the buffers on the stack. This resulted in the device failing at initialization. Introduce dedicated send/receive buffers as part of the state structure, and add a mutex to protect access to them. Note: we also had to tweak the API to mxl111sf_ctrl_msg to pass the pointer to the state struct rather than the device, since we need it inside the function to access the buffers and the mutex. This patch adjusts the callers to match the API change. Signed-off-by: Devin Heitmueller Reported-by: Doug Lung Cc: Michael Ira Krufky Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 5cc9b698a494827b15f74ef70a31d7911d00e52a Author: Jiahau Chang Date: Thu Jul 20 14:48:27 2017 +0300 xhci: Bad Ethernet performance plugged in ASM1042A host commit 9da5a1092b13468839b1a864b126cacfb72ad016 upstream. When USB Ethernet is plugged in ASMEDIA ASM1042A xHCI host, bad performance was manifesting in Web browser use (like download large file such as ISO image). It is known limitation of ASM1042A that is not compatible with driver scheduling, As a workaround we can modify flow control handling of ASM1042A. The register we modify is changes the behavior [use quirk bit 28, usleep_range 40-60us, empty non-pci function -Mathias] Signed-off-by: Jiahau Chang Signed-off-by: Ian Pilcher Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 7b7a1f02338d47489dbcbb517aa152f15a50e390 Author: Mathias Nyman Date: Thu Jul 20 14:48:26 2017 +0300 xhci: Fix NULL pointer dereference when cleaning up streams for removed host commit 4b895868bb2da60a386a17cde3bf9ecbc70c79f4 upstream. This off by one in stream_id indexing caused NULL pointer dereference and soft lockup on machines with USB attached SCSI devices connected to a hotpluggable xhci controller. The code that cleans up pending URBs for dead hosts tried to dereference a stream ring at the invalid stream_id 0. ep->stream_info->stream_rings[0] doesn’t point to a ring. Start looping stream_id from 1 like in all the other places in the driver, and check that the ring exists before trying to kill URBs on it. Reported-by: rocko r Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit be67d4afbee8c71628c4220d792c09b46bd4700e Author: Mathias Nyman Date: Thu Jul 20 14:48:29 2017 +0300 xhci: fix 20000ms port resume timeout commit a54408d0a004757789863d74e29c2297edae0b4d upstream. A uncleared PLC (port link change) bit will prevent furuther port event interrupts for that port. Leaving it uncleared caused get_port_status() to timeout after 20000ms while waiting to get the final port event interrupt for resume -> U0 state change. This is a targeted fix for a specific case where we get a port resume event racing with xhci resume. The port event interrupt handler notices xHC is not yet running and bails out early, leaving PLC uncleared. The whole xhci port resuming needs more attention, but while working on it it anyways makes sense to always ensure PLC is cleared in get_port_status before setting a new link state and waiting for its completion. Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 01c5b39310da6cbd6c99e7389211b734a69de582 Author: Shu Wang Date: Thu Jul 20 14:48:31 2017 +0300 xhci: fix memleak in xhci_run() commit d6f5f071f1e13cadecf8aef1faa7e5d6fbc9f33b upstream. Found this issue by kmemleak. xhci_run() did not check return val and free command for xhci_queue_vendor_command() unreferenced object 0xffff88011c0be500 (size 64): comm “kworker/0:1", pid 58, jiffies 4294670908 (age 50.420s) hex dump (first 32 bytes): backtrace: [] kmemleak_alloc+0x4a/0xa0 [] kmem_cache_alloc_trace+0xca/0x1d0 [] xhci_alloc_command+0x44/0x130 [] xhci_run+0x4cc/0x630 [] usb_add_hcd+0x3bb/0x950 [] usb_hcd_pci_probe+0x188/0x500 [] xhci_pci_probe+0x2c/0x220 [] local_pci_probe+0x45/0xa0 [] work_for_cpu_fn+0x14/0x20 [] process_one_work+0x149/0x360 [] worker_thread+0x1d8/0x3c0 [] kthread+0x109/0x140 [] ret_from_fork+0x25/0x30 [] 0xffffffffffffffff Signed-off-by: Shu Wang Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 9c97237c71a73d98464476077e58a37f6359acb0 Author: Peter Chen Date: Thu Jul 20 14:48:30 2017 +0300 usb: xhci: fix spinlock recursion for USB2 test mode commit 576d55460e7f209139545a348746c2fcadf61bc3 upstream. Both xhci_hub_control and xhci_disable_slot tries to hold spinlock, the spinlock recursion occurs when enters USB2 test mode. Fix it by unlock spinlock before calling xhci_disable_slot. Fixes: 0f1d832ed1fb (“usb: xhci: Add port test modes support for usb2”) Signed-off-by: Peter Chen Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 07c79fd97e00a90e26554798c61f45e2db30fc5d Author: Michael Hernandez Date: Thu May 18 10:47:47 2017 -0700 PCI/MSI: Ignore affinity if pre/post vector count is more than min_vecs commit 6f9a22bc5775d231ab8fbe2c2f3c88e45e3e7c28 upstream. min_vecs is the minimum amount of vectors needed to operate in MSI-X mode which may just include the vectors that don’t need affinity. Disabling affinity settings causes the qla2xxx driver scsi_add_host() to fail when blk_mq is enabled as the blk_mq_pci_map_queues() expects affinity masks on each vector. Fixes: dfef358bd1be (“PCI/MSI: Don’t apply affinity if there aren’t enough vectors left”) Signed-off-by: Michael Hernandez Signed-off-by: Himanshu Madhani Signed-off-by: Bjorn Helgaas Reviewed-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit c1ead164ebc2795c4a6b9778e4c697be5f2297ec Author: Chen Yu Date: Thu May 25 16:49:07 2017 +0800 PCI/PM: Restore the status of PCI devices across hibernation commit e60514bd4485c0c7c5a7cf779b200ce0b95c70d6 upstream. Currently we saw a lot of “No irq handler” errors during hibernation, which caused the system hang finally: ata4.00: qc timeout (cmd 0xec) ata4.00: failed to IDENTIFY (I/O error, err_mask=0x4) ata4.00: revalidation failed (errno=-5) ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300) do_IRQ: 31.151 No irq handler for vector According to above logs, there is an interrupt triggered and it is dispatched to CPU31 with a vector number 151, but there is no handler for it, thus this IRQ will not get acked and will cause an IRQ flood which kills the system. To be more specific, the 31.151 is an interrupt from the AHCI host controller. After some investigation, the reason why this issue is triggered is because the thaw_noirq() function does not restore the MSI/MSI-X settings across hibernation. The scenario is illustrated below: 1. Before hibernation, IRQ 34 is the handler for the AHCI device, which is bound to CPU31. 2. Hibernation starts, the AHCI device is put into low power state. 3. All the nonboot CPUs are put offline, so IRQ 34 has to be migrated to the last alive one - CPU0. 4. After the snapshot has been created, all the nonboot CPUs are brought up again; IRQ 34 remains bound to CPU0. 5. AHCI devices are put into D0. 6. The snapshot is written to the disk. The issue is triggered in step 6. The AHCI interrupt should be delivered to CPU0, however it is delivered to the original CPU31 instead, which causes the “No irq handler” issue. Ying Huang has provided a clue that, in step 3 it is possible that writing to the register might not take effect as the PCI devices have been suspended. In step 3, the IRQ 34 affinity should be modified from CPU31 to CPU0, but in fact it is not. In __pci_write_msi_msg(), if the device is already in low power state, the low level MSI message entry will not be updated but cached. During the device restore process after a normal suspend/resume, pci_restore_msi_state() writes the cached MSI back to the hardware. But this is not the case for hibernation. pci_restore_msi_state() is not currently called in pci_pm_thaw_noirq(), although pci_save_state() has saved the necessary PCI cached information in pci_pm_freeze_noirq(). Restore the PCI status for the device during hibernation. Otherwise the status might be lost across hibernation (for example, settings for MSI, MSI-X, ATS, ACS, IOV, etc.), which might cause problems during hibernation. Suggested-by: Ying Huang Suggested-by: Rafael J. Wysocki Signed-off-by: Chen Yu [bhelgaas: changelog] Signed-off-by: Bjorn Helgaas Reviewed-by: Rafael J. Wysocki Cc: Len Brown Cc: Dan Williams Cc: Rui Zhang Cc: Ying Huang Signed-off-by: Greg Kroah-Hartman commit 18fc66a885ebda727239742139524146fbaefb34 Author: Shawn Lin Date: Mon Jul 3 17:21:02 2017 +0800 PCI: rockchip: Use normal register bank for config accessors commit dc8cca5ef25ac4cb0dfc37467521a759767ff361 upstream. Rockchip’s RC has two banks of registers for the root port: a normal bank that is strictly compatible with the PCIe spec, and a privileged bank that can be used to change RO bits of root port registers. When probing the RC driver, we use the privileged bank to do some basic setup work as some RO bits are hw-inited to wrong value. But we didn’t change to the normal bank after probing the driver. This leads to a serious problem when the PME code tries to clear the PME status by writing PCI_EXP_RTSTA_PME to the register of PCI_EXP_RTSTA. Per PCIe 3.0 spec, section 7.8.14, the PME status bit is RW1C. So the PME code is doing the right thing to clear the PME status but we find the RC doesn’t clear it but actually setting it to one. So finally the system trap in pcie_pme_work_fn() as PCI_EXP_RTSTA_PME is true now forever. This issue can be reproduced by booting kernel with pci=nomsi. Use the normal register bank for the PCI config accessors. The privileged bank is used only internally by this driver. Fixes: e77f847d (“PCI: rockchip: Add Rockchip PCIe controller support”) Signed-off-by: Shawn Lin Signed-off-by: Bjorn Helgaas Cc: Jeffy Chen Cc: Brian Norris Signed-off-by: Greg Kroah-Hartman commit 31f8d306b8eb38459370348b3ca2d1d9c07dbf86 Author: Bjorn Helgaas Date: Fri Aug 19 16:30:25 2016 +0800 PCI: Work around poweroff & suspend-to-RAM issue on Macbook Pro 11 commit 13cfc732160f7bc7e596128ce34cda361c556966 upstream. Neither soft poweroff (transition to ACPI power state S5) nor suspend-to-RAM (transition to state S3) works on the Macbook Pro 11,4 and 11,5. The problem is related to the [mem 0x7fa00000-0x7fbfffff] space. When we use that space, e.g., by assigning it to the 00:1c.0 Root Port, the ACPI Power Management 1 Control Register (PM1_CNT) at [io 0x1804] doesn’t work anymore. Linux does a soft poweroff (transition to S5) by writing to PM1_CNT. The theory about why this doesn’t work is: - The write to PM1_CNT causes an SMI - The BIOS SMI handler depends on something in [mem 0x7fa00000-0x7fbfffff] - When Linux assigns [mem 0x7fa00000-0x7fbfffff] to the 00:1c.0 Port, it covers up whatever the SMI handler uses, so the SMI handler no longer works correctly Reserve the [mem 0x7fa00000-0x7fbfffff] space so we don’t assign it to anything. This is voodoo programming, since we don’t know what the real conflict is, but we’ve failed to find the root cause. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=103211 Tested-by: [email protected] Signed-off-by: Bjorn Helgaas Cc: Rafael J. Wysocki Cc: Lukas Wunner Cc: Chen Yu Signed-off-by: Greg Kroah-Hartman commit 2e09bcd1732da525da98c4f419cb79a65564e637 Author: Jon Derrick Date: Thu Jun 22 09:15:42 2017 -0600 PCI: vmd: Move SRCU cleanup after bus, child device removal commit 0cb259c47a4df466d641c1f07ae3eccaa9ba3ccb upstream. Recent __call_srcu() changes have exposed that we need to cleanup SRCU structures after pci_stop_root_bus() calls into vmd_msi_free(). Fixes: 3906b91844d6 (“PCI: vmd: Use SRCU as a local RCU to prevent delaying global RCU”) Signed-off-by: Jon Derrick Signed-off-by: Bjorn Helgaas Acked-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 2614198e88934c9cc5900f4ee2a46a3865e4ea5c Author: Juergen Gross Date: Wed Jul 5 16:05:20 2017 +0200 xen/x86: fix cpu hotplug commit c185ddec54657c145a0c2055e4b87918da24974f upstream. Commit dc6416f1d711eb4c1726e845d653235dcaae12e1 (“xen/x86: Call cpu_startup_entry(CPUHP_AP_ONLINE_IDLE) from xen_play_dead()") introduced an error leading to a stack overflow of the idle task when a cpu was brought offline/online many times: by calling cpu_startup_entry() instead of returning at the end of xen_play_dead() do_idle() would be entered again and again. Don’t use cpu_startup_entry(), but cpuhp_online_idle() instead allowing to return from xen_play_dead(). Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 4fa26aab699a64f75058f422b5edf41f03eeb333 Author: Madhavan Srinivasan Date: Tue Jul 11 16:27:49 2017 +0530 powerpc/perf: Fix SDAR_MODE value for continous sampling on Power9 commit 20dd4c624d25156d5ec3345bbb690b98175ef879 upstream. In case of continous sampling (non-marked), the code currently sets MMCRA[SDAR_MODE] to 0b01 (Update on TLB miss) for Power9 DD1. On DD2 and later it copies the sdar_mode value from the event code, which for most events is 0b00 (No updates). However we must set a non-zero value for SDAR_MODE when doing continuous sampling, so honor the event code, unless it’s zero, in which case we use use 0b01 (Update on TLB miss). Fixes: 78b4416aa249 (“powerpc/perf: Handle sdar_mode for marked event in power9”) Signed-off-by: Madhavan Srinivasan Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 27444f6571cd391ea37bd543e077bdf29f35cf07 Author: Benjamin Herrenschmidt Date: Sat Jul 8 07:45:32 2017 -0500 powerpc/mm/radix: Properly clear process table entry commit c6bb0b8d426a8cf865ca9c8a532cc3a2927cfceb upstream. On radix, the process table entry we want to clear when destroying a context is entry 0, not entry 1. This has no *immediate* consequence on Power9, but it can cause other bugs to become worse. Fixes: 7e381c0ff618 (“powerpc/mm/radix: Add mmu context handling callback for radix”) Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Aneesh Kumar K.V Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit e6c8bf1df68fb70564f4ca002c1d83e9b5e57301 Author: Oliver O’Halloran Date: Thu Jul 6 18:46:43 2017 +1000 powerpc/asm: Mark cr0 as clobbered in mftb() commit 2400fd822f467cb4c886c879d8ad99feac9cf319 upstream. The workaround for the CELL timebase bug does not correctly mark cr0 as being clobbered. This means GCC doesn’t know that the asm block changes cr0 and might leave the result of an unrelated comparison in cr0 across the block, which we then trash, leading to basically random behaviour. Fixes: 859deea949c3 ("[POWERPC] Cell timebase bug workaround”) Signed-off-by: Oliver O’Halloran [mpe: Tweak change log and flag for stable] Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 0b4226798486d45e5a94cbbe81ef01a42ffc61c9 Author: Anton Blanchard Date: Thu Jun 15 09:46:39 2017 +1000 powerpc: Fix emulation of mfocrf in emulate_step() commit 64e756c55aa46fc18fd53e8f3598b73b528d8637 upstream. From POWER4 onwards, mfocrf() only places the specified CR field into the destination GPR, and the rest of it is set to 0. The PowerPC AS from version 3.0 now requires this behaviour. The emulation code currently puts the entire CR into the destination GPR. Fix it. Fixes: 6888199f7fe5 ("[POWERPC] Emulate more instructions in software”) Signed-off-by: Anton Blanchard Acked-by: Naveen N. Rao Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 9c4614c44e1dcc31599a8d983623878e9c1c9e45 Author: Anton Blanchard Date: Thu Jun 15 09:46:38 2017 +1000 powerpc: Fix emulation of mcrf in emulate_step() commit 87c4b83e0fe234a1f0eed131ab6fa232036860d5 upstream. The mcrf emulation code was using the CR field number directly as the shift value, without taking into account that CR fields are numbered from 0-7 starting at the high bits. That meant it was looking at the CR fields in the reverse order. Fixes: cf87c3f6b647 (“powerpc: Emulate icbi, mcrf and conditional-trap instructions”) Signed-off-by: Anton Blanchard Acked-by: Naveen N. Rao Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 1e605f20580759892d896cd123b6e906f3f35877 Author: Michael Ellerman Date: Tue Jul 11 22:10:54 2017 +1000 powerpc/64: Fix atomic64_inc_not_zero() to return an int commit 01e6a61aceb82e13bec29502a8eb70d9574f97ad upstream. Although it’s not documented anywhere, there is an expectation that atomic64_inc_not_zero() returns a result which fits in an int. This is the behaviour implemented on all arches except powerpc. This has caused at least one bug in practice, in the percpu-refcount code, where the long result from our atomic64_inc_not_zero() was truncated to an int leading to lost references and stuck systems. That was worked around in that code in commit 966d2b04e070 (“percpu-refcount: fix reference leak during percpu-atomic transition”). To the best of my grepping abilities there are no other callers in-tree which truncate the value, but we should fix it anyway. Because the breakage is subtle and potentially very harmful I’m also tagging it for stable. Code generation is largely unaffected because in most cases the callers are just using the result for a test anyway. In particular the case of fget() that was mentioned in commit a6cf7ed5119f (“powerpc/atomic: Implement atomic*_inc_not_zero”) generates exactly the same code. Fixes: a6cf7ed5119f (“powerpc/atomic: Implement atomic*_inc_not_zero”) Noticed-by: Linus Torvalds Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 13f46943f51e2b763a73a19722c9f57afc855f4e Author: Balbir Singh Date: Thu Jun 29 03:04:10 2017 +1000 powerpc/mm/radix: Fix execute permissions for interrupt_vectors commit 7f6d498ed3354740cfd100e4aa99e388f1a95be7 upstream. Commit 9abcc981de97 (“powerpc/mm/radix: Only add X for pages overlapping kernel text”) changed the linear mapping on Radix to only mark the kernel text executable. However if the kernel is run relocated, for example as a kdump kernel, then the exception vectors are split from the kernel text, ie. they remain at real address 0. We tend to get away with it, because the kernel itself will usually be below 1G, which means the 1G page at 0-1G is marked executable and everything works OK. However if the kernel is loaded above 1G, or the system has less than 1G in total (meaning we can’t use a 1G page), then the exception vectors will not be marked executable and the kernel will fail to boot. Fix it by also checking if the address range overlaps the exception vectors when deciding if we should add PAGE_KERNEL_X. Fixes: 9abcc981de97 (“powerpc/mm/radix: Only add X for pages overlapping kernel text”) Signed-off-by: Balbir Singh [mpe: Combine with the existing check, rewrite change log] Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit f349607b7aa58801d7b6cdc84a5ca7760d581b2c Author: Balbir Singh Date: Thu Jun 29 03:04:07 2017 +1000 powerpc/pseries: Fix passing of pp0 in updatepp() and updateboltedpp() commit e71ff982ae4c17d176e9f0132157d54973788377 upstream. Once upon a time there were only two PP (page protection) bits. In ISA 2.03 an additional PP bit was added, but because of the layout of the HPTE it could not be made contiguous with the existing PP bits. The result is that we now have three PP bits, named pp0, pp1, pp2, where pp0 occupies bit 63 of dword 1 of the HPTE and pp1 and pp2 occupy bits 1 and 0 respectively. Until recently Linux hasn’t used pp0, however with the addition of _PAGE_KERNEL_RO we started using it. The problem arises in the LPAR code, where we need to translate the PP bits into the argument for the H_PROTECT hypercall. Currently the code only passes bits 0-2 of newpp, which covers pp1, pp2 and N (no execute), meaning pp0 is not passed to the hypervisor at all. We can’t simply pass it through in bit 63, as that would collide with a different field in the flags argument, as defined in PAPR. Instead we have to shift it down to bit 8 (IBM bit 55). Fixes: e58e87adc8bf (“powerpc/mm: Update _PAGE_KERNEL_RO”) Signed-off-by: Balbir Singh [mpe: Simplify the test, rework change log] Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit cab0b22bfdc5c714c2021035db9da724c631f0b3 Author: Michael Ellerman Date: Tue Jun 6 15:48:57 2017 +1000 powerpc/mm/radix: Only add X for pages overlapping kernel text commit 9abcc981de9775659a0f6e4a52a3448ea72e59da upstream. Currently we map the whole linear mapping with PAGE_KERNEL_X. Instead we should check if the page overlaps the kernel text and only then add PAGE_KERNEL_X. Note that we still use 1G pages if they’re available, so this will typically still result in a 1G executable page at KERNELBASE. So this fix is primarily useful for catching stray branches to high linear mapping addresses. Without this patch, we can execute at 1G in xmon using: 0:mon> m c000000040000000 c000000040000000 00 l c000000040000000 00000000 01006038 c000000040000004 00000000 2000804e c000000040000008 00000000 x 0:mon> di c000000040000000 c000000040000000 38600001 li r3,1 c000000040000004 4e800020 blr 0:mon> p c000000040000000 return value is 0x1 After we get a 400 as expected: 0:mon> p c000000040000000 *** 400 exception occurred Fixes: 2bfd65e45e87 (“powerpc/mm/radix: Add radix callbacks for early init routines”) Signed-off-by: Michael Ellerman Reviewed-by: Aneesh Kumar K.V Acked-by: Balbir Singh Signed-off-by: Greg Kroah-Hartman commit db367439b12800221e0aafb0bf11180269fb1a53 Author: Paolo Bonzini Date: Wed Jul 5 10:30:56 2017 +0200 scsi: virtio_scsi: always read VPD pages for multiqueue too commit a680f1d463aeaeb00d22af257a56e111967c2f18 upstream. Multi-queue virtio-scsi uses a different scsi_host_template struct. Add the .device_alloc field there, too. Fixes: 25d1d50e23275e141e3a3fe06c25a99f4c4bf4e0 Cc: David Gibson Signed-off-by: Paolo Bonzini Reviewed-by: Fam Zheng Reviewed-by: Stefan Hajnoczi Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 26e21de7d0e22b6c8c53b60fe49127d1dac53183 Author: Bart Van Assche Date: Tue May 23 16:48:36 2017 -0700 xen/scsiback: Fix a TMR related use-after-free commit 9f4ab18ac51dc87345a9cbd2527e6acf7a0a9335 upstream. scsiback_release_cmd() must not dereference se_cmd->se_tmr_req because that memory is freed by target_free_cmd_mem() before scsiback_release_cmd() is called. Fix this use-after-free by inlining struct scsiback_tmr into struct vscsibk_pend. Signed-off-by: Bart Van Assche Reviewed-by: Juergen Gross Cc: Christoph Hellwig Cc: Hannes Reinecke Cc: David Disseldorp Cc: [email protected] Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 430c78c7a839c6b750999e197904a35fbff9c94d Author: Nicholas Bellinger Date: Fri Jul 7 14:45:49 2017 -0700 iscsi-target: Add login_keys_workaround attribute for non RFC initiators commit 138d351eefb727ab9e41a3dc5f112ceb4f6e59f2 upstream. This patch re-introduces part of a long standing login workaround that was recently dropped by: commit 1c99de981f30b3e7868b8d20ce5479fa1c0fea46 Author: Nicholas Bellinger Date: Sun Apr 2 13:36:44 2017 -0700 iscsi-target: Drop work-around for legacy GlobalSAN initiator Namely, the workaround for FirstBurstLength ended up being required by Mellanox Flexboot PXE boot ROMs as reported by Robert. So this patch re-adds the work-around for FirstBurstLength within iscsi_check_proposer_for_optional_reply(), and makes the key optional to respond when the initiator does not propose, nor respond to it. Also as requested by Arun, this patch introduces a new TPG attribute named ‘login_keys_workaround’ that controls the use of both the FirstBurstLength workaround, as well as the two other existing workarounds for gPXE iSCSI boot client. By default, the workaround is enabled with login_keys_workaround=1, since Mellanox FlexBoot requires it, and Arun has verified the Qlogic MSFT initiator already proposes FirstBurstLength, so it’s uneffected by this re-adding this part of the original work-around. Reported-by: Robert LeBlanc Cc: Robert LeBlanc Reviewed-by: Arun Easi Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit bbfbcfa3bc2f29277cf5b25c5d09228518e1d3c3 Author: Bart Van Assche Date: Fri Jun 2 14:21:52 2017 -0700 scsi: Avoid that scsi_exit_rq() triggers a use-after-free commit 8e6882545d8c06f99e9e117741cc87f3338b0bef upstream. Dereferencing shost from scsi_exit_rq() is not safe because the SCSI host may already have been freed when scsi_exit_rq() is called. Increasing the shost reference count in scsi_init_rq() and dropping that reference in scsi_exit_rq() is nontrivial since scsi_host_dev_release() may sleep and since scsi_exit_rq() may be called from interrupt context. Since scsi_exit_rq() only needs a single bit from shost, copy that bit into struct scsi_cmnd. Reported-by: Scott Bauer Fixes: e9c787e65c0c (“scsi: allocate scsi_cmnd structures as part of struct request”) Signed-off-by: Bart Van Assche Reviewed-by: Christoph Hellwig Cc: Hannes Reinecke Cc: Scott Bauer Cc: Jan Kara Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit d5ec2793a65264c06949fedbeb2582dd93b7f49d Author: Ewan D. Milne Date: Tue Jun 27 14:55:58 2017 -0400 scsi: Add STARGET_CREATED_REMOVE state to scsi_target_state commit f9279c968c257ee39b0d7bd2571a4d231a67bcc1 upstream. The addition of the STARGET_REMOVE state had the side effect of introducing a race condition that can cause a crash. scsi_target_reap_ref_release() checks the starget->state to see if it still in STARGET_CREATED, and if so, skips calling transport_remove_device() and device_del(), because the starget->state is only set to STARGET_RUNNING after scsi_target_add() has called device_add() and transport_add_device(). However, if an rport loss occurs while a target is being scanned, it can happen that scsi_remove_target() will be called while the starget is still in the STARGET_CREATED state. In this case, the starget->state will be set to STARGET_REMOVE, and as a result, scsi_target_reap_ref_release() will take the wrong path. The end result is a panic: [ 1255.356653] Oops: 0000 [#1] SMP [ 1255.360154] Modules linked in: x86_pkg_temp_thermal kvm_intel kvm irqbypass crc32c_intel ghash_clmulni_i [ 1255.393234] CPU: 5 PID: 149 Comm: kworker/u96:4 Tainted: G W 4.11.0+ #8 [ 1255.401879] Hardware name: Dell Inc. PowerEdge R320/08VT7V, BIOS 2.0.22 11/19/2013 [ 1255.410327] Workqueue: scsi_wq_6 fc_scsi_scan_rport [scsi_transport_fc] [ 1255.417720] task: ffff88060ca8c8c0 task.stack: ffffc900048a8000 [ 1255.424331] RIP: 0010:kernfs_find_ns+0x13/0xc0 [ 1255.429287] RSP: 0018:ffffc900048abbf0 EFLAGS: 00010246 [ 1255.435123] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 1255.443083] RDX: 0000000000000000 RSI: ffffffff8188d659 RDI: 0000000000000000 [ 1255.451043] RBP: ffffc900048abc10 R08: 0000000000000000 R09: 0000012433fe0025 [ 1255.459005] R10: 0000000025e5a4b5 R11: 0000000025e5a4b5 R12: ffffffff8188d659 [ 1255.466972] R13: 0000000000000000 R14: ffff8805f55e5088 R15: 0000000000000000 [ 1255.474931] FS: 0000000000000000(0000) GS:ffff880616b40000(0000) knlGS:0000000000000000 [ 1255.483959] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1255.490370] CR2: 0000000000000068 CR3: 0000000001c09000 CR4: 00000000000406e0 [ 1255.498332] Call Trace: [ 1255.501058] kernfs_find_and_get_ns+0x31/0x60 [ 1255.505916] sysfs_unmerge_group+0x1d/0x60 [ 1255.510498] dpm_sysfs_remove+0x22/0x60 [ 1255.514783] device_del+0xf4/0x2e0 [ 1255.518577] ? device_remove_file+0x19/0x20 [ 1255.523241] attribute_container_class_device_del+0x1a/0x20 [ 1255.529457] transport_remove_classdev+0x4e/0x60 [ 1255.534607] ? transport_add_class_device+0x40/0x40 [ 1255.540046] attribute_container_device_trigger+0xb0/0xc0 [ 1255.546069] transport_remove_device+0x15/0x20 [ 1255.551025] scsi_target_reap_ref_release+0x25/0x40 [ 1255.556467] scsi_target_reap+0x2e/0x40 [ 1255.560744] __scsi_scan_target+0xaa/0x5b0 [ 1255.565312] scsi_scan_target+0xec/0x100 [ 1255.569689] fc_scsi_scan_rport+0xb1/0xc0 [scsi_transport_fc] [ 1255.576099] process_one_work+0x14b/0x390 [ 1255.580569] worker_thread+0x4b/0x390 [ 1255.584651] kthread+0x109/0x140 [ 1255.588251] ? rescuer_thread+0x330/0x330 [ 1255.592730] ? kthread_park+0x60/0x60 [ 1255.596815] ret_from_fork+0x29/0x40 [ 1255.600801] Code: 24 08 48 83 42 40 01 5b 41 5c 5d c3 66 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 [ 1255.621876] RIP: kernfs_find_ns+0x13/0xc0 RSP: ffffc900048abbf0 [ 1255.628479] CR2: 0000000000000068 [ 1255.632756] —[ end trace 34a69ba0477d036f ]— Fix this by adding another scsi_target state STARGET_CREATED_REMOVE to distinguish this case. Fixes: f05795d3d771 (“scsi: Add intermediate STARGET_REMOVE state to scsi_target_state”) Reported-by: David Jeffery Signed-off-by: Ewan D. Milne Reviewed-by: Laurence Oberman Tested-by: Laurence Oberman Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 1dfabed337ad9a44642e2f836701dc9f57afe4c5 Author: Quinn Tran Date: Fri Jun 2 09:11:53 2017 -0700 scsi: qla2xxx: Allow ABTS, PURX, RIDA on ATIOQ for ISP83XX/27XX commit 3c4810ffdc8e4f34d387f59baf0abefcfa4ada6a upstream. Driver added mechanism to move ABTS/PUREX/RIDA mailbox to ATIO queue as part of commit id 41dc529a4602ac737020f423f84686a81de38e6d (“qla2xxx: Improve RSCN handling in driver”). This patch adds a check to only allow ABTS/PURX/RIDA to be moved to ATIO Queue for ISP83XX and ISP27XX. Signed-off-by: Quinn Tran Signed-off-by: Himanshu Madhani Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 2ced4c4ce3c8801663b9fbd1fa64ce88bb9e94fe Author: Paolo Bonzini Date: Wed Jun 21 16:35:46 2017 +0200 scsi: virtio_scsi: let host do exception handling commit e72c9a2a67a6400c8ef3d01d4c461dbbbfa0e1f0 upstream. virtio_scsi tries to do exception handling after the default 30 seconds timeout expires. However, it’s better to let the host control the timeout, otherwise with a heavy I/O load it is likely that an abort will also timeout. This leads to fatal errors like filesystems going offline. Disable the ‘sd’ timeout and allow the host to do exception handling, following the precedent of the storvsc driver. Hannes has a proposal to introduce timeouts in virtio, but this provides an immediate solution for stable kernels too. [mkp: fixed typo] Reported-by: Douglas Miller Cc: “James E.J. Bottomley” Cc: “Martin K. Petersen” Cc: Hannes Reinecke Cc: [email protected] Signed-off-by: Paolo Bonzini Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit ad8e43cfadd2de6c065eabef2069b83f13e1a4e2 Author: Maurizio Lombardi Date: Tue Jun 27 11:53:27 2017 +0200 scsi: ses: do not add a device to an enclosure if enclosure_add_links() fails. commit 62e62ffd95539b9220894a7900a619e0f3ef4756 upstream. The enclosure_add_device() function should fail if it can’t create the relevant sysfs links. Signed-off-by: Maurizio Lombardi Tested-by: Douglas Miller Acked-by: James Bottomley Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit adc0157721d07473e1455c669d20fd615373631f Author: Krzysztof Kozlowski Date: Wed Jun 28 16:56:20 2017 +0200 PM / Domains: Fix unsafe iteration over modified list of domains commit a7e2d1bce4c1db471f1cbc0c4666a3112bbf0994 upstream. of_genpd_remove_last() iterates over list of domains and removes matching element thus it has to use safe version of list iteration. Fixes: 17926551c98a (PM / Domains: Add support for removing nested PM domains by provider) Signed-off-by: Krzysztof Kozlowski Acked-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 01ee0ee75933c106bc8772491fb9d287439e9b5f Author: Krzysztof Kozlowski Date: Wed Jun 28 16:56:19 2017 +0200 PM / Domains: Fix unsafe iteration over modified list of domain providers commit b556b15dc04e9b9b98790f04c21acf5e24f994b2 upstream. of_genpd_del_provider() iterates over list of domain provides and removes matching element thus it has to use safe version of list iteration. Fixes: aa42240ab254 (PM / Domains: Add generic OF-based PM domain look-up) Signed-off-by: Krzysztof Kozlowski Acked-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 61461312f0b0eb4e71915efd4c852baa7aa2b4b1 Author: Krzysztof Kozlowski Date: Wed Jun 28 16:56:18 2017 +0200 PM / Domains: Fix unsafe iteration over modified list of device links commit c6e83cac3eda5f7dd32ee1453df2f7abb5c6cd46 upstream. pm_genpd_remove_subdomain() iterates over domain’s master_links list and removes matching element thus it has to use safe version of list iteration. Fixes: f721889ff65a ("PM / Domains: Support for generic I/O PM domains (v8)") Signed-off-by: Krzysztof Kozlowski Acked-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 5a18ee01953f7185974bb21cac31c424d4fa350d Author: Peter Rosin Date: Wed May 31 14:32:33 2017 +0200 ASoC: atmel: tse850: fix off-by-one in the “ANA” enumeration count commit a00cebf51d5ceed8ba9f6fac5fb189b38cd5a7c2 upstream. At some point I added the “Low” entry at the beginning of the array without bumping the enumeration count from 9 to 10. Fix this. While at it, fix the anti-pattern for the other enumeration (used by MUX{1,2}). Fixes: aa43112445f0 (“ASoC: atmel: tse850: add ASoC driver for the Axentia TSE-850”) Signed-off-by: Peter Rosin Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 8024384eeb078a79d22494413a4652272bac7ea3 Author: Satish Babu Patakokila Date: Fri Jun 16 17:33:40 2017 -0700 ASoC: compress: Derive substream from stream based on direction commit 01b8cedfd0422326caae308641dcadaa85e0ca72 upstream. Currently compress driver hardcodes direction as playback to get substream from the stream. This results in getting the incorrect substream for compressed capture usecase. To fix this, remove the hardcoding and derive substream based on the stream direction. Signed-off-by: Satish Babu Patakokila Signed-off-by: Banajit Goswami Acked-By: Vinod Koul Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 1f3fb26751321b592e5d800316e7598e7c4d9d96 Author: Shawn Guo Date: Sat Jun 17 22:25:28 2017 +0800 ASoC: zx-i2s: flip I2S master/slave mode commit a205c159f9e2db586a5ea475f4d22fa22e78fed8 upstream. The SND_SOC_DAIFMT_MASTER bits are defined to specify the master/slave mode for Codec, not I2S. So the I2S master/slave mode should be flipped according to SND_SOC_DAIFMT_MASTER bits. Signed-off-by: Shawn Guo Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 2e74a4f521f9f8df7d3ab4be0806dab25084c20d Author: Cyrille Pitchen Date: Fri Jun 23 17:39:16 2017 +0200 spi: atmel: fix corrupted data issue on SAM9 family SoCs commit 7094576ccdc3acfe1e06a1e2ab547add375baf7f upstream. This patch disables the use of the DMA for data transfer and forces the use of PIO transfers instead as a quick fixup to solve the cache aliasing issue on ARM9 based cores, which embeds a VIVT data cache. Indeed in the case of VIVT data caches, it is not safe to call dma_map_*() functions to map buffers for DMA transfers when those buffers have been allocated by vmalloc() or from any DMA-unsafe area. Further patches may propose a better solution based on the use of a bounce buffer at the SPI sub-system level but such solution needs more time to be discussed. Then the use of DMA transfers could be enabled again to improve the performances but before that, this patch already solves the issue. Signed-off-by: Cyrille Pitchen Acked-by: Nicolas Ferre Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 9317c1d0abe51f5d11ef295b2f94fc91268b56e5 Author: Matwey V Kornilov Date: Thu Nov 24 13:32:48 2016 +0300 igb: Explicitly select page 0 at initialization commit 440aeca4b9858248d8f16d724d9fa87a4f65fa33 upstream. The functions igb_read_phy_reg_gs40g/igb_write_phy_reg_gs40g (which were removed in 2a3cdea) explicitly selected the required page at every phy_reg access. Currently, igb_get_phy_id_82575 relays on the fact that page 0 is already selected. The assumption is not fulfilled for my Lex 3I380CW motherboard with integrated dual i211 based gigabit ethernet. This leads to igb initialization failure and network interfaces are not working: igb: Intel® Gigabit Ethernet Network Driver - version 5.4.0-k igb: Copyright © 2007-2014 Intel Corporation. igb: probe of 0000:01:00.0 failed with error -2 igb: probe of 0000:02:00.0 failed with error -2 In order to fix it, we explicitly select page 0 before first access to phy registers. See also: https://bugzilla.suse.com/show_bug.cgi?id=1009911 See also: http://www.lex.com.tw/products/pdf/3I380A&3I380CW.pdf Fixes: 2a3cdea (“igb: Remove GS40G specific defines/functions”) Signed-off-by: Matwey V Kornilov Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman commit 114571a8a2bca1b418dab9b0391c42de521ed753 Author: Filipe Manana Date: Thu Jul 6 15:31:46 2017 +0100 Btrfs: incremental send, fix invalid memory access commit 24e52b11e0ca788513b945a87b57cc0522a92933 upstream. When doing an incremental send, while processing an extent that changed between the parent and send snapshots and that extent was an inline extent in the parent snapshot, it’s possible to access a memory region beyond the end of leaf if the inline extent is very small and it is the first item in a leaf. An example scenario is described below. The send snapshot has the following leaf: leaf 33865728 items 33 free space 773 generation 46 owner 5 fs uuid ab7090d8-dafd-4fb9-9246-723b6d2e2fb7 chunk uuid 2d16478c-c704-4ab9-b574-68bff2281b1f (…) item 14 key (335 EXTENT_DATA 0) itemoff 3052 itemsize 53 generation 36 type 1 (regular) extent data disk byte 12791808 nr 4096 extent data offset 0 nr 4096 ram 4096 extent compression 0 (none) item 15 key (335 EXTENT_DATA 8192) itemoff 2999 itemsize 53 generation 36 type 1 (regular) extent data disk byte 138170368 nr 225280 extent data offset 0 nr 225280 ram 225280 extent compression 0 (none) (…) And the parent snapshot has the following leaf: leaf 31272960 items 17 free space 17 generation 31 owner 5 fs uuid ab7090d8-dafd-4fb9-9246-723b6d2e2fb7 chunk uuid 2d16478c-c704-4ab9-b574-68bff2281b1f item 0 key (335 EXTENT_DATA 0) itemoff 3951 itemsize 44 generation 31 type 0 (inline) inline extent data size 23 ram_bytes 613 compression 1 (zlib) (…) When computing the send stream, it is detected that the extent of inode 335, at file offset 0, and at fs/btrfs/send.c:is_extent_unchanged() we grab the leaf from the parent snapshot and access the inline extent item. However, before jumping to the ‘out’ label, we access the ‘offset’ and ‘disk_bytenr’ fields of the extent item, which should not be done for inline extents since the inlined data starts at the offset of the ‘disk_bytenr’ field and can be very small. For example accessing the ‘offset’ field of the file extent item results in the following trace: [ 599.705368] general protection fault: 0000 [#1] PREEMPT SMP [ 599.706296] Modules linked in: btrfs psmouse i2c_piix4 ppdev acpi_cpufreq serio_raw parport_pc i2c_core evdev tpm_tis tpm_tis_core sg pcspkr parport tpm button su$ [ 599.709340] CPU: 7 PID: 5283 Comm: btrfs Not tainted 4.10.0-rc8-btrfs-next-46+ #1 [ 599.709340] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org 04/01/2014 [ 599.709340] task: ffff88023eedd040 task.stack: ffffc90006658000 [ 599.709340] RIP: 0010:read_extent_buffer+0xdb/0xf4 [btrfs] [ 599.709340] RSP: 0018:ffffc9000665ba00 EFLAGS: 00010286 [ 599.709340] RAX: db73880000000000 RBX: 0000000000000000 RCX: 0000000000000001 [ 599.709340] RDX: ffffc9000665ba60 RSI: db73880000000000 RDI: ffffc9000665ba5f [ 599.709340] RBP: ffffc9000665ba30 R08: 0000000000000001 R09: ffff88020dc5e098 [ 599.709340] R10: 0000000000001000 R11: 0000160000000000 R12: 6db6db6db6db6db7 [ 599.709340] R13: ffff880000000000 R14: 0000000000000000 R15: ffff88020dc5e088 [ 599.709340] FS: 00007f519555a8c0(0000) GS:ffff88023f3c0000(0000) knlGS:0000000000000000 [ 599.709340] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 599.709340] CR2: 00007f1411afd000 CR3: 0000000235f8e000 CR4: 00000000000006e0 [ 599.709340] Call Trace: [ 599.709340] btrfs_get_token_64+0x93/0xce [btrfs] [ 599.709340] ? printk+0x48/0x50 [ 599.709340] btrfs_get_64+0xb/0xd [btrfs] [ 599.709340] process_extent+0x3a1/0x1106 [btrfs] [ 599.709340] ? btree_read_extent_buffer_pages+0x5/0xef [btrfs] [ 599.709340] changed_cb+0xb03/0xb3d [btrfs] [ 599.709340] ? btrfs_get_token_32+0x7a/0xcc [btrfs] [ 599.709340] btrfs_compare_trees+0x432/0x53d [btrfs] [ 599.709340] ? process_extent+0x1106/0x1106 [btrfs] [ 599.709340] btrfs_ioctl_send+0x960/0xe26 [btrfs] [ 599.709340] btrfs_ioctl+0x181b/0x1fed [btrfs] [ 599.709340] ? trace_hardirqs_on_caller+0x150/0x1ac [ 599.709340] vfs_ioctl+0x21/0x38 [ 599.709340] ? vfs_ioctl+0x21/0x38 [ 599.709340] do_vfs_ioctl+0x611/0x645 [ 599.709340] ? rcu_read_unlock+0x5b/0x5d [ 599.709340] ? __fget+0x6d/0x79 [ 599.709340] SyS_ioctl+0x57/0x7b [ 599.709340] entry_SYSCALL_64_fastpath+0x18/0xad [ 599.709340] RIP: 0033:0x7f51945eec47 [ 599.709340] RSP: 002b:00007ffc21c13e98 EFLAGS: 00000202 ORIG_RAX: 0000000000000010 [ 599.709340] RAX: ffffffffffffffda RBX: ffffffff81096459 RCX: 00007f51945eec47 [ 599.709340] RDX: 00007ffc21c13f20 RSI: 0000000040489426 RDI: 0000000000000004 [ 599.709340] RBP: ffffc9000665bf98 R08: 00007f519450d700 R09: 00007f519450d700 [ 599.709340] R10: 00007f519450d9d0 R11: 0000000000000202 R12: 0000000000000046 [ 599.709340] R13: ffffc9000665bf78 R14: 0000000000000000 R15: 00007f5195574040 [ 599.709340] ? trace_hardirqs_off_caller+0x43/0xb1 [ 599.709340] Code: 29 f0 49 39 d8 4c 0f 47 c3 49 03 81 58 01 00 00 44 89 c1 4c 01 c2 4c 29 c3 48 c1 f8 03 49 0f af c4 48 c1 e0 0c 4c 01 e8 48 01 c6 a4 31 f6 4$ [ 599.709340] RIP: read_extent_buffer+0xdb/0xf4 [btrfs] RSP: ffffc9000665ba00 [ 599.762057] —[ end trace fe00d7af61b9f49e ]— This is because the ‘offset’ field starts at an offset of 37 bytes (offsetof(struct btrfs_file_extent_item, offset)), has a length of 8 bytes and therefore attemping to read it causes a 1 byte access beyond the end of the leaf, as the first item’s content in a leaf is located at the tail of the leaf, the item size is 44 bytes and the offset of that field plus its length (37 + 8 = 45) goes beyond the item’s size by 1 byte. So fix this by accessing the ‘offset’ and ‘disk_bytenr’ fields after jumping to the ‘out’ label if we are processing an inline extent. We move the reading operation of the ‘disk_bytenr’ field too because we have the same problem as for the ‘offset’ field explained above when the inline data is less then 8 bytes. The access to the ‘generation’ field is also moved but just for the sake of grouping access to all the fields. Fixes: e1cbfd7bf6da (“Btrfs: send, fix file hole not being preserved due to inline extent”) Signed-off-by: Filipe Manana Signed-off-by: Greg Kroah-Hartman commit 88b4b8154872fb13d320b92bc985debe55ffbb3f Author: Jan Kara Date: Thu Jun 22 15:31:07 2017 +0200 btrfs: Don’t clear SGID when inheriting ACLs commit b7f8a09f8097db776b8d160862540e4fc1f51296 upstream. When new directory ‘DIR1’ is created in a directory ‘DIR0’ with SGID bit set, DIR1 is expected to have SGID bit set (and owning group equal to the owning group of ‘DIR0’). However when ‘DIR0’ also has some default ACLs that ‘DIR1’ inherits, setting these ACLs will result in SGID bit on ‘DIR1’ to get cleared if user is not member of the owning group. Fix the problem by moving posix_acl_update_mode() out of __btrfs_set_acl() into btrfs_set_acl(). That way the function will not be called when inheriting ACLs which is what we want as it prevents SGID bit clearing and the mode has been properly set by posix_acl_create() anyway. Fixes: 073931017b49d9458aa351605b43a7e34598caef CC: [email protected] CC: David Sterba Signed-off-by: Jan Kara Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit dad8a6e14678601ea7d013ca3d745a42f75c4458 Author: Filipe Manana Date: Tue May 30 05:29:09 2017 +0100 Btrfs: fix invalid extent maps due to hole punching commit 609805d809733d0c669f21f710bdac308cc63cba upstream. While punching a hole in a range that is not aligned with the sector size (currently the same as the page size) we can end up leaving an extent map in memory with a length that is smaller then the sector size or with a start offset that is not aligned to the sector size. Both cases are not expected and can lead to problems. This issue is easily detected after the patch from commit a7e3b975a0f9 (“Btrfs: fix reported number of inode blocks”), introduced in kernel 4.12-rc1, in a scenario like the following for example: $ mkfs.btrfs -f /dev/sdb $ mount /dev/sdb /mnt $ xfs_io -c “pwrite -S 0xaa -b 100K 0 100K” /mnt/foo $ xfs_io -c “fpunch 60K 90K” /mnt/foo $ xfs_io -c “pwrite -S 0xbb -b 100K 50K 100K” /mnt/foo $ xfs_io -c “pwrite -S 0xcc -b 50K 100K 50K” /mnt/foo $ umount /mnt After the unmount operation we can see several warnings emmitted due to underflows related to space reservation counters: [ 2837.443299] ------------[ cut here ]------------ [ 2837.447395] WARNING: CPU: 8 PID: 2474 at fs/btrfs/inode.c:9444 btrfs_destroy_inode+0xe8/0x27e [btrfs] [ 2837.452108] Modules linked in: dm_flakey dm_mod ppdev parport_pc psmouse parport sg pcspkr acpi_cpufreq tpm_tis tpm_tis_core i2c_piix4 i2c_core evdev tpm button se rio_raw sunrpc loop autofs4 ext4 crc16 jbd2 mbcache btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_gene ric raid1 raid0 multipath linear md_mod sr_mod cdrom sd_mod ata_generic virtio_scsi ata_piix libata virtio_pci virtio_ring virtio e1000 scsi_mod floppy [ 2837.458389] CPU: 8 PID: 2474 Comm: umount Tainted: G W 4.10.0-rc8-btrfs-next-43+ #1 [ 2837.459754] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org 04/01/2014 [ 2837.462379] Call Trace: [ 2837.462379] dump_stack+0x68/0x92 [ 2837.462379] __warn+0xc2/0xdd [ 2837.462379] warn_slowpath_null+0x1d/0x1f [ 2837.462379] btrfs_destroy_inode+0xe8/0x27e [btrfs] [ 2837.462379] destroy_inode+0x3d/0x55 [ 2837.462379] evict+0x177/0x17e [ 2837.462379] dispose_list+0x50/0x71 [ 2837.462379] evict_inodes+0x132/0x141 [ 2837.462379] generic_shutdown_super+0x3f/0xeb [ 2837.462379] kill_anon_super+0x12/0x1c [ 2837.462379] btrfs_kill_super+0x16/0x21 [btrfs] [ 2837.462379] deactivate_locked_super+0x30/0x68 [ 2837.462379] deactivate_super+0x36/0x39 [ 2837.462379] cleanup_mnt+0x58/0x76 [ 2837.462379] __cleanup_mnt+0x12/0x14 [ 2837.462379] task_work_run+0x77/0x9b [ 2837.462379] prepare_exit_to_usermode+0x9d/0xc5 [ 2837.462379] syscall_return_slowpath+0x196/0x1b9 [ 2837.462379] entry_SYSCALL_64_fastpath+0xab/0xad [ 2837.462379] RIP: 0033:0x7f3ef3e6b9a7 [ 2837.462379] RSP: 002b:00007ffdd0d8de58 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 [ 2837.462379] RAX: 0000000000000000 RBX: 0000556f76a39060 RCX: 00007f3ef3e6b9a7 [ 2837.462379] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000556f76a3f910 [ 2837.462379] RBP: 0000556f76a3f910 R08: 0000556f76a3e670 R09: 0000000000000015 [ 2837.462379] R10: 00000000000006b4 R11: 0000000000000246 R12: 00007f3ef436ce64 [ 2837.462379] R13: 0000000000000000 R14: 0000556f76a39240 R15: 00007ffdd0d8e0e0 [ 2837.519355] —[ end trace e79345fe24b30b8d ]— [ 2837.596256] ------------[ cut here ]------------ [ 2837.597625] WARNING: CPU: 8 PID: 2474 at fs/btrfs/extent-tree.c:5699 btrfs_free_block_groups+0x246/0x3eb [btrfs] [ 2837.603547] Modules linked in: dm_flakey dm_mod ppdev parport_pc psmouse parport sg pcspkr acpi_cpufreq tpm_tis tpm_tis_core i2c_piix4 i2c_core evdev tpm button serio_raw sunrpc loop autofs4 ext4 crc16 jbd2 mbcache btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod sr_mod cdrom sd_mod ata_generic virtio_scsi ata_piix libata virtio_pci virtio_ring virtio e1000 scsi_mod floppy [ 2837.659372] CPU: 8 PID: 2474 Comm: umount Tainted: G W 4.10.0-rc8-btrfs-next-43+ #1 [ 2837.663359] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org 04/01/2014 [ 2837.663359] Call Trace: [ 2837.663359] dump_stack+0x68/0x92 [ 2837.663359] __warn+0xc2/0xdd [ 2837.663359] warn_slowpath_null+0x1d/0x1f [ 2837.663359] btrfs_free_block_groups+0x246/0x3eb [btrfs] [ 2837.663359] close_ctree+0x1dd/0x2e1 [btrfs] [ 2837.663359] ? evict_inodes+0x132/0x141 [ 2837.663359] btrfs_put_super+0x15/0x17 [btrfs] [ 2837.663359] generic_shutdown_super+0x6a/0xeb [ 2837.663359] kill_anon_super+0x12/0x1c [ 2837.663359] btrfs_kill_super+0x16/0x21 [btrfs] [ 2837.663359] deactivate_locked_super+0x30/0x68 [ 2837.663359] deactivate_super+0x36/0x39 [ 2837.663359] cleanup_mnt+0x58/0x76 [ 2837.663359] __cleanup_mnt+0x12/0x14 [ 2837.663359] task_work_run+0x77/0x9b [ 2837.663359] prepare_exit_to_usermode+0x9d/0xc5 [ 2837.663359] syscall_return_slowpath+0x196/0x1b9 [ 2837.663359] entry_SYSCALL_64_fastpath+0xab/0xad [ 2837.663359] RIP: 0033:0x7f3ef3e6b9a7 [ 2837.663359] RSP: 002b:00007ffdd0d8de58 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 [ 2837.663359] RAX: 0000000000000000 RBX: 0000556f76a39060 RCX: 00007f3ef3e6b9a7 [ 2837.663359] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000556f76a3f910 [ 2837.663359] RBP: 0000556f76a3f910 R08: 0000556f76a3e670 R09: 0000000000000015 [ 2837.663359] R10: 00000000000006b4 R11: 0000000000000246 R12: 00007f3ef436ce64 [ 2837.663359] R13: 0000000000000000 R14: 0000556f76a39240 R15: 00007ffdd0d8e0e0 [ 2837.739445] —[ end trace e79345fe24b30b8e ]— [ 2837.745595] ------------[ cut here ]------------ [ 2837.746412] WARNING: CPU: 8 PID: 2474 at fs/btrfs/extent-tree.c:5700 btrfs_free_block_groups+0x261/0x3eb [btrfs] [ 2837.747955] Modules linked in: dm_flakey dm_mod ppdev parport_pc psmouse parport sg pcspkr acpi_cpufreq tpm_tis tpm_tis_core i2c_piix4 i2c_core evdev tpm button serio_raw sunrpc loop autofs4 ext4 crc16 jbd2 mbcache btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod sr_mod cdrom sd_mod ata_generic virtio_scsi ata_piix libata virtio_pci virtio_ring virtio e1000 scsi_mod floppy [ 2837.755395] CPU: 8 PID: 2474 Comm: umount Tainted: G W 4.10.0-rc8-btrfs-next-43+ #1 [ 2837.756769] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org 04/01/2014 [ 2837.758526] Call Trace: [ 2837.758925] dump_stack+0x68/0x92 [ 2837.759383] __warn+0xc2/0xdd [ 2837.759383] warn_slowpath_null+0x1d/0x1f [ 2837.759383] btrfs_free_block_groups+0x261/0x3eb [btrfs] [ 2837.759383] close_ctree+0x1dd/0x2e1 [btrfs] [ 2837.759383] ? evict_inodes+0x132/0x141 [ 2837.759383] btrfs_put_super+0x15/0x17 [btrfs] [ 2837.759383] generic_shutdown_super+0x6a/0xeb [ 2837.759383] kill_anon_super+0x12/0x1c [ 2837.759383] btrfs_kill_super+0x16/0x21 [btrfs] [ 2837.759383] deactivate_locked_super+0x30/0x68 [ 2837.759383] deactivate_super+0x36/0x39 [ 2837.759383] cleanup_mnt+0x58/0x76 [ 2837.759383] __cleanup_mnt+0x12/0x14 [ 2837.759383] task_work_run+0x77/0x9b [ 2837.759383] prepare_exit_to_usermode+0x9d/0xc5 [ 2837.759383] syscall_return_slowpath+0x196/0x1b9 [ 2837.759383] entry_SYSCALL_64_fastpath+0xab/0xad [ 2837.759383] RIP: 0033:0x7f3ef3e6b9a7 [ 2837.759383] RSP: 002b:00007ffdd0d8de58 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 [ 2837.759383] RAX: 0000000000000000 RBX: 0000556f76a39060 RCX: 00007f3ef3e6b9a7 [ 2837.759383] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000556f76a3f910 [ 2837.759383] RBP: 0000556f76a3f910 R08: 0000556f76a3e670 R09: 0000000000000015 [ 2837.759383] R10: 00000000000006b4 R11: 0000000000000246 R12: 00007f3ef436ce64 [ 2837.759383] R13: 0000000000000000 R14: 0000556f76a39240 R15: 00007ffdd0d8e0e0 [ 2837.777063] —[ end trace e79345fe24b30b8f ]— [ 2837.778235] ------------[ cut here ]------------ [ 2837.778856] WARNING: CPU: 8 PID: 2474 at fs/btrfs/extent-tree.c:9825 btrfs_free_block_groups+0x348/0x3eb [btrfs] [ 2837.791385] Modules linked in: dm_flakey dm_mod ppdev parport_pc psmouse parport sg pcspkr acpi_cpufreq tpm_tis tpm_tis_core i2c_piix4 i2c_core evdev tpm button serio_raw sunrpc loop autofs4 ext4 crc16 jbd2 mbcache btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod sr_mod cdrom sd_mod ata_generic virtio_scsi ata_piix libata virtio_pci virtio_ring virtio e1000 scsi_mod floppy [ 2837.797711] CPU: 8 PID: 2474 Comm: umount Tainted: G W 4.10.0-rc8-btrfs-next-43+ #1 [ 2837.798594] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org 04/01/2014 [ 2837.800118] Call Trace: [ 2837.800515] dump_stack+0x68/0x92 [ 2837.801015] __warn+0xc2/0xdd [ 2837.801471] warn_slowpath_null+0x1d/0x1f [ 2837.801698] btrfs_free_block_groups+0x348/0x3eb [btrfs] [ 2837.801698] close_ctree+0x1dd/0x2e1 [btrfs] [ 2837.801698] ? evict_inodes+0x132/0x141 [ 2837.801698] btrfs_put_super+0x15/0x17 [btrfs] [ 2837.801698] generic_shutdown_super+0x6a/0xeb [ 2837.801698] kill_anon_super+0x12/0x1c [ 2837.801698] btrfs_kill_super+0x16/0x21 [btrfs] [ 2837.801698] deactivate_locked_super+0x30/0x68 [ 2837.801698] deactivate_super+0x36/0x39 [ 2837.801698] cleanup_mnt+0x58/0x76 [ 2837.801698] __cleanup_mnt+0x12/0x14 [ 2837.801698] task_work_run+0x77/0x9b [ 2837.801698] prepare_exit_to_usermode+0x9d/0xc5 [ 2837.801698] syscall_return_slowpath+0x196/0x1b9 [ 2837.801698] entry_SYSCALL_64_fastpath+0xab/0xad [ 2837.801698] RIP: 0033:0x7f3ef3e6b9a7 [ 2837.801698] RSP: 002b:00007ffdd0d8de58 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 [ 2837.801698] RAX: 0000000000000000 RBX: 0000556f76a39060 RCX: 00007f3ef3e6b9a7 [ 2837.801698] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000556f76a3f910 [ 2837.801698] RBP: 0000556f76a3f910 R08: 0000556f76a3e670 R09: 0000000000000015 [ 2837.801698] R10: 00000000000006b4 R11: 0000000000000246 R12: 00007f3ef436ce64 [ 2837.801698] R13: 0000000000000000 R14: 0000556f76a39240 R15: 00007ffdd0d8e0e0 [ 2837.818441] —[ end trace e79345fe24b30b90 ]— [ 2837.818991] BTRFS info (device sdc): space_info 1 has 7974912 free, is not full [ 2837.819830] BTRFS info (device sdc): space_info total=8388608, used=417792, pinned=0, reserved=0, may_use=18446744073709547520, readonly=0 What happens in the above example is the following: 1) When punching the hole, at btrfs_punch_hole(), the variable tail_len is set to 2048 (as tail_start is 148Kb + 1 and offset + len is 150Kb). This results in the creation of an extent map with a length of 2Kb starting at file offset 148Kb, through find_first_non_hole() -> btrfs_get_extent(). 2) The second write (first write after the hole punch operation), sets the range [50Kb, 152Kb[ to delalloc. 3) The third write, at btrfs_find_new_delalloc_bytes(), sees the extent map covering the range [148Kb, 150Kb[ and ends up calling set_extent_bit() for the same range, which results in splitting an existing extent state record, covering the range [148Kb, 152Kb[ into two 2Kb extent state records, covering the ranges [148Kb, 150Kb[ and [150Kb, 152Kb[. 4) Finally at lock_and_cleanup_extent_if_need(), immediately after calling btrfs_find_new_delalloc_bytes() we clear the delalloc bit from the range [100Kb, 152Kb[ which results in the btrfs_clear_bit_hook() callback being invoked against the two 2Kb extent state records that cover the ranges [148Kb, 150Kb[ and [150Kb, 152Kb[. When called against the first 2Kb extent state, it calls btrfs_delalloc_release_metadata() with a length argument of 2048 bytes. That function rounds up the length to a sector size aligned length, so it ends up considering a length of 4096 bytes, and then calls calc_csum_metadata_size() which results in decrementing the inode’s csum_bytes counter by 4096 bytes, so after it stays a value of 0 bytes. Then the same happens when btrfs_clear_bit_hook() is called against the second extent state that has a length of 2Kb, covering the range [150Kb, 152Kb[, the length is rounded up to 4096 and calc_csum_metadata_size() ends up being called to decrement 4096 bytes from the inode’s csum_bytes counter, which at that time has a value of 0, leading to an underflow, which is exactly what triggers the first warning, at btrfs_destroy_inode(). All the other warnings relate to several space accounting counters that underflow as well due to similar reasons. A similar case but where the hole punching operation creates an extent map with a start offset not aligned to the sector size is the following: $ mkfs.btrfs -f /dev/sdb $ mount /dev/sdb /mnt $ xfs_io -f -c “fpunch 695K 820K” $SCRATCH_MNT/bar $ xfs_io -c “pwrite -S 0xaa 1008K 307K” $SCRATCH_MNT/bar $ xfs_io -c “pwrite -S 0xbb -b 630K 1073K 630K” $SCRATCH_MNT/bar $ xfs_io -c “pwrite -S 0xcc -b 459K 1068K 459K” $SCRATCH_MNT/bar $ umount /mnt During the unmount operation we get similar traces for the same reasons as in the first example. So fix the hole punching operation to make sure it never creates extent maps with a length that is not aligned to the sector size nor with a start offset that is not aligned to the sector size, as this breaks all assumptions and it’s a land mine. Fixes: d77815461f04 (“btrfs: Avoid trucating page or punching hole in a already existed hole.”) Signed-off-by: Filipe Manana Reviewed-by: Liu Bo Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit a88266ef19946afec0a7323d23df5acf821c85fd Author: Brian Norris Date: Fri May 12 09:41:58 2017 -0700 mwifiex: fixup error cases in mwifiex_add_virtual_intf() commit 8535107aa4ef92520cbb9a4739563b389c5f8e2c upstream. If we fail to add an interface in mwifiex_add_virtual_intf(), we might hit a BUG_ON() in the networking code, because we didn’t tear things down properly. Among the problems: (a) when failing to allocate workqueues, we fail to unregister the netdev before calling free_netdev() (b) even if we do try to unregister the netdev, we’re still holding the rtnl lock, so the device never properly unregistered; we’ll be at state NETREG_UNREGISTERING, and then hit free_netdev()'s: BUG_ON(dev->reg_state != NETREG_UNREGISTERED); © we’re allocating some dependent resources (e.g., DFS workqueues) after we’ve registered the interface; this may or may not cause problems, but it’s good practice to allocate these before registering (d) we’re not even trying to unwind anything when mwifiex_send_cmd() or mwifiex_sta_init_cmd() fail To fix these issues, let’s: * add a stacked set of error handling labels, to keep error handling consistent and properly ordered (resolving (a) and (d)) * move the workqueue allocations before the registration (to resolve ©; also resolves (b) by avoiding error cases where we have to unregister) [Incidentally, it’s pretty easy to interrupt the alloc_workqueue() in, e.g., the following: iw phy phy0 interface add mlan0 type station by sending it SIGTERM.] This bugfix covers commits like commit 7d652034d1a0 (“mwifiex: channel switch support for mwifiex”), but parts of this bug exist all the way back to the introduction of dynamic interface handling in commit 93a1df48d224 (“mwifiex: add cfg80211 handlers add/del_virtual_intf”). Signed-off-by: Brian Norris Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit ad000510c3b53fa5259aa2260dcb75aac9f56414 Author: Ankit Kumar Date: Tue May 23 11:16:52 2017 +0530 pstore: Don’t warn if data is uncompressed and type is not PSTORE_TYPE_DMESG commit 4a16d1cb245c56e72fd40a28f3cdb394cde4b341 upstream. commit 9abdcccc3d5f (“pstore: Extract common arguments into structure”) moved record decompression to function. decompress_record() gets called without checking type and compressed flag. Warning will be reported if data is uncompressed. Pstore type PSTORE_TYPE_PPC_OPAL, PSTORE_TYPE_PPC_COMMON doesn’t contain compressed data and warning get printed part of dmesg. Partial dmesg log: [ 35.848914] pstore: ignored compressed record type 6 [ 35.848927] pstore: ignored compressed record type 8 Above warning should not get printed as it is known that data won’t be compressed for above type and it is valid condition. This patch returns if data is not compressed and print warning only if data is compressed and type is not PSTORE_TYPE_DMESG. Reported-by: Anton Blanchard Signed-off-by: Ankit Kumar Reviewed-by: Mahesh Salgaonkar Signed-off-by: Kees Cook Fixes: 9abdcccc3d5f (“pstore: Extract common arguments into structure”) Signed-off-by: Greg Kroah-Hartman commit 1566e0592c90b141f0e0f881d0103331ec558650 Author: Arnd Bergmann Date: Thu May 11 13:52:09 2017 +0200 wlcore: fix 64K page support commit 4a4274bf2dbbd1c7a45be0c89a1687c9d2eef4a0 upstream. In the stable linux-3.16 branch, I ran into a warning in the wlcore driver: drivers/net/wireless/ti/wlcore/spi.c: In function 'wl12xx_spi_raw_write’: drivers/net/wireless/ti/wlcore/spi.c:315:1: error: the frame size of 12848 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] Newer kernels no longer show the warning, but the bug is still there, as the allocation is based on the CPU page size rather than the actual capabilities of the hardware. This replaces the PAGE_SIZE macro with the SZ_4K macro, i.e. 4096 bytes per buffer. Signed-off-by: Arnd Bergmann Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit b53b679317b3e5882aee682932f60cabe75e3d2e Author: Jason A. Donenfeld Date: Sat Jun 10 04:59:11 2017 +0200 Bluetooth: use constant time memory comparison for secret values commit 329d82309824ff1082dc4a91a5bbed8c3bec1580 upstream. This file is filled with complex cryptography. Thus, the comparisons of MACs and secret keys and curve points and so forth should not add timing attacks, which could either result in a direct forgery, or, given the complexity, some other type of attack. Signed-off-by: Jason A. Donenfeld Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 3f30aa79a3caf3a4364dbbf6da72c2a3c5d3bbaf Author: Adrian Hunter Date: Fri May 26 11:17:09 2017 +0300 perf intel-pt: Clear FUP flag on error commit 6a558f12dbe85437acbdec5e149ea07b5554eced upstream. Sometimes a FUP packet is associated with a TSX transaction and a flag is set to indicate that. Ensure that flag is cleared on any error condition because at that point the decoder can no longer assume it is correct. Signed-off-by: Adrian Hunter Cc: Andi Kleen Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit ea6c25496e94967c41798996f8e3c667df11d0cb Author: Adrian Hunter Date: Fri May 26 11:17:08 2017 +0300 perf intel-pt: Use FUP always when scanning for an IP commit 622b7a47b843c78626f40c1d1aeef8483383fba2 upstream. The decoder will try to use branch packets to find an IP to start decoding or to recover from errors. Currently the FUP packet is used only in the case of an overflow, however there is no reason for that to be a special case. So just use FUP always when scanning for an IP. Signed-off-by: Adrian Hunter Cc: Andi Kleen Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit c68f8e30d7be490fabfcb9c4201af0ef1691b1fa Author: Adrian Hunter Date: Fri May 26 11:17:07 2017 +0300 perf intel-pt: Ensure never to set ‘last_ip’ when packet ‘count’ is zero commit f952eaceb089b691eba7c4e13686e742a8f26bf5 upstream. Intel PT uses IP compression based on the last IP. For decoding purposes, ‘last IP’ is not updated when a branch target has been suppressed, which is indicated by IPBytes == 0. IPBytes is stored in the packet 'count’, so ensure never to set ‘last_ip’ when packet ‘count’ is zero. Signed-off-by: Adrian Hunter Cc: Andi Kleen Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit d7cccb4b6cffd31c6fce4c980776ff94a6c0bd47 Author: Adrian Hunter Date: Fri May 26 11:17:06 2017 +0300 perf intel-pt: Fix last_ip usage commit ee14ac0ef6827cd6f9a572cc83dd0191ea17812c upstream. Intel PT uses IP compression based on the last IP. For decoding purposes, ‘last IP’ is considered to be reset to zero whenever there is a synchronization packet (PSB). The decoder wasn’t doing that, and was treating the zero value to mean that there was no last IP, whereas compression can be done against the zero value. Fix by setting last_ip to zero when a PSB is received and keep track of have_last_ip. Signed-off-by: Adrian Hunter Cc: Andi Kleen Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit c93c534c8c1d0fbb1f7e1d858b7f9d301a935da4 Author: Adrian Hunter Date: Fri May 26 11:17:05 2017 +0300 perf intel-pt: Ensure IP is zero when state is INTEL_PT_STATE_NO_IP commit ad7167a8cd174ba7d8c0d0ed8d8410521206d104 upstream. A value of zero is used to indicate that there is no IP. Ensure the value is zero when the state is INTEL_PT_STATE_NO_IP. Signed-off-by: Adrian Hunter Cc: Andi Kleen Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 14f2cad1e0a0afe0e62df84bf5c6aa73eded60d7 Author: Adrian Hunter Date: Fri May 26 11:17:04 2017 +0300 perf intel-pt: Fix missing stack clear commit 12b7080609097753fd8198cc1daf589be3ec1cca upstream. The return compression stack must be cleared whenever there is a PSB. Fix one case where that was not happening. Signed-off-by: Adrian Hunter Cc: Andi Kleen Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 309721dd36c2e7a6b734a14fff924aa011e1f60c Author: Adrian Hunter Date: Fri May 26 11:17:03 2017 +0300 perf intel-pt: Improve sample timestamp commit 3f04d98e972b59706bd43d6cc75efac91f8fba50 upstream. The decoder uses its current timestamp in samples. Usually that is a timestamp that has already passed, but in some cases it is a timestamp for a branch that the decoder is walking towards, and consequently hasn’t reached. Improve that situation by using the pkt_state to determine when to use the current or previous timestamp. Signed-off-by: Adrian Hunter Cc: Andi Kleen Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 84c366c6ddae7d55efa20ae526a19b29c68e8aac Author: Adrian Hunter Date: Fri May 26 11:17:02 2017 +0300 perf intel-pt: Move decoder error setting into one condition commit 22c06892332d8916115525145b78e606e9cc6492 upstream. Move decoder error setting into one condition. Cc’ed to stable because later fixes depend on it. Signed-off-by: Adrian Hunter Cc: Andi Kleen Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit c9270e3728345481b21136731ebd37794b276102 Author: Mateusz Jurczyk Date: Tue Jun 13 18:44:28 2017 +0200 NFC: Add sockaddr length checks before accessing sa_family in bind handlers commit f6a5885fc4d68e7f25ffb42b9d8d80aebb3bacbb upstream. Verify that the caller-provided sockaddr structure is large enough to contain the sa_family field, before accessing it in bind() handlers of the AF_NFC socket. Since the syscall doesn’t enforce a minimum size of the corresponding memory region, very short sockaddrs (zero or one byte long) result in operating on uninitialized memory while referencing .sa_family. Signed-off-by: Mateusz Jurczyk Signed-off-by: Samuel Ortiz Signed-off-by: Greg Kroah-Hartman commit e66553a5900b9759fb3574033d3a05ec2ccf98a0 Author: Mateusz Jurczyk Date: Wed May 24 12:26:20 2017 +0200 nfc: Fix the sockaddr length sanitization in llcp_sock_connect commit 608c4adfcabab220142ee335a2a003ccd1c0b25b upstream. Fix the sockaddr length verification in the connect() handler of NFC/LLCP sockets, to compare against the size of the actual structure expected on input (sockaddr_nfc_llcp) instead of its shorter version (sockaddr_nfc). Both structures are defined in include/uapi/linux/nfc.h. The fields specific to the _llcp extended struct are as follows: 276 __u8 dsap; /* Destination SAP, if known */ 277 __u8 ssap; /* Source SAP to be bound to */ 278 char service_name[NFC_LLCP_MAX_SERVICE_NAME]; /* Service name URI */; 279 size_t service_name_len; If the caller doesn’t provide a sufficiently long sockaddr buffer, these fields remain uninitialized (and they currently originate from the stack frame of the top-level sys_connect handler). They are then copied by llcp_sock_connect() into internal storage (nfc_llcp_sock structure), and could be subsequently read back through the user-mode getsockname() function (handled by llcp_sock_getname()). This would result in the disclosure of up to ~70 uninitialized bytes from the kernel stack to user-mode clients capable of creating AFC_NFC sockets. Signed-off-by: Mateusz Jurczyk Acked-by: Kees Cook Signed-off-by: Samuel Ortiz Signed-off-by: Greg Kroah-Hartman commit b6a39af459ca47e69f9de1241538e515450c4725 Author: Mateusz Jurczyk Date: Wed May 24 12:42:26 2017 +0200 nfc: Ensure presence of required attributes in the activate_target handler commit a0323b979f81ad2deb2c8836eab506534891876a upstream. Check that the NFC_ATTR_TARGET_INDEX and NFC_ATTR_PROTOCOLS attributes (in addition to NFC_ATTR_DEVICE_INDEX) are provided by the netlink client prior to accessing them. This prevents potential unhandled NULL pointer dereference exceptions which can be triggered by malicious user-mode programs, if they omit one or both of these attributes. Signed-off-by: Mateusz Jurczyk Acked-by: Kees Cook Signed-off-by: Samuel Ortiz Signed-off-by: Greg Kroah-Hartman commit 36a8a4e98c2258d8834084c836fb50f0aed0fcfe Author: Johan Hovold Date: Thu Mar 30 12:15:39 2017 +0200 NFC: nfcmrvl: fix firmware-management initialisation commit 45dd39b974f6632222dd5cdcbea7358a077ab0b0 upstream. The nci-device was never deregistered in the event that fw-initialisation failed. Fix this by moving the firmware initialisation before device registration since the firmware work queue should be available before registering. Note that this depends on a recent fix that moved device-name initialisation back to to nci_allocate_device() as the firmware-workqueue name is now derived from the nfc-device name. Fixes: 3194c6870158 (“NFC: nfcmrvl: add firmware download support”) Cc: Vincent Cuissard Signed-off-by: Johan Hovold Signed-off-by: Samuel Ortiz Signed-off-by: Greg Kroah-Hartman commit 7b69ecce4d9f8dc7f3d1478956266a88754ea9f1 Author: Johan Hovold Date: Thu Mar 30 12:15:38 2017 +0200 NFC: nfcmrvl: use nfc-device for firmware download commit e5834ac22948169bbd7c45996d8d4905edd20f5e upstream. Use the nfc- rather than phy-device in firmware-management code that needs a valid struct device. This specifically fixes a NULL-pointer dereference in nfcmrvl_fw_dnld_init() during registration when the underlying tty is one end of a Unix98 pty. Note that the driver still uses the phy device for any debugging, which is fine for now. Fixes: 3194c6870158 (“NFC: nfcmrvl: add firmware download support”) Cc: Vincent Cuissard Signed-off-by: Johan Hovold Signed-off-by: Samuel Ortiz Signed-off-by: Greg Kroah-Hartman commit 6cb06562945e47a4d538c3d509268994bbb88339 Author: Johan Hovold Date: Thu Mar 30 12:15:37 2017 +0200 NFC: nfcmrvl: do not use device-managed resources commit 0cbe40112f42cf5e008f9127f6cd5952ba3946c7 upstream. This specifically fixes resource leaks in the registration error paths. Device-managed resources is a bad fit for this driver as devices can be registered from the n_nci line discipline. Firstly, a tty may not even have a corresponding device (should it be part of a Unix98 pty) something which would lead to a NULL-pointer dereference when registering resources. Secondly, if the tty has a class device, its lifetime exceeds that of the line discipline, which means that resources would leak every time the line discipline is closed (or if registration fails). Currently, the devres interface was only being used to request a reset gpio despite the fact that it was already explicitly freed in nfcmrvl_nci_unregister_dev() (along with the private data), something which also prevented the resource leak at close. Note that the driver treats gpio number 0 as invalid despite it being perfectly valid. This will be addressed in a follow-up patch. Fixes: b2fe288eac72 (“NFC: nfcmrvl: free reset gpio”) Fixes: 4a2b947f56b3 (“NFC: nfcmrvl: add chip reset management”) Cc: Vincent Cuissard Signed-off-by: Johan Hovold Signed-off-by: Samuel Ortiz Signed-off-by: Greg Kroah-Hartman commit 5d714615ca9ac166208832229b14f46f3f515e59 Author: Johan Hovold Date: Thu Mar 30 12:15:36 2017 +0200 NFC: nfcmrvl_uart: add missing tty-device sanity check commit 15e0c59f1535926a939d1df66d6edcf997d7c1b9 upstream. Make sure to check the tty-device pointer before trying to access the parent device to avoid dereferencing a NULL-pointer when the tty is one end of a Unix98 pty. Fixes: e097dc624f78 (“NFC: nfcmrvl: add UART driver”) Cc: Vincent Cuissard Signed-off-by: Johan Hovold Signed-off-by: Samuel Ortiz Signed-off-by: Greg Kroah-Hartman commit 3e540b655c0335f917b7bde408acb9459ada2285 Author: Johan Hovold Date: Thu Mar 30 12:15:35 2017 +0200 NFC: fix broken device allocation commit 20777bc57c346b6994f465e0d8261a7fbf213a09 upstream. Commit 7eda8b8e9677 (“NFC: Use IDR library to assing NFC devices IDs”) moved device-id allocation and struct-device initialisation from nfc_allocate_device() to nfc_register_device(). This broke just about every nfc-device-registration error path, which continue to call nfc_free_device() that tries to put the device reference of the now uninitialised (but zeroed) struct device: kobject: '(null)' (ce316420): is not initialized, yet kobject_put() is being called. The late struct-device initialisation also meant that various work queues whose names are derived from the nfc device name were also misnamed: 421 root 0 SW< [(null)_nci_cmd_] 422 root 0 SW< [(null)_nci_rx_w] 423 root 0 SW< [(null)_nci_tx_w] Move the id-allocation and struct-device initialisation back to nfc_allocate_device() and fix up the single call site which did not use nfc_free_device() in its error path. Fixes: 7eda8b8e9677 (“NFC: Use IDR library to assing NFC devices IDs”) Cc: Samuel Ortiz Signed-off-by: Johan Hovold Signed-off-by: Samuel Ortiz Signed-off-by: Greg Kroah-Hartman commit bf3d383a38bd10de3202a3de6363d0bd355200ca Author: Emmanuel Grumbach Date: Fri May 5 08:51:24 2017 +0300 iwlwifi: mvm: fix the recovery flow while connecting commit 6b28f9784c394f0692e160f81b07c82cb64af160 upstream. In BSS mode in the disconnection flow, mac80211 removes the AP station before the vif is set to unassociated. Our firmware wants it the other way around: first set the vif as unassociated, and then remove the AP station. In order to bridge between those two different behaviors, iwlmvm doesn’t remove the station from the firmware when mac80211 removes it, but only after the vif is set to unassociated. The implementation is in iwl_mvm_bss_info_changed_station: if (assoc state was modified && mvmvif->ap_sta_id is VALID && assoc state is now UNASSC) remove_the_station_from_the_firmware() During the recovery flow, mac80211 re-adds the AP station and then reconfigures the vif. Since the vif is not associated, and then, we enter the if above (which was intended to be taken in the disconnection flow only) and remove the station we just added. This defeats the recovery flow. Fix this by not removing the AP station in this flow if we are in recovery flow. Signed-off-by: Emmanuel Grumbach Signed-off-by: Luca Coelho Signed-off-by: Greg Kroah-Hartman commit a1b6a2c3592b7a4d2a12b31fc5c4c38706a3f8f9 Author: Miaoqing Pan Date: Tue Jun 27 17:31:53 2017 +0300 ath9k: fix an invalid pointer dereference in ath9k_rng_stop() commit 07246c115801c27652700e3679bb58661ef7ed65 upstream. The bug was triggered when do suspend/resuming continuously on Dell XPS L322X/0PJHXN version 9333 (2013) with kernel 4.12.0-041200rc4-generic. But can’t reproduce on DELL E5440 + AR9300 PCIE chips. The warning is caused by accessing invalid pointer sc->rng_task. sc->rng_task is not be cleared after kthread_stop(sc->rng_task) be called in ath9k_rng_stop(). Because the kthread is stopped before ath9k_rng_kthread() be scheduled. So set sc->rng_task to null after kthread_stop(sc->rng_task) to resolve this issue. WARNING: CPU: 0 PID: 984 at linux/kernel/kthread.c:71 kthread_stop+0xf1/0x100 CPU: 0 PID: 984 Comm: NetworkManager Not tainted 4.12.0-041200rc4-generic #201706042031 Hardware name: Dell Inc. Dell System XPS L322X/0PJHXN, BIOS A09 05/15/2013 task: ffff950170fdda00 task.stack: ffffa22c01538000 RIP: 0010:kthread_stop+0xf1/0x100 RSP: 0018:ffffa22c0153b5b0 EFLAGS: 00010246 RAX: ffffffffa6257800 RBX: ffff950171b79560 RCX: 0000000000000000 RDX: 0000000080000000 RSI: 000000007fffffff RDI: ffff9500ac9a9680 RBP: ffffa22c0153b5c8 R08: 0000000000000000 R09: 0000000000000000 R10: ffffa22c0153b648 R11: ffff9501768004b8 R12: ffff9500ac9a9680 R13: ffff950171b79f70 R14: ffff950171b78780 R15: ffff9501749dc018 FS: 00007f0d6bfd5540(0000) GS:ffff95017f200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc190161a08 CR3: 0000000232906000 CR4: 00000000001406f0 Call Trace: ath9k_rng_stop+0x1a/0x20 [ath9k] ath9k_stop+0x3b/0x1d0 [ath9k] drv_stop+0x33/0xf0 [mac80211] ieee80211_stop_device+0x43/0x50 [mac80211] ieee80211_do_stop+0x4f2/0x810 [mac80211] Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=196043 Reported-by: Giulio Genovese Tested-by: Giulio Genovese Signed-off-by: Miaoqing Pan Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit e9fe79bcf1a7f0121fc97b0ac0c80b7878117521 Author: Miaoqing Pan Date: Tue Jun 27 17:31:51 2017 +0300 ath9k: fix tx99 bus error commit bde717ab473668377fc65872398a102d40cb2d58 upstream. The hard coded register 0x9864 and 0x9924 are invalid for ar9300 chips. Signed-off-by: Miaoqing Pan Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 33c147af30973b25d04014342e42292bd31f0996 Author: Miaoqing Pan Date: Tue Jun 27 17:31:49 2017 +0300 ath9k: fix tx99 use after free commit cf8ce1ea61b75712a154c93e40f2a5af2e4dd997 upstream. One scenario that could lead to UAF is two threads writing simultaneously to the “tx99” debug file. One of them would set the “start” value to true and follow to ath9k_tx99_init(). Inside the function it would set the sc->tx99_state to true after allocating sc->tx99skb. Then, the other thread would execute write_file_tx99() and call ath9k_tx99_deinit(). sc->tx99_state would be freed. After that, the first thread would continue inside ath9k_tx99_init() and call r = ath9k_tx99_send(sc, sc->tx99_skb, &txctl); that would make use of the freed sc->tx99_skb memory. Signed-off-by: Miaoqing Pan Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit b0c642732004c5255e716fc6b15343a9a670e7e5 Author: Viresh Kumar Date: Tue Apr 25 15:57:08 2017 +0530 thermal: cpu_cooling: Avoid accessing potentially freed structures commit 289d72afddf83440117c35d864bf0c6309c1d011 upstream. After the lock is dropped, it is possible that the cpufreq_dev gets freed before we call get_level() and that can cause kernel to crash. Drop the lock after we are done using the structure. Fixes: 02373d7c69b4 (“thermal: cpu_cooling: fix lockdep problems in cpu_cooling”) Signed-off-by: Viresh Kumar Reviewed-by: Lukasz Luba Tested-by: Lukasz Luba Signed-off-by: Eduardo Valentin Signed-off-by: Greg Kroah-Hartman commit b0bc1293bbc03fa7f60b82c3fbdde99375957f6a Author: Johan Hovold Date: Tue Jun 6 17:59:03 2017 +0200 thermal: max77620: fix device-node reference imbalance commit c592fafbdbb6b1279b76a54722d1465ca77e5bde upstream. The thermal child device reuses the parent MFD-device device-tree node when registering a thermal zone, but did not take a reference to the node. This leads to a reference imbalance, and potential use-after-free, when the node reference is dropped by the platform-bus device destructor (once for the child and later again for the parent). Fix this by dropping any reference already held to a device-tree node and getting a reference to the parent’s node which will be balanced on reprobe or on platform-device release, whichever comes first. Note that simply clearing the of_node pointer on probe errors and on driver unbind would not allow the use of device-managed resources as specifically thermal_zone_of_sensor_unregister() claims that a valid device-tree node pointer is needed during deregistration (even if it currently does not seem to use it). Fixes: ec4664b3fd6d (“thermal: max77620: Add thermal driver for reporting junction temp”) Cc: Laxman Dewangan Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 7c6846307cae4cfe1adc3e6b6b7b7794d6616887 Author: Mauro Carvalho Chehab Date: Thu May 18 10:40:00 2017 -0300 s5p-jpeg: don’t return a random width/height commit a16e37726c444cbda91e73ed5f742e717bfe866f upstream. Gcc 7.1 complains about: drivers/media/platform/s5p-jpeg/jpeg-core.c: In function 's5p_jpeg_parse_hdr.isra.9’: drivers/media/platform/s5p-jpeg/jpeg-core.c:1207:12: warning: ‘width’ may be used uninitialized in this function [-Wmaybe-uninitialized] result->w = width; ~~~~~~~~~~^~~~~~~ drivers/media/platform/s5p-jpeg/jpeg-core.c:1208:12: warning: ‘height’ may be used uninitialized in this function [-Wmaybe-uninitialized] result->h = height; ~~~~~~~~~~^~~~~~~~ Indeed the code would allow it to return a random value (although it shouldn’t happen, in practice). So, explicitly set both to zero, just in case. Acked-by: Andrzej Pietrasiewicz Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 0f2de24938d76900a10a6e9b633661792a5509ad Author: Arnd Bergmann Date: Thu May 11 08:46:44 2017 -0300 ir-core: fix gcc-7 warning on bool arithmetic commit bd7e31bbade02bc1e92aa00d5cf2cee2da66838a upstream. gcc-7 suggests that an expression using a bitwise not and a bitmask on a ‘bool’ variable is better written using boolean logic: drivers/media/rc/imon.c: In function 'imon_incoming_scancode’: drivers/media/rc/imon.c:1725:22: error: ‘~’ on a boolean expression [-Werror=bool-operation] ictx->pad_mouse = ~(ictx->pad_mouse) & 0x1; ^ drivers/media/rc/imon.c:1725:22: note: did you mean to use logical not? I agree. Fixes: 21677cfc562a (“V4L/DVB: ir-core: add imon driver”) Signed-off-by: Arnd Bergmann Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit e346433d5ac9f6a484ff40085c4fb5a636703f77 Author: Linus Torvalds Date: Wed Jul 12 19:25:47 2017 -0700 disable new gcc-7.1.1 warnings for now commit bd664f6b3e376a8ef4990f87d08271cc2d01ba9a upstream. I made the mistake of upgrading my desktop to the new Fedora 26 that comes with gcc-7.1.1. There’s nothing wrong per se that I’ve noticed, but I now have 1500 lines of warnings, mostly from the new format-truncation warning triggering all over the tree. We use 'snprintf()' and friends in a lot of places, and often know that the numbers are fairly small (ie a controller index or similar), but gcc doesn’t know that, and sees an 'int’, and thinks that it could be some huge number. And then complains when our buffers are not able to fit the name for the ten millionth controller. These warnings aren’t necessarily bad per se, and we probably want to look through them subsystem by subsystem, but at least during the merge window they just mean that I can’t even see if somebody is introducing any *real* problems when I pull. So warnings disabled for now. Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman