| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Change-Id: Icbc7f7b0d6e52485eadc2d801224e01eaffe29e1
|
|
|
|
| |
Change-Id: I4af44a979e5ab3b9d29888ce178ea9c0f71432b3
|
|
|
|
|
|
|
|
|
| |
defconfig: cyanogenmod_n7000_defconfig
Fix two mali400 drivers compile together
Use mali400 r3p2 driver,disabled mali r3p1 driver.
Change-Id: Ia6c4290414b3f97f57b38da41dae6107c4d9c657
|
|
|
|
|
|
|
| |
* noticed these CONSTANTLY flooding the log with screen off
using wireless adb (so it was unplugged)
Change-Id: I4df4f0da9f62cfd86552b77c71d4a2de11dac5d4
|
|
|
|
| |
Change-Id: I08dc1617e3f77b63a4eee45f78abbb989a5276f4
|
|
|
|
|
|
| |
d710 needs to use old mali drivers due to new ones causing signal to be completely killed
Change-Id: I450c356b50e3f3521a63717a1c241e3b818b936f
|
|
|
|
|
|
|
| |
This patch enables 'scaling_available_frequencies' attribute
showing list of available frequencies.
Change-Id: I9b6ad786ffaaba8ad6fe5aa9045fd793c095b5ae
|
|
|
|
| |
Change-Id: I21c2828a547f8387dada2e6393d92fe115e2491f
|
|
|
|
|
| |
Change-Id: I3b9e6cee7343c9dd3a7ae68694e60991047db50d
Signed-off-by: Jorge Ruesga <jorge@ruesga.com>
|
|\ |
|
| |
| |
| |
| |
| |
| | |
from GT-N7100_SEA_KK_Opensource
Change-Id: I1ddaa2c88660427348f359a6477aced196c4d7dc
|
|/
|
|
| |
Change-Id: I2c3f9dee52cd1241eb576a73893f8d8cf55bbe76
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|\ |
|
| |
| |
| |
| | |
Change-Id: I5af258d2245024918f08a1a7c93c6efcc4d177b3
|
|\ \ |
|
| |/
| |
| |
| | |
Change-Id: I85efd4c5b2d6a7283c430f5eca2a730ef6b03d18
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| |
| | |
Includes updated kernel source from i9305
Change-Id: I91ae18b30d02de037701250c46a457d035da56e1
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add a new flag DMF_MERGE_IS_OPTIONAL to struct mapped_device to indicate
whether the device can accept bios larger than the size its merge
function returns. When set, use this to send large bios to snapshots
which can split them if necessary. Snapshot I/O may be significantly
fragmented and this approach seems to improve peformance.
Before the patch, dm_set_device_limits restricted bio size to page size
if the underlying device had a merge function and the target didn't
provide a merge function. After the patch, dm_set_device_limits
restricts bio size to page size if the underlying device has a merge
function, doesn't have DMF_MERGE_IS_OPTIONAL flag and the target doesn't
provide a merge function.
The snapshot target can't provide a merge function because when the merge
function is called, it is impossible to determine where the bio will be
remapped. Previously this led us to impose a 4k limit, which we can
now remove if the snapshot store is located on a device without a merge
function. Together with another patch for optimizing full chunk writes,
it improves performance from 29MB/s to 40MB/s when writing to the
filesystem on snapshot store.
If the snapshot store is placed on a non-dm device with a merge function
(such as md-raid), device mapper still limits all bios to page size.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
|
|/
|
|
|
|
|
| |
Suppress sparse warnings about cpu_to_le32() by using __le32 types for
on-disk data etc.
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
|
|
|
|
|
|
|
| |
-updates are from i605 4.3 kernel source
-updates + small hack fixes front cam on kona
Change-Id: If8348be6dbef50bb322a60d554d177e046eec429
|
|
|
|
| |
Change-Id: I21144c9f3146c9043b137f180c064627ebeed71e
|
|\ |
|
| |
| |
| |
| | |
Change-Id: Ic5542259e9ff91ba20216844cf8a65f4a252c111
|
|\ \
| |/
|/|
| | |
outside the packet" into cm-11.0
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
packet
Some Cisco phones create huge messages that are spread over multiple packets.
After calculating the offset of the SIP body, it is validated to be within
the packet and the packet is dropped otherwise. This breaks operation of
these phones. Since connection tracking is supposed to be passive, just let
those packets pass unmodified and untracked.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Conflicts:
net/netfilter/nf_conntrack_sip.c
This commit appears in the 3.8 and 3.9 branches of the Linux kernel
and according to feanor3 on xda-developers:
The "Cisco Jabber" app lets you use your cell phone as a SIP
endpoint with your work number on a Cisco phone system. The
registration packets that Cisco uses are apparently larger
than normal. With your kernel, the registration does not complete.
With your kernel and line 1421 changed to NF_ACCEPT, the registration
complete
Change-Id: If0c4eff68fa10af43767ad49808394910cae4309
|
| |
| |
| |
| | |
Change-Id: Ifd1bd76ec2ebf8014107747474145d0bfc9a3281
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
in some crowded WLANs, with a lot of multicast packages circulating,
the device would not enter deep sleep.
this will allow the device to enter deep sleep.
Change-Id: I72cfefe89af64a7152e644d5095a57823ef04f4e
|
|\ \ \ |
|