- 07 Oct, 2016 14 commits
-
-
Paul Burton authored
commit 305723ab upstream. Malta boards used with CPU emulators feature a switch to disable use of an IOCU. Software has to check this switch & ignore any present IOCU if the switch is closed. The read used to do this was unsafe for 64 bit kernels, as it simply casted the address 0xbf403000 to a pointer & dereferenced it. Whilst in a 32 bit kernel this would access kseg1, in a 64 bit kernel this attempts to access xuseg & results in an address error exception. Fix by accessing a correctly formed ckseg1 address generated using the CKSEG1ADDR macro. Whilst modifying this code, define the name of the register and the bit we care about within it, which indicates whether PCI DMA is routed to the IOCU or straight to DRAM. The code previously checked that bit 0 was also set, but the least significant 7 bits of the CONFIG_GEN0 register contain the value of the MReqInfo signal provided to the IOCU OCP bus, so singling out bit 0 makes little sense & that part of the check is dropped. Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Fixes: b6d92b4a ("MIPS: Add option to disable software I/O coherency.") Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Kees Cook <keescook@chromium.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/14187/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Will Deacon authored
commit 3a402a70 upstream. When TIF_SINGLESTEP is set for a task, the single-step state machine is enabled and we must take care not to reset it to the active-not-pending state if it is already in the active-pending state. Unfortunately, that's exactly what user_enable_single_step does, by unconditionally setting the SS bit in the SPSR for the current task. This causes failures in the GDB testsuite, where GDB ends up missing expected step traps if the instruction being stepped generates another trap, e.g. PTRACE_EVENT_FORK from an SVC instruction. This patch fixes the problem by preserving the current state of the stepping state machine when TIF_SINGLESTEP is set on the current thread. Cc: <stable@vger.kernel.org> Reported-by:
Yao Qi <yao.qi@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Srinivas Ramana authored
commit 117e5e9c upstream. If the bootloader uses the long descriptor format and jumps to kernel decompressor code, TTBCR may not be in a right state. Before enabling the MMU, it is required to clear the TTBCR.PD0 field to use TTBR0 for translation table walks. The commit dbece458 ("ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores") does the reset of TTBCR.N, but doesn't consider all the bits for the size of TTBCR.N. Clear TTBCR.PD0 field and reset all the three bits of TTBCR.N to indicate the use of TTBR0 and the correct base address width. Fixes: dbece458 ("ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores") Acked-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
Srinivas Ramana <sramana@codeaurora.org> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Dan Carpenter authored
commit f4693b08 upstream. We can't assign -EINVAL to a u16. Fixes: 3948f0e0 ('usb: add Freescale QE/CPM USB peripheral controller driver') Acked-by:
Peter Chen <peter.chen@nxp.com> Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Sara Sharon authored
commit d5d0689a upstream. This fixes a pretty ancient bug that hasn't manifested itself until now. The scratchbuf for command queue is allocated only for 32 slots but is accessed with the queue write pointer - which can be up to 256. Since the scratch buf size was 16 and there are up to 256 TFDs we never passed a page boundary when accessing the scratch buffer, but when attempting to increase the size of the scratch buffer a panic was quick to follow when trying to access the address resulted in a page boundary. Signed-off-by:
Sara Sharon <sara.sharon@intel.com> Fixes: 38c0f334 ("iwlwifi: use coherent DMA memory for command header") Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Michael Walle authored
commit b53893aa upstream. According to the datasheet you should only write 1 to this bit. If it is not set, at least AIN3 will return bad values on newer silicon revisions. Fixes: d84ca5b3 ("hwmon: Add driver for ADT7411 voltage and temperature sensor") Signed-off-by:
Michael Walle <michael@walle.cc> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Dan Carpenter authored
commit 2d6a4d64 upstream. The curly braces are missing here so we print stuff unintentionally. Fixes: 9da4714a ('slub: slabinfo update for cmpxchg handling') Link: http://lkml.kernel.org/r/20160715211243.GE19522@mwandaSigned-off-by:
Christoph Lameter <cl@linux.com> Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Cc: Colin Ian King <colin.king@canonical.com> Cc: Laura Abbott <labbott@fedoraproject.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Robin Murphy authored
commit ba6dea4f upstream. Whilst MPIDR values themselves are less than 32 bits, it is still perfectly valid for a DT to have #address-cells > 1 in the CPUs node, resulting in the "reg" property having leading zero cell(s). In that situation, the big-endian nature of the data conspires with the current behaviour of only reading the first cell to cause the kernel to think all CPUs have ID 0, and become resoundingly unhappy as a consequence. Take the full property length into account when parsing CPUs so as to be correct under any circumstances. Cc: Russell King <linux@armlinux.org.uk> Signed-off-by:
-
Alex Deucher authored
commit 670bb4fd upstream. Add clock quirks for Jet parts. Reviewed-by:
Sonny Jiang <sonny.jiang@amd.com> Tested-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Sergei Miroshnichenko authored
commit 9abefcb1 upstream. A timer was used to restart after the bus-off state, leading to a relatively large can_restart() executed in an interrupt context, which in turn sets up pinctrl. When this happens during system boot, there is a high probability of grabbing the pinctrl_list_mutex, which is locked already by the probe() of other device, making the kernel suspect a deadlock condition [1]. To resolve this issue, the restart_timer is replaced by a delayed work. [1] https://github.com/victronenergy/venus/issues/24Signed-off-by:
Sergei Miroshnichenko <sergeimir@emcraft.com> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
zhong jiang authored
commit 5b398e41 upstream. I hit the following hung task when runing a OOM LTP test case with 4.1 kernel. Call trace: [<ffffffc000086a88>] __switch_to+0x74/0x8c [<ffffffc000a1bae0>] __schedule+0x23c/0x7bc [<ffffffc000a1c09c>] schedule+0x3c/0x94 [<ffffffc000a1eb84>] rwsem_down_write_failed+0x214/0x350 [<ffffffc000a1e32c>] down_write+0x64/0x80 [<ffffffc00021f794>] __ksm_exit+0x90/0x19c [<ffffffc0000be650>] mmput+0x118/0x11c [<ffffffc0000c3ec4>] do_exit+0x2dc/0xa74 [<ffffffc0000c46f8>] do_group_exit+0x4c/0xe4 [<ffffffc0000d0f34>] get_signal+0x444/0x5e0 [<ffffffc000089fcc>] do_signal+0x1d8/0x450 [<ffffffc00008a35c>] do_notify_resume+0x70/0x78 The oom victim cannot terminate because it needs to take mmap_sem for write while the lock is held by ksmd for read which loops in the page allocator ksm_do_scan scan_get_next_rmap_item down_read get_next_rmap_item alloc_rmap_item #ksmd will loop permanently. There is no way forward because the oom victim cannot release any memory in 4.1 based kernel. Since 4.6 we have the oom reaper which would solve this problem because it would release the memory asynchronously. Nevertheless we can relax alloc_rmap_item requirements and use __GFP_NORETRY because the allocation failure is acceptable as ksm_do_scan would just retry later after the lock got dropped. Such a patch would be also easy to backport to older stable kernels which do not have oom_reaper. While we are at it add GFP_NOWARN so the admin doesn't have to be alarmed by the allocation failure. Link: http://lkml.kernel.org/r/1474165570-44398-1-git-send-email-zhongjiang@huawei.comSigned-off-by:
zhong jiang <zhongjiang@huawei.com> Suggested-by:
Hugh Dickins <hughd@google.com> Suggested-by:
Michal Hocko <mhocko@suse.cz> Acked-by:
Michal Hocko <mhocko@suse.com> Acked-by:
-
Karl Beldan authored
commit f6d7c1b5 upstream. This fixes subpage writes when using 4-bit HW ECC. There has been numerous reports about ECC errors with devices using this driver for a while. Also the 4-bit ECC has been reported as broken with subpages in [1] and with 16 bits NANDs in the driver and in mach* board files both in mainline and in the vendor BSPs. What I saw with 4-bit ECC on a 16bits NAND (on an LCDK) which got me to try reinitializing the ECC engine: - R/W on whole pages properly generates/checks RS code - try writing the 1st subpage only of a blank page, the subpage is well written and the RS code properly generated, re-reading the same page the HW detects some ECC error, reading the same page again no ECC error is detected Note that the ECC engine is already reinitialized in the 1-bit case. Tested on my LCDK with UBI+UBIFS using subpages. This could potentially get rid of the issue workarounded in [1]. [1] 28c015a9 ("mtd: davinci-nand: disable subpage write for keystone-nand") Fixes: 6a4123e5 ("mtd: nand: davinci_nand, 4-bit ECC for smallpage") Signed-off-by:
Karl Beldan <kbeldan@baylibre.com> Acked-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by:
Brian Norris <computersforpeace@gmail.com> Signed-off-by:
-
Michael Ellerman authored
commit e8a4fd0a upstream. The encoding of the lengths in the ibm_architecture_vec array is "interesting" to say the least. It's non-obvious how the number of bytes we provide relates to the length value. In fact we already got it wrong once, see 11e9ed43 "Fix up ibm_architecture_vec definition". So add some macros to make it (hopefully) clearer. These at least have the property that the integer present in the code is equal to the number of bytes that follows it. Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Reviewed-by:
Stewart Smith <stewart@linux.vnet.ibm.com> Signed-off-by:
-
Peter Zijlstra authored
commit ecf7d01c upstream. Oleg noticed that its possible to falsely observe p->on_cpu == 0 such that we'll prematurely continue with the wakeup and effectively run p on two CPUs at the same time. Even though the overlap is very limited; the task is in the middle of being scheduled out; it could still result in corruption of the scheduler data structures. CPU0 CPU1 set_current_state(...) <preempt_schedule> context_switch(X, Y) prepare_lock_switch(Y) Y->on_cpu = 1; finish_lock_switch(X) store_release(X->on_cpu, 0); try_to_wake_up(X) LOCK(p->pi_lock); t = X->on_cpu; // 0 context_switch(Y, X) prepare_lock_switch(X) X->on_cpu = 1; finish_lock_switch(Y) store_release(Y->on_cpu, 0); </preempt_schedule> schedule(); deactivate_task(X); X->on_rq = 0; if (X->on_rq) // false if (t) while (X->on_cpu) cpu_relax(); context_switch(X, ..) finish_lock_switch(X) store_release(X->on_cpu, 0); Avoid the load of X->on_cpu being hoisted over the X->on_rq load. Reported-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Ingo Molnar <mingo@kernel.org> Cc: Mike Galbraith <efault@gmx.de> Signed-off-by:
-
- 06 Oct, 2016 26 commits
-
-
Jeff Mahoney authored
Prior to v3.17, XFS used positive error codes internally. Commit af8d9716 (xfs: inode recovery readahead can race with inode buffer creation), upstream commit b79f4a1c backported from later releases need the error code signs reversed. Negative error codes will cause assertion failures (BUG_ON on kernels with assertions enabled. Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Cc: Dave Chinner <dchinner@redhat.com> Cc: Brian Foster <bfoster@redhat.com> Signed-off-by:
-
Bart Van Assche authored
commit 51093254 upstream. Let the target core check task existence instead of the SRP target driver. Additionally, let the target core check the validity of the task management request instead of the ib_srpt driver. This patch fixes the following kernel crash: BUG: unable to handle kernel NULL pointer dereference at 0000000000000001 IP: [<ffffffffa0565f37>] srpt_handle_new_iu+0x6d7/0x790 [ib_srpt] Oops: 0002 [#1] SMP Call Trace: [<ffffffffa05660ce>] srpt_process_completion+0xde/0x570 [ib_srpt] [<ffffffffa056669f>] srpt_compl_thread+0x13f/0x160 [ib_srpt] [<ffffffff8109726f>] kthread+0xcf/0xe0 [<ffffffff81613cfc>] ret_from_fork+0x7c/0xb0 Signed-off-by:
Bart Van Assche <bart.vanassche@sandisk.com> Fixes: 3e4f5748 ("ib_srpt: Convert TMR path to target_submit_tmr") Tested-by:
Alex Estrin <alex.estrin@intel.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Cc: Nicholas Bellinger <nab@linux-iscsi.org> Cc: Sagi Grimberg <sagig@mellanox.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
Doug Ledford <dledford@redhat.com> Acked-by:
Benjamin Poirier <bpoirier@suse.com> Signed-off-by:
-
Oliver Neukum authored
commit 60bcabd0 upstream. This fixes the oops discovered by the Umap2 project and Alan Stern. The intf member needs to be set before the firmware is downloaded. Signed-off-by:
Oliver Neukum <oneukum@suse.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Kinglong Mee authored
commit 3f42d2c4 upstream. Connection from alloc_conn must be freed through free_conn, otherwise, the reference of svc_xprt will never be put. Signed-off-by:
Kinglong Mee <kinglongmee@gmail.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Michal Hocko authored
commit 735f2770 upstream. Commit fec1d011 ("[PATCH] Disable CLONE_CHILD_CLEARTID for abnormal exit") has caused a subtle regression in nscd which uses CLONE_CHILD_CLEARTID to clear the nscd_certainly_running flag in the shared databases, so that the clients are notified when nscd is restarted. Now, when nscd uses a non-persistent database, clients that have it mapped keep thinking the database is being updated by nscd, when in fact nscd has created a new (anonymous) one (for non-persistent databases it uses an unlinked file as backend). The original proposal for the CLONE_CHILD_CLEARTID change claimed (https://lkml.org/lkml/2006/10/25/233): : The NPTL library uses the CLONE_CHILD_CLEARTID flag on clone() syscalls : on behalf of pthread_create() library calls. This feature is used to : request that the kernel clear the thread-id in user space (at an address : provided in the syscall) when the thread disassociates itself from the : address space, which is done in mm_release(). : : Unfortunately, when a multi-threaded process incurs a core dump (such as : from a SIGSEGV), the core-dumping thread sends SIGKILL signals to all of : the other threads, which then proceed to clear their user-space tids : before synchronizing in exit_mm() with the start of core dumping. This : misrepresents the state of process's address space at the time of the : SIGSEGV and makes it more difficult for someone to debug NPTL and glibc : problems (misleading him/her to conclude that the threads had gone away : before the fault). : : The fix below is to simply avoid the CLONE_CHILD_CLEARTID action if a : core dump has been initiated. The resulting patch from Roland (https://lkml.org/lkml/2006/10/26/269) seems to have a larger scope than the original patch asked for. It seems that limitting the scope of the check to core dumping should work for SIGSEGV issue describe above. [Changelog partly based on Andreas' description] Fixes: fec1d011 ("[PATCH] Disable CLONE_CHILD_CLEARTID for abnormal exit") Link: http://lkml.kernel.org/r/1471968749-26173-1-git-send-email-mhocko@kernel.orgSigned-off-by:
William Preston <wpreston@suse.com> Acked-by:
-
Vitaly Kuznetsov authored
commit 32a15832 upstream. It looks like clockevents_unbind is being exported by mistake as: - it is static; - it is not listed in include/linux/clockchips.h; - EXPORT_SYMBOL_GPL(clockevents_unbind) follows clockevents_unbind_device() implementation. I think clockevents_unbind_device should be exported instead. This is going to be used to teardown Hyper-V clockevent devices on module unload. Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Joerg Roedel authored
commit 3254de6b upstream. Not doing so might cause IO-Page-Faults when a device uses an alias request-id and the alias-dte is left in a lower page-mode which does not cover the address allocated from the iova-allocator. Fixes: 492667da ('x86/amd-iommu: Remove amd_iommu_pd_table') Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
WANG Cong authored
commit 205e1e25 upstream. Matt reported that we have a NULL pointer dereference in ppp_pernet() from ppp_connect_channel(), i.e. pch->chan_net is NULL. This is due to that a parallel ppp_unregister_channel() could happen while we are in ppp_connect_channel(), during which pch->chan_net set to NULL. Since we need a reference to net per channel, it makes sense to sync the refcnt with the life time of the channel, therefore we should release this reference when we destroy it. Fixes: 1f461dcd ("ppp: take reference on channels netns") Reported-by:
Matt Bennett <Matt.Bennett@alliedtelesis.co.nz> Cc: Paul Mackerras <paulus@samba.org> Cc: linux-ppp@vger.kernel.org Cc: Guillaume Nault <g.nault@alphalink.fr> Cc: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Reviewed-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
-
Khem Raj authored
commit 1e407ee3 upstream. gcc-6 correctly warns about a out of bounds access arch/powerpc/kernel/ptrace.c:407:24: warning: index 32 denotes an offset greater than size of 'u64[32][1] {aka long long unsigned int[32][1]}' [-Warray-bounds] offsetof(struct thread_fp_state, fpr[32][0])); ^ check the end of array instead of beginning of next element to fix this Signed-off-by:
Khem Raj <raj.khem@gmail.com> Cc: Kees Cook <keescook@chromium.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Segher Boessenkool <segher@kernel.crashing.org> Tested-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Acked-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
-
Michael Ellerman authored
commit 4fa9a3f6 upstream. This struct is unused, which is now a build error with gcc 6: error: 'os_area_db_id_video_mode' defined but not used There doesn't seem to be any good reason to keep it around so remove it, it's in the history if anyone needs it. Signed-off-by:
-
Sam Ravnborg authored
commit 6eb64b8c upstream. Fix headers_install by adjusting the path to arch files. And delete unused Kbuild file. Drop special handling of cris in the headers.sh script as a nice side-effect. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Cc: Mikael Starvik <starvik@axis.com> Cc: David Howells <dhowells@redhat.com> Signed-off-by:
Jesper Nilsson <jesper.nilsson@axis.com> Signed-off-by:
-
Balbir Singh authored
commit 135e8c92 upstream. The origin of the issue I've seen is related to a missing memory barrier between check for task->state and the check for task->on_rq. The task being woken up is already awake from a schedule() and is doing the following: do { schedule() set_current_state(TASK_(UN)INTERRUPTIBLE); } while (!cond); The waker, actually gets stuck doing the following in try_to_wake_up(): while (p->on_cpu) cpu_relax(); Analysis: The instance I've seen involves the following race: CPU1 CPU2 while () { if (cond) break; do { schedule(); set_current_state(TASK_UN..) } while (!cond); wakeup_routine() spin_lock_irqsave(wait_lock) raw_spin_lock_irqsave(wait_lock) wake_up_process() } try_to_wake_up() set_current_state(TASK_RUNNING); .. list_del(&waiter.list); CPU2 wakes up CPU1, but before it can get the wait_lock and set current state to TASK_RUNNING the following occurs: CPU3 wakeup_routine() raw_spin_lock_irqsave(wait_lock) if (!list_empty) wake_up_process() try_to_wake_up() raw_spin_lock_irqsave(p->pi_lock) .. if (p->on_rq && ttwu_wakeup()) .. while (p->on_cpu) cpu_relax() .. CPU3 tries to wake up the task on CPU1 again since it finds it on the wait_queue, CPU1 is spinning on wait_lock, but immediately after CPU2, CPU3 got it. CPU3 checks the state of p on CPU1, it is TASK_UNINTERRUPTIBLE and the task is spinning on the wait_lock. Interestingly since p->on_rq is checked under pi_lock, I've noticed that try_to_wake_up() finds p->on_rq to be 0. This was the most confusing bit of the analysis, but p->on_rq is changed under runqueue lock, rq_lock, the p->on_rq check is not reliable without this fix IMHO. The race is visible (based on the analysis) only when ttwu_queue() does a remote wakeup via ttwu_queue_remote. In which case the p->on_rq change is not done uder the pi_lock. The result is that after a while the entire system locks up on the raw_spin_irqlock_save(wait_lock) and the holder spins infintely Reproduction of the issue: The issue can be reproduced after a long run on my system with 80 threads and having to tweak available memory to very low and running memory stress-ng mmapfork test. It usually takes a long time to reproduce. I am trying to work on a test case that can reproduce the issue faster, but thats work in progress. I am still testing the changes on my still in a loop and the tests seem OK thus far. Big thanks to Benjamin and Nick for helping debug this as well. Ben helped catch the missing barrier, Nick caught every missing bit in my theory. Signed-off-by:
Balbir Singh <bsingharora@gmail.com> [ Updated comment to clarify matching barriers. Many architectures do not have a full barrier in switch_to() so that cannot be relied upon. ] Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Alexey Kardashevskiy <aik@ozlabs.ru> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Nicholas Piggin <nicholas.piggin@gmail.com> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/e02cce7b-d9ca-1ad0-7a61-ea97c7582b37@gmail.comSigned-off-by:
-
Dan Carpenter authored
commit 8a545f18 upstream. We can't pass error pointers to kfree() or it causes an oops. Fixes: 52b209f7 ('get rid of hostfs_read_inode()') Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
Dan Carpenter authored
commit f4cceb2a upstream. If kmap fails, it leads to memory corruption. Fixes: f64122c1 ('drm: add new QXL driver. (v1.4)') Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20160711084633.GA31411@mwandaSigned-off-by:
-
Yadi.hu authored
commit 371a0153 upstream. the eg20t driver call request_irq() function before the pch_base_address, base address of i2c controller's register, is assigned an effective value. there is one possible scenario that an interrupt which isn't inside eg20t arrives immediately after request_irq() is executed when i2c controller shares an interrupt number with others. since the interrupt handler pch_i2c_handler() has already active as shared action, it will be called and read its own register to determine if this interrupt is from itself. At that moment, since base address of i2c registers is not remapped in kernel space yet,so the INT handler will access an illegal address and then a error occurs. Signed-off-by:
Yadi.hu <yadi.hu@windriver.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Jeff Mahoney authored
commit 325c50e3 upstream. If the subvol/snapshot create/destroy ioctls are passed a regular file with execute permissions set, we'll eventually Oops while trying to do inode->i_op->lookup via lookup_one_len. This patch ensures that the file descriptor refers to a directory. Fixes: cb8e7090 (Btrfs: Fix subvolume creation locking rules) Fixes: 76dda93c (Btrfs: add snapshot/subvolume destroy ioctl) Signed-off-by:
Chris Mason <clm@fb.com> Signed-off-by:
-
Fabio Estevam authored
commit 4de349e7 upstream. On a imx6ul-pico board the following error is seen during system suspend: dpm_run_callback(): platform_pm_resume+0x0/0x54 returns -110 PM: Device 2090000.flexcan failed to resume: error -110 The reason for this suspend error is because when the CAN interface is not active the clocks are disabled and then flexcan_chip_enable() will always fail due to a timeout error. In order to fix this issue, only call flexcan_chip_enable/disable() when the CAN interface is active. Based on a patch from Dong Aisheng in the NXP kernel. Signed-off-by:
Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by:
-
Steven Rostedt (Red Hat) authored
commit 1245800c upstream. The iter->seq can be reset outside the protection of the mutex. So can reading of user data. Move the mutex up to the beginning of the function. Fixes: d7350c3f ("tracing/core: make the read callbacks reentrants") Reported-by:
Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Al Viro authored
commit 1ae2293d upstream. Signed-off-by:
-
Dan Carpenter authored
commit 79ad07d4 upstream. There is a cut and paste issue here. The bug is that we are allocating more memory than necessary for msp_maps. We should be allocating enough space for a map_info struct (144 bytes) but we instead allocate enough for an mtd_info struct (1840 bytes). It's a small waste. The other part of this is not harmful but when we allocated msp_flash then we allocated enough space fro a map_info pointer instead of an mtd_info pointer. But since pointers are the same size it works out fine. Anyway, I decided to clean up all three allocations a bit to make them a bit more consistent and clear. Fixes: 68aa0fa8 ('[MTD] PMC MSP71xx flash/rootfs mappings') Signed-off-by:
-
Al Viro authored
commit e23d4159 upstream. Switching iov_iter fault-in to multipages variants has exposed an old bug in underlying fault_in_multipages_...(); they break if the range passed to them wraps around. Normally access_ok() done by callers will prevent such (and it's a guaranteed EFAULT - ERR_PTR() values fall into such a range and they should not point to any valid objects). However, on architectures where userland and kernel live in different MMU contexts (e.g. s390) access_ok() is a no-op and on those a range with a wraparound can reach fault_in_multipages_...(). Since any wraparound means EFAULT there, the fix is trivial - turn those while (uaddr <= end) ... into if (unlikely(uaddr > end)) return -EFAULT; do ... while (uaddr <= end); Reported-by:
Jan Stancek <jstancek@redhat.com> Tested-by:
-
Colin Ian King authored
commit b6acb0cf upstream. Fix indent warning when building with gcc 6: drivers/staging/iio/adc/ad7192.c:239:4: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation] Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Arnd Bergmann authored
commit 2cce76c3 upstream. gcc-6 warns about code in il3945_hw_txq_ctx_free() being somewhat ambiguous: drivers/net/wireless/intel/iwlegacy/3945.c:1022:5: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses] This adds a set of curly braces to avoid the warning. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Arnd Bergmann authored
commit 8e0cc8c3 upstream. gcc points out code that is not indented the way it is interpreted: net/caif/cfpkt_skbuff.c: In function 'cfpkt_setlen': net/caif/cfpkt_skbuff.c:289:4: error: statement is indented as if it were guarded by... [-Werror=misleading-indentation] return cfpkt_getlen(pkt); ^~~~~~ net/caif/cfpkt_skbuff.c:286:3: note: ...this 'else' clause, but it is not else ^~~~ It is clear from the context that not returning here would be a bug, as we'd end up passing a negative length into a function that takes a u16 length, so it is not missing curly braces here, and I'm assuming that the indentation is the only part that's wrong about it. Signed-off-by:
-
Steven Rostedt authored
commit 377ccbb4 upstream. With the latest gcc compilers, they give a warning if __builtin_return_address() parameter is greater than 0. That is because if it is used by a function called by a top level function (or in the case of the kernel, by assembly), it can try to access stack frames outside the stack and crash the system. The tracing system uses __builtin_return_address() of up to 2! But it is well aware of the dangers that it may have, and has even added precautions to protect against it (see the thunk code in arch/x86/entry/thunk*.S) Linus originally added KBUILD_CFLAGS that would suppress the warning for the entire kernel, as simply adding KBUILD_CFLAGS to the tracing directory wouldn't work. The tracing directory plays a bit with the CFLAGS and requires a little more logic. This adds that special logic to only suppress the warning for the tracing directory. If it is used anywhere else outside of tracing, the warning will still be triggered. Link: http://lkml.kernel.org/r/20160728223043.51996267@grimm.local.homeTested-by:
-
Linus Torvalds authored
commit 124a3d88 upstream. Newer versions of gcc warn about the use of __builtin_return_address() with a non-zero argument when "-Wall" is specified: kernel/trace/trace_irqsoff.c: In function ‘stop_critical_timings’: kernel/trace/trace_irqsoff.c:433:86: warning: calling ‘__builtin_return_address’ with a nonzero argument is unsafe [-Wframe-address] stop_critical_timing(CALLER_ADDR0, CALLER_ADDR1); [ .. repeats a few times for other similar cases .. ] It is true that a non-zero argument is somewhat dangerous, and we do not actually have very many uses of that in the kernel - but the ftrace code does use it, and as Stephen Rostedt says: "We are well aware of the danger of using __builtin_return_address() of > 0. In fact that's part of the reason for having the "thunk" code in x86 (See arch/x86/entry/thunk_{64,32}.S). [..] it adds extra frames when tracking irqs off sections, to prevent __builtin_return_address() from accessing bad areas. In fact the thunk_32.S states: 'Trampoline to trace irqs off. (otherwise CALLER_ADDR1 might crash)'." For now, __builtin_return_address() with a non-zero argument is the best we can do, and the warning is not helpful and can end up making people miss other warnings for real problems. So disable the frame-address warning on compilers that need it. Acked-by:
-
