aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* futex: Make lookup_pi_state more robustHEADmasterThomas Gleixner2015-12-061-28/+106
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 54a217887a7b658e2650c3feff22756ab80c7339 upstream. The current implementation of lookup_pi_state has ambigous handling of the TID value 0 in the user space futex. We can get into the kernel even if the TID value is 0, because either there is a stale waiters bit or the owner died bit is set or we are called from the requeue_pi path or from user space just for fun. The current code avoids an explicit sanity check for pid = 0 in case that kernel internal state (waiters) are found for the user space address. This can lead to state leakage and worse under some circumstances. Handle the cases explicit: Waiter | pi_state | pi->owner | uTID | uODIED | ? [1] NULL | --- | --- | 0 | 0/1 | Valid [2] NULL | --- | --- | >0 | 0/1 | Valid [3] Found | NULL | -- | Any | 0/1 | Invalid [4] Found | Found | NULL | 0 | 1 | Valid [5] Found | Found | NULL | >0 | 1 | Invalid [6] Found | Found | task | 0 | 1 | Valid [7] Found | Found | NULL | Any | 0 | Invalid [8] Found | Found | task | ==taskTID | 0/1 | Valid [9] Found | Found | task | 0 | 0 | Invalid [10] Found | Found | task | !=taskTID | 0/1 | Invalid [1] Indicates that the kernel can acquire the futex atomically. We came came here due to a stale FUTEX_WAITERS/FUTEX_OWNER_DIED bit. [2] Valid, if TID does not belong to a kernel thread. If no matching thread is found then it indicates that the owner TID has died. [3] Invalid. The waiter is queued on a non PI futex [4] Valid state after exit_robust_list(), which sets the user space value to FUTEX_WAITERS | FUTEX_OWNER_DIED. [5] The user space value got manipulated between exit_robust_list() and exit_pi_state_list() [6] Valid state after exit_pi_state_list() which sets the new owner in the pi_state but cannot access the user space value. [7] pi_state->owner can only be NULL when the OWNER_DIED bit is set. [8] Owner and user space value match [9] There is no transient state which sets the user space TID to 0 except exit_robust_list(), but this is indicated by the FUTEX_OWNER_DIED bit. See [4] [10] There is no transient state which leaves owner and user space TID out of sync. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Kees Cook <keescook@chromium.org> Cc: Will Drewry <wad@chromium.org> Cc: Darren Hart <dvhart@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Tested-by: Moritz Bandemer <replicant@posteo.mx>
* futex: Always cleanup owner tid in unlock_piThomas Gleixner2015-12-061-22/+18
| | | | | | | | | | | | | | | | | | | | | commit 13fbca4c6ecd96ec1a1cfa2e4f2ce191fe928a5e upstream. If the owner died bit is set at futex_unlock_pi, we currently do not cleanup the user space futex. So the owner TID of the current owner (the unlocker) persists. That's observable inconsistant state, especially when the ownership of the pi state got transferred. Clean it up unconditionally. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Kees Cook <keescook@chromium.org> Cc: Will Drewry <wad@chromium.org> Cc: Darren Hart <dvhart@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [steven@steven676.net: make apply to 3.0] Tested-by: Moritz Bandemer <replicant@posteo.mx>
* futex: Validate atomic acquisition in futex_lock_pi_atomic()Thomas Gleixner2015-12-061-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | commit b3eaa9fc5cd0a4d74b18f6b8dc617aeaf1873270 upstream. We need to protect the atomic acquisition in the kernel against rogue user space which sets the user space futex to 0, so the kernel side acquisition succeeds while there is existing state in the kernel associated to the real owner. Verify whether the futex has waiters associated with kernel state. If it has, return -EINVAL. The state is corrupted already, so no point in cleaning it up. Subsequent calls will fail as well. Not our problem. [ tglx: Use futex_top_waiter() and explain why we do not need to try restoring the already corrupted user space state. ] Signed-off-by: Darren Hart <dvhart@linux.intel.com> Cc: Kees Cook <keescook@chromium.org> Cc: Will Drewry <wad@chromium.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Tested-by: Moritz Bandemer <replicant@posteo.mx>
* futex: Prevent attaching to kernel threadsThomas Gleixner2015-12-061-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit f0d71b3dcb8332f7971b5f2363632573e6d9486a upstream. We happily allow userspace to declare a random kernel thread to be the owner of a user space PI futex. Found while analysing the fallout of Dave Jones syscall fuzzer. We also should validate the thread group for private futexes and find some fast way to validate whether the "alleged" owner has RW access on the file which backs the SHM, but that's a separate issue. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Dave Jones <davej@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Darren Hart <darren@dvhart.com> Cc: Davidlohr Bueso <davidlohr@hp.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Clark Williams <williams@redhat.com> Cc: Paul McKenney <paulmck@linux.vnet.ibm.com> Cc: Lai Jiangshan <laijs@cn.fujitsu.com> Cc: Roland McGrath <roland@hack.frob.com> Cc: Carlos ODonell <carlos@redhat.com> Cc: Jakub Jelinek <jakub@redhat.com> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Link: http://lkml.kernel.org/r/20140512201701.194824402@linutronix.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Tested-by: Moritz Bandemer <replicant@posteo.mx>
* futex: Add another early deadlock detection checkThomas Gleixner2015-12-061-12/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 866293ee54227584ffcb4a42f69c1f365974ba7f upstream. Dave Jones trinity syscall fuzzer exposed an issue in the deadlock detection code of rtmutex: http://lkml.kernel.org/r/20140429151655.GA14277@redhat.com That underlying issue has been fixed with a patch to the rtmutex code, but the futex code must not call into rtmutex in that case because - it can detect that issue early - it avoids a different and more complex fixup for backing out If the user space variable got manipulated to 0x80000000 which means no lock holder, but the waiters bit set and an active pi_state in the kernel is found we can figure out the recursive locking issue by looking at the pi_state owner. If that is the current task, then we can safely return -EDEADLK. The check should have been added in commit 59fa624 (futex: Handle futex_pi OWNER_DIED take over correctly) already, but I did not see the above issue caused by user space manipulation back then. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Dave Jones <davej@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Darren Hart <darren@dvhart.com> Cc: Davidlohr Bueso <davidlohr@hp.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Clark Williams <williams@redhat.com> Cc: Paul McKenney <paulmck@linux.vnet.ibm.com> Cc: Lai Jiangshan <laijs@cn.fujitsu.com> Cc: Roland McGrath <roland@hack.frob.com> Cc: Carlos ODonell <carlos@redhat.com> Cc: Jakub Jelinek <jakub@redhat.com> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Link: http://lkml.kernel.org/r/20140512201701.097349971@linutronix.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Tested-by: Moritz Bandemer <replicant@posteo.mx>
* ARM: 7527/1: uaccess: explicitly check __user pointer when !CPU_USE_DOMAINSRussell King2015-12-064-21/+56
| | | | | | | | | | | | | | | | | | | | | | | commit 8404663 upstream. The {get,put}_user macros don't perform range checking on the provided __user address when !CPU_HAS_DOMAINS. This patch reworks the out-of-line assembly accessors to check the user address against a specified limit, returning -EFAULT if is is out of range. [will: changed get_user register allocation to match put_user] [rmk: fixed building on older ARM architectures] Reported-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> [bwh: Backported to 3.2: TUSER() was called T()] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> [steven@steven676.net: make apply to 3.0] Tested-by: Moritz Bandemer <replicant@posteo.mx>
* Merge branch 'master' of fossencdi.org:kernel_samsung_smdk4412Wolfgang Wiedmeyer2015-12-06451-2422/+214996
|\
| * Merge remote-tracking branch 'github/cm-11.0'Wolfgang Wiedmeyer2015-10-22451-2422/+214996
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: firmware/Makefile firmware/epen/W9001_B713.bin.ihex firmware/epen/W9001_B746.bin.ihex firmware/epen/W9001_B746JD.bin.ihex firmware/epen/W9001_B746L.bin.ihex firmware/epen/W9001_B746S.bin.ihex
| | * Add a new device: sc02c1732102015-04-131-0/+3177
| | | | | | | | | | | | Change-Id: I170fbc042c3dcc8b9132f2c0c78619f8bbebb60c
| | * mach-u1.c: Fix a compile bug1732102015-04-131-3/+1
| | | | | | | | | | | | Change-Id: I7832308a6381c6d23365751b93960dfafebb268c
| | * smdk4412: update exynos ionsbrissen2015-03-161-0/+6
| | | | | | | | | | | | | | | | | | Taken from GT-N7100_SEA_KK_Opensource Change-Id: Ieb6da81ab9472c8e0a8114138b96b727b5f24fc7
| | * bcmdhd wireless: Fix sprintf/sscanf format strings.Christian Neumüller2015-03-115-55/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | %X is int. This is too wide for the chars used there, so use %hhx instead. Avoid undefined pointer casts from char* to unsigned int* in sscanf calls. Also use the already defined MACF and update it with %hhx instead of typing this long format string all over again. Add MACF_U which is the same as MACF but with uppercase hex (%hhX instead of %hhx). Change-Id: Idd2465e0d05bca9b05566abeec05a5ad59a577ad
| | * bcmdhd wireless: Fix more off by one errors.Christian Neumüller2015-03-111-13/+13
| | | | | | | | | | | | | | | | | | | | | These were not detected by the stack protector, either because the functions where not called or because the corruption hits a local variable. Change-Id: I385c81b133ee09c28df56597df3fb25d9c063f43
| | * bcmdhd wireless: Fix off by one in initialization.Christian Neumüller2015-03-101-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An sprintf in dhd_write_macaddr wrote a rogue null byte after the buffer. Found with CONFIG_CC_STACKPROTECTOR=y (idea of Lanchon at XDA Developers [1]). [1]: http://forum.xda-developers.com/showthread.php?p=55306602 Panic, on a Samsung Galaxy S2 i9100, was: <0>[ 26.412257] c1 Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: bf013a2c <0>[ 26.412315] c1 <4>[ 26.412334] c1 Backtrace: <4>[ 26.412382] c1 [<c064e5b8>] (dump_backtrace+0x0/0x10c) from [<c0b91e6c>] (dump_stack+0x18/0x1c) <4>[ 26.412439] c1 r6:e211e820 r5:c0ed4760 r4:c0f5c940 r3:271aed5c <4>[ 26.412496] c1 [<c0b91e54>] (dump_stack+0x0/0x1c) from [<c0b92204>] (panic+0x80/0x1ac) <4>[ 26.412561] c1 [<c0b92184>] (panic+0x0/0x1ac) from [<c0684be0>] (init_oops_id+0x0/0x58) <4>[ 26.412613] c1 r3:271aed5c r2:271aed00 r1:bf013a2c r0:c0cb8880 <4>[ 26.412663] c1 r7:e273bc32 <4>[ 26.412742] c1 [<c0684bc4>] (__stack_chk_fail+0x0/0x1c) from [<bf013a2c>] (dhd_write_macaddr+0x2e4/0x310 [dhd]) <4>[ 26.412864] c1 [<bf013748>] (dhd_write_macaddr+0x0/0x310 [dhd]) from [<bf01a554>] (dhd_bus_start+0x1a4/0x2e0 [dhd]) <4>[ 26.412985] c1 [<bf01a3b0>] (dhd_bus_start+0x0/0x2e0 [dhd]) from [<bf020558>] (dhdsdio_probe+0x4a4/0x72c [dhd]) <4>[ 26.413097] c1 [<bf0200b4>] (dhdsdio_probe+0x0/0x72c [dhd]) from [<bf00c0ec>] (bcmsdh_probe+0xf8/0x150 [dhd]) <4>[ 26.413206] c1 [<bf00bff4>] (bcmsdh_probe+0x0/0x150 [dhd]) from [<bf00e038>] (bcmsdh_sdmmc_probe+0x54/0xbc [dhd]) <4>[ 26.413304] c1 [<bf00dfe4>] (bcmsdh_sdmmc_probe+0x0/0xbc [dhd]) from [<c09a7fe8>] (sdio_bus_probe+0xfc/0x108) <4>[ 26.413368] c1 r5:e2d97000 r4:e2d97008 <4>[ 26.413414] c1 [<c09a7eec>] (sdio_bus_probe+0x0/0x108) from [<c0896764>] (driver_probe_device+0x94/0x1a8) <4>[ 26.413474] c1 r8:00000000 r7:bf067414 r6:e2d9703c r5:c0f6ddb8 r4:e2d97008 <4>[ 26.413531] c1 r3:c09a7eec <4>[ 26.413563] c1 [<c08966d0>] (driver_probe_device+0x0/0x1a8) from [<c089690c>] (__driver_attach+0x94/0x98) <4>[ 26.413624] c1 r7:e2e631e0 r6:e2d9703c r5:bf067414 r4:e2d97008 <4>[ 26.413683] c1 [<c0896878>] (__driver_attach+0x0/0x98) from [<c0895678>] (bus_for_each_dev+0x4c/0x94) <4>[ 26.413742] c1 r6:c0896878 r5:bf067414 r4:00000000 r3:c0896878 <4>[ 26.413799] c1 [<c089562c>] (bus_for_each_dev+0x0/0x94) from [<c0896428>] (driver_attach+0x24/0x28) <4>[ 26.413857] c1 r6:c0f02af0 r5:bf067414 r4:bf067414 <4>[ 26.413904] c1 [<c0896404>] (driver_attach+0x0/0x28) from [<c08960c8>] (bus_add_driver+0x180/0x250) <4>[ 26.413970] c1 [<c0895f48>] (bus_add_driver+0x0/0x250) from [<c0896e14>] (driver_register+0x80/0x150) <4>[ 26.414037] c1 [<c0896d94>] (driver_register+0x0/0x150) from [<c09a8128>] (sdio_register_driver+0x2c/0x30) <4>[ 26.414131] c1 [<c09a80fc>] (sdio_register_driver+0x0/0x30) from [<bf00e250>] (sdio_function_init+0x3c/0x8c [dhd]) <4>[ 26.414244] c1 [<bf00e214>] (sdio_function_init+0x0/0x8c [dhd]) from [<bf00c19c>] (bcmsdh_register+0x1c/0x24 [dhd]) <4>[ 26.414311] c1 r5:00000004 r4:bf06a3c4 <4>[ 26.414398] c1 [<bf00c180>] (bcmsdh_register+0x0/0x24 [dhd]) from [<bf027990>] (dhd_bus_register+0x24/0x48 [dhd]) <4>[ 26.414515] c1 [<bf02796c>] (dhd_bus_register+0x0/0x48 [dhd]) from [<bf07618c>] (init_module+0x18c/0x284 [dhd]) <4>[ 26.414610] c1 [<bf076000>] (init_module+0x0/0x284 [dhd]) from [<c06448f8>] (do_one_initcall+0x128/0x1a8) <4>[ 26.414683] c1 [<c06447d0>] (do_one_initcall+0x0/0x1a8) from [<c06b9710>] (sys_init_module+0xdf8/0x1b1c) <4>[ 26.414756] c1 [<c06b8918>] (sys_init_module+0x0/0x1b1c) from [<c064a8c0>] (ret_fast_syscall+0x0/0x30) <2>[ 26.414861] c0 CPU0: stopping <4>[ 26.414886] c0 Backtrace: <4>[ 26.414920] c0 [<c064e5b8>] (dump_backtrace+0x0/0x10c) from [<c0b91e6c>] (dump_stack+0x18/0x1c) <4>[ 26.414977] c0 r6:c0d54000 r5:c0eb5d08 r4:00000006 r3:271aed5c <4>[ 26.415039] c0 [<c0b91e54>] (dump_stack+0x0/0x1c) from [<c06444bc>] (do_IPI+0x258/0x29c) <4>[ 26.415102] c0 [<c0644264>] (do_IPI+0x0/0x29c) from [<c064a340>] (__irq_svc+0x80/0x130) <4>[ 26.415156] c0 Exception stack(0xc0d55ef0 to 0xc0d55f38) <4>[ 26.415197] c0 5ee0: 3b9ac9ff 540deacd 01c99e53 00072679 <4>[ 26.415258] c0 5f00: c0f5a468 00000000 c0d54000 00000000 c1b540a8 412fc091 00000000 c0d55f64 <4>[ 26.415317] c0 5f20: 540deacd c0d55f38 c06aa768 c065bd78 20000013 ffffffff <4>[ 26.415380] c0 [<c065bd3c>] (exynos4_enter_idle+0x0/0x174) from [<c099a890>] (cpuidle_idle_call+0xa4/0x120) <4>[ 26.415442] c0 r7:00000000 r6:00000001 r5:c0f815ac r4:c1b540b8 <4>[ 26.415498] c0 [<c099a7ec>] (cpuidle_idle_call+0x0/0x120) from [<c064bd40>] (cpu_idle+0xc4/0x100) <4>[ 26.415554] c0 r8:4000406a r7:c0ba09a8 r6:c0f59ec4 r5:c0ebd8c4 r4:c0d54000 <4>[ 26.415610] c0 r3:c099a7ec <4>[ 26.415641] c0 [<c064bc7c>] (cpu_idle+0x0/0x100) from [<c0b83238>] (rest_init+0x8c/0xa4) <4>[ 26.415694] c0 r7:c1b51180 r6:c0f59e00 r5:00000002 r4:c0d54000 <4>[ 26.415752] c0 [<c0b831ac>] (rest_init+0x0/0xa4) from [<c00089c4>] (start_kernel+0x2dc/0x330) <4>[ 26.415807] c0 r5:c063d944 r4:c0eb5d34 <4>[ 26.415845] c0 [<c00086e8>] (start_kernel+0x0/0x330) from [<40008044>] (0x40008044) Change-Id: Iaa907383e196fdf787ae4660977b58de79212de1
| | * ARM: Exynos: Call cpu_pm_enter/exit in Low Power States.Christian Neumüller2014-12-301-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In low power cpuidle states, the FPU registers get corrupted. By calling cpu_pm_enter, the VFP module gets notified so that it saves the FPU state and restores it from RAM the next time a thread uses it. The comments at cpu_pm_enter/exit indicate that these functions must be called with interrupts disabled, so place the calls between local_irq_disable/local_irq_enble. See http://forum.xda-developers.com/showthread.php?p=57637134 to http://forum.xda-developers.com/showthread.php?p=57643086. Change-Id: Icde0ab93734cf2a4febfabc3c04e77ce955bd9da
| | * ARM: gic: Use cpu pm notifiers to save gic stateColin Cross2014-12-301-0/+187
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the cpu is powered down in a low power mode, the gic cpu interface may be reset, and when the cpu cluster is powered down, the gic distributor may also be reset. This patch uses CPU_PM_ENTER and CPU_PM_EXIT notifiers to save and restore the gic cpu interface registers, and the CPU_CLUSTER_PM_ENTER and CPU_CLUSTER_PM_EXIT notifiers to save and restore the gic distributor registers. Merge note: Samsung had already applied the changes to struct gic_chip_data, although it still remains in the .c file instead of having been moved to the header. Original-author: Gary King <gking@nvidia.com> Signed-off-by: Colin Cross <ccross@android.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Tested-and-Acked-by: Shawn Guo <shawn.guo@linaro.org> Tested-by: Vishwanath BS <vishwanath.bs@ti.com> Conflicts: arch/arm/include/asm/hardware/gic.h Change-Id: I50b5cdd161637ff7b871ac5ffb30d669ec60c662
| | * ARM: Enable CPU_PM notifiers on ARM machines.Santosh Shilimkar2014-12-301-0/+1
| | | | | | | | | | | | | | | | | | | | | Change-Id: Ifecfa0399e7fca47c43e4f24225448d6ff3780f4 Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Tested-and-Acked-by: Shawn Guo <shawn.guo@linaro.org> Tested-by: Vishwanath BS <vishwanath.bs@ti.com>
| | * kernel/cpu_pm.c: fix various typosNicolas Pitre2014-12-301-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | Change-Id: I9a623e3c087f0569b0b2443bf59d2997da5b340c Signed-off-by: Nicolas Pitre <nico@linaro.org> Acked-by: Colin Cross <ccross@android.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| | * cpu_pm: call notifiers during suspendColin Cross2014-12-301-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implements syscore_ops in cpu_pm to call the cpu and cpu cluster notifiers during suspend and resume, allowing drivers receiving the notifications to avoid implementing syscore_ops. Change-Id: I82b1a1e4464b8250a547f23999151c8a09ca4e22 Signed-off-by: Colin Cross <ccross@android.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> Tested-and-Acked-by: Shawn Guo <shawn.guo@linaro.org> Tested-by: Vishwanath BS <vishwanath.bs@ti.com>
| | * ARM: 7873/1: vfp: clear vfp_current_hw_state for dying cpuYuanyuan Zhong2014-12-301-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The CPU_DYING notifier is called by cpu stopper task which does not own the context held in the VFP hardware. Calling vfp_force_reload() has no effect. Replace it with clearing vfp_current_hw_state. Change-Id: If6ea6b94e04dc4588c5bf2ec0fad4d0dcc49ffd6 Signed-off-by: Yuanyuan Zhong <zyy@motorola.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Lanchon <lanchon@gmail.com>
| | * ARM: 7419/1: vfp: fix VFP flushing regression on sigreturn pathWill Deacon2014-12-301-12/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit ff9a184c ("ARM: 7400/1: vfp: clear fpscr length and stride bits on entry to sig handler") flushes the VFP state prior to entering a signal handler so that a VFP operation inside the handler will trap and force a restore of ABI-compliant registers. Reflushing and disabling VFP on the sigreturn path is predicated on the saved thread state indicating that VFP was used by the handler -- however for SMP platforms this is only set on context-switch, making the check unreliable and causing VFP register corruption in userspace since the register values are not necessarily those restored from the sigframe. This patch unconditionally flushes the VFP state after a signal handler. Since we already perform the flush before the handler and the flushing itself happens lazily, the redundant flush when VFP is not used by the handler is essentially a nop. Change-Id: Ia9ec6384fae3281def1dc93914af336857a09949 Reported-by: Jon Medhurst <tixy@linaro.org> Signed-off-by: Jon Medhurst <tixy@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Lanchon <lanchon@gmail.com>
| | * ARM: 7400/1: vfp: clear fpscr length and stride bits on entry to sig handlerWill Deacon2014-12-301-1/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ARM PCS mandates that the length and stride bits of the fpscr are cleared on entry to and return from a public interface. Although signal handlers run asynchronously with respect to the interrupted function, the handler itself expects to run as though it has been called like a normal function. This patch updates the state mirroring the VFP hardware before entry to a signal handler so that it adheres to the PCS. Furthermore, we disable VFP to ensure that we trap on any floating point operation performed by the signal handler and synchronise the hardware appropriately. A check is inserted after the signal handler to avoid redundant flushing if VFP was not used. Change-Id: Ic16296179773f609e2768c89756a0abece1a3247 Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Lanchon <lanchon@gmail.com>
| | * ARM: 7399/1: vfp: move user vfp state save/restore code out of signal.cWill Deacon2014-12-303-51/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The user VFP state must be preserved (subject to ucontext modifications) across invocation of a signal handler and this is currently handled by vfp_{preserve,restore}_context in signal.c Since this code requires intimate low-level knowledge of the VFP state, this patch moves it into vfpmodule.c. Change-Id: Ib82f326e7815d139b696d1db6a357769b449c1f3 Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Lanchon <lanchon@gmail.com>
| | * cpu_pm: Add cpu power management notifiersColin Cross2014-12-304-0/+314
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During some CPU power modes entered during idle, hotplug and suspend, peripherals located in the CPU power domain, such as the GIC, localtimers, and VFP, may be powered down. Add a notifier chain that allows drivers for those peripherals to be notified before and after they may be reset. Notified drivers can include VFP co-processor, interrupt controller and it's PM extensions, local CPU timers context save/restore which shouldn't be interrupted. Hence CPU PM event APIs must be called with interrupts disabled. Change-Id: I2918473962a75cd55c148f91a3c09a773c99162c Signed-off-by: Colin Cross <ccross@android.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> Tested-and-Acked-by: Shawn Guo <shawn.guo@linaro.org> Tested-by: Kevin Hilman <khilman@ti.com> Tested-by: Vishwanath BS <vishwanath.bs@ti.com> Signed-off-by: Lanchon <lanchon@gmail.com>
| | * ARM: vfp: Use cpu pm notifiers to save vfp stateColin Cross2014-12-301-8/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the cpu is powered down in a low power mode, the vfp registers may be reset. This patch uses CPU_PM_ENTER and CPU_PM_EXIT notifiers to save and restore the cpu's vfp registers. Change-Id: I805e18a5b705202f63748136c2608ce80d2d5f20 Signed-off-by: Colin Cross <ccross@android.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> Tested-and-Acked-by: Shawn Guo <shawn.guo@linaro.org> Tested-by: Vishwanath BS <vishwanath.bs@ti.com> Signed-off-by: Lanchon <lanchon@gmail.com>
| | * ARM: vfp: ensure that thread flushing works if preemptedRussell King2014-12-301-10/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prevent a preemption event causing the initialized VFP state being overwritten by ensuring that the VFP hardware access is disabled prior to starting initialization. We can then do this in safety while still allowing preemption to occur. Change-Id: I93922d95f641aa989b2acefe009a656e27d4d9bf Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Lanchon <lanchon@gmail.com>
| | * ARM: vfp: fix a hole in VFP thread migrationRussell King2014-12-303-55/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix a hole in the VFP thread migration. Lets define two threads. Thread 1, we'll call 'interesting_thread' which is a thread which is running on CPU0, using VFP (so vfp_current_hw_state[0] = &interesting_thread->vfpstate) and gets migrated off to CPU1, where it continues execution of VFP instructions. Thread 2, we'll call 'new_cpu0_thread' which is the thread which takes over on CPU0. This has also been using VFP, and last used VFP on CPU0, but doesn't use it again. The following code will be executed twice: cpu = thread->cpu; /* * On SMP, if VFP is enabled, save the old state in * case the thread migrates to a different CPU. The * restoring is done lazily. */ if ((fpexc & FPEXC_EN) && vfp_current_hw_state[cpu]) { vfp_save_state(vfp_current_hw_state[cpu], fpexc); vfp_current_hw_state[cpu]->hard.cpu = cpu; } /* * Thread migration, just force the reloading of the * state on the new CPU in case the VFP registers * contain stale data. */ if (thread->vfpstate.hard.cpu != cpu) vfp_current_hw_state[cpu] = NULL; The first execution will be on CPU0 to switch away from 'interesting_thread'. interesting_thread->cpu will be 0. So, vfp_current_hw_state[0] points at interesting_thread->vfpstate. The hardware state will be saved, along with the CPU number (0) that it was executing on. 'thread' will be 'new_cpu0_thread' with new_cpu0_thread->cpu = 0. Also, because it was executing on CPU0, new_cpu0_thread->vfpstate.hard.cpu = 0, and so the thread migration check is not triggered. This means that vfp_current_hw_state[0] remains pointing at interesting_thread. The second execution will be on CPU1 to switch _to_ 'interesting_thread'. So, 'thread' will be 'interesting_thread' and interesting_thread->cpu now will be 1. The previous thread executing on CPU1 is not relevant to this so we shall ignore that. We get to the thread migration check. Here, we discover that interesting_thread->vfpstate.hard.cpu = 0, yet interesting_thread->cpu is now 1, indicating thread migration. We set vfp_current_hw_state[1] to NULL. So, at this point vfp_current_hw_state[] contains the following: [0] = &interesting_thread->vfpstate [1] = NULL Our interesting thread now executes a VFP instruction, takes a fault which loads the state into the VFP hardware. Now, through the assembly we now have: [0] = &interesting_thread->vfpstate [1] = &interesting_thread->vfpstate CPU1 stops due to ptrace (and so saves its VFP state) using the thread switch code above), and CPU0 calls vfp_sync_hwstate(). if (vfp_current_hw_state[cpu] == &thread->vfpstate) { vfp_save_state(&thread->vfpstate, fpexc | FPEXC_EN); BANG, we corrupt interesting_thread's VFP state by overwriting the more up-to-date state saved by CPU1 with the old VFP state from CPU0. Fix this by ensuring that we have sane semantics for the various state describing variables: 1. vfp_current_hw_state[] points to the current owner of the context information stored in each CPUs hardware, or NULL if that state information is invalid. 2. thread->vfpstate.hard.cpu always contains the most recent CPU number which the state was loaded into or NR_CPUS if no CPU owns the state. So, for a particular CPU to be a valid owner of the VFP state for a particular thread t, two things must be true: vfp_current_hw_state[cpu] == &t->vfpstate && t->vfpstate.hard.cpu == cpu. and that is valid from the moment a CPU loads the saved VFP context into the hardware. This gives clear and consistent semantics to interpreting these variables. This patch also fixes thread copying, ensuring that t->vfpstate.hard.cpu is invalidated, otherwise CPU0 may believe it was the last owner. The hole can happen thus: - thread1 runs on CPU2 using VFP, migrates to CPU3, exits and thread_info freed. - New thread allocated from a previously running thread on CPU2, reusing memory for thread1 and copying vfp.hard.cpu. At this point, the following are true: new_thread1->vfpstate.hard.cpu == 2 &new_thread1->vfpstate == vfp_current_hw_state[2] Lastly, this also addresses thread flushing in a similar way to thread copying. Hole is: - thread runs on CPU0, using VFP, migrates to CPU1 but does not use VFP. - thread calls execve(), so thread flush happens, leaving vfp_current_hw_state[0] intact. This vfpstate is memset to 0 causing thread->vfpstate.hard.cpu = 0. - thread migrates back to CPU0 before using VFP. At this point, the following are true: thread->vfpstate.hard.cpu == 0 &thread->vfpstate == vfp_current_hw_state[0] Change-Id: Ifd268aa2499217ad0abd25cb0905b80bc5057229 Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Lanchon <lanchon@gmail.com>
| | * otg: when removing ED from readyQ also set flagLeon Winter2014-11-031-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The driver keeps track of the "is this endpoint in the list" state with the redundant flag ".is_in_transfer_ready_q". It should therefore always be sync with the .next and .prev of the readyq_list list: struct ed *ed; otg_list_head *qlist = (typeof qlist) ed->readyq_list; (qlist->prev == LIST_POISON2 || qlist->next == LIST_POISON1) == !ed->ed_status.is_in_transfer_ready_q; Should both properties be not in sync, bad things can happen. All code paths in driver rely on the flag and then call list operations. If the flag suggests the entry is in the list, otg_list_pop () will be called. When the entry however is not in the list, the members .prev and .next are poisoned and an attempt to do list operations on them results into a NULL (or rather an invalid address which is the poison) pointer dereference. Such a fault would then trigger a kernel panic and the device rebooting. In real life this happens when disconnecting USB devices frequently, especially when in operation (transfering data while detaching). While in most positions in the code, it was taken care to keep both properties, the flag and the list entry state, consistent, one position was left out, which is addressed with this patch. Extensive testing shows that the device would crash easily and in a reproducable manner without the patch but does not show any faults with the patch applied. Change-Id: I80f3a8e7d866c699ddcd1c61b04d956e39d2197c
| | * samsung_battery: Attemp to fix LPM (off charging mode) with KitKat bootloaderKetut Putu Kumajaya2014-09-261-3/+15
| | | | | | | | | | | | Change-Id: Icbc7f7b0d6e52485eadc2d801224e01eaffe29e1
| | * s3cfb_ops: Attempt to fix LPM (off charging mode) graphics issueKetut Putu Kumajaya2014-09-261-0/+13
| | | | | | | | | | | | Change-Id: I4af44a979e5ab3b9d29888ce178ea9c0f71432b3
| | * Fix kernel build errors for GT-N7000huangyuxuan012014-08-281-16/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | defconfig: cyanogenmod_n7000_defconfig Fix two mali400 drivers compile together Use mali400 r3p2 driver,disabled mali r3p1 driver. Change-Id: Ia6c4290414b3f97f57b38da41dae6107c4d9c657
| | * cpuidle-exynos4: calm down some logspamDan Pasanen2014-08-161-2/+2
| | | | | | | | | | | | | | | | | | | | | * noticed these CONSTANTLY flooding the log with screen off using wireless adb (so it was unplugged) Change-Id: I4df4f0da9f62cfd86552b77c71d4a2de11dac5d4
| | * d710: enable r3p1 mali drivers and autoregen defconfigDorian Snyder2014-08-041-9/+39
| | | | | | | | | | | | Change-Id: I08dc1617e3f77b63a4eee45f78abbb989a5276f4
| | * mali: add r3p1 for devices that need itDorian Snyder2014-08-04180-0/+34683
| | | | | | | | | | | | | | | | | | d710 needs to use old mali drivers due to new ones causing signal to be completely killed Change-Id: I450c356b50e3f3521a63717a1c241e3b818b936f
| | * mach-exynos: cpufreq: Show list of available frequenciesDonggeun Kim2014-07-231-1/+22
| | | | | | | | | | | | | | | | | | | | | This patch enables 'scaling_available_frequencies' attribute showing list of available frequencies. Change-Id: I9b6ad786ffaaba8ad6fe5aa9045fd793c095b5ae
| | * smdk4412: fix kona bootloopsbrissen2014-07-111-0/+2
| | | | | | | | | | | | Change-Id: I21c2828a547f8387dada2e6393d92fe115e2491f
| | * smdk4412: fix buildJorge Ruesga2014-07-101-2/+2
| | | | | | | | | | | | | | | Change-Id: I3b9e6cee7343c9dd3a7ae68694e60991047db50d Signed-off-by: Jorge Ruesga <jorge@ruesga.com>
| | * Merge "smdk4412: update mali driver" into cm-11.0sbrissen2014-07-094-5/+10
| | |\
| | | * smdk4412: update mali driversbrissen2014-06-244-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | from GT-N7100_SEA_KK_Opensource Change-Id: I1ddaa2c88660427348f359a6477aced196c4d7dc
| | * | d710: build stage2 initramfs into kernelDorian Snyder2014-06-264-36/+4
| | |/ | | | | | | | | | Change-Id: I2c3f9dee52cd1241eb576a73893f8d8cf55bbe76
| | * Fix CVE-2014-3153Thomas Gleixner2014-06-161-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | futex-prevent-requeue-pi-on-same-futex.patch futex: Forbid uaddr == uaddr2 in futex_requeue(..., requeue_pi=1) If uaddr == uaddr2, then we have broken the rule of only requeueing from a non-pi futex to a pi futex with this call. If we attempt this, then dangling pointers may be left for rt_waiter resulting in an exploitable condition. This change brings futex_requeue() in line with futex_wait_requeue_pi() which performs the same check as per commit 6f7b0a2a5c0f ("futex: Forbid uaddr == uaddr2 in futex_wait_requeue_pi()") [ tglx: Compare the resulting keys as well, as uaddrs might be different depending on the mapping ] Change-Id: Ibe6195215657c86bf2e39305656fdacf7230389d Reported-by: Pinkie Pie Signed-off-by: Will Drewry <wad@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Darren Hart <dvhart@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| | * Merge "synaptics_s7301: add disabling keypad" into cm-11.0sbrissen2014-06-023-13/+52
| | |\
| | | * synaptics_s7301: add disabling keypadsbrissen2014-03-263-13/+52
| | | | | | | | | | | | | | | | Change-Id: I5af258d2245024918f08a1a7c93c6efcc4d177b3
| | * | Merge "smdk4412: cypress-touchkey - add keydisabler" into cm-11.0sbrissen2014-06-022-0/+42
| | |\ \
| | | * | smdk4412: cypress-touchkey - add keydisablersbrissen2014-03-282-0/+42
| | | |/ | | | | | | | | | | | | Change-Id: I85efd4c5b2d6a7283c430f5eca2a730ef6b03d18
| | * | n_tty: Fix n_tty_write crash when echoing in raw modePeter Hurley2014-05-131-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The tty atomic_write_lock does not provide an exclusion guarantee for the tty driver if the termios settings are LECHO & !OPOST. And since it is unexpected and not allowed to call TTY buffer helpers like tty_insert_flip_string concurrently, this may lead to crashes when concurrect writers call pty_write. In that case the following two writers: * the ECHOing from a workqueue and * pty_write from the process race and can overflow the corresponding TTY buffer like follows. If we look into tty_insert_flip_string_fixed_flag, there is: int space = __tty_buffer_request_room(port, goal, flags); struct tty_buffer *tb = port->buf.tail; ... memcpy(char_buf_ptr(tb, tb->used), chars, space); ... tb->used += space; so the race of the two can result in something like this: A B __tty_buffer_request_room __tty_buffer_request_room memcpy(buf(tb->used), ...) tb->used += space; memcpy(buf(tb->used), ...) ->BOOM B's memcpy is past the tty_buffer due to the previous A's tb->used increment. Since the N_TTY line discipline input processing can output concurrently with a tty write, obtain the N_TTY ldisc output_lock to serialize echo output with normal tty writes. This ensures the tty buffer helper tty_insert_flip_string is not called concurrently and everything is fine. Note that this is nicely reproducible by an ordinary user using forkpty and some setup around that (raw termios + ECHO). And it is present in kernels at least after commit d945cb9cce20ac7143c2de8d88b187f62db99bdc (pty: Rework the pty layer to use the normal buffering logic) in 2.6.31-rc3. js: add more info to the commit log js: switch to bool js: lock unconditionally js: lock only the tty->ops->write call References: CVE-2014-0196 Reported-and-tested-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [bwh: Backported to 3.4: output_lock is a member of struct tty_struct] Change-Id: I11d1685056e18f107c970fbe2cab5176ca3a91c4
| | * | mc1n2: Allow swapping of microphone ADC channelsAndrew Dodd2014-05-122-2/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The SGH-I777 libaudio has the configuration for ADC0[0] and ADC0[1] swapped. When using GT-I9100 libaudio, this results in the microphones being improperly swapped between the main mic and the NR mic near the earpiece. This patch allows the mic channels to be swapped within the driver to deal with incompatible libaudio. It is configurable via CONFIG_SND_SOC_MC1N2_MIC_ADC_SWAP in the defconfig in case the SGH-I777 libaudio becomes available. Change-Id: Id5738369f3614c6ccf710ac02ae96ee65eb4398b
| | * | smdk4412: update sound soc and codecsmarkcs2014-04-2870-645/+78620
| | | | | | | | | | | | | | | | | | | | | | | | Includes updated kernel source from i9305 Change-Id: I91ae18b30d02de037701250c46a457d035da56e1
| | * | dm crypt: optionally support discard requestsMilan Broz2014-04-042-5/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add optional parameter field to dmcrypt table and support "allow_discards" option. Discard requests bypass crypt queue processing. Bio is simple remapped to underlying device. Note that discard will be never enabled by default because of security consequences. It is up to the administrator to enable it for encrypted devices. (Note that userspace cryptsetup does not understand new optional parameters yet. Support for this will come later. Until then, you should use 'dmsetup' to enable and disable this.) Signed-off-by: Milan Broz <mbroz@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com>
| | * | dm table: share target argument parsing functionsMike Snitzer2014-04-044-112/+147
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move multipath target argument parsing code into dm-table so other targets can share it. Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com>
generated by cgit v1.1 at 2024-04-25 17:14:07 +0000