3.4.99-stable review
Greg Kroah-Hartman
maintainercover 3.4.99-stable review
This is the start of the stable review cycle for the 3.4.99 release. There are 22 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu Jul 17 23:16:04 UTC 2014. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.99-rc1.gz
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 3.4.99-rc1
Lan Tianyu <[email protected]>
ACPI / battery: Retry to get battery information if failed during probing
Roland Dreier <[email protected]>
x86, ioremap: Speed up check for RAM pages
H. Peter Anvin <[email protected]>
x86, espfix: Make it possible to disable 16-bit support
H. Peter Anvin <[email protected]>
x86, espfix: Make espfix64 a Kconfig option, fix UML
H. Peter Anvin <[email protected]>
x86, espfix: Fix broken header guard
H. Peter Anvin <[email protected]>
x86, espfix: Move espfix definitions into a separate header file
H. Peter Anvin <[email protected]>
x86-64, espfix: Don't leak bits 31:16 of %esp returning to 16-bit stack
H. Peter Anvin <[email protected]>
Revert "x86-64, modify_ldt: Make support for 16-bit segments a runtime option"
Thomas Gleixner <[email protected]>
rtmutex: Plug slow unlock race
Thomas Gleixner <[email protected]>
rtmutex: Handle deadlock detection smarter
Thomas Gleixner <[email protected]>
rtmutex: Detect changes in the pi lock chain
Thomas Gleixner <[email protected]>
rtmutex: Fix deadlock detector for real
Steven Rostedt (Red Hat) <[email protected]>
tracing: Remove ftrace_stop/start() from reading the trace file
Christian König <[email protected]>
drm/radeon: stop poisoning the GART TLB
Theodore Ts'o <[email protected]>
ext4: clarify error count warning messages
Anton Blanchard <[email protected]>
powerpc/perf: Never program book3s PMCs with values >= 0x80000000
Axel Lin <[email protected]>
hwmon: (adm1029) Ensure the fan_div cache is updated in set_fan_div
Axel Lin <[email protected]>
hwmon: (amc6821) Fix permissions for temp2_input
Gu Zheng <[email protected]>
cpuset,mempolicy: fix sleeping function called from invalid context
Bert Vermeulen <[email protected]>
USB: ftdi_sio: Add extra PID.
Andras Kovacs <[email protected]>
USB: cp210x: add support for Corsair usb dongle
Bernd Wachter <[email protected]>
usb: option: Add ID for Telewell TW-LTE 4G v2
-------------
Diffstat:
Documentation/x86/x86_64/mm.txt | 2 + Makefile | 4 +- arch/powerpc/perf/core-book3s.c | 17 ++- arch/x86/Kconfig | 25 +++- arch/x86/include/asm/espfix.h | 16 ++ arch/x86/include/asm/pgtable_64_types.h | 2 + arch/x86/include/asm/setup.h | 2 + arch/x86/kernel/Makefile | 1 + arch/x86/kernel/entry_32.S | 12 ++ arch/x86/kernel/entry_64.S | 81 +++++++++- arch/x86/kernel/espfix_64.c | 209 ++++++++++++++++++++++++++ arch/x86/kernel/ldt.c | 10 +- arch/x86/kernel/smpboot.c | 7 + arch/x86/mm/dump_pagetables.c | 31 ++-- arch/x86/mm/ioremap.c | 26 +++- arch/x86/vdso/vdso32-setup.c | 8 - drivers/acpi/battery.c | 27 +++- drivers/gpu/drm/radeon/rs600.c | 6 +- drivers/hwmon/adm1029.c | 3 + drivers/hwmon/amc6821.c | 2 +- drivers/usb/serial/cp210x.c | 1 + drivers/usb/serial/ftdi_sio.c | 3 +- drivers/usb/serial/ftdi_sio_ids.h | 3 +- drivers/usb/serial/option.c | 2 + fs/ext4/super.c | 7 +- init/main.c | 4 + kernel/cpuset.c | 8 +- kernel/rtmutex-debug.h | 5 + kernel/rtmutex.c | 252 ++++++++++++++++++++++++++++---- kernel/rtmutex.h | 5 + kernel/trace/trace.c | 2 - mm/mempolicy.c | 2 - 32 files changed, 696 insertions(+), 89 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/22 usb: option: Add ID for Telewell TW-LTE 4G v2
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bernd Wachter <[email protected]>
commit 3d28bd840b2d3981cd28caf5fe1df38f1344dd60 upstream.
Add ID of the Telewell 4G v2 hardware to option driver to get legacy serial interface working
--- drivers/usb/serial/option.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/usb/serial/option.c +2 -0
@@ -1501,6 +1501,8 @@ static const struct usb_device_id option .driver_info = (kernel_ulong_t)&net_intf2_blacklist }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1426, 0xff, 0xff, 0xff), /* ZTE MF91 */ .driver_info = (kernel_ulong_t)&net_intf2_blacklist }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1428, 0xff, 0xff, 0xff), /* Telewell TW-LTE 4G v2 */ + .driver_info = (kernel_ulong_t)&net_intf2_blacklist }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1533, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1534, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1535, 0xff, 0xff, 0xff) },
Greg Kroah-Hartman
maintainerPATCH 2/22 USB: cp210x: add support for Corsair usb dongle
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andras Kovacs <[email protected]>
commit b9326057a3d8447f5d2e74a7b521ccf21add2ec0 upstream.
Corsair USB Dongles are shipped with Corsair AXi series PSUs. These are cp210x serial usb devices, so make driver detect these. I have a program, that can get information from these PSUs.
Tested with 2 different dongles shipped with Corsair AX860i and AX1200i units.
--- drivers/usb/serial/cp210x.c | 1 + 1 file changed, 1 insertion(+)
drivers/usb/serial/cp210x.c +1 -0
@@ -159,6 +159,7 @@ static const struct usb_device_id id_tab { USB_DEVICE(0x1843, 0x0200) }, /* Vaisala USB Instrument Cable */ { USB_DEVICE(0x18EF, 0xE00F) }, /* ELV USB-I2C-Interface */ { USB_DEVICE(0x1ADB, 0x0001) }, /* Schweitzer Engineering C662 Cable */ + { USB_DEVICE(0x1B1C, 0x1C00) }, /* Corsair USB Dongle */ { USB_DEVICE(0x1BE3, 0x07A6) }, /* WAGO 750-923 USB Service Cable */ { USB_DEVICE(0x1E29, 0x0102) }, /* Festo CPX-USB */ { USB_DEVICE(0x1E29, 0x0501) }, /* Festo CMSP */
Greg Kroah-Hartman
maintainerPATCH 3/22 USB: ftdi_sio: Add extra PID.
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bert Vermeulen <[email protected]>
commit 5a7fbe7e9ea0b1b9d7ffdba64db1faa3a259164c upstream.
This patch adds PID 0x0003 to the VID 0x128d (Testo). At least the Testo 435-4 uses this, likely other gear as well.
--- drivers/usb/serial/ftdi_sio.c | 3 ++- drivers/usb/serial/ftdi_sio_ids.h | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-)
drivers/usb/serial/ftdi_sio.c +2 -1
@@ -731,7 +731,8 @@ static struct usb_device_id id_table_com { USB_DEVICE(FTDI_VID, FTDI_ACG_HFDUAL_PID) }, { USB_DEVICE(FTDI_VID, FTDI_YEI_SERVOCENTER31_PID) }, { USB_DEVICE(FTDI_VID, FTDI_THORLABS_PID) }, - { USB_DEVICE(TESTO_VID, TESTO_USB_INTERFACE_PID) }, + { USB_DEVICE(TESTO_VID, TESTO_1_PID) }, + { USB_DEVICE(TESTO_VID, TESTO_3_PID) }, { USB_DEVICE(FTDI_VID, FTDI_GAMMA_SCOUT_PID) }, { USB_DEVICE(FTDI_VID, FTDI_TACTRIX_OPENPORT_13M_PID) }, { USB_DEVICE(FTDI_VID, FTDI_TACTRIX_OPENPORT_13S_PID) },
drivers/usb/serial/ftdi_sio_ids.h +2 -1
@@ -798,7 +798,8 @@* Submitted by Colin Leroy */ #define TESTO_VID 0x128D -#define TESTO_USB_INTERFACE_PID 0x0001 +#define TESTO_1_PID 0x0001 +#define TESTO_3_PID 0x0003/* * Mobility Electronics products.
Greg Kroah-Hartman
maintainerPATCH 4/22 cpuset,mempolicy: fix sleeping function called from invalid context
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gu Zheng <[email protected]>
commit 391acf970d21219a2a5446282d3b20eace0c0d7a upstream.
When runing with the kernel(3.15-rc7+), the follow bug occurs:
[ 9969.258987] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:586 [ 9969.359906] in_atomic(): 1, irqs_disabled(): 0, pid: 160655, name: python [ 9969.441175] INFO: lockdep is turned off. [ 9969.488184] CPU: 26 PID: 160655 Comm: python Tainted: G A 3.15.0-rc7+ #85 [ 9969.581032] Hardware name: FUJITSU-SV PRIMEQUEST 1800E/SB, BIOS PRIMEQUEST 1000 Series BIOS Version 1.39 11/16/2012 [ 9969.706052] ffffffff81a20e60 ffff8803e941fbd0 ffffffff8162f523 ffff8803e941fd18 [ 9969.795323] ffff8803e941fbe0 ffffffff8109995a ffff8803e941fc58 ffffffff81633e6c [ 9969.884710] ffffffff811ba5dc ffff880405c6b480 ffff88041fdd90a0 0000000000002000 [ 9969.974071] Call Trace: [ 9970.003403] [<ffffffff8162f523>] dump_stack+0x4d/0x66 [ 9970.065074] [<ffffffff8109995a>] __might_sleep+0xfa/0x130 [ 9970.130743] [<ffffffff81633e6c>] mutex_lock_nested+0x3c/0x4f0 [ 9970.200638] [<ffffffff811ba5dc>] ? kmem_cache_alloc+0x1bc/0x210 [ 9970.272610] [<ffffffff81105807>] cpuset_mems_allowed+0x27/0x140 [ 9970.344584] [<ffffffff811b1303>] ? __mpol_dup+0x63/0x150 [ 9970.409282] [<ffffffff811b1385>] __mpol_dup+0xe5/0x150 [ 9970.471897] [<ffffffff811b1303>] ? __mpol_dup+0x63/0x150 [ 9970.536585] [<ffffffff81068c86>] ? copy_process.part.23+0x606/0x1d40 [ 9970.613763] [<ffffffff810bf28d>] ? trace_hardirqs_on+0xd/0x10 [ 9970.683660] [<ffffffff810ddddf>] ? monotonic_to_bootbased+0x2f/0x50 [ 9970.759795] [<ffffffff81068cf0>] copy_process.part.23+0x670/0x1d40 [ 9970.834885] [<ffffffff8106a598>] do_fork+0xd8/0x380 [ 9970.894375] [<ffffffff81110e4c>] ? __audit_syscall_entry+0x9c/0xf0 [ 9970.969470] [<ffffffff8106a8c6>] SyS_clone+0x16/0x20 [ 9971.030011] [<ffffffff81642009>] stub_clone+0x69/0x90 [ 9971.091573] [<ffffffff81641c29>] ? system_call_fastpath+0x16/0x1b
The cause is that cpuset_mems_allowed() try to take mutex_lock(&callback_mutex) under the rcu_read_lock(which was hold in __mpol_dup()). And in cpuset_mems_allowed(), the access to cpuset is under rcu_read_lock, so in __mpol_dup, we can reduce the rcu_read_lock protection region to protect the access to cpuset only in current_cpuset_is_being_rebound(). So that we can avoid this bug.
This patch is a temporary solution that just addresses the bug mentioned above, can not fix the long-standing issue about cpuset.mems rebinding on fork():
"When the forker's task_struct is duplicated (which includes
->mems_allowed) and it races with an update to cpuset_being_rebound in update_tasks_nodemask() then the task's mems_allowed doesn't get updated. And the child task's mems_allowed can be wrong if the cpuset's nodemask changes before the child has been added to the cgroup's tasklist."
--- kernel/cpuset.c | 8 +++++++- mm/mempolicy.c | 2 -- 2 files changed, 7 insertions(+), 3 deletions(-)
kernel/cpuset.c +7 -1
@@ -1152,7 +1152,13 @@ done:int current_cpuset_is_being_rebound (void ) { -return task_cs (current) == cpuset_being_rebound; +int ret; + +rcu_read_lock (); + ret =task_cs (current) == cpuset_being_rebound; +rcu_read_unlock (); + +return ret; }static int update_relax_domain_level (struct cpuset *cs,s64 val)
mm/mempolicy.c +0 -2
@@ -1991,7 +1991,6 @@ struct mempolicy *__mpol_dup(struct memp }else *new = *old; -rcu_read_lock ();if (current_cpuset_is_being_rebound ()) {nodemask_t mems =cpuset_mems_allowed (current);if (new->flags &MPOL_F_REBINDING )
@@ -1999,7 +1998,6 @@ struct mempolicy *__mpol_dup(struct mempelse mpol_rebind_policy (new, &mems,MPOL_REBIND_ONCE ); } -rcu_read_unlock ();atomic_set (&new->refcnt,1 );return new; }
Greg Kroah-Hartman
maintainerPATCH 5/22 hwmon: (amc6821) Fix permissions for temp2_input
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Axel Lin <[email protected]>
commit df86754b746e9a0ff6f863f690b1c01d408e3cdc upstream.
temp2_input should not be writable, fix it.
--- drivers/hwmon/amc6821.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hwmon/amc6821.c +1 -1
@@ -715,7 +715,7 @@ static SENSOR_DEVICE_ATTR(temp1_max_alar get_temp_alarm, NULL, IDX_TEMP1_MAX); static SENSOR_DEVICE_ATTR(temp1_crit_alarm, S_IRUGO, get_temp_alarm, NULL, IDX_TEMP1_CRIT); -static SENSOR_DEVICE_ATTR(temp2_input, S_IRUGO | S_IWUSR, +static SENSOR_DEVICE_ATTR(temp2_input, S_IRUGO, get_temp, NULL, IDX_TEMP2_INPUT); static SENSOR_DEVICE_ATTR(temp2_min, S_IRUGO | S_IWUSR, get_temp, set_temp, IDX_TEMP2_MIN);
Greg Kroah-Hartman
maintainerPATCH 6/22 hwmon: (adm1029) Ensure the fan_div cache is updated in set_fan_div
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Axel Lin <[email protected]>
commit 1035a9e3e9c76b64a860a774f5b867d28d34acc2 upstream.
Writing to fanX_div does not clear the cache. As a result, reading from fanX_div may return the old value for up to two seconds after writing a new value.
This patch ensures the fan_div cache is updated in set_fan_div().
--- drivers/hwmon/adm1029.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/hwmon/adm1029.c +3 -0
@@ -231,6 +231,9 @@ static ssize_t set_fan_div(struct device/* Update the value */ reg = (reg &0x3F ) | (val <<6 ); +/* Update the cache */ + data->fan_div[attr->index] = reg; +/* Write value */ i2c_smbus_write_byte_data (client,ADM1029_REG_FAN_DIV [attr->index], reg);
Greg Kroah-Hartman
maintainerPATCH 7/22 powerpc/perf: Never program book3s PMCs with values >= 0x80000000
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anton Blanchard <[email protected]>
commit f56029410a13cae3652d1f34788045c40a13ffc7 upstream.
We are seeing a lot of PMU warnings on POWER8:
Can't find PMC that caused IRQ
Looking closer, the active PMC is 0 at this point and we took a PMU exception on the transition from negative to 0. Some versions of POWER8 have an issue where they edge detect and not level detect PMC overflows.
A number of places program the PMC with (0x80000000 - period_left), where period_left can be negative. We can either fix all of these or just ensure that period_left is always >= 1.
This patch takes the second option.
--- arch/powerpc/perf/core-book3s.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-)
arch/powerpc/perf/core-book3s.c +16 -1
@@ -472,7 +472,22 @@ static void power_pmu_read(struct perf_e }while (local64_cmpxchg (&event->hw.prev_count, prev, val) != prev);local64_add (delta, &event->count); -local64_sub (delta, &event->hw.period_left); + +/* +* A number of places program the PMC with (0x80000000 - period_left). +* We never want period_left to be less than 1 because we will program +* the PMC with a value >= 0x800000000 and an edge detected PMC will +* roll around to 0 before taking an exception. We have seen this +* on POWER8. +* +* To fix this, clamp the minimum value of period_left to 1. +*/ +do { + prev =local64_read (&event->hw.period_left); + val = prev - delta; +if (val <1 ) + val =1 ; + }while (local64_cmpxchg (&event->hw.period_left, prev, val) != prev); }/*
Greg Kroah-Hartman
maintainerPATCH 8/22 ext4: clarify error count warning messages
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Theodore Ts'o <[email protected]>
commit ae0f78de2c43b6fadd007c231a352b13b5be8ed2 upstream.
Make it clear that values printed are times, and that it is error since last fsck. Also add note about fsck version required.
--- fs/ext4/super.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
fs/ext4/super.c +4 -3
@@ -2589,10 +2589,11 @@ static void print_daily_error_info(unsig es = sbi->s_es;if (es->s_error_count) -ext4_msg (sb,KERN_NOTICE ,"error count: %u" , +/* fsck newer than v1.41.13 is needed to clean this condition. */ +ext4_msg (sb,KERN_NOTICE ,"error count since last fsck: %u" ,le32_to_cpu (es->s_error_count));if (es->s_first_error_time) { - printk(KERN_NOTICE "EXT4-fs (%s): initial error at %u: %.*s:%d", + printk(KERN_NOTICE "EXT4-fs (%s): initial error at time %u: %.*s:%d", sb->s_id, le32_to_cpu(es->s_first_error_time), (int) sizeof(es->s_first_error_func), es->s_first_error_func,
@@ -2606,7 +2607,7 @@ static void print_daily_error_info(unsigprintk ("\n" ); }if (es->s_last_error_time) { - printk(KERN_NOTICE "EXT4-fs (%s): last error at %u: %.*s:%d", + printk(KERN_NOTICE "EXT4-fs (%s): last error at time %u: %.*s:%d", sb->s_id, le32_to_cpu(es->s_last_error_time), (int) sizeof(es->s_last_error_func), es->s_last_error_func,
Greg Kroah-Hartman
maintainerPATCH 10/22 tracing: Remove ftrace_stop/start() from reading the trace file
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Steven Rostedt (Red Hat)" <[email protected]>
commit 099ed151675cd1d2dbeae1dac697975f6a68716d upstream.
Disabling reading and writing to the trace file should not be able to disable all function tracing callbacks. There's other users today (like kprobes and perf). Reading a trace file should not stop those from happening.
--- kernel/trace/trace.c | 2 -- 1 file changed, 2 deletions(-)
kernel/trace/trace.c +0 -2
@@ -1052,7 +1052,6 @@ void tracing_start(void)arch_spin_unlock (&ftrace_max_lock); -ftrace_start (); out:raw_spin_unlock_irqrestore (&tracing_start_lock, flags); }
@@ -1068,7 +1067,6 @@ void tracing_stop(void)struct ring_buffer *buffer;unsigned long flags; -ftrace_stop ();raw_spin_lock_irqsave (&tracing_start_lock, flags);if (trace_stop_count++) goto out;
Greg Kroah-Hartman
maintainerPATCH 11/22 rtmutex: Fix deadlock detector for real
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <[email protected]>
commit 397335f004f41e5fcf7a795e94eb3ab83411a17c upstream.
The current deadlock detection logic does not work reliably due to the following early exit path:
/* * Drop out, when the task has no waiters. Note, * top_waiter can be NULL, when we are in the deboosting * mode! */ if (top_waiter && (!task_has_pi_waiters(task) || top_waiter != task_top_pi_waiter(task))) goto out_unlock_pi;
So this not only exits when the task has no waiters, it also exits unconditionally when the current waiter is not the top priority waiter of the task.
So in a nested locking scenario, it might abort the lock chain walk and therefor miss a potential deadlock.
Simple fix: Continue the chain walk, when deadlock detection is enabled.
We also avoid the whole enqueue, if we detect the deadlock right away (A-A). It's an optimization, but also prevents that another waiter who comes in after the detection and before the task has undone the damage observes the situation and detects the deadlock and returns -EDEADLOCK, which is wrong as the other task is not in a deadlock situation.
--- kernel/rtmutex.c | 32 ++++++++++++++++++++++++++++---- 1 file changed, 28 insertions(+), 4 deletions(-)
kernel/rtmutex.c +28 -4
@@ -211,9 +211,16 @@ static int rt_mutex_adjust_prio_chain(st* top_waiter can be NULL, when we are in the deboosting * mode! */ -if (top_waiter && (!task_has_pi_waiters (task) || - top_waiter !=task_top_pi_waiter (task))) - goto out_unlock_pi; +if (top_waiter) { +if (!task_has_pi_waiters (task)) + goto out_unlock_pi; +/* +* If deadlock detection is off, we stop here if we +* are not the top pi waiter of the task. +*/ +if (!detect_deadlock && top_waiter !=task_top_pi_waiter (task)) + goto out_unlock_pi; + }/* * When deadlock detection is off then we check, if further
@@ -229,7 +236,12 @@ static int rt_mutex_adjust_prio_chain(st goto retry; } -/* Deadlock detection */ +/* +* Deadlock detection. If the lock is the same as the original +* lock which caused us to walk the lock chain or if the +* current lock is owned by the task which initiated the chain +* walk, we detected a deadlock. +*/ if (lock == orig_lock ||rt_mutex_owner (lock) == top_task) {debug_rt_mutex_deadlock (deadlock_detect, orig_waiter, lock);raw_spin_unlock (&lock->wait_lock);
@@ -398,6 +410,18 @@ static int task_blocks_on_rt_mutex(strucunsigned long flags;int chain_walk =0 , res; +/* +* Early deadlock detection. We really don't want the task to +* enqueue on itself just to untangle the mess later. It's not +* only an optimization. We drop the locks, so another waiter +* can come in before the chain walk detects the deadlock. So +* the other will detect the deadlock and return -EDEADLOCK, +* which is wrong, as the other waiter is not in a deadlock +* situation. +*/ +if (detect_deadlock && owner == task) +return -EDEADLK ; +raw_spin_lock_irqsave (&task->pi_lock, flags);__rt_mutex_adjust_prio (task); waiter->task = task;
Greg Kroah-Hartman
maintainerPATCH 12/22 rtmutex: Detect changes in the pi lock chain
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <[email protected]>
commit 82084984383babe728e6e3c9a8e5c46278091315 upstream.
When we walk the lock chain, we drop all locks after each step. So the lock chain can change under us before we reacquire the locks. That's harmless in principle as we just follow the wrong lock path. But it can lead to a false positive in the dead lock detection logic:
T0 holds L0
T0 blocks on L1 held by T1
T1 blocks on L2 held by T2
T2 blocks on L3 held by T3
T4 blocks on L4 held by T4
Now we walk the chain
lock T1 -> lock L2 -> adjust L2 -> unlock T1 ->
lock T2 -> adjust T2 -> drop locks
T2 times out and blocks on L0
Now we continue:
lock T2 -> lock L0 -> deadlock detected, but it's not a deadlock at all.
Brad tried to work around that in the deadlock detection logic itself, but the more I looked at it the less I liked it, because it's crystal ball magic after the fact.
We actually can detect a chain change very simple:
lock T1 -> lock L2 -> adjust L2 -> unlock T1 -> lock T2 -> adjust T2 ->
next_lock = T2->pi_blocked_on->lock;
drop locks
T2 times out and blocks on L0
Now we continue:
lock T2 ->
if (next_lock != T2->pi_blocked_on->lock)
return;So if we detect that T2 is now blocked on a different lock we stop the chain walk. That's also correct in the following scenario:
lock T1 -> lock L2 -> adjust L2 -> unlock T1 -> lock T2 -> adjust T2 ->
next_lock = T2->pi_blocked_on->lock;
drop locks
T3 times out and drops L3
T2 acquires L3 and blocks on L4 now
Now we continue:
lock T2 ->
if (next_lock != T2->pi_blocked_on->lock)
return;We don't have to follow up the chain at that point, because T2 propagated our priority up to T4 already.
[ Folded a cleanup patch from peterz ]
--- kernel/rtmutex.c | 74 +++++++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 59 insertions(+), 15 deletions(-)
kernel/rtmutex.c +59 -15
@@ -141,6 +141,11 @@ static void rt_mutex_adjust_prio(struct*/ int max_lock_depth =1024 ; +static inline struct rt_mutex *task_blocked_on_lock (struct task_struct *p) +{ +return p->pi_blocked_on ? p->pi_blocked_on->lock :NULL ; +} +/* * Adjust the priority chain. Also used for deadlock detection. * Decreases task's usage by one - may thus free the task.
@@ -149,6 +154,7 @@ int max_lock_depth = 1024;static int rt_mutex_adjust_prio_chain (struct task_struct *task,int deadlock_detect,struct rt_mutex *orig_lock, +struct rt_mutex *next_lock,struct rt_mutex_waiter *orig_waiter,struct task_struct *top_task) {
@@ -207,6 +213,18 @@ static int rt_mutex_adjust_prio_chain(st goto out_unlock_pi;/* +* We dropped all locks after taking a refcount on @task, so +* the task might have moved on in the lock chain or even left +* the chain completely and blocks now on an unrelated lock or +* on @orig_lock. +* +* We stored the lock on which @task was blocked in @next_lock, +* so we can detect the chain change. +*/ +if (next_lock != waiter->lock) + goto out_unlock_pi; + +/* * Drop out, when the task has no waiters. Note, * top_waiter can be NULL, when we are in the deboosting * mode!
@@ -292,11 +310,26 @@ static int rt_mutex_adjust_prio_chain(st__rt_mutex_adjust_prio (task); } +/* +* Check whether the task which owns the current lock is pi +* blocked itself. If yes we store a pointer to the lock for +* the lock chain change detection above. After we dropped +* task->pi_lock next_lock cannot be dereferenced anymore. +*/ + next_lock =task_blocked_on_lock (task); +raw_spin_unlock_irqrestore (&task->pi_lock, flags); top_waiter =rt_mutex_top_waiter (lock);raw_spin_unlock (&lock->wait_lock); +/* +* We reached the end of the lock chain. Stop right here. No +* point to go back just to figure that out. +*/ +if (!next_lock) + goto out_put_task; +if (!detect_deadlock && waiter != top_waiter) goto out_put_task;
@@ -407,8 +440,9 @@ static int task_blocks_on_rt_mutex(struc {struct task_struct *owner =rt_mutex_owner (lock);struct rt_mutex_waiter *top_waiter = waiter; -unsigned long flags; +struct rt_mutex *next_lock;int chain_walk =0 , res; +unsigned long flags;/* * Early deadlock detection. We really don't want the task to
@@ -441,20 +475,28 @@ static int task_blocks_on_rt_mutex(strucif (!owner)return 0 ; +raw_spin_lock_irqsave (&owner->pi_lock, flags);if (waiter ==rt_mutex_top_waiter (lock)) { -raw_spin_lock_irqsave (&owner->pi_lock, flags);plist_del (&top_waiter->pi_list_entry, &owner->pi_waiters);plist_add (&waiter->pi_list_entry, &owner->pi_waiters);__rt_mutex_adjust_prio (owner);if (owner->pi_blocked_on) chain_walk =1 ; -raw_spin_unlock_irqrestore (&owner->pi_lock, flags); - } -else if (debug_rt_mutex_detect_deadlock (waiter, detect_deadlock)) + }else if (debug_rt_mutex_detect_deadlock (waiter, detect_deadlock)) { chain_walk =1 ; + } -if (!chain_walk) +/* Store the lock on which owner is blocked or NULL */ + next_lock =task_blocked_on_lock (owner); + +raw_spin_unlock_irqrestore (&owner->pi_lock, flags); +/* +* Even if full deadlock detection is on, if the owner is not +* blocked itself, we can avoid finding this out in the chain +* walk. +*/ +if (!chain_walk || !next_lock)return 0 ;/*
@@ -466,8 +508,8 @@ static int task_blocks_on_rt_mutex(strucraw_spin_unlock (&lock->wait_lock); - res =rt_mutex_adjust_prio_chain (owner, detect_deadlock, lock, waiter, - task); + res =rt_mutex_adjust_prio_chain (owner, detect_deadlock, lock, + next_lock, waiter, task);raw_spin_lock (&lock->wait_lock);
@@ -516,8 +558,8 @@ static void remove_waiter(struct rt_mute {int first = (waiter ==rt_mutex_top_waiter (lock));struct task_struct *owner =rt_mutex_owner (lock); +struct rt_mutex *next_lock =NULL ;unsigned long flags; -int chain_walk =0 ;raw_spin_lock_irqsave (¤t->pi_lock, flags);plist_del (&waiter->list_entry, &lock->wait_list);
@@ -541,15 +583,15 @@ static void remove_waiter(struct rt_mute }__rt_mutex_adjust_prio (owner); -if (owner->pi_blocked_on) - chain_walk =1 ; +/* Store the lock on which owner is blocked or NULL */ + next_lock =task_blocked_on_lock (owner);raw_spin_unlock_irqrestore (&owner->pi_lock, flags); }WARN_ON (!plist_node_empty (&waiter->pi_list_entry)); -if (!chain_walk) +if (!next_lock)return ;/* gets dropped in rt_mutex_adjust_prio_chain()! */
@@ -557,7 +599,7 @@ static void remove_waiter(struct rt_muteraw_spin_unlock (&lock->wait_lock); -rt_mutex_adjust_prio_chain (owner,0 , lock,NULL , current); +rt_mutex_adjust_prio_chain (owner,0 , lock, next_lock,NULL , current);raw_spin_lock (&lock->wait_lock); }
@@ -570,6 +612,7 @@ static void remove_waiter(struct rt_mutevoid rt_mutex_adjust_pi (struct task_struct *task) {struct rt_mutex_waiter *waiter; +struct rt_mutex *next_lock;unsigned long flags;raw_spin_lock_irqsave (&task->pi_lock, flags);
@@ -579,12 +622,13 @@ void rt_mutex_adjust_pi(struct task_struraw_spin_unlock_irqrestore (&task->pi_lock, flags);return ; } - + next_lock = waiter->lock;raw_spin_unlock_irqrestore (&task->pi_lock, flags);/* gets dropped in rt_mutex_adjust_prio_chain()! */ get_task_struct (task); -rt_mutex_adjust_prio_chain (task,0 ,NULL ,NULL , task); + +rt_mutex_adjust_prio_chain (task,0 ,NULL , next_lock,NULL , task); }/**
Greg Kroah-Hartman
maintainerPATCH 13/22 rtmutex: Handle deadlock detection smarter
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <[email protected]>
commit 3d5c9340d1949733eb37616abd15db36aef9a57c upstream.
Even in the case when deadlock detection is not requested by the caller, we can detect deadlocks. Right now the code stops the lock chain walk and keeps the waiter enqueued, even on itself. Silly not to yell when such a scenario is detected and to keep the waiter enqueued.
Return -EDEADLK unconditionally and handle it at the call sites.
The futex calls return -EDEADLK. The non futex ones dequeue the waiter, throw a warning and put the task into a schedule loop.
Tagged for stable as it makes the code more robust.
--- kernel/rtmutex-debug.h | 5 +++++ kernel/rtmutex.c | 33 ++++++++++++++++++++++++++++----- kernel/rtmutex.h | 5 +++++ 3 files changed, 38 insertions(+), 5 deletions(-)
kernel/rtmutex-debug.h +5 -0
@@ -31,3 +31,8 @@ static inline int debug_rt_mutex_detect_ {return (waiter !=NULL ); } + +static inline void rt_mutex_print_deadlock (struct rt_mutex_waiter *w) +{ +debug_rt_mutex_print_deadlock (w); +}
kernel/rtmutex.c +28 -5
@@ -188,7 +188,7 @@ static int rt_mutex_adjust_prio_chain(st }put_task_struct (task); -return deadlock_detect ? -EDEADLK :0 ; +return -EDEADLK ; } retry:/*
@@ -263,7 +263,7 @@ static int rt_mutex_adjust_prio_chain(stif (lock == orig_lock ||rt_mutex_owner (lock) == top_task) {debug_rt_mutex_deadlock (deadlock_detect, orig_waiter, lock);raw_spin_unlock (&lock->wait_lock); - ret = deadlock_detect ? -EDEADLK :0 ; + ret = -EDEADLK ; goto out_unlock_pi; }
@@ -453,7 +453,7 @@ static int task_blocks_on_rt_mutex(struc* which is wrong, as the other waiter is not in a deadlock * situation. */ -if (detect_deadlock && owner == task) +if (owner == task)return -EDEADLK ;raw_spin_lock_irqsave (&task->pi_lock, flags);
@@ -680,6 +680,26 @@ __rt_mutex_slowlock(struct rt_mutex *locreturn ret; } +static void rt_mutex_handle_deadlock (int res,int detect_deadlock, +struct rt_mutex_waiter *w) +{ +/* +* If the result is not -EDEADLOCK or the caller requested +* deadlock detection, nothing to do here. +*/ +if (res != -EDEADLOCK || detect_deadlock) +return ; + +/* +* Yell lowdly and stop the task right here. +*/ +rt_mutex_print_deadlock (w); +while (1 ) { +set_current_state (TASK_INTERRUPTIBLE ); +schedule (); + } +} +/* * Slow path lock function: */
@@ -717,8 +737,10 @@ rt_mutex_slowlock(struct rt_mutex *lock,set_current_state (TASK_RUNNING ); -if (unlikely (ret)) +if (unlikely (ret)) {remove_waiter (lock, &waiter); +rt_mutex_handle_deadlock (ret, detect_deadlock, &waiter); + }/* * try_to_take_rt_mutex() sets the waiter bit
@@ -1026,7 +1048,8 @@ int rt_mutex_start_proxy_lock(struct rt_return 1 ; } - ret =task_blocks_on_rt_mutex (lock, waiter, task, detect_deadlock); +/* We enforce deadlock detection for futexes */ + ret =task_blocks_on_rt_mutex (lock, waiter, task,1 );if (ret && !rt_mutex_owner (lock)) {/*
kernel/rtmutex.h +5 -0
@@ -24,3 +24,8 @@#define debug_rt_mutex_print_deadlock (w) do { } while (0)#define debug_rt_mutex_detect_deadlock (w,d) (d)#define debug_rt_mutex_reset_waiter (w) do { } while (0) + +static inline void rt_mutex_print_deadlock (struct rt_mutex_waiter *w) +{ +WARN (1 ,"rtmutex deadlock detected\n" ); +}
Greg Kroah-Hartman
maintainerPATCH 14/22 rtmutex: Plug slow unlock race
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <[email protected]>
commit 27e35715df54cbc4f2d044f681802ae30479e7fb upstream.
When the rtmutex fast path is enabled the slow unlock function can create the following situation:
spin_lock(foo->m->wait_lock);
foo->m->owner = NULL; rt_mutex_lock(foo->m); <-- fast path free = atomic_dec_and_test(foo->refcnt); rt_mutex_unlock(foo->m); <-- fast path if (free) kfree(foo);
spin_unlock(foo->m->wait_lock); <--- Use after free.
Plug the race by changing the slow unlock to the following scheme:
while (!rt_mutex_has_waiters(m)) {
/* Clear the waiters bit in m->owner */
clear_rt_mutex_waiters(m);
owner = rt_mutex_owner(m);
spin_unlock(m->wait_lock);
if (cmpxchg(m->owner, owner, 0) == owner)
return;
spin_lock(m->wait_lock);
}So in case of a new waiter incoming while the owner tries the slow path unlock we have two situations:
unlock(wait_lock); lock(wait_lock); cmpxchg(p, owner, 0) == owner mark_rt_mutex_waiters(lock); acquire(lock);
Or:
unlock(wait_lock); lock(wait_lock); mark_rt_mutex_waiters(lock); cmpxchg(p, owner, 0) != owner enqueue_waiter(); unlock(wait_lock); lock(wait_lock); wakeup_next waiter(); unlock(wait_lock); lock(wait_lock); acquire(lock);
If the fast path is disabled, then the simple
m->owner = NULL; unlock(m->wait_lock);
is sufficient as all access to m->owner is serialized via m->wait_lock;
Also document and clarify the wakeup_next_waiter function as suggested by Oleg Nesterov.
--- kernel/rtmutex.c | 115 ++++++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 109 insertions(+), 6 deletions(-)
kernel/rtmutex.c +109 -6
@@ -81,6 +81,47 @@ static inline void mark_rt_mutex_waiters owner = *p; }while (cmpxchg (p, owner, owner |RT_MUTEX_HAS_WAITERS ) != owner); } + +/* +* Safe fastpath aware unlock: +* 1) Clear the waiters bit +* 2) Drop lock->wait_lock +* 3) Try to unlock the lock with cmpxchg +*/ +static inline bool unlock_rt_mutex_safe (struct rt_mutex *lock) + __releases(lock->wait_lock) +{ +struct task_struct *owner =rt_mutex_owner (lock); + +clear_rt_mutex_waiters (lock); +raw_spin_unlock (&lock->wait_lock); +/* +* If a new waiter comes in between the unlock and the cmpxchg +* we have two situations: +* +* unlock(wait_lock); +* lock(wait_lock); +* cmpxchg(p, owner, 0) == owner +* mark_rt_mutex_waiters(lock); +* acquire(lock); +* or: +* +* unlock(wait_lock); +* lock(wait_lock); +* mark_rt_mutex_waiters(lock); +* +* cmpxchg(p, owner, 0) != owner +* enqueue_waiter(); +* unlock(wait_lock); +* lock(wait_lock); +* wake waiter(); +* unlock(wait_lock); +* lock(wait_lock); +* acquire(lock); +*/ +return rt_mutex_cmpxchg (lock, owner,NULL ); +} +#else # define rt_mutex_cmpxchg (l,c,n) (0)static inline void mark_rt_mutex_waiters (struct rt_mutex *lock)
@@ -88,6 +129,17 @@ static inline void mark_rt_mutex_waiters lock->owner = (struct task_struct *) ((unsigned long)lock->owner | RT_MUTEX_HAS_WAITERS); } + +/* +* Simple slow path only version: lock->owner is protected by lock->wait_lock. +*/ +static inline bool unlock_rt_mutex_safe (struct rt_mutex *lock) + __releases(lock->wait_lock) +{ + lock->owner =NULL ; +raw_spin_unlock (&lock->wait_lock); +return true; +}#endif /*
@@ -519,7 +571,8 @@ static int task_blocks_on_rt_mutex(struc/* * Wake up the next waiter on the lock. * -* Remove the top waiter from the current tasks waiter list and wake it up. +* Remove the top waiter from the current tasks pi waiter list and +* wake it up. * * Called with lock->wait_lock held. */
@@ -540,10 +593,23 @@ static void wakeup_next_waiter(struct rt*/ plist_del (&waiter->pi_list_entry, ¤t->pi_waiters); -rt_mutex_set_owner (lock,NULL ); +/* +* As we are waking up the top waiter, and the waiter stays +* queued on the lock until it gets the lock, this lock +* obviously has waiters. Just set the bit here and this has +* the added benefit of forcing all new tasks into the +* slow path making sure no task of lower priority than +* the top waiter can steal this lock. +*/ + lock->owner = (void *)RT_MUTEX_HAS_WAITERS ;raw_spin_unlock_irqrestore (¤t->pi_lock, flags); +/* +* It's safe to dereference waiter as it cannot go away as +* long as we hold lock->wait_lock. The waiter task needs to +* acquire it in order to dequeue the waiter. +*/ wake_up_process (waiter->task); }
@@ -796,12 +862,49 @@ rt_mutex_slowunlock(struct rt_mutex *locrt_mutex_deadlock_account_unlock (current); -if (!rt_mutex_has_waiters (lock)) { - lock->owner =NULL ; -raw_spin_unlock (&lock->wait_lock); -return ; +/* +* We must be careful here if the fast path is enabled. If we +* have no waiters queued we cannot set owner to NULL here +* because of: +* +* foo->lock->owner = NULL; +* rtmutex_lock(foo->lock); <- fast path +* free = atomic_dec_and_test(foo->refcnt); +* rtmutex_unlock(foo->lock); <- fast path +* if (free) +* kfree(foo); +* raw_spin_unlock(foo->lock->wait_lock); +* +* So for the fastpath enabled kernel: +* +* Nothing can set the waiters bit as long as we hold +* lock->wait_lock. So we do the following sequence: +* +* owner = rt_mutex_owner(lock); +* clear_rt_mutex_waiters(lock); +* raw_spin_unlock(&lock->wait_lock); +* if (cmpxchg(&lock->owner, owner, 0) == owner) +* return; +* goto retry; +* +* The fastpath disabled variant is simple as all access to +* lock->owner is serialized by lock->wait_lock: +* +* lock->owner = NULL; +* raw_spin_unlock(&lock->wait_lock); +*/ +while (!rt_mutex_has_waiters (lock)) { +/* Drops lock->wait_lock ! */ +if (unlock_rt_mutex_safe (lock) == true) +return ; +/* Relock the rtmutex and try again */ +raw_spin_lock (&lock->wait_lock); } +/* +* The wakeup next waiter path does not suffer from the above +* race. See the comments there. +*/ wakeup_next_waiter (lock);raw_spin_unlock (&lock->wait_lock);
Greg Kroah-Hartman
maintainerPATCH 15/22 Revert "x86-64, modify_ldt: Make support for 16-bit segments a runtime option"
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: "H. Peter Anvin" <[email protected]>
commit 7ed6fb9b5a5510e4ef78ab27419184741169978a upstream.
This reverts commit fa81511bb0bbb2b1aace3695ce869da9762624ff in preparation of merging in the proper fix (espfix64).
--- arch/x86/kernel/ldt.c | 4 +--- arch/x86/vdso/vdso32-setup.c | 8 -------- 2 files changed, 1 insertion(+), 11 deletions(-)
arch/x86/kernel/ldt.c +1 -3
@@ -20,8 +20,6 @@#include <asm/mmu_context.h> #include <asm/syscalls.h> -int sysctl_ldt16 =0 ; -#ifdef CONFIG_SMP static void flush_ldt (void *current_mm) {
@@ -236,7 +234,7 @@ static int write_ldt(void __user *ptr, u* IRET leaking the high bits of the kernel stack address. */ #ifdef CONFIG_X86_64 -if (!ldt_info.seg_32bit && !sysctl_ldt16) { +if (!ldt_info.seg_32bit) { error = -EINVAL ; goto out_unlock; }
arch/x86/vdso/vdso32-setup.c +0 -8
@@ -41,7 +41,6 @@ enum {#ifdef CONFIG_X86_64 #define vdso_enabled sysctl_vsyscall32#define arch_setup_additional_pages syscall32_setup_pages -extern int sysctl_ldt16;#endif /*
@@ -380,13 +379,6 @@ static ctl_table abi_table2[] = { .maxlen = sizeof(int), .mode = 0644, .proc_handler = proc_dointvec - }, - { - .procname = "ldt16", - .data = &sysctl_ldt16, - .maxlen = sizeof(int), - .mode = 0644, - .proc_handler = proc_dointvec }, {} };
Greg Kroah-Hartman
maintainerPATCH 16/22 x86-64, espfix: Dont leak bits 31:16 of %esp returning to 16-bit stack
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: "H. Peter Anvin" <[email protected]>
commit 3891a04aafd668686239349ea58f3314ea2af86b upstream.
The IRET instruction, when returning to a 16-bit segment, only restores the bottom 16 bits of the user space stack pointer. This causes some 16-bit software to break, but it also leaks kernel state to user space. We have a software workaround for that ("espfix") for the 32-bit kernel, but it relies on a nonzero stack segment base which is not available in 64-bit mode.
In checkin:
b3b42ac2cbae x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels
we "solved" this by forbidding 16-bit segments on 64-bit kernels, with the logic that 16-bit support is crippled on 64-bit kernels anyway (no V86 support), but it turns out that people are doing stuff like running old Win16 binaries under Wine and expect it to work.
This works around this by creating percpu "ministacks", each of which is mapped 2^16 times 64K apart. When we detect that the return SS is on the LDT, we copy the IRET frame to the ministack and use the relevant alias to return to userspace. The ministacks are mapped readonly, so if IRET faults we promote #GP to #DF which is an IST vector and thus has its own stack; we then do the fixup in the #DF handler.
(Making #GP an IST exception would make the msr_safe functions unsafe in NMI/MC context, and quite possibly have other effects.)
Special thanks to:
- Andy Lutomirski, for the suggestion of using very small stack slots and copy (as opposed to map) the IRET frame there, and for the suggestion to mark them readonly and let the fault promote to #DF.
- Konrad Wilk for paravirt fixup and testing.
- Borislav Petkov for testing help and useful comments.
--- Documentation/x86/x86_64/mm.txt | 2 arch/x86/include/asm/pgtable_64_types.h | 2 arch/x86/include/asm/setup.h | 3 arch/x86/kernel/Makefile | 1 arch/x86/kernel/entry_64.S | 73 ++++++++++- arch/x86/kernel/espfix_64.c | 208 ++++++++++++++++++++++++++++++++ arch/x86/kernel/ldt.c | 11 - arch/x86/kernel/smpboot.c | 7 + arch/x86/mm/dump_pagetables.c | 31 +++- init/main.c | 4 10 files changed, 316 insertions(+), 26 deletions(-)
Documentation/x86/x86_64/mm.txt +2 -0
@@ -12,6 +12,8 @@ ffffc90000000000 - ffffe8ffffffffff (=45 ffffe90000000000 - ffffe9ffffffffff (=40 bits) hole ffffea0000000000 - ffffeaffffffffff (=40 bits) virtual memory map (1TB) ... unused hole ... +ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp fixup stacks +... unused hole ... ffffffff80000000 - ffffffffa0000000 (=512 MB) kernel text mapping, from phys 0 ffffffffa0000000 - fffffffffff00000 (=1536 MB) module mapping space
arch/x86/include/asm/pgtable_64_types.h +2 -0
@@ -59,5 +59,7 @@ typedef struct { pteval_t pte; } pte_t;#define MODULES_VADDR _AC(0xffffffffa0000000, UL)#define MODULES_END _AC(0xffffffffff000000, UL)#define MODULES_LEN (MODULES_END - MODULES_VADDR) +#define ESPFIX_PGD_ENTRY _AC(-2, UL) +#define ESPFIX_BASE_ADDR (ESPFIX_PGD_ENTRY << PGDIR_SHIFT)#endif /* _ASM_X86_PGTABLE_64_DEFS_H */
arch/x86/include/asm/setup.h +3 -0
@@ -59,6 +59,9 @@ extern void x86_ce4100_early_setup(void)static inline void x86_ce4100_early_setup (void ) { }#endif +extern void init_espfix_bsp (void ); +extern void init_espfix_ap (void ); +#ifndef _SETUP/*
arch/x86/kernel/Makefile +1 -0
@@ -28,6 +28,7 @@ obj-$(CONFIG_X86_64) += sys_x86_64.o x86 obj-y += syscall_$(BITS).o obj-$(CONFIG_X86_64) += vsyscall_64.o obj-$(CONFIG_X86_64) += vsyscall_emu_64.o +obj-$(CONFIG_X86_64) += espfix_64.o obj-y += bootflag.o e820.o obj-y += pci-dma.o quirks.o topology.o kdebugfs.o obj-y += alternative.o i8253.o pci-nommu.o hw_breakpoint.o
arch/x86/kernel/entry_64.S +69 -4
114 lines not on this page · raw message
arch/x86/kernel/espfix_64.c new file +208 -0
208 lines not on this page · raw message
arch/x86/kernel/ldt.c +0 -11
@@ -229,17 +229,6 @@ static int write_ldt(void __user *ptr, u } } -/* -* On x86-64 we do not support 16-bit segments due to -* IRET leaking the high bits of the kernel stack address. -*/ -#ifdef CONFIG_X86_64 -if (!ldt_info.seg_32bit) { - error = -EINVAL ; - goto out_unlock; - } -#endif -fill_ldt (&ldt, &ldt_info);if (oldmode) ldt.avl =0 ;
arch/x86/kernel/smpboot.c +7 -0
@@ -271,6 +271,13 @@ notrace static void __cpuinit start_secocheck_tsc_sync_target ();/* +* Enable the espfix hack for this CPU +*/ +#ifdef CONFIG_X86_64 +init_espfix_ap (); +#endif + +/* * We need to hold call_lock, so there is no inconsistency * between the time smp_call_function() determines number of * IPI recipients, and the time when the determination is made
arch/x86/mm/dump_pagetables.c +20 -11
@@ -30,11 +30,13 @@ struct pg_state {unsigned long start_address;unsigned long current_address;const struct addr_marker *marker; +unsigned long lines; };struct addr_marker {unsigned long start_address;const char *name; +unsigned long max_lines; };/* indices for address_markers; keep sync'd w/ address_markers below */
@@ -45,6 +47,7 @@ enum address_markers_idx {LOW_KERNEL_NR ,VMALLOC_START_NR ,VMEMMAP_START_NR , +ESPFIX_START_NR ,HIGH_KERNEL_NR ,MODULES_VADDR_NR , MODULES_END_NR,
@@ -67,6 +70,7 @@ static struct addr_marker address_marker { PAGE_OFFSET, "Low Kernel Mapping" }, { VMALLOC_START, "vmalloc() Area" }, { VMEMMAP_START, "Vmemmap" }, + { ESPFIX_BASE_ADDR, "ESPfix Area", 16 }, { __START_KERNEL_map, "High Kernel Mapping" }, { MODULES_VADDR, "Modules" }, { MODULES_END, "End Modules" },
@@ -163,7 +167,7 @@ static void note_page(struct seq_file *m pgprot_t new_prot, int level) {pgprotval_t prot, cur; -static const char units[] ="KMGTPE" ; +static const char units[] ="BKMGTPE" ;/* * If we have a "break" in the series, we need to flush the state that
@@ -178,6 +182,7 @@ static void note_page(struct seq_file *m st->current_prot = new_prot; st->level = level; st->marker = address_markers; + st->lines =0 ;seq_printf (m,"---[ %s ]---\n" , st->marker->name); }else if (prot != cur || level != st->level || st->current_address >= st->marker[1 ].start_address) {
@@ -188,17 +193,21 @@ static void note_page(struct seq_file *m/* * Now print the actual finished series */ -seq_printf (m,"0x%0*lx-0x%0*lx " , - width, st->start_address, - width, st->current_address); - - delta = (st->current_address - st->start_address) >>10 ; -while (!(delta &1023 ) && unit[1 ]) { - delta >>=10 ; - unit++; +if (!st->marker->max_lines || + st->lines < st->marker->max_lines) { +seq_printf (m,"0x%0*lx-0x%0*lx " , + width, st->start_address, + width, st->current_address); + + delta = (st->current_address - st->start_address) >>10 ; +while (!(delta &1023 ) && unit[1 ]) { + delta >>=10 ; + unit++; + } +seq_printf (m,"%9lu%c " , delta, *unit); +printk_prot (m, st->current_prot, st->level); } -seq_printf (m,"%9lu%c " , delta, *unit); -printk_prot (m, st->current_prot, st->level); + st->lines++;/* * We print markers for special areas of address space,
init/main.c +4 -0
@@ -606,6 +606,10 @@ asmlinkage void __init start_kernel(voidif (efi_enabled (EFI_RUNTIME_SERVICES ))efi_enter_virtual_mode ();#endif +#ifdef CONFIG_X86_64 +/* Should be run before the first non-init thread is created */ +init_espfix_bsp (); +#endif thread_info_cache_init ();cred_init ();fork_init (totalram_pages);
Greg Kroah-Hartman
maintainerPATCH 17/22 x86, espfix: Move espfix definitions into a separate header file
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: "H. Peter Anvin" <[email protected]>
commit e1fe9ed8d2a4937510d0d60e20705035c2609aea upstream.
Sparse warns that the percpu variables aren't declared before they are defined. Rather than hacking around it, move espfix definitions into a proper header file.
--- arch/x86/include/asm/espfix.h | 16 ++++++++++++++++ arch/x86/include/asm/setup.h | 5 ++--- arch/x86/kernel/espfix_64.c | 1 + 3 files changed, 19 insertions(+), 3 deletions(-)
arch/x86/include/asm/espfix.h new file +16 -0
@@ -0,0 +1,16 @@ +#ifdef _ASM_X86_ESPFIX_H +#define _ASM_X86_ESPFIX_H + +#ifdef CONFIG_X86_64 + +#include <asm/percpu.h> + +DECLARE_PER_CPU_READ_MOSTLY(unsigned long, espfix_stack); +DECLARE_PER_CPU_READ_MOSTLY(unsigned long, espfix_waddr); + +extern void init_espfix_bsp (void ); +extern void init_espfix_ap (void ); + +#endif /* CONFIG_X86_64 */ + +#endif /* _ASM_X86_ESPFIX_H */
arch/x86/include/asm/setup.h +2 -3
@@ -59,11 +59,10 @@ extern void x86_ce4100_early_setup(void)static inline void x86_ce4100_early_setup (void ) { }#endif -extern void init_espfix_bsp (void ); -extern void init_espfix_ap (void ); -#ifndef _SETUP +#include <asm/espfix.h> +/* * This is set up by the setup-routine at boot-time */
arch/x86/kernel/espfix_64.c +1 -0
@@ -40,6 +40,7 @@#include <asm/pgtable.h> #include <asm/pgalloc.h> #include <asm/setup.h> +#include <asm/espfix.h> /* * Note: we only need 6*8 = 48 bytes for the espfix stack, but round
Greg Kroah-Hartman
maintainerPATCH 18/22 x86, espfix: Fix broken header guard
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: "H. Peter Anvin" <[email protected]>
commit 20b68535cd27183ebd3651ff313afb2b97dac941 upstream.
Header guard is #ifndef, not #ifdef...
--- arch/x86/include/asm/espfix.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/include/asm/espfix.h +1 -1
@@ -1,4 +1,4 @@ -#ifdef _ASM_X86_ESPFIX_H +#ifndef _ASM_X86_ESPFIX_H#define _ASM_X86_ESPFIX_H#ifdef CONFIG_X86_64
Greg Kroah-Hartman
maintainerPATCH 19/22 x86, espfix: Make espfix64 a Kconfig option, fix UML
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: "H. Peter Anvin" <[email protected]>
commit 197725de65477bc8509b41388157c1a2283542bb upstream.
Make espfix64 a hidden Kconfig option. This fixes the x86-64 UML build which had broken due to the non-existence of init_espfix_bsp() in UML: since UML uses its own Kconfig, this option does not appear in the UML build.
This also makes it possible to make support for 16-bit segments a configuration option, for the people who want to minimize the size of the kernel.
--- arch/x86/Kconfig | 4 ++++ arch/x86/kernel/Makefile | 2 +- arch/x86/kernel/smpboot.c | 2 +- init/main.c | 2 +- 4 files changed, 7 insertions(+), 3 deletions(-)
arch/x86/Kconfig +4 -0
@@ -920,6 +920,10 @@ config VM86 XFree86 to initialize some video cards via BIOS. Disabling this option saves about 6k. +config X86_ESPFIX64 + def_bool y + depends on X86_64 + config TOSHIBA tristate "Toshiba Laptop support" depends on X86_32
arch/x86/kernel/Makefile +1 -1
@@ -28,7 +28,7 @@ obj-$(CONFIG_X86_64) += sys_x86_64.o x86 obj-y += syscall_$(BITS).o obj-$(CONFIG_X86_64) += vsyscall_64.o obj-$(CONFIG_X86_64) += vsyscall_emu_64.o -obj-$(CONFIG_X86_64) += espfix_64.o +obj-$(CONFIG_X86_ESPFIX64) += espfix_64.o obj-y += bootflag.o e820.o obj-y += pci-dma.o quirks.o topology.o kdebugfs.o obj-y += alternative.o i8253.o pci-nommu.o hw_breakpoint.o
arch/x86/kernel/smpboot.c +1 -1
@@ -273,7 +273,7 @@ notrace static void __cpuinit start_seco/* * Enable the espfix hack for this CPU */ -#ifdef CONFIG_X86_64 +#ifdef CONFIG_X86_ESPFIX64 init_espfix_ap ();#endif
init/main.c +1 -1
@@ -606,7 +606,7 @@ asmlinkage void __init start_kernel(voidif (efi_enabled (EFI_RUNTIME_SERVICES ))efi_enter_virtual_mode ();#endif -#ifdef CONFIG_X86_64 +#ifdef CONFIG_X86_ESPFIX64 /* Should be run before the first non-init thread is created */ init_espfix_bsp ();#endif
Greg Kroah-Hartman
maintainerPATCH 20/22 x86, espfix: Make it possible to disable 16-bit support
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: "H. Peter Anvin" <[email protected]>
commit 34273f41d57ee8d854dcd2a1d754cbb546cb548f upstream.
Embedded systems, which may be very memory-size-sensitive, are extremely unlikely to ever encounter any 16-bit software, so make it a CONFIG_EXPERT option to turn off support for any 16-bit software whatsoever.
--- arch/x86/Kconfig | 23 ++++++++++++++++++----- arch/x86/kernel/entry_32.S | 12 ++++++++++++ arch/x86/kernel/entry_64.S | 8 ++++++++ arch/x86/kernel/ldt.c | 5 +++++ 4 files changed, 43 insertions(+), 5 deletions(-)
arch/x86/Kconfig +18 -5
@@ -915,14 +915,27 @@ config VM86 default y depends on X86_32 ---help--- - This option is required by programs like DOSEMU to run 16-bit legacy - code on X86 processors. It also may be needed by software like - XFree86 to initialize some video cards via BIOS. Disabling this - option saves about 6k. + This option is required by programs like DOSEMU to run + 16-bit real mode legacy code on x86 processors. It also may + be needed by software like XFree86 to initialize some video + cards via BIOS. Disabling this option saves about 6K. + +config X86_16BIT + bool "Enable support for 16-bit segments" if EXPERT + default y + ---help--- + This option is required by programs like Wine to run 16-bit + protected mode legacy code on x86 processors. Disabling + this option saves about 300 bytes on i386, or around 6K text + plus 16K runtime memory on x86-64, + +config X86_ESPFIX32 + def_bool y + depends on X86_16BIT && X86_32 config X86_ESPFIX64 def_bool y - depends on X86_64 + depends on X86_16BIT && X86_64 config TOSHIBA tristate "Toshiba Laptop support"
arch/x86/kernel/entry_32.S +12 -0
@@ -524,6 +524,7 @@ syscall_exit: restore_all: TRACE_IRQS_IRET restore_all_notrace: +#ifdef CONFIG_X86_ESPFIX32 movl PT_EFLAGS(%esp), %eax # mix EFLAGS, SS and CS # Warning: PT_OLDSS(%esp) contains the wrong/random values if we # are returning to the kernel.
@@ -534,6 +535,7 @@ restore_all_notrace: cmpl $((SEGMENT_LDT << 8) | USER_RPL), %eax CFI_REMEMBER_STATE je ldt_ss # returning to user-space with LDT SS +#endif restore_nocheck: RESTORE_REGS 4 # skip orig_eax/error_code irq_return:
@@ -549,6 +551,7 @@ ENTRY(iret_exc) .long irq_return,iret_exc .previous +#ifdef CONFIG_X86_ESPFIX32 CFI_RESTORE_STATE ldt_ss: #ifdef CONFIG_PARAVIRT
@@ -592,6 +595,7 @@ ldt_ss: lss (%esp), %esp /* switch to espfix segment */ CFI_ADJUST_CFA_OFFSET -8 jmp restore_nocheck +#endif CFI_ENDPROC ENDPROC(system_call)
@@ -765,6 +769,7 @@ ENDPROC(ptregs_clone) * the high word of the segment base from the GDT and swiches to the * normal stack and adjusts ESP with the matching offset. */ +#ifdef CONFIG_X86_ESPFIX32 /* fixup the stack */ mov GDT_ESPFIX_SS + 4, %al /* bits 16..23 */ mov GDT_ESPFIX_SS + 7, %ah /* bits 24..31 */
@@ -774,8 +779,10 @@ ENDPROC(ptregs_clone) pushl_cfi %eax lss (%esp), %esp /* switch to the normal stack segment */ CFI_ADJUST_CFA_OFFSET -8 +#endif .endm .macro UNWIND_ESPFIX_STACK +#ifdef CONFIG_X86_ESPFIX32 movl %ss, %eax /* see if on espfix stack */ cmpw $__ESPFIX_SS, %ax
@@ -786,6 +793,7 @@ ENDPROC(ptregs_clone) /* switch to normal stack */ FIXUP_ESPFIX_STACK 27: +#endif .endm /*
@@ -1317,11 +1325,13 @@ END(debug) */ ENTRY(nmi) RING0_INT_FRAME +#ifdef CONFIG_X86_ESPFIX32 pushl_cfi %eax movl %ss, %eax cmpw $__ESPFIX_SS, %ax popl_cfi %eax je nmi_espfix_stack +#endif cmpl $ia32_sysenter_target,(%esp) je nmi_stack_fixup pushl_cfi %eax
@@ -1361,6 +1371,7 @@ nmi_debug_stack_check: FIX_STACK 24, nmi_stack_correct, 1 jmp nmi_stack_correct +#ifdef CONFIG_X86_ESPFIX32 nmi_espfix_stack: /* We have a RING0_INT_FRAME here. *
@@ -1382,6 +1393,7 @@ nmi_espfix_stack: lss 12+4(%esp), %esp # back to espfix stack CFI_ADJUST_CFA_OFFSET -24 jmp irq_return +#endif CFI_ENDPROC END(nmi)
arch/x86/kernel/entry_64.S +8 -0
@@ -904,8 +904,10 @@ irq_return: * Are we returning to a stack segment from the LDT? Note: in * 64-bit mode SS:RSP on the exception stack is always valid. */ +#ifdef CONFIG_X86_ESPFIX64 testb $4,(SS-RIP)(%rsp) jnz irq_return_ldt +#endif irq_return_iret: INTERRUPT_RETURN
@@ -923,6 +925,7 @@ ENTRY(native_iret) .previous #endif +#ifdef CONFIG_X86_ESPFIX64 irq_return_ldt: pushq_cfi %rax pushq_cfi %rdi
@@ -946,6 +949,7 @@ irq_return_ldt: movq %rax,%rsp popq_cfi %rax jmp irq_return_iret +#endif .section .fixup,"ax" bad_iret:
@@ -1019,6 +1023,7 @@ END(common_interrupt) * modify the stack to make it look like we just entered * the #GP handler from user space, similar to bad_iret. */ +#ifdef CONFIG_X86_ESPFIX64 ALIGN __do_double_fault: XCPT_FRAME 1 RDI+8
@@ -1044,6 +1049,9 @@ __do_double_fault: retq CFI_ENDPROC END(__do_double_fault) +#else +# define __do_double_fault do_double_fault +#endif /* * End of kprobes section
arch/x86/kernel/ldt.c +5 -0
@@ -229,6 +229,11 @@ static int write_ldt(void __user *ptr, u } } +if (!IS_ENABLED (CONFIG_X86_16BIT ) && !ldt_info.seg_32bit) { + error = -EINVAL ; + goto out_unlock; + } +fill_ldt (&ldt, &ldt_info);if (oldmode) ldt.avl =0 ;
Greg Kroah-Hartman
maintainerPATCH 21/22 x86, ioremap: Speed up check for RAM pages
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Roland Dreier <[email protected]>
commit c81c8a1eeede61e92a15103748c23d100880cc8a upstream.
In __ioremap_caller() (the guts of ioremap), we loop over the range of pfns being remapped and checks each one individually with page_is_ram(). For large ioremaps, this can be very slow. For example, we have a device with a 256 GiB PCI BAR, and ioremapping this BAR can take 20+ seconds -- sometimes long enough to trigger the soft lockup detector!
Internally, page_is_ram() calls walk_system_ram_range() on a single page. Instead, we can make a single call to walk_system_ram_range() from __ioremap_caller(), and do our further checks only for any RAM pages that we find. For the common case of MMIO, this saves an enormous amount of work, since the range being ioremapped doesn't intersect system RAM at all.
With this change, ioremap on our 256 GiB BAR takes less than 1 second.
--- arch/x86/mm/ioremap.c | 26 +++++++++++++++++++------- 1 file changed, 19 insertions(+), 7 deletions(-)
arch/x86/mm/ioremap.c +19 -7
@@ -50,6 +50,21 @@ int ioremap_change_attr(unsigned long vareturn err; } +static int __ioremap_check_ram (unsigned long start_pfn,unsigned long nr_pages, +void *arg) +{ +unsigned long i; + +for (i =0 ; i < nr_pages; ++i) +if (pfn_valid (start_pfn + i) && + !PageReserved (pfn_to_page (start_pfn + i))) +return 1 ; + +WARN_ONCE (1 ,"ioremap on RAM pfn 0x%lx\n" , start_pfn); + +return 0 ; +} +/* * Remap an arbitrary physical address space into the kernel virtual * address space. Needed when the kernel wants to access high addresses
@@ -93,14 +108,11 @@ static void __iomem *__ioremap_caller(re/* * Don't allow anybody to remap normal RAM that we're using.. */ + pfn = phys_addr >>PAGE_SHIFT ; last_pfn = last_addr >>PAGE_SHIFT ; -for (pfn = phys_addr >>PAGE_SHIFT ; pfn <= last_pfn; pfn++) { -int is_ram =page_is_ram (pfn); - -if (is_ram &&pfn_valid (pfn) && !PageReserved (pfn_to_page (pfn))) -return NULL ; -WARN_ON_ONCE (is_ram); - } +if (walk_system_ram_range (pfn, last_pfn - pfn +1 ,NULL , + __ioremap_check_ram) ==1 ) +return NULL ;/* * Mappings have to be page-aligned
Greg Kroah-Hartman
maintainerPATCH 22/22 ACPI / battery: Retry to get battery information if failed during probing
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lan Tianyu <[email protected]>
commit 75646e758a0ecbed5024454507d5be5b9ea9dcbf upstream.
Some machines (eg. Lenovo Z480) ECs are not stable during boot up and causes battery driver fails to be loaded due to failure of getting battery information from EC sometimes. After several retries, the operation will work. This patch is to retry to get battery information 5 times if the first try fails.
[ backport to 3.14.5: removed second parameter in acpi_battery_update(), introduced by the commit 9e50bc14a7f58b5d8a55973b2d69355852ae2dae (ACPI /
battery: Accelerate battery resume callback)]
--- drivers/acpi/battery.c | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-)
drivers/acpi/battery.c +26 -1
@@ -34,6 +34,7 @@#include <linux/dmi.h> #include <linux/slab.h> #include <linux/suspend.h> +#include <linux/delay.h> #include <asm/unaligned.h> #ifdef CONFIG_ACPI_PROCFS_POWER
@@ -1055,6 +1056,28 @@ static int battery_notify(struct notifiereturn 0 ; } +/* +* Some machines'(E,G Lenovo Z480) ECs are not stable +* during boot up and this causes battery driver fails to be +* probed due to failure of getting battery information +* from EC sometimes. After several retries, the operation +* may work. So add retry code here and 20ms sleep between +* every retries. +*/ +static int acpi_battery_update_retry (struct acpi_battery *battery) +{ +int retry, ret; + +for (retry =5 ; retry; retry--) { + ret =acpi_battery_update (battery); +if (!ret) +break ; + +msleep (20 ); + } +return ret; +} +static int acpi_battery_add (struct acpi_device *device) {int result =0 ;
@@ -1074,9 +1097,11 @@ static int acpi_battery_add(struct acpi_if (ACPI_SUCCESS (acpi_get_handle (battery->device->handle,"_BIX" , &handle)))set_bit (ACPI_BATTERY_XINFO_PRESENT , &battery->flags); - result =acpi_battery_update (battery); + + result =acpi_battery_update_retry (battery);if (result) goto fail; +#ifdef CONFIG_ACPI_PROCFS_POWER result =acpi_battery_add_fs (device);#endif
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.4.99 release. There are 22 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu Jul 17 23:16:04 UTC 2014. Anything received after that time might be too late.
Build results:
total: 117 pass: 111 fail: 6
Failed builds:
alpha:allmodconfig
arm:spear6xx_defconfig
score:defconfig
sparc64:allmodconfig
unicore32:defconfig
xtensa:allmodconfig
Qemu tests all passed.
Results are as expected.
Details are available at http://server.roeck-us.net:8010/builders.
A note on the above link and its accessibility: I have seen relentless attacks from various sources recently. All but one of those attacks originated from IP addresses allocated to Chinese service providers (the one exception was an attack from an Amazon virtual host). Attacks have become more sophisticated over time, to a point where I no longer trust my firewalls.
For this reason, I now permanently block the entire IP address range of a service provider if an attack originates from an address range allocated to that provider. I understand that this may bve considered a bit drastic, but this is my server, the information on it is provided free of charge, for the benefit of everyone, and there should be no reason to attack it. Blame the attackers, not me.
If you have reason to believe that your address has been blocked, I will be happy to selectively unblock it if you can show me legitimate interest in accessing the information.
Guenter
Greg Kroah-Hartman
maintainerQuoted 11 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.4.99 release. There are 22 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu Jul 17 23:16:04 UTC 2014. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.99-rc1.gzand the diffstat can be found below.
And, as with 3.10, 3.14, and 3.15, here's a -rc2 release:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.99-rc2.gz
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.4.99 release. There are 22 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu Jul 17 23:16:04 UTC 2014. Anything received after that time might be too late.
Quoted 8 lines
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.99-rc1.gzand the diffstat can be found below.
thanks,
greg k-h
rc1 and rc2 compiled and booted on my test system. No dmesg regressions.
-- Shuah
Signature · 4 lines
Shuah Khan Senior Linux Kernel Developer - Open Source Group Samsung Research America(Silicon Valley) [email protected] | (970) 672-0658