- 10 Dec, 2017 40 commits
-
-
Kees Cook authored
[ Upstream commit 564c9cc8 ] Using .text.unlikely for refcount exceptions isn't safe because gcc may move entire functions into .text.unlikely (e.g. in6_dev_dev()), which would cause any uses of a protected refcount_t function to stay inline with the function, triggering the protection unconditionally: .section .text.unlikely,"ax",@progbits .type in6_dev_get, @function in6_dev_getx: .LFB4673: .loc 2 4128 0 .cfi_startproc ... lock; incl 480(%rbx) js 111f .pushsection .text.unlikely 111: lea 480(%rbx), %rcx 112: .byte 0x0f, 0xff .popsection 113: This creates a unique .text..refcount section and adds an additional test to the exception handler to WARN in the case of having none of OF, SF, nor ZF set so we can see things like this more easily in the future. The double dot for the section name keeps it out of the TEXT_MAIN macro namespace, to avoid collisions and so it can be put at the end with text.unlikely to keep the cold code together. See commit: cb87481e ("kbuild: linker script do not match C names unless LD_DEAD_CODE_DATA_ELIMINATION is configured") ... which matches C names: [a-zA-Z0-9_] but not ".". Reported-by:
Mike Galbraith <efault@gmx.de> Signed-off-by:
Kees Cook <keescook@chromium.org> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Elena <elena.reshetova@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-arch <linux-arch@vger.kernel.org> Fixes: 7a46ec0e ("locking/refcounts, x86/asm: Implement fast refcount overflow protection") Link: http://lkml.kernel.org/r/1504382986-49301-2-git-send-email-keescook@chromium.orgSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
Sasha Levin <alexander.levin@verizon.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Masami Hiramatsu authored
[ Upstream commit 5bb4fc2d ] Disable preemption in ftrace-based jprobe handlers as described in Documentation/kprobes.txt: "Probe handlers are run with preemption disabled." This will fix jprobes behavior when CONFIG_PREEMPT=y. Signed-off-by:
Masami Hiramatsu <mhiramat@kernel.org> Cc: Alexei Starovoitov <ast@fb.com> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Paul E . McKenney <paulmck@linux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/150581530024.32348.9863783558598926771.stgit@devboxSigned-off-by:
-
Thomas Richter authored
[ Upstream commit 3440fe27 ] Commit d78ada4a ("perf tests attr: Do not store failed events") does not create an event file in the /tmp directory when the perf_open_event() system call failed. This can lead to a situation where not /tmp/event-xx-yy-zz result file exists at all (for example on a s390x virtual machine environment) where no CPUMF hardware is available. The following command then fails with a python call back chain instead of printing failure: [root@s8360046 perf]# /usr/bin/python2 ./tests/attr.py -d ./tests/attr/ \ -p ./perf -v -ttest-stat-basic running './tests/attr//test-stat-basic' Traceback (most recent call last): File "./tests/attr.py", line 379, in <module> main() File "./tests/attr.py", line 370, in main run_tests(options) File "./tests/attr.py", line 311, in run_tests Test(f, options).run() File "./tests/attr.py", line 300, in run self.compare(self.expect, self.result) File "./tests/attr.py", line 248, in compare exp_event.diff(res_event) UnboundLocalError: local variable 'res_event' referenced before assignment [root@s8360046 perf]# This patch catches this pitfall and prints an error message instead: [root@s8360047 perf]# /usr/bin/python2 ./tests/attr.py -d ./tests/attr/ \ -p ./perf -vvv -ttest-stat-basic running './tests/attr//test-stat-basic' loading expected events Event event:base-stat fd = 1 group_fd = -1 flags = 0|8 [....] sample_regs_user = 0 sample_stack_user = 0 'PERF_TEST_ATTR=/tmp/tmpJbMQMP ./perf stat -o /tmp/tmpJbMQMP/perf.data -e cycles kill >/dev/null 2>&1' ret '1', expected '1' loading result events compare matching [event:base-stat] match: [event:base-stat] matches [] res_event is empty FAILED './tests/attr//test-stat-basic' - match failure [root@s8360047 perf]# Signed-off-by:
Thomas-Mich Richter <tmricht@linux.vnet.ibm.com> Acked-by:
Jiri Olsa <jolsa@kernel.org> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Thomas-Mich Richter <tmricht@linux.vnet.ibm.com> LPU-Reference: 20170913081209.39570-1-tmricht@linux.vnet.ibm.com Link: http://lkml.kernel.org/n/tip-04d63nn7svfgxdhi60gq2mlm@git.kernel.orgSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Thomas Richter authored
[ Upstream commit 22905582 ] Command perf test -v 16 (Setup struct perf_event_attr test) always reports success even if the test case fails. It works correctly if you also specify -F (for don't fork). root@s35lp76 perf]# ./perf test -v 16 15: Setup struct perf_event_attr : --- start --- running './tests/attr/test-record-no-delay' [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.002 MB /tmp/tmp4E1h7R/perf.data (1 samples) ] expected task=0, got 1 expected precise_ip=0, got 3 expected wakeup_events=1, got 0 FAILED './tests/attr/test-record-no-delay' - match failure test child finished with 0 ---- end ---- Setup struct perf_event_attr: Ok The reason for the wrong error reporting is the return value of the system() library call. It is called in run_dir() file tests/attr.c and returns the exit status, in above case 0xff00. This value is given as parameter to the exit() function which can only handle values 0-0xff. The child process terminates with exit value of 0 and the parent does not detect any error. This patch corrects the error reporting and prints the correct test result. Signed-off-by:
-
Ioana Radulescu authored
[ Upstream commit 8dabf52f ] For some dpio functions, a cpu id parameter value of -1 is valid and means "any". But when trying to validate this param value against an upper limit, in this case num_possible_cpus(), we risk obtaining the wrong result due to an implicit cast. Avoid an incorrect check result by explicitly comparing the cpu id with the "any" value before verifying the upper bound. Signed-off-by:
Ioana Radulescu <ruxandra.radulescu@nxp.com> Signed-off-by:
-
Ian Jamison authored
[ Upstream commit a0983c74 ] UART core function uart_update_mctrl relies on a cached value of modem control lines. This was used but not updated by local RTS control functions within imx.c. These are used for RS485 line driver enable signalling. Having an out-of-date value in the cached mctrl can result in the transmitter being enabled when it shouldn't be. Fix this by updating the mctrl value before applying it. Signed-off-by:
Ian Jamison <ian.dev@arkver.com> Origin: id:8195c96e674517b82a6ff7fe914c7ba0f86e702b.1505375165.git.ian.dev@arkver.com Acked-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Tested-by:
Clemens Gruber <clemens.gruber@pqgruber.com> Signed-off-by:
-
Ben Hutchings authored
[ Upstream commit c15562c0 ] usbip_host_driver.h now depends on several additional headers, which need to be installed along with it. Fixes: 021aed84 ("staging: usbip: userspace: migrate usbip_host_driver ...") Fixes: 3391ba0e ("usbip: tools: Extract generic code to be shared with ...") Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Acked-by:
Shuah Khan <shuahkh@osg.samsung.com> Signed-off-by:
-
Andy Lowe authored
[ Upstream commit 7464779f ] If a port has no dma channel defined in the device tree, then don't attempt to allocate a dma channel for the port. Also suppress the warning message concerning the failure to allocate a dma channel. Continue to emit the warning message if a dma channel is defined but cannot be allocated. Signed-off-by:
Andy Lowe <andy_lowe@mentor.com> Signed-off-by:
Eugeniu Rosca <erosca@de.adit-jv.com> Signed-off-by:
-
Jibin Xu authored
[ Upstream commit b00bebbc ] When kernel configuration SMP,PREEMPT and DEBUG_PREEMPT are enabled, echo 1 >/proc/sys/kernel/sysrq echo p >/proc/sysrq-trigger kernel will print call trace as below: sysrq: SysRq : Show Regs BUG: using __this_cpu_read() in preemptible [00000000] code: sh/435 caller is __this_cpu_preempt_check+0x18/0x20 Call trace: [<ffffff8008088e80>] dump_backtrace+0x0/0x1d0 [<ffffff8008089074>] show_stack+0x24/0x30 [<ffffff8008447970>] dump_stack+0x90/0xb0 [<ffffff8008463950>] check_preemption_disabled+0x100/0x108 [<ffffff8008463998>] __this_cpu_preempt_check+0x18/0x20 [<ffffff80084c9194>] sysrq_handle_showregs+0x1c/0x40 [<ffffff80084c9c7c>] __handle_sysrq+0x12c/0x1a0 [<ffffff80084ca140>] write_sysrq_trigger+0x60/0x70 [<ffffff8008251e00>] proc_reg_write+0x90/0xd0 [<ffffff80081f1788>] __vfs_write+0x48/0x90 [<ffffff80081f241c>] vfs_write+0xa4/0x190 [<ffffff80081f3354>] SyS_write+0x54/0xb0 [<ffffff80080833f0>] el0_svc_naked+0x24/0x28 This can be seen on a common board like an r-pi3. This happens because when echo p >/proc/sysrq-trigger, get_irq_regs() is called outside of IRQ context, if preemption is enabled in this situation,kernel will print the call trace. Since many prior discussions on the mailing lists have made it clear that get_irq_regs either just returns NULL or stale data when used outside of IRQ context,we simply avoid calling it outside of IRQ context. Signed-off-by:
Jibin Xu <jibin.xu@windriver.com> Signed-off-by:
-
Lu Baolu authored
[ Upstream commit dcabc76f ] xhci_disable_slot() is a helper for disabling a slot when a device goes away or recovers from error situations. Currently, it returns success when it sees a dead host. This is not the right way to go. It should return error and let the invoker know that disable slot command was failed due to a dead host. Fixes: f9e609b8 ("usb: xhci: Add helper function xhci_disable_slot().") Cc: Guoqing Zhang <guoqing.zhang@intel.com> Signed-off-by:
Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Leo Yan authored
[ Upstream commit 0f87855d ] If cpuidle init fails, the code misses to unregister the driver for current CPU. Furthermore, we also need to rollback to cancel all previous CPUs registration; but the code retrieves driver handler by using function cpuidle_get_driver(), this function returns back current CPU driver handler but not previous CPU's handler, which leads to the failure handling code cannot unregister previous CPUs driver. This commit fixes two mentioned issues, it adds error handling path 'goto out_unregister_drv' for current CPU driver unregistration; and it is to replace cpuidle_get_driver() with cpuidle_get_cpu_driver(), the later function can retrieve driver handler for previous CPUs according to the CPU device handler so can unregister the driver properly. This patch also adds extra error handling paths 'goto out_kfree_dev' and 'goto out_kfree_drv' and adjusts the freeing sentences for previous CPUs; so make the code more readable for freeing 'dev' and 'drv' structures. Suggested-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by:
Leo Yan <leo.yan@linaro.org> Fixes: d50a7d8a (ARM: cpuidle: Support asymmetric idle definition) Acked-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Larry Finger authored
[ Upstream commit 43d15c20 ] The kbuild test robot reports the following: drivers/staging//rtlwifi/phydm/phydm_dig.c: In function 'odm_pause_dig': drivers/staging//rtlwifi/phydm/phydm_dig.c:494:45: warning: array subscript is below array bounds [-Warray-bounds] odm_write_dig(dm, dig_tab->pause_dig_value[max_level]); This condition is caused when a loop falls through. The fix is to pin max_level to be >= 0. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> c: kbuild test robot <fengguang.wu@intel.com> Fixes: 9ce99b04 staging: r8822be: Add phydm mini driver Signed-off-by:
-
Ioana Radulescu authored
[ Upstream commit cbb3ea40 ] On Rx path, if we fail to build an skb from the incoming FD, we still need to update the channel buffer count accordingly, otherwise we risk depleting the pool while the software counter still sees available buffers. Signed-off-by:
-
Chunfeng Yun authored
[ Upstream commit c162ff0a ] When failing to get IRQ number, platform_get_irq() may return -EPROBE_DEFER, but we ignore it and always return -ENODEV, so fix it. Signed-off-by:
Chunfeng Yun <chunfeng.yun@mediatek.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Gustavo A. R. Silva authored
[ Upstream commit a8e9b186 ] Add missing break statement in order to prevent the code from falling through. Signed-off-by:
Gustavo A. R. Silva <garsilva@embeddedor.com> Cc: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Cc: linux-edac <linux-edac@vger.kernel.org> Link: http://lkml.kernel.org/r/20171016174029.GA19757@embeddedor.comSigned-off-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit e20824e9 ] While the new family-specific compatible values introduced by commit 6f54cc1a ("devicetree: bindings: R-Car Gen2 CMT0 and CMT1 bindings") use the recommended order "<vendor>,<family>-<device>", the new SoC-specific compatible values still use the old and deprecated order "<vendor>,<device>-<soc>". Switch the SoC-specific compatible values to the recommended order while there are no upstream users of these compatible values yet. Fixes: 7f03a0ec ("devicetree: bindings: r8a73a4 and R-Car Gen2 CMT bindings") Fixes: 63d9e8ca ("devicetree: bindings: Deprecate property, update example") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Ard Biesheuvel authored
[ Upstream commit 21492e13 ] The ACPI GTDT code validates the CNTFRQ field of each MMIO timer frame against the CNTFRQ system register of the current CPU, to ensure that they are equal, which is mandated by the architecture. However, reading the CNTFRQ field of a frame is not possible until the RFRQ bit in the frame's CNTACRn register is set, and doing so before that willl produce the following error: arch_timer: [Firmware Bug]: CNTFRQ mismatch: frame @ 0x00000000e0be0000: (0x00000000), CPU: (0x0ee6b280) arch_timer: Disabling MMIO timers due to CNTFRQ mismatch arch_timer: Failed to initialize memory-mapped timer. The reason is that the CNTFRQ field is RES0 if access is not enabled. So move the validation of CNTFRQ into the loop that iterates over the timers to find the best frame, but defer it until after we have selected the best frame, which should also have enabled the RFRQ bit. Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
-
Dave Hansen authored
[ Upstream commit da20ab35 ] We do not have tracepoints for sys_modify_ldt() because we define it directly instead of using the normal SYSCALL_DEFINEx() macros. However, there is a reason sys_modify_ldt() does not use the macros: it has an 'int' return type instead of 'unsigned long'. This is a bug, but it's a bug cemented in the ABI. What does this mean? If we return -EINVAL from a function that returns 'int', we have 0x00000000ffffffea in %rax. But, if we return -EINVAL from a function returning 'unsigned long', we end up with 0xffffffffffffffea in %rax, which is wrong. To work around this and maintain the 'int' behavior while using the SYSCALL_DEFINEx() macros, so we add a cast to 'unsigned int' in both implementations of sys_modify_ldt(). Signed-off-by:
Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by:
Andy Lutomirski <luto@kernel.org> Reviewed-by:
Brian Gerst <brgerst@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20171018172107.1A79C532@viggo.jf.intel.comSigned-off-by:
-
Masami Hiramatsu authored
[ Upstream commit a30b85df ] We want to wait for all potentially preempted kprobes trampoline execution to have completed. This guarantees that any freed trampoline memory is not in use by any task in the system anymore. synchronize_rcu_tasks() gives such a guarantee, so use it. Also, this guarantees to wait for all potentially preempted tasks on the instructions which will be replaced with a jump. Since this becomes a problem only when CONFIG_PREEMPT=y, enable CONFIG_TASKS_RCU=y for synchronize_rcu_tasks() in that case. Signed-off-by:
Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Naveen N . Rao <naveen.n.rao@linux.vnet.ibm.com> Cc: Paul E . McKenney <paulmck@linux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/150845661962.5443.17724352636247312231.stgit@devboxSigned-off-by:
-
Aaron Sierra authored
[ Upstream commit 0ab84da2 ] The upper four bits of the XR17V35x fractional divisor register (DLD) control general chip function (RS-485 direction pin polarity, multidrop mode, XON/XOFF parity check, and fast IR mode). Don't allow these bits to be clobbered when setting the baudrate. Signed-off-by:
Aaron Sierra <asierra@xes-inc.com> Signed-off-by:
-
Reinette Chatre authored
[ Upstream commit 87943db7 ] Sai reported a warning during some MBA tests: [ 236.755559] ====================================================== [ 236.762443] WARNING: possible circular locking dependency detected [ 236.769328] 4.14.0-rc4-yocto-standard #8 Not tainted [ 236.774857] ------------------------------------------------------ [ 236.781738] mount/10091 is trying to acquire lock: [ 236.787071] (cpu_hotplug_lock.rw_sem){++++}, at: [<ffffffff8117f892>] static_key_enable+0x12/0x30 [ 236.797058] but task is already holding lock: [ 236.803552] (&type->s_umount_key#37/1){+.+.}, at: [<ffffffff81208b2f>] sget_userns+0x32f/0x520 [ 236.813247] which lock already depends on the new lock. [ 236.822353] the existing dependency chain (in reverse order) is: [ 236.830686] -> #4 (&type->s_umount_key#37/1){+.+.}: [ 236.837756] __lock_acquire+0x1100/0x11a0 [ 236.842799] lock_acquire+0xdf/0x1d0 [ 236.847363] down_write_nested+0x46/0x80 [ 236.852310] sget_userns+0x32f/0x520 [ 236.856873] kernfs_mount_ns+0x7e/0x1f0 [ 236.861728] rdt_mount+0x30c/0x440 [ 236.866096] mount_fs+0x38/0x150 [ 236.870262] vfs_kern_mount+0x67/0x150 [ 236.875015] do_mount+0x1df/0xd50 [ 236.879286] SyS_mount+0x95/0xe0 [ 236.883464] entry_SYSCALL_64_fastpath+0x18/0xad [ 236.889183] -> #3 (rdtgroup_mutex){+.+.}: [ 236.895292] __lock_acquire+0x1100/0x11a0 [ 236.900337] lock_acquire+0xdf/0x1d0 [ 236.904899] __mutex_lock+0x80/0x8f0 [ 236.909459] mutex_lock_nested+0x1b/0x20 [ 236.914407] intel_rdt_online_cpu+0x3b/0x4a0 [ 236.919745] cpuhp_invoke_callback+0xce/0xb80 [ 236.925177] cpuhp_thread_fun+0x1c5/0x230 [ 236.930222] smpboot_thread_fn+0x11a/0x1e0 [ 236.935362] kthread+0x152/0x190 [ 236.939536] ret_from_fork+0x27/0x40 [ 236.944097] -> #2 (cpuhp_state-up){+.+.}: [ 236.950199] __lock_acquire+0x1100/0x11a0 [ 236.955241] lock_acquire+0xdf/0x1d0 [ 236.959800] cpuhp_issue_call+0x12e/0x1c0 [ 236.964845] __cpuhp_setup_state_cpuslocked+0x13b/0x2f0 [ 236.971242] __cpuhp_setup_state+0xa7/0x120 [ 236.976483] page_writeback_init+0x43/0x67 [ 236.981623] pagecache_init+0x38/0x3b [ 236.986281] start_kernel+0x3c6/0x41a [ 236.990931] x86_64_start_reservations+0x2a/0x2c [ 236.996650] x86_64_start_kernel+0x72/0x75 [ 237.001793] verify_cpu+0x0/0xfb [ 237.005966] -> #1 (cpuhp_state_mutex){+.+.}: [ 237.012364] __lock_acquire+0x1100/0x11a0 [ 237.017408] lock_acquire+0xdf/0x1d0 [ 237.021969] __mutex_lock+0x80/0x8f0 [ 237.026527] mutex_lock_nested+0x1b/0x20 [ 237.031475] __cpuhp_setup_state_cpuslocked+0x54/0x2f0 [ 237.037777] __cpuhp_setup_state+0xa7/0x120 [ 237.043013] page_alloc_init+0x28/0x30 [ 237.047769] start_kernel+0x148/0x41a [ 237.052425] x86_64_start_reservations+0x2a/0x2c [ 237.058145] x86_64_start_kernel+0x72/0x75 [ 237.063284] verify_cpu+0x0/0xfb [ 237.067456] -> #0 (cpu_hotplug_lock.rw_sem){++++}: [ 237.074436] check_prev_add+0x401/0x800 [ 237.079286] __lock_acquire+0x1100/0x11a0 [ 237.084330] lock_acquire+0xdf/0x1d0 [ 237.088890] cpus_read_lock+0x42/0x90 [ 237.093548] static_key_enable+0x12/0x30 [ 237.098496] rdt_mount+0x406/0x440 [ 237.102862] mount_fs+0x38/0x150 [ 237.107035] vfs_kern_mount+0x67/0x150 [ 237.111787] do_mount+0x1df/0xd50 [ 237.116058] SyS_mount+0x95/0xe0 [ 237.120233] entry_SYSCALL_64_fastpath+0x18/0xad [ 237.125952] other info that might help us debug this: [ 237.134867] Chain exists of: cpu_hotplug_lock.rw_sem --> rdtgroup_mutex --> &type->s_umount_key#37/1 [ 237.148425] Possible unsafe locking scenario: [ 237.155015] CPU0 CPU1 [ 237.160057] ---- ---- [ 237.165100] lock(&type->s_umount_key#37/1); [ 237.169952] lock(rdtgroup_mutex); [ 237.176641] lock(&type->s_umount_key#37/1); [ 237.184287] lock(cpu_hotplug_lock.rw_sem); [ 237.189041] *** DEADLOCK *** When the resctrl filesystem is mounted the locks must be acquired in the same order as was done when the cpus came online: cpu_hotplug_lock before rdtgroup_mutex. This also requires to switch the static_branch_enable() calls to the _cpulocked variant because now cpu hotplug lock is held already. [ tglx: Switched to cpus_read_[un]lock ] Reported-by:
Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com> Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com> Tested-by:
Vikas Shivappa <vikas.shivappa@linux.intel.com> Cc: fenghua.yu@intel.com Cc: tony.luck@intel.com Link: https://lkml.kernel.org/r/9c41b91bc2f47d9e95b62b213ecdb45623c47a9f.1508490116.git.reinette.chatre@intel.comSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Reinette Chatre authored
[ Upstream commit 95953034 ] The platform informs via CPUID.(EAX=0x10, ECX=res#):EBX[31:0] (valid res# are only 1 for L3 and 2 for L2) which unit of the allocation may be used by other entities in the platform. This information is valid whether CDP (Code and Data Prioritization) is enabled or not. Ensure that the bitmask of shareable resource is initialized when CDP is enabled. Fixes: 0dd2d749 ("x86/intel_rdt: Show bitmask of shareable resource with other executing units" Signed-off-by:
Fenghua Yu <fenghua.yu@intel.com> Acked-by:
Tony Luck <tony.luck@intel.com> Link: https://lkml.kernel.org/r/815747bddc820ca221a8924edaf4d1a7324547e4.1508490116.git.reinette.chatre@intel.comSigned-off-by:
-
Kishon Vijay Abraham I authored
[ Upstream commit 7a4db656 ] PCI core access configuration space registers in resume_noirq callbacks. In the case of dra7xx, PIPE3 PHY connected to PCIe controller has to be enabled before accessing configuration space registers. Since PIPE3 PHY is enabled by only configuring control module registers, no aborts has been observed so far (though during noirq stage, interface clock of PIPE3 PHY is not enabled). With new TRM updates, PIPE3 PHY has to be initialized (PIPE3 PHY registers has to be accessed) as well which requires the interface clock of PIPE3 PHY to be enabled. The interface clock of PIPE3 PHY is derived from OCP2SCP and hence PCIe PHY is modeled as a child of OCP2SCP. Since pm_runtime is not enabled during noirq stage, pm_runtime_get_sync done in phy_init doesn't enable OCP2SCP clocks resulting in abort when PIPE3 PHY registers are accessed. Create a function dependency between PCIe and PHY here to make sure PCIe is suspended before PCIe PHY/OCP2SCP and resumed after PCIe PHY/OCP2SCP. Suggested-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
Sekhar Nori <nsekhar@ti.com> Acked-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Alexey Khoroshilov authored
[ Upstream commit ce035409 ] If devm_extcon_dev_allocate() fails, we should disable clk before return. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Fixes: 860d2686 ("usb: phy: tahvo: Use devm_extcon_dev_[allocate|register]() and replace deprecated API") Signed-off-by:
-
Peter Zijlstra authored
[ Upstream commit a9cd8194 ] Event timestamps are serialized using ctx->lock, make sure to hold it over reading all values. Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Edward A. James authored
[ Upstream commit 6dcf2fb5 ] The pmbus core may call read/write word data functions with a page value of -1, intending to perform the operation without setting the page. However, the read/write word data functions accept only unsigned 8-bit page numbers, and therefore cannot check for negative page number to avoid setting the page. This results in setting the page number to 0xFF. This may result in errors or undefined behavior of some devices (specifically the ir35221, which allows the page to be set to 0xFF, but some subsequent operations to read registers may fail). Switch the pmbus_set_page page parameter to an integer and perform the check for negative page there. Make read/write functions consistent in accepting an integer page number parameter. Signed-off-by:
Edward A. James <eajames@us.ibm.com> Fixes: cbcdec62 ("hwmon: (pmbus): Access word data for STATUS_WORD") Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Subhash Jadavani authored
[ Upstream commit c7ccee22 ] SDCC controller reset (SW_RST) during probe may trigger power irq if previous status of PWRCTL was either BUS_ON or IO_HIGH_V. So before we enable the power irq interrupt in GIC (by registering the interrupt handler), we need to ensure that any pending power irq interrupt status is acknowledged otherwise power irq interrupt handler would be fired prematurely. Signed-off-by:
Subhash Jadavani <subhashj@codeaurora.org> Signed-off-by:
Vijay Viswanath <vviswana@codeaurora.org> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Fabrizio Castro authored
[ Upstream commit a3d95d1d ] mmc_regulator_get_supply returns -EPROBE_DEFER if either vmmc or vqmmc regulators had their probing deferred. vqmmc regulator is needed by UHS to work properly, therefore this patch checks the value returned by mmc_regulator_get_supply to make sure we have a reference to both vmmc and vqmmc (if found in the DT). Signed-off-by:
Fabrizio Castro <fabrizio.castro@bp.renesas.com> Reviewed-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by:
-
Johan Hovold authored
[ Upstream commit 4d5e0689 ] Take an extra reference to the controller before deregistering it to prevent use-after-free in the interrupt handler in case an interrupt fires before the line is disabled. Fixes: b1353d1c ("spi: Add Analog Devices AXI SPI Engine controller support") Acked-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Hiromitsu Yamasaki authored
[ Upstream commit 36735783 ] DMA supports 32-bit words only, even if BITLEN1 of SITMDR2 register is 16bit. Fixes: b0d0ce8b ("spi: sh-msiof: Add DMA support") Signed-off-by:
Hiromitsu Yamasaki <hiromitsu.yamasaki.ym@renesas.com> Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Acked-by:
Dirk Behme <dirk.behme@de.bosch.com> Signed-off-by:
-
Colin Ian King authored
[ Upstream commit 123c0aab ] There is a check on pmlmepriv before dereferencing it when vfree'ing pmlmepriv->free_bss_buf however the previous call to rtw_free_mlme_priv_ie_data deferences pmlmepriv causing a null pointer deference if it is null. Avoid this by also calling rtw_free_mlme_priv_ie_data if the pointer is non-null. Detected by CoverityScan, CID#1230262 ("Dereference before null check") Fixes: 7b464c9f ("staging: r8188eu: Add files for new driver - part 4") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Stanislaw Gruszka authored
[ Upstream commit c40a45a4 ] Patch fixes splat: r8822be 0000:04:00.0: DMA-API: device driver frees DMA memory with different size [device address=0x0000000078477000] [map size=4096 bytes] [unmap size=424 bytes] <snip> Call Trace: debug_dma_unmap_page+0xa5/0xb0 ? unmap_single+0x2f/0x40 _rtl8822be_send_bcn_or_cmd_packet+0x2c5/0x300 [r8822be] ? _rtl8822be_send_bcn_or_cmd_packet+0x2c5/0x300 [r8822be] rtl8822b_halmac_cb_write_data_rsvd_page+0x51/0xc0 [r8822be] _halmac_write_data_rsvd_page+0x22/0x30 [r8822be] halmac_download_rsvd_page_88xx+0xee/0x1f0 [r8822be] halmac_dlfw_to_mem_88xx+0x80/0x120 [r8822be] halmac_download_firmware_88xx.part.47+0x477/0x600 [r8822be] halmac_download_firmware_88xx+0x32/0x40 [r8822be] rtl_halmac_dlfw+0x70/0x120 [r8822be] rtl_halmac_init_hal+0x5f/0x1b0 [r8822be] rtl8822be_hw_init+0x8a2/0x1040 [r8822be] Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Acked-by:
-
Lukas Wunner authored
[ Upstream commit 3236a965 ] This driver's ->rs485_config callback checks if SER_RS485_RTS_ON_SEND and SER_RS485_RTS_AFTER_SEND have the same value. If they do, it means the user has passed in invalid data with the TIOCSRS485 ioctl() since RTS must have a different polarity when sending and when not sending. In this case, rs485 mode is not enabled (the RS485_URA bit is not set in the RS485 Enable Register) and this is supposed to be signaled back to the user by clearing the SER_RS485_ENABLED bit in struct serial_rs485 ... except a missing tilde character is preventing that from happening. Fixes: 28e3fb6c ("serial: Add support for Fintek F81216A LPC to 4 UART") Cc: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Cc: "Ji-Ze Hong (Peter Hong)" <hpeter@gmail.com> Signed-off-by:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
-
Greg Ungerer authored
[ Upstream commit f55ab8f2 ] The m68k pg_data_table is a fix size array defined in arch/m68k/mm/init.c. Index numbers within it are defined based on memory size. But for Coldfire these don't take into account a non-zero physical RAM base address, and this causes us to access past the end of this array at system start time. Change the node shift calculation so that we keep the index inside its range. Reported-by:
Angelo Dureghello <angelo@sysam.it> Tested-by:
Greg Ungerer <gerg@linux-m68k.org> Signed-off-by:
-
Bryan O'Donoghue authored
[ Upstream commit 44b02da3 ] Commit 12927835 ("greybus: loopback: Add asynchronous bi-directional support") does what it says on the tin - namely, adds support for asynchronous bi-directional loopback operations. What it neglects to do though is increment the per-connection gb->iteration_count on an asynchronous operation error. This patch fixes that omission. Fixes: 12927835 ("greybus: loopback: Add asynchronous bi-directional support") Signed-off-by:
Bryan O'Donoghue <pure.logic@nexus-software.ie> Reported-by:
Mitch Tasman <tasman@leaflabs.com> Reviewed-by:
-
Andy Lutomirski authored
[ Upstream commit d60ad744 ] Bits 19:16 of LAR's result are undefined, and some upcoming improvements to the test case seem to trigger this. Mask off those bits to avoid spurious failures. commit 5b781c7e ("x86/tls: Forcibly set the accessed bit in TLS segments") adds a valid case in which LAR's output doesn't quite agree with set_thread_area()'s input. This isn't triggered in the test as is, but it will be if we start calling set_thread_area() with the accessed bit clear. Work around this discrepency. I've added a Fixes tag so that -stable can pick this up if neccesary. Signed-off-by:
-
Andy Lutomirski authored
[ Upstream commit fec8f5ae ] We weren't testing the .limit and .limit_in_pages fields very well. Add more tests. This addition seems to trigger the "bits 16:19 are undefined" issue that was fixed in an earlier patch. I think that, at least on my CPU, the high nibble of the limit ends in LAR bits 16:19. Signed-off-by:
-
Christian Borntraeger authored
[ Upstream commit 48070c73 ] As of today QEMU does not provide the AIS facility to its guest. This prevents Linux guests from using PCI devices as the ais facility is checked during init. As this is just a performance optimization, we can move the ais check into the code where we need it (calling the SIC instruction). This is used at initialization and on interrupt. Both places do not require any serialization, so we can simply skip the instruction. Since we will now get all interrupts, we can also avoid the 2nd scan. As we can have multiple interrupts in parallel we might trigger spurious irqs more often for the non-AIS case but the core code can handle that. Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by:
Pierre Morel <pmorel@linux.vnet.ibm.com> Reviewed-by:
Halil Pasic <pasic@linux.vnet.ibm.com> Acked-by:
Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
-
Ulf Hansson authored
[ Upstream commit 5241ab40 ] During system-wide PM, genpd relies on its PM callbacks to be invoked for all its attached devices, as to deal with powering off/on the PM domain. In other words, genpd is not compatible with the direct_complete path, if executed by the PM core for any of its attached devices. However, when genpd's ->prepare() callback invokes pm_generic_prepare(), it does not take into account that it may return 1. Instead it treats that as an error internally and expects the PM core to abort the prepare phase and roll back. This leads to genpd not properly powering on/off the PM domain, because its internal counters gets wrongly balanced. To fix the behaviour, allow drivers to return 1 from their ->prepare() callbacks, but let's return 0 from genpd's ->prepare() callback in such case, as that prevents the PM core from running the direct_complete path for the device. Signed-off-by:
-
Jason J. Herne authored
[ Upstream commit 408358b5 ] Because we do not make use of the cda (channel data address) for test, no-op ccws no address translation takes place. This means cda could contain a guest address which we do not want to attempt to free. Let's check the command type and skip cda free when it is not needed. For a TIC ccw, ccw->cda points to either a ccw in an existing chain or it points to a whole new allocated chain. In either case the data will be freed when the owning chain is freed. Signed-off-by:
Jason J. Herne <jjherne@linux.vnet.ibm.com> Reviewed-by:
Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Reviewed-by:
Cornelia Huck <cohuck@redhat.com> Signed-off-by:
-
