3.0.38-stable review
Subsystems (32)
cover 3.0.38-stable review
This is the start of the stable review cycle for the 3.0.38 release. There are 23 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 19 23:23:28 UTC 2012. 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.0.38-rc1.gz
and the diffstat can be found below.
thanks,
greg k-h
-------------
Makefile | 4 +- arch/arm/plat-samsung/adc.c | 8 +- drivers/hwmon/it87.c | 2 +- drivers/input/joystick/xpad.c | 1 + drivers/media/dvb/dvb-core/dvbdev.c | 1 + drivers/mtd/nand/nandsim.c | 12 +-- drivers/net/e1000e/82571.c | 3 + drivers/net/wireless/rt2x00/rt2x00usb.c | 2 +- drivers/platform/x86/intel_ips.c | 22 ++++++ fs/buffer.c | 22 +++--- fs/fifo.c | 9 +-- include/linux/hrtimer.h | 10 ++- include/linux/timex.h | 2 +- kernel/hrtimer.c | 53 +++++++++---- kernel/time/ntp.c | 124 ++++++++++--------------------- kernel/time/timekeeping.c | 115 +++++++++++++++++++++------- net/ipv4/tcp_input.c | 2 + net/wireless/util.c | 2 +- 18 files changed, 234 insertions(+), 160 deletions(-)
PATCH 1/37 Remove easily user-triggerable BUG from generic_setlease
From: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Jones <[email protected]>
commit 8d657eb3b43861064d36241e88d9d61c709f33f0 upstream.
This can be trivially triggered from userspace by passing in something unexpected.
kernel BUG at fs/locks.c:1468!
invalid opcode: 0000 [#1] SMP
RIP: 0010:generic_setlease+0xc2/0x100
Call Trace:
__vfs_setlease+0x35/0x40
fcntl_setlease+0x76/0x150
sys_fcntl+0x1c6/0x810
system_call_fastpath+0x1a/0x1f--- fs/locks.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/locks.c +1 -1
@@ -1465,7 +1465,7 @@ int generic_setlease(struct file *filp,case F_WRLCK :return generic_add_lease (filp, arg, flp);default : -BUG (); +return -EINVAL ; } }EXPORT_SYMBOL (generic_setlease);
PATCH 2/37 media: cx231xx: dont DMA to random addresses
From: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Dillow <[email protected]>
commit a7deca6fa79d5c65575532e780f3c93f6bf8ddad upstream.
Commit 7a6f6c29d264cdd2fe0eb3d923217eed5f0ad134 (cx231xx: use URB_NO_TRANSFER_DMA_MAP) was intended to avoid mapping the DMA buffer for URB twice. This works for the URBs allocated with usb_alloc_urb(), as those are allocated from cohernent DMA pools, but the flag was also added for the VBI and audio URBs, which have a manually allocated area. This leaves the random trash in the structure after allocation as the DMA address, corrupting memory and preventing VBI and audio from working. Letting the USB core map the buffers solves the problem.
--- drivers/media/video/cx231xx/cx231xx-audio.c | 4 ++-- drivers/media/video/cx231xx/cx231xx-vbi.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-)
drivers/media/video/cx231xx/cx231xx-audio.c +2 -2
@@ -307,7 +307,7 @@ static int cx231xx_init_audio_isoc(struc urb->context = dev; urb->pipe =usb_rcvisocpipe (dev->udev, dev->adev.end_point_addr); - urb->transfer_flags =URB_ISO_ASAP |URB_NO_TRANSFER_DMA_MAP ; + urb->transfer_flags =URB_ISO_ASAP ; urb->transfer_buffer = dev->adev.transfer_buffer[i]; urb->interval =1 ; urb->complete = cx231xx_audio_isocirq;
@@ -368,7 +368,7 @@ static int cx231xx_init_audio_bulk(struc urb->context = dev; urb->pipe =usb_rcvbulkpipe (dev->udev, dev->adev.end_point_addr); - urb->transfer_flags =URB_NO_TRANSFER_DMA_MAP ; + urb->transfer_flags =0 ; urb->transfer_buffer = dev->adev.transfer_buffer[i]; urb->complete = cx231xx_audio_bulkirq; urb->transfer_buffer_length = sb_size;
drivers/media/video/cx231xx/cx231xx-vbi.c +1 -1
@@ -452,7 +452,7 @@ int cx231xx_init_vbi_isoc(struct cx231xxreturn -ENOMEM ; } dev->vbi_mode.bulk_ctl.urb[i] = urb; - urb->transfer_flags =URB_NO_TRANSFER_DMA_MAP ; + urb->transfer_flags =0 ; dev->vbi_mode.bulk_ctl.transfer_buffer[i] =kzalloc (sb_size,GFP_KERNEL );
PATCH 3/37 hwmon: (it87) Preserve configuration register bits on init
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jean Delvare <[email protected]>
commit 41002f8dd5938d5ad1d008ce5bfdbfe47fa7b4e8 upstream.
We were accidentally losing one bit in the configuration register on device initialization. It was reported to freeze one specific system right away. Properly preserve all bits we don't explicitly want to change in order to prevent that.
--- drivers/hwmon/it87.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hwmon/it87.c +1 -1
@@ -2157,7 +2157,7 @@ static void __devinit it87_init_device(s/* Start monitoring */ it87_write_value (data,IT87_REG_CONFIG , - (it87_read_value (data,IT87_REG_CONFIG ) &0x36 ) + (it87_read_value (data,IT87_REG_CONFIG ) &0x3e ) | (update_vbat ?0x41 :0x01 )); }
PATCH 4/37 block: fix infinite loop in __getblk_slow
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jeff Moyer <[email protected]>
commit 91f68c89d8f35fe98ea04159b9a3b42d0149478f upstream.
Commit 080399aaaf35 ("block: don't mark buffers beyond end of disk as mapped") exposed a bug in __getblk_slow that causes mount to hang as it loops infinitely waiting for a buffer that lies beyond the end of the disk to become uptodate.
The problem was initially reported by Torsten Hilbrich here:
https://lkml.org/lkml/2012/6/18/54
and also reported independently here:
http://www.sysresccd.org/forums/viewtopic.php?f=13&t=4511
and then Richard W.M. Jones and Marcos Mello noted a few separate bugzillas also associated with the same issue. This patch has been confirmed to fix:
https://bugzilla.redhat.com/show_bug.cgi?id=835019
The main problem is here, in __getblk_slow:
for (;;) {
struct buffer_head * bh;
int ret;
bh = __find_get_block(bdev, block, size);
if (bh)
return bh;
ret = grow_buffers(bdev, block, size);
if (ret < 0)
return NULL;
if (ret == 0)
free_more_memory();
}__find_get_block does not find the block, since it will not be marked as mapped, and so grow_buffers is called to fill in the buffers for the associated page. I believe the for (;;) loop is there primarily to retry in the case of memory pressure keeping grow_buffers from succeeding. However, we also continue to loop for other cases, like the block lying beond the end of the disk. So, the fix I came up with is to only loop when grow_buffers fails due to memory allocation issues (return value of 0).
The attached patch was tested by myself, Torsten, and Rich, and was found to resolve the problem in call cases.
--- fs/buffer.c | 22 +++++++++++++--------- 1 file changed, 13 insertions(+), 9 deletions(-)
fs/buffer.c +13 -9
@@ -1036,6 +1036,9 @@ grow_buffers(struct block_device *bdev,static struct buffer_head *__getblk_slow (struct block_device *bdev,sector_t block,int size) { +int ret; +struct buffer_head *bh; +/* Size must be multiple of hard sectorsize */ if (unlikely (size & (bdev_logical_block_size (bdev)-1 ) || (size <512 || size >PAGE_SIZE ))) {
@@ -1048,20 +1051,21 @@ __getblk_slow(struct block_device *bdev,return NULL ; } -for (;;) { -struct buffer_head * bh; -int ret; +retry: + bh =__find_get_block (bdev, block, size); +if (bh) +return bh; + ret =grow_buffers (bdev, block, size); +if (ret ==0 ) { +free_more_memory (); + goto retry; + }else if (ret >0 ) { bh =__find_get_block (bdev, block, size);if (bh)return bh; - - ret =grow_buffers (bdev, block, size); -if (ret <0 ) -return NULL ; -if (ret ==0 ) -free_more_memory (); } +return NULL ; }/*
PATCH 5/37 media: dvb-core: Release semaphore on error path dvb_register_device()
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Santosh Nayak <[email protected]>
commit 82163edcdfa4eb3d74516cc8e9f38dd3d039b67d upstream.
There is a missing "up_write()" here. Semaphore should be released before returning error value.
--- drivers/media/dvb/dvb-core/dvbdev.c | 1 + 1 file changed, 1 insertion(+)
drivers/media/dvb/dvb-core/dvbdev.c +1 -0
@@ -243,6 +243,7 @@ int dvb_register_device(struct dvb_adaptif (minor ==MAX_DVB_MINORS ) {kfree (dvbdevfops);kfree (dvbdev); +up_write (&minor_rwsem);mutex_unlock (&dvbdev_register_lock);return -EINVAL ; }
PATCH 6/37 mtd: nandsim: dont open code a do_div helper
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Herton Ronaldo Krzesinski <[email protected]>
commit 596fd46268634082314b3af1ded4612e1b7f3f03 upstream.
We don't need to open code the divide function, just use div_u64 that already exists and do the same job. While this is a straightforward clean up, there is more to that, the real motivation for this.
While building on a cross compiling environment in armel, using gcc 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5), I was getting the following build error:
ERROR: "__aeabi_uldivmod" [drivers/mtd/nand/nandsim.ko] undefined!
After investigating with objdump and hand built assembly version generated with the compiler, I narrowed __aeabi_uldivmod as being generated from the divide function. When nandsim.c is built with -fno-inline-functions-called-once, that happens when CONFIG_DEBUG_SECTION_MISMATCH is enabled, the do_div optimization in arch/arm/include/asm/div64.h doesn't work as expected with the open coded divide function: even if the do_div we are using doesn't have a constant divisor, the compiler still includes the else parts of the optimized do_div macro, and translates the divisions there to use __aeabi_uldivmod, instead of only calling __do_div_asm -> __do_div64 and optimizing/removing everything else out.
So to reproduce, gcc 4.6 plus CONFIG_DEBUG_SECTION_MISMATCH=y and CONFIG_MTD_NAND_NANDSIM=m should do it, building on armel.
After this change, the compiler does the intended thing even with -fno-inline-functions-called-once, and optimizes out as expected the constant handling in the optimized do_div on arm. As this also avoids a build issue, I'm marking for Stable, as I think is applicable for this case.
--- drivers/mtd/nand/nandsim.c | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-)
drivers/mtd/nand/nandsim.c +3 -9
@@ -28,7 +28,7 @@#include <linux/module.h> #include <linux/moduleparam.h> #include <linux/vmalloc.h> -#include <asm/div64.h> +#include <linux/math64.h> #include <linux/slab.h> #include <linux/errno.h> #include <linux/string.h>
@@ -547,12 +547,6 @@ static char *get_partition_name(int i)return kstrdup (buf,GFP_KERNEL ); } -static uint64_t divide (uint64_t n,uint32_t d) -{ -do_div (n, d); -return n; -} -/* * Initialize the nandsim structure. *
@@ -581,7 +575,7 @@ static int init_nandsim(struct mtd_info ns->geom.oobsz = mtd->oobsize; ns->geom.secsz = mtd->erasesize; ns->geom.pgszoob = ns->geom.pgsz + ns->geom.oobsz; - ns->geom.pgnum =divide (ns->geom.totsz, ns->geom.pgsz); + ns->geom.pgnum =div_u64 (ns->geom.totsz, ns->geom.pgsz); ns->geom.totszoob = ns->geom.totsz + (uint64_t )ns->geom.pgnum * ns->geom.oobsz; ns->geom.secshift =ffs (ns->geom.secsz) -1 ; ns->geom.pgshift = chip->page_shift;
@@ -924,7 +918,7 @@ static int setup_wear_reporting(struct mif (!rptwear)return 0 ; - wear_eb_count =divide (mtd->size, mtd->erasesize); + wear_eb_count =div_u64 (mtd->size, mtd->erasesize); mem = wear_eb_count *sizeof (unsigned long );if (mem /sizeof (unsigned long ) != wear_eb_count) {NS_ERR ("Too many erase blocks for wear reporting\n" );
PATCH 7/37 md/raid1: fix use-after-free bug in RAID1 data-check code.
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: NeilBrown <[email protected]>
commit 2d4f4f3384d4ef4f7c571448e803a1ce721113d5 upstream.
This bug has been present ever since data-check was introduce in 2.6.16. However it would only fire if a data-check were done on a degraded array, which was only possible if the array has 3 or more devices. This is certainly possible, but is quite uncommon.
Since hot-replace was added in 3.3 it can happen more often as the same condition can arise if not all possible replacements are present.
The problem is that as soon as we submit the last read request, the 'r1_bio' structure could be freed at any time, so we really should stop looking at it. If the last device is being read from we will stop looking at it. However if the last device is not due to be read from, we will still check the bio pointer in the r1_bio, but the r1_bio might already be free.
So use the read_targets counter to make sure we stop looking for bios to submit as soon as we have submitted them all.
This fix is suitable for any -stable kernel since 2.6.16.
--- drivers/md/raid1.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/md/raid1.c +2 -1
@@ -2486,9 +2486,10 @@ static sector_t sync_request(struct mdde*/ if (test_bit (MD_RECOVERY_REQUESTED , &mddev->recovery)) {atomic_set (&r1_bio->remaining, read_targets); -for (i =0 ; i < conf->raid_disks *2 ; i++) { +for (i =0 ; i < conf->raid_disks *2 && read_targets; i++) { bio = r1_bio->bios[i];if (bio->bi_end_io == end_sync_read) { + read_targets--;md_sync_acct (bio->bi_bdev, nr_sectors);generic_make_request (bio); }
PATCH 8/37 ARM: SAMSUNG: fix race in s3c_adc_start for ADC
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Todd Poynor <[email protected]>
commit 8265981bb439f3ecc5356fb877a6c2a6636ac88a upstream.
Checking for adc->ts_pend already claimed should be done with the lock held.
--- arch/arm/plat-samsung/adc.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
arch/arm/plat-samsung/adc.c +5 -3
@@ -157,11 +157,13 @@ int s3c_adc_start(struct s3c_adc_clientreturn -EINVAL ; } -if (client->is_ts && adc->ts_pend) -return -EAGAIN ; -spin_lock_irqsave (&adc->lock, flags); +if (client->is_ts && adc->ts_pend) { +spin_unlock_irqrestore (&adc->lock, flags); +return -EAGAIN ; + } + client->channel = channel; client->nr_samples = nr_samples;
PATCH 9/37 ACPICA: Fix possible fault in return package object repair code
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bob Moore <[email protected]>
commit 46befd6b38d802dfc5998e7d7938854578b45d9d upstream.
Fixes a problem that can occur when a lone package object is wrapped with an outer package object in order to conform to the ACPI specification. Can affect these predefined names:
_ALR,_MLS,_PSS,_TRT,_TSS,_PRT,_HPX,_DLM,_CSD,_PSD,_TSD
https://bugzilla.kernel.org/show_bug.cgi?id=44171
This problem was introduced in 3.4-rc1 by commit 6a99b1c94d053b3420eaa4a4bc8b2883dd90a2f9
(ACPICA: Object repair code: Support to add Package wrappers)
--- drivers/acpi/acpica/nspredef.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/acpi/acpica/nspredef.c +1 -1
@@ -638,7 +638,7 @@ acpi_ns_check_package(struct acpi_predef/* Create the new outer package and populate it */ status = -acpi_ns_wrap_with_package (data, *elements, +acpi_ns_wrap_with_package (data, return_object, return_object_ptr);if (ACPI_FAILURE (status)) {return (status);
PATCH 10/37 cpufreq / ACPI: Fix not loading acpi-cpufreq driver regression
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Renninger <[email protected]>
commit c4686c71a9183f76e3ef59098da5c098748672f6 upstream.
Commit d640113fe80e45ebd4a5b420b introduced a regression on SMP systems where the processor core with ACPI id zero is disabled (typically should be the case because of hyperthreading). The regression got spread through stable kernels.
On 3.0.X it got introduced via 3.0.18.
Such platforms may be rare, but do exist.
Look out for a disabled processor with acpi_id 0 in dmesg:
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x10] disabled)
This problem has been observed on a:
HP Proliant BL280c G6 blade
This patch restricts the introduced workaround to platforms with nr_cpu_ids <= 1.
--- drivers/acpi/processor_core.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/acpi/processor_core.c +4 -2
@@ -189,10 +189,12 @@ int acpi_get_cpuid(acpi_handle handle, i* Processor (CPU3, 0x03, 0x00000410, 0x06) {} * } * -* Ignores apic_id and always return 0 for CPU0's handle. +* Ignores apic_id and always returns 0 for the processor +* handle with acpi id 0 if nr_cpu_ids is 1. +* This should be the case if SMP tables are not found. * Return -1 for other CPU's handle. */ -if (acpi_id ==0 ) +if (nr_cpu_ids <=1 && acpi_id ==0 )return acpi_id;else return apic_id;
PATCH 11/37 sched/nohz: Rewrite and fix load-avg computation -- again
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Zijlstra <[email protected]>
commit 5167e8d5417bf5c322a703d2927daec727ea40dd upstream.
Thanks to Charles Wang for spotting the defects in the current code:
- If we go idle during the sample window -- after sampling, we get a negative bias because we can negate our own sample.
- If we wake up during the sample window we get a positive bias because we push the sample to a known active period.
So rewrite the entire nohz load-avg muck once again, now adding copious documentation to the code.
--- include/linux/sched.h | 8 + kernel/sched/core.c | 275 ++++++++++++++++++++++++++++++++++------------- kernel/sched/idle_task.c | 1 kernel/sched/sched.h | 2 kernel/time/tick-sched.c | 2 5 files changed, 213 insertions(+), 75 deletions(-)
include/linux/sched.h +8 -0
@@ -1933,6 +1933,14 @@ static inline int set_cpus_allowed_ptr(s }#endif +#ifdef CONFIG_NO_HZ +void calc_load_enter_idle (void ); +void calc_load_exit_idle (void ); +#else +static inline void calc_load_enter_idle (void ) { } +static inline void calc_load_exit_idle (void ) { } +#endif /* CONFIG_NO_HZ */ +#ifndef CONFIG_CPUMASK_OFFSTACK static inline int set_cpus_allowed (struct task_struct *p,cpumask_t new_mask) {
kernel/sched/core.c +203 -72
352 lines not on this page · raw message
kernel/sched/idle_task.c +0 -1
@@ -25,7 +25,6 @@ static void check_preempt_curr_idle(strustatic struct task_struct *pick_next_task_idle (struct rq *rq) {schedstat_inc (rq, sched_goidle); -calc_load_account_idle (rq);return rq->idle; }
kernel/sched/sched.h +0 -2
@@ -940,8 +940,6 @@ static inline u64 sched_avg_period(void)return (u64 )sysctl_sched_time_avg *NSEC_PER_MSEC /2 ; } -void calc_load_account_idle (struct rq *this_rq); -#ifdef CONFIG_SCHED_HRTICK /*
kernel/time/tick-sched.c +2 -0
@@ -401,6 +401,7 @@ static void tick_nohz_stop_sched_tick(st*/ if (!ts->tick_stopped) {select_nohz_load_balancer (1 ); +calc_load_enter_idle (); ts->idle_tick =hrtimer_get_expires (&ts->sched_timer); ts->tick_stopped =1 ;
@@ -591,6 +592,7 @@ void tick_nohz_idle_exit(void)account_idle_ticks (ticks);#endif +calc_load_exit_idle ();touch_softlockup_watchdog ();/* * Cancel the scheduled timer and restore the tick
Re: [ 11/37] sched/nohz: Rewrite and fix load-avg computation -- again
Hi,
Quoted 4 lines · Greg Kroah-Hartman
commit
5167e8d5417bf5c322a703d2927daec727ea40ddupstream.Thanks to Charles Wang for spotting the defects in the current code:
Quoted 8 lines
- If we go idle during the sample window -- after sampling, we get a negative bias because we can negate our own sample.
- If we wake up during the sample window we get a positive bias because we push the sample to a known active period.
So rewrite the entire nohz load-avg muck once again, now adding copious documentation to the code.
I'm thrilled to see this regression fix for stable@, but are we really really sure that it won't cause new regressions?
Words like "rewrite" set off alarm bells. As do missing acks:
Quoted 2 lines
Cc Linus Torvalds <[email protected]>Cc Andrew Morton <[email protected]>
(though I guess there's an implied ack from Linus, given that it was pulled). And big diffstats:
Quoted 6 lines
include/linux/sched.h | 8 + kernel/sched/core.c | 275 ++++++++++++++++++++++++++++++++++------------- kernel/sched/idle_task.c | 1 kernel/sched/sched.h | 2 kernel/time/tick-sched.c | 2 5 files changed, 213 insertions(+), 75 deletions(-)
Thanks,
Jonathan
Re: [ 11/37] sched/nohz: Rewrite and fix load-avg computation -- again
Quoted 2 lines · Jonathan Nieder
I'm thrilled to see this regression fix for stable@, but are we really really sure that it won't cause new regressions?
Doug Smythies ran a ~68 hour test on it, running various synthetic loads of various frequencies against it and comparing the reported load averages against the expected values and found it to be 'good'.
This doesn't guarantee we won't find more 'interesting' problems in there, but it does give me fair confidence in it.
Re: [ 11/37] sched/nohz: Rewrite and fix load-avg computation -- again
Quoted 11 lines · Peter Zijlstra
Quoted 2 lines · Jonathan Nieder
I'm thrilled to see this regression fix for stable@, but are we really really sure that it won't cause new regressions?
Doug Smythies ran a ~68 hour test on it, running various synthetic loads of various frequencies against it and comparing the reported load averages against the expected values and found it to be 'good'.
This doesn't guarantee we won't find more 'interesting' problems in there, but it does give me fair confidence in it.
Yeah, that sounds good. Very nice to hear.
Is the code to generate the synthetic loads and expected results somewhere easy to find (like LTP or tools/testing) to make it easier to keep this code working well in the future?
Grateful,
Jonathan
Re: [ 11/37] sched/nohz: Rewrite and fix load-avg computation -- again
Quoted 10 lines · Jonathan Nieder
Quoted 9 lines · Peter Zijlstra
Quoted 2 lines · Jonathan Nieder
I'm thrilled to see this regression fix for stable@, but are we really really sure that it won't cause new regressions?
Doug Smythies ran a ~68 hour test on it, running various synthetic loads of various frequencies against it and comparing the reported load averages against the expected values and found it to be 'good'.
Quoted 8 lines
Quoted 2 lines
This doesn't guarantee we won't find more 'interesting' problems in there, but it does give me fair confidence in it.
Yeah, that sounds good. Very nice to hear.
Is the code to generate the synthetic loads and expected results somewhere easy to find (like LTP or
tools/testing) to make it easier to keep this code working well in the future?
/me finds Doug isn't actually on the CC, /me fixes.
Doug had this web-page with all his testing activities, graphs and code etc..
http://www.smythies.com/~doug/network/load_average/
Seems to still work.
Last time I tried his scripts they weren't very user friendly, and afaik he's making the pretty graphs 'manually'. But whatever he's got is there I think.
If someone wants to take it and make it pretty and 'usable' for people in a hurry I'm sure Doug wouldn't mind.
RE: [ 11/37] sched/nohz: Rewrite and fix load-avg computation -- again
Quoted 10 lines · Peter Zijlstra
Quoted 8 lines · Jonathan Nieder
Quoted 7 lines
Quoted 4 lines · Peter Zijlstra
On Tue, 2012-07-17 at 19:16 -0500, Jonathan Nieder wrote:
I'm thrilled to see this regression fix for stable@, but are we really really sure that it won't cause new regressions?
Doug Smythies ran a ~68 hour test on it, running various synthetic
loads
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
of various frequencies against it and comparing the reported load averages against the expected values and found it to be 'good'.
This doesn't guarantee we won't find more 'interesting' problems in there, but it does give me fair confidence in it.
Quoted 7 lines
Quoted 5 lines
Yeah, that sounds good. Very nice to hear.
Is the code to generate the synthetic loads and expected results somewhere easy to find (like LTP or
tools/testing) to make it easier to keep this code working well in the future?/me finds Doug isn't actually on the CC, /me fixes.
Thanks.
Quoted 4 lines
Doug had this web-page with all his testing activities, graphs and code etc..
http://www.smythies.com/~doug/network/load_average/
Seems to still work.
Those web pages will be there for a long time (years).
Quoted 3 lines
Last time I tried his scripts they weren't very user friendly, and afaik he's making the pretty graphs 'manually'. But whatever he's got is there I think.
Yes, pretty graphs were manually done.
Yes, scripts lack user friendliness, but everything I used is posted.
Quoted 2 lines
If someone wants to take it and make it pretty and 'usable' for people in a hurry I'm sure Doug wouldn't mind.
Someday I might make it more useable myself. Peter's "consume.c" is very useful also. (I haven't posted it in my web notes yet, but I will.)
The 68 hour test was just one of the tests runs, albeit the main one. Among the other tests was what I call the "Charles Wang" scenario, high frequency high loads.
The only operating scenario of potential concern was around higher loads higher number of processes, where the reported load average Was a little low and worse than the same conditions without this patch, although still pretty good (graph attached).
PATCH 12/37 intel_ips: blacklist HP ProBook laptops
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit 88ca518b0bb4161e5f20f8a1d9cc477cae294e54 upstream.
intel_ips driver spews the warning message
"ME failed to update for more than 1s, likely hung"
at each second endlessly on HP ProBook laptops with IronLake.
As this has never worked, better to blacklist the driver for now.
--- drivers/platform/x86/intel_ips.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+)
drivers/platform/x86/intel_ips.c +22 -0
@@ -72,6 +72,7 @@#include <linux/string.h> #include <linux/tick.h> #include <linux/timer.h> +#include <linux/dmi.h> #include <drm/i915_drm.h> #include <asm/msr.h> #include <asm/processor.h>
@@ -1485,6 +1486,24 @@ static DEFINE_PCI_DEVICE_TABLE(ips_id_taMODULE_DEVICE_TABLE (pci, ips_id_table); +static int ips_blacklist_callback (const struct dmi_system_id *id) +{ +pr_info ("Blacklisted intel_ips for %s\n" , id->ident); +return 1 ; +} + +static const struct dmi_system_id ips_blacklist[] = { + { + .callback = ips_blacklist_callback, + .ident ="HP ProBook" , + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"Hewlett-Packard" ), +DMI_MATCH (DMI_PRODUCT_NAME ,"HP ProBook" ), + }, + }, + { }/* terminating entry */ +}; +static int ips_probe (struct pci_dev *dev,const struct pci_device_id *id) {u64 platform_info;
@@ -1494,6 +1513,9 @@ static int ips_probe(struct pci_dev *devu16 htshi, trc, trc_required_mask;u8 tse; +if (dmi_check_system (ips_blacklist)) +return -ENODEV ; + ips =kzalloc (sizeof (struct ips_driver ),GFP_KERNEL );if (!ips)return -ENOMEM ;
PATCH 13/37 fifo: Do not restart open() if it already found a partner
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anders Kaseorg <[email protected]>
commit 05d290d66be6ef77a0b962ebecf01911bd984a78 upstream.
If a parent and child process open the two ends of a fifo, and the child immediately exits, the parent may receive a SIGCHLD before its open() returns. In that case, we need to make sure that open() will return successfully after the SIGCHLD handler returns, instead of throwing EINTR or being restarted. Otherwise, the restarted open() would incorrectly wait for a second partner on the other end.
The following test demonstrates the EINTR that was wrongly thrown from the parent’s open(). Change .sa_flags = 0 to .sa_flags = SA_RESTART to see a deadlock instead, in which the restarted open() waits for a second reader that will never come. (On my systems, this happens pretty reliably within about 5 to 500 iterations. Others report that it manages to loop ~forever sometimes; YMMV.)
#include <sys/stat.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <fcntl.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#define CHECK(x) do if ((x) == -1) {perror(#x); abort();} while(0)void handler(int signum) {}
int main()
{
struct sigaction act = {.sa_handler = handler, .sa_flags = 0};
CHECK(sigaction(SIGCHLD, &act, NULL));
CHECK(mknod("fifo", S_IFIFO | S_IRWXU, 0));
for (;;) {
int fd;
pid_t pid;
putc('.', stderr);
CHECK(pid = fork());
if (pid == 0) {
CHECK(fd = open("fifo", O_RDONLY));
_exit(0);
}
CHECK(fd = open("fifo", O_WRONLY));
CHECK(close(fd));
CHECK(waitpid(pid, NULL, 0));
}
}This is what I suspect was causing the Git test suite to fail in t9010-svn-fe.sh:
http://bugs.debian.org/678852
--- fs/fifo.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-)
fs/fifo.c +4 -5
@@ -14,7 +14,7 @@#include <linux/sched.h> #include <linux/pipe_fs_i.h> -static void wait_for_partner (struct inode * inode,unsigned int *cnt) +static int wait_for_partner (struct inode * inode,unsigned int *cnt) {int cur = *cnt;
@@ -23,6 +23,7 @@ static void wait_for_partner(struct inodif (signal_pending (current))break ; } +return cur == *cnt ? -ERESTARTSYS :0 ; }static void wake_up_partner (struct inode * inode)
@@ -67,8 +68,7 @@ static int fifo_open(struct inode *inode* seen a writer */ filp->f_version = pipe->w_counter; }else { -wait_for_partner (inode, &pipe->w_counter); -if (signal_pending (current)) +if (wait_for_partner (inode, &pipe->w_counter)) goto err_rd; } }
@@ -90,8 +90,7 @@ static int fifo_open(struct inode *inodewake_up_partner (inode);if (!pipe->readers) { -wait_for_partner (inode, &pipe->r_counter); -if (signal_pending (current)) +if (wait_for_partner (inode, &pipe->r_counter)) goto err_wr; }break ;
PATCH 14/37 rt2x00usb: fix indexes ordering on RX queue kick
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stanislaw Gruszka <[email protected]>
commit efd821182cec8c92babef6e00a95066d3252fda4 upstream.
On rt2x00_dmastart() we increase index specified by Q_INDEX and on rt2x00_dmadone() we increase index specified by Q_INDEX_DONE. So entries between Q_INDEX_DONE and Q_INDEX are those we currently process in the hardware. Entries between Q_INDEX and Q_INDEX_DONE are those we can submit to the hardware.
According to that fix rt2x00usb_kick_queue(), as we need to submit RX entries that are not processed by the hardware. It worked before only for empty queue, otherwise was broken.
Note that for TX queues indexes ordering are ok. We need to kick entries that have filled skb, but was not submitted to the hardware, i.e. started from Q_INDEX_DONE and have ENTRY_DATA_PENDING bit set.
Quoted 1 line
From practical standpoint this fixes RX queue stall, usually reproducible
in AP mode, like for example reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=828824
--- drivers/net/wireless/rt2x00/rt2x00usb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/wireless/rt2x00/rt2x00usb.c +1 -1
@@ -436,8 +436,8 @@ void rt2x00usb_kick_queue(struct data_qucase QID_RX :if (!rt2x00queue_full (queue))rt2x00queue_for_each_entry (queue, -Q_INDEX_DONE ,Q_INDEX , +Q_INDEX_DONE ,NULL , rt2x00usb_kick_rx_entry);break ;
PATCH 15/37 e1000e: Correct link check logic for 82571 serdes
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tushar Dave <[email protected]>
commit d0efa8f23a644f7cb7d1f8e78dd9a223efa412a3 upstream.
SYNCH bit and IV bit of RXCW register are sticky. Before examining these bits, RXCW should be read twice to filter out one-time false events and have correct values for these bits. Incorrect values of these bits in link check logic can cause weird link stability issues if auto-negotiation fails.
--- drivers/net/ethernet/intel/e1000e/82571.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/net/ethernet/intel/e1000e/82571.c +3 -0
@@ -1553,6 +1553,9 @@ static s32 e1000_check_for_serdes_link_8 ctrl =er32 (CTRL ); status =er32 (STATUS ); rxcw =er32 (RXCW ); +/* SYNCH bit and IV bit are sticky */ +udelay (10 ); + rxcw =er32 (RXCW );if ((rxcw &E1000_RXCW_SYNCH ) && !(rxcw &E1000_RXCW_IV )) {
PATCH 16/37 iwlegacy: always monitor for stuck queues
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stanislaw Gruszka <[email protected]>
commit c2ca7d92ed4bbd779516beb6eb226e19f7f7ab0f upstream.
This is iwlegacy version of:
commit 342bbf3fee2fa9a18147e74b2e3c4229a4564912
Author: Johannes Berg <[email protected]> Date: Sun Mar 4 08:50:46 2012 -0800
iwlwifi: always monitor for stuck queues
If we only monitor while associated, the following can happen:
- we're associated, and the queue stuck check runs, setting the queue "touch" time to X
- we disassociate, stopping the monitoring, which leaves the time set to X
- almost 2s later, we associate, and enqueue a frame
- before the frame is transmitted, we monitor for stuck queues, and find the time set to X, although it is now later than X + 2000ms, so we decide that the queue is stuck and erroneously restart the device
--- drivers/net/wireless/iwlegacy/common.c | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-)
drivers/net/wireless/iwlegacy/common.c +6 -8
@@ -4767,14 +4767,12 @@ il_bg_watchdog(unsigned long data)return ;/* monitor and check for other stuck queues */ -if (il_is_any_associated (il)) { -for (cnt =0 ; cnt < il->hw_params.max_txq_num; cnt++) { -/* skip as we already checked the command queue */ -if (cnt == il->cmd_queue) -continue ; -if (il_check_stuck_queue (il, cnt)) -return ; - } +for (cnt =0 ; cnt < il->hw_params.max_txq_num; cnt++) { +/* skip as we already checked the command queue */ +if (cnt == il->cmd_queue) +continue ; +if (il_check_stuck_queue (il, cnt)) +return ; } mod_timer(&il->watchdog,
PATCH 17/37 iwlegacy: dont mess up the SCD when removing a key
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Emmanuel Grumbach <[email protected]>
commit b48d96652626b315229b1b82c6270eead6a77a6d upstream.
When we remove a key, we put a key index which was supposed to tell the fw that we are actually removing the key. But instead the fw took that index as a valid index and messed up the SRAM of the device.
This memory corruption on the device mangled the data of the SCD. The impact on the user is that SCD queue 2 got stuck after having removed keys.
--- drivers/net/wireless/iwlegacy/4965-mac.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/wireless/iwlegacy/4965-mac.c +2 -2
@@ -3405,7 +3405,7 @@ il4965_remove_dynamic_key(struct il_privreturn 0 ; } -if (il->stations[sta_id].sta.key.key_offset ==WEP_INVALID_OFFSET ) { +if (il->stations[sta_id].sta.key.key_flags &STA_KEY_FLG_INVALID ) {IL_WARN ("Removing wrong key %d 0x%x\n" , keyconf->keyidx, key_flags);spin_unlock_irqrestore (&il->sta_lock, flags);
@@ -3420,7 +3420,7 @@ il4965_remove_dynamic_key(struct il_privmemset (&il->stations[sta_id].sta.key,0 ,sizeof (struct il4965_keyinfo )); il->stations[sta_id].sta.key.key_flags =STA_KEY_FLG_NO_ENC |STA_KEY_FLG_INVALID ; - il->stations[sta_id].sta.key.key_offset =WEP_INVALID_OFFSET ; + il->stations[sta_id].sta.key.key_offset = keyconf->hw_key_idx; il->stations[sta_id].sta.sta.modify_mask =STA_MODIFY_KEY_MASK ; il->stations[sta_id].sta.mode =STA_CONTROL_MODIFY_MSK ;
PATCH 18/37 rpmsg: fix dependency on initialization order
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Federico Fuga <[email protected]>
commit 9634252617441991b01dacaf4040866feecaf36f upstream.
When rpmsg drivers are built into the kernel, they must not initialize before the rpmsg bus does, otherwise they'd trigger a BUG() in drivers/base/driver.c line 169 (driver_register()).
To fix that, and to stop depending on arbitrary linkage ordering of those built-in rpmsg drivers, we make the rpmsg bus initialize at subsys_initcall.
--- drivers/rpmsg/virtio_rpmsg_bus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/rpmsg/virtio_rpmsg_bus.c +1 -1
@@ -1085,7 +1085,7 @@ static int __init rpmsg_init(void)return ret; } -module_init (rpmsg_init); +subsys_initcall (rpmsg_init); static void __exit rpmsg_fini(void) {
PATCH 19/37 mac80211: destroy assoc_data correctly if assoc fails
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eliad Peller <[email protected]>
commit 10a9109f2705fdc3caa94d768b2559587a9a050c upstream.
If association failed due to internal error (e.g. no supported rates IE), we call ieee80211_destroy_assoc_data() with assoc=true, while we actually reject the association.
This results in the BSSID not being zeroed out.
After passing assoc=false, we no longer have to call sta_info_destroy_addr() explicitly. While on it, move the "associated" message after the assoc_success check.
--- net/mac80211/mlme.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
net/mac80211/mlme.c +2 -4
@@ -2183,15 +2183,13 @@ ieee80211_rx_mgmt_assoc_resp(struct ieee sdata->name, mgmt->sa, status_code);ieee80211_destroy_assoc_data (sdata, false); }else { -printk (KERN_DEBUG "%s: associated\n" , sdata->name); -if (!ieee80211_assoc_success (sdata, *bss, mgmt, len)) {/* oops -- internal error -- send timeout for now */ -ieee80211_destroy_assoc_data (sdata, true); -sta_info_destroy_addr (sdata, mgmt->bssid); +ieee80211_destroy_assoc_data (sdata, false);cfg80211_put_bss (*bss);return RX_MGMT_CFG80211_ASSOC_TIMEOUT ; } +printk (KERN_DEBUG "%s: associated\n" , sdata->name);/* * destroy assoc_data afterwards, as otherwise an idle
PATCH 20/37 stmmac: Fix for nfs hang on multiple reboot
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Deepak Sikri <[email protected]>
commit 8e83989106562326bfd6aaf92174fe138efd026b upstream.
It was observed that during multiple reboots nfs hangs. The status of receive descriptors shows that all the descriptors were in control of CPU, and none were assigned to DMA.
Also the DMA status register confirmed that the Rx buffer is unavailable.
This patch adds the fix for the same by adding the memory barriers to ascertain that the all instructions before enabling the Rx or Tx DMA are completed which involves the proper setting of the ownership bit in DMA descriptors.
--- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +3 -0
@@ -1158,6 +1158,7 @@ static netdev_tx_t stmmac_xmit(struct sk priv->hw->desc->prepare_tx_desc (desc,0 , len, csum_insertion);wmb (); priv->hw->desc->set_tx_owner (desc); +wmb (); }/* Interrupt on completition only for the latest segment */
@@ -1173,6 +1174,7 @@ static netdev_tx_t stmmac_xmit(struct sk/* To avoid raise condition */ priv->hw->desc->set_tx_owner (first); +wmb (); priv->cur_tx++;
@@ -1236,6 +1238,7 @@ static inline void stmmac_rx_refill(stru }wmb (); priv->hw->desc->set_rx_owner (p + entry); +wmb (); } }
PATCH 21/37 bonding: debugfs and network namespaces are incompatible
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Eric W. Biederman" <[email protected]>
commit 96ca7ffe748bf91f851e6aa4479aa11c8b1122ba upstream.
The bonding debugfs support has been broken in the presence of network namespaces since it has been added. The debugfs support does not handle multiple bonding devices with the same name in different network namespaces.
I haven't had any bug reports, and I'm not interested in getting any. Disable the debugfs support when network namespaces are enabled.
--- drivers/net/bonding/bond_debugfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/bonding/bond_debugfs.c +1 -1
@@ -6,7 +6,7 @@#include "bonding.h" #include "bond_alb.h" -#ifdef CONFIG_DEBUG_FS +#if defined(CONFIG_DEBUG_FS ) && !defined(CONFIG_NET_NS )#include <linux/debugfs.h> #include <linux/seq_file.h>
PATCH 22/37 bonding: Manage /proc/net/bonding/ entries from the netdev events
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Eric W. Biederman" <[email protected]>
commit a64d49c3dd504b685f9742a2f3dcb11fb8e4345f upstream.
It was recently reported that moving a bonding device between network namespaces causes warnings from /proc. It turns out after the move we were trying to add and to remove the /proc/net/bonding entries from the wrong network namespace.
Move the bonding /proc registration code into the NETDEV_REGISTER and NETDEV_UNREGISTER events where the proc registration and unregistration will always happen at the right time.
--- drivers/net/bonding/bond_main.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
drivers/net/bonding/bond_main.c +6 -3
@@ -3218,6 +3218,12 @@ static int bond_master_netdev_event(unsiswitch (event) {case NETDEV_CHANGENAME :return bond_event_changename (event_bond); +case NETDEV_UNREGISTER : +bond_remove_proc_entry (event_bond); +break ; +case NETDEV_REGISTER : +bond_create_proc_entry (event_bond); +break ;default :break ; }
@@ -4402,8 +4408,6 @@ static void bond_uninit(struct net_devicbond_work_cancel_all (bond); -bond_remove_proc_entry (bond); -bond_debug_unregister (bond);__hw_addr_flush (&bond->mc_list);
@@ -4805,7 +4809,6 @@ static int bond_init(struct net_device *bond_set_lockdep_class (bond_dev); -bond_create_proc_entry (bond);list_add_tail (&bond->bond_list, &bn->dev_list);bond_prepare_sysfs_group (bond);
PATCH 23/37 Input: bcm5974 - Add support for 2012 MacBook Pro Retina
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Henrik Rydberg <[email protected]>
commit 3dde22a98e94eb18527f0ff0068fb2fb945e58d4 upstream.
Add support for the 15'' MacBook Pro Retina model (MacBookPro10,1).
Patch originally written by clipcarl (forums.opensuse.org).
--- drivers/input/mouse/bcm5974.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)
drivers/input/mouse/bcm5974.c +20 -0
@@ -79,6 +79,10 @@#define USB_DEVICE_ID_APPLE_WELLSPRING5A_ANSI 0x0252#define USB_DEVICE_ID_APPLE_WELLSPRING5A_ISO 0x0253#define USB_DEVICE_ID_APPLE_WELLSPRING5A_JIS 0x0254 +/* MacbookPro10,1 (unibody, June 2012) */ +#define USB_DEVICE_ID_APPLE_WELLSPRING7_ANSI 0x0262 +#define USB_DEVICE_ID_APPLE_WELLSPRING7_ISO 0x0263 +#define USB_DEVICE_ID_APPLE_WELLSPRING7_JIS 0x0264#define BCM5974_DEVICE (prod) { \ .match_flags = (USB_DEVICE_ID_MATCH_DEVICE | \
@@ -128,6 +132,10 @@ static const struct usb_device_id bcm597BCM5974_DEVICE (USB_DEVICE_ID_APPLE_WELLSPRING5A_ANSI ),BCM5974_DEVICE (USB_DEVICE_ID_APPLE_WELLSPRING5A_ISO ),BCM5974_DEVICE (USB_DEVICE_ID_APPLE_WELLSPRING5A_JIS ), +/* MacbookPro10,1 */ +BCM5974_DEVICE (USB_DEVICE_ID_APPLE_WELLSPRING7_ANSI ), +BCM5974_DEVICE (USB_DEVICE_ID_APPLE_WELLSPRING7_ISO ), + BCM5974_DEVICE(USB_DEVICE_ID_APPLE_WELLSPRING7_JIS), /* Terminating entry */ {} };
@@ -354,6 +362,18 @@ static const struct bcm5974_config bcm59 { DIM_X, DIM_X / SN_COORD, -4620, 5140 }, { DIM_Y, DIM_Y / SN_COORD, -150, 6600 } }, + { +USB_DEVICE_ID_APPLE_WELLSPRING7_ANSI , +USB_DEVICE_ID_APPLE_WELLSPRING7_ISO , +USB_DEVICE_ID_APPLE_WELLSPRING7_JIS , +HAS_INTEGRATED_BUTTON , +0x84 ,sizeof (struct bt_data ), +0x81 ,TYPE2 ,FINGER_TYPE2 ,FINGER_TYPE2 +SIZEOF_ALL_FINGERS , + { DIM_PRESSURE, DIM_PRESSURE / SN_PRESSURE, 0, 300 }, + { DIM_WIDTH, DIM_WIDTH / SN_WIDTH, 0, 2048 }, + { DIM_X, DIM_X / SN_COORD, -4750, 5280 }, + { DIM_Y, DIM_Y / SN_COORD, -150, 6730 } + }, {} };
PATCH 24/37 Input: xpad - handle all variations of Mad Catz Beat Pad
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yuri Khan <[email protected]>
commit 3ffb62cb9ac2430c2504c6ff9727d0f2476ef0bd upstream.
The device should be handled by xpad driver instead of generic HID driver.
--- drivers/hid/hid-core.c | 1 + drivers/hid/hid-ids.h | 3 +++ drivers/input/joystick/xpad.c | 1 + 3 files changed, 5 insertions(+)
drivers/hid/hid-core.c +1 -0
@@ -1914,6 +1914,7 @@ static const struct hid_device_id hid_ig { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MCT) }, { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_HYBRID) }, { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_HEATCONTROL) }, + { HID_USB_DEVICE(USB_VENDOR_ID_MADCATZ, USB_DEVICE_ID_MADCATZ_BEATPAD) }, { HID_USB_DEVICE(USB_VENDOR_ID_MCC, USB_DEVICE_ID_MCC_PMD1024LS) }, { HID_USB_DEVICE(USB_VENDOR_ID_MCC, USB_DEVICE_ID_MCC_PMD1208LS) }, { HID_USB_DEVICE(USB_VENDOR_ID_MICROCHIP, USB_DEVICE_ID_PICKIT1) },
drivers/hid/hid-ids.h +3 -0
@@ -509,6 +509,9 @@#define USB_DEVICE_ID_CRYSTALTOUCH 0x0006#define USB_DEVICE_ID_CRYSTALTOUCH_DUAL 0x0007 +#define USB_VENDOR_ID_MADCATZ 0x0738 +#define USB_DEVICE_ID_MADCATZ_BEATPAD 0x4540 +#define USB_VENDOR_ID_MCC 0x09db#define USB_DEVICE_ID_MCC_PMD1024LS 0x0076#define USB_DEVICE_ID_MCC_PMD1208LS 0x007a
drivers/input/joystick/xpad.c +1 -0
@@ -238,6 +238,7 @@ static struct usb_device_id xpad_table [XPAD_XBOX360_VENDOR (0x045e ),/* Microsoft X-Box 360 controllers */ XPAD_XBOX360_VENDOR (0x046d ),/* Logitech X-Box 360 style controllers */ XPAD_XBOX360_VENDOR (0x0738 ),/* Mad Catz X-Box 360 controllers */ + { USB_DEVICE(0x0738, 0x4540) }, /* Mad Catz Beat Pad */XPAD_XBOX360_VENDOR (0x0e6f ),/* 0x0e6f X-Box 360 controllers */ XPAD_XBOX360_VENDOR (0x12ab ),/* X-Box 360 dance pads */ XPAD_XBOX360_VENDOR(0x1430), /* RedOctane X-Box 360 controllers */
PATCH 25/37 Input: xpad - add signature for Razer Onza Tournament Edition
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ilia Katsnelson <[email protected]>
commit cc71a7e899cc6b2ff41e1be48756782ed004d802 upstream.
--- drivers/input/joystick/xpad.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/input/joystick/xpad.c +3 -1
@@ -164,6 +164,7 @@ static const struct xpad_device { { 0x1bad, 0x0003, "Harmonix Rock Band Drumkit", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360 }, { 0x0f0d, 0x0016, "Hori Real Arcade Pro.EX", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 }, { 0x0f0d, 0x000d, "Hori Fighting Stick EX2", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 }, + { 0x1689, 0xfd00, "Razer Onza Tournament Edition", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360 }, { 0xffff, 0xffff, "Chinese-made Xbox Controller", 0, XTYPE_XBOX }, { 0x0000, 0x0000, "Generic X-Box pad", 0, XTYPE_UNKNOWN } };
@@ -244,7 +245,8 @@ static struct usb_device_id xpad_table [XPAD_XBOX360_VENDOR (0x1430 ),/* RedOctane X-Box 360 controllers */ XPAD_XBOX360_VENDOR (0x146b ),/* BigBen Interactive Controllers */ XPAD_XBOX360_VENDOR (0x1bad ),/* Harminix Rock Band Guitar and Drums */ - XPAD_XBOX360_VENDOR(0x0f0d), /* Hori Controllers */ +XPAD_XBOX360_VENDOR (0x0f0d ),/* Hori Controllers */ + XPAD_XBOX360_VENDOR(0x1689), /* Razer Onza */ { } };
PATCH 26/37 Input: xpad - add Andamiro Pump It Up pad
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yuri Khan <[email protected]>
commit e76b8ee25e034ab601b525abb95cea14aa167ed3 upstream.
I couldn't find the vendor ID in any of the online databases, but this mat has a Pump It Up logo on the top side of the controller compartment, and a disclaimer stating that Andamiro will not be liable on the bottom.
--- drivers/input/joystick/xpad.c | 1 + 1 file changed, 1 insertion(+)
drivers/input/joystick/xpad.c +1 -0
@@ -142,6 +142,7 @@ static const struct xpad_device { { 0x0c12, 0x880a, "Pelican Eclipse PL-2023", 0, XTYPE_XBOX }, { 0x0c12, 0x8810, "Zeroplus Xbox Controller", 0, XTYPE_XBOX }, { 0x0c12, 0x9902, "HAMA VibraX - *FAULTY HARDWARE*", 0, XTYPE_XBOX }, + { 0x0d2f, 0x0002, "Andamiro Pump It Up pad", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX }, { 0x0e4c, 0x1097, "Radica Gamester Controller", 0, XTYPE_XBOX }, { 0x0e4c, 0x2390, "Radica Games Jtech Controller", 0, XTYPE_XBOX }, { 0x0e6f, 0x0003, "Logic3 Freebird wireless Controller", 0, XTYPE_XBOX },
PATCH 27/37 HID: add support for 2012 MacBook Pro Retina
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ryan Bourgeois <[email protected]>
commit b2e6ad7dfe26aac5bf136962d0b11d180b820d44 upstream.
Add support for the 15'' MacBook Pro Retina. The keyboard is the same as recent models.
The patch needs to be synchronized with the bcm5974 patch for the trackpad - as usual.
Patch originally written by clipcarl (forums.opensuse.org).
--- drivers/hid/hid-apple.c | 6 ++++++ drivers/hid/hid-core.c | 6 ++++++ drivers/hid/hid-ids.h | 3 +++ 3 files changed, 15 insertions(+)
drivers/hid/hid-apple.c +6 -0
@@ -514,6 +514,12 @@ static const struct hid_device_id apple_ .driver_data = APPLE_HAS_FN | APPLE_ISO_KEYBOARD }, { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING5A_JIS), .driver_data = APPLE_HAS_FN | APPLE_RDESC_JIS }, + { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING7_ANSI), + .driver_data = APPLE_HAS_FN }, + { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING7_ISO), + .driver_data = APPLE_HAS_FN | APPLE_ISO_KEYBOARD }, + { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING7_JIS), + .driver_data = APPLE_HAS_FN | APPLE_RDESC_JIS }, { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ANSI), .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN }, { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ISO),
drivers/hid/hid-core.c +6 -0
@@ -1379,6 +1379,9 @@ static const struct hid_device_id hid_ha { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING6A_ANSI) }, { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING6A_ISO) }, { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING6A_JIS) }, + { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING7_ANSI) }, + { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING7_ISO) }, + { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING7_JIS) }, { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ANSI) }, { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ISO) }, { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_JIS) },
@@ -2009,6 +2012,9 @@ static const struct hid_device_id hid_mo { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING6A_ANSI) }, { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING6A_ISO) }, { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING6A_JIS) }, + { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING7_ANSI) }, + { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING7_ISO) }, + { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING7_JIS) }, { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_TP_ONLY) }, { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER1_TP_ONLY) }, { }
drivers/hid/hid-ids.h +3 -0
@@ -125,6 +125,9 @@#define USB_DEVICE_ID_APPLE_WELLSPRING6_ANSI 0x024c#define USB_DEVICE_ID_APPLE_WELLSPRING6_ISO 0x024d#define USB_DEVICE_ID_APPLE_WELLSPRING6_JIS 0x024e +#define USB_DEVICE_ID_APPLE_WELLSPRING7_ANSI 0x0262 +#define USB_DEVICE_ID_APPLE_WELLSPRING7_ISO 0x0263 +#define USB_DEVICE_ID_APPLE_WELLSPRING7_JIS 0x0264#define USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ANSI 0x0239#define USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ISO 0x023a#define USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_JIS 0x023b
PATCH 28/37 clk: Check parent for NULL in clk_change_rate
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pawel Moll <[email protected]>
commit bf47b4fd8f9f81cd5ce40e1945c6334d088226d1 upstream.
clk_change_rate() is accessing parent's rate without checking if the parent exists at all. In case of root clocks this will cause NULL pointer dereference.
This patch follows what clk_calc_new_rates() does in such situation.
--- drivers/clk/clk.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
drivers/clk/clk.c +6 -3
@@ -834,18 +834,21 @@ static void clk_change_rate(struct clk * {struct clk *child;unsigned long old_rate; +unsigned long best_parent_rate =0 ;struct hlist_node *tmp; old_rate = clk->rate; +if (clk->parent) + best_parent_rate = clk->parent->rate; +if (clk->ops->set_rate) clk->ops->set_rate (clk->hw, clk->new_rate);if (clk->ops->recalc_rate) - clk->rate = clk->ops->recalc_rate (clk->hw, - clk->parent->rate); + clk->rate = clk->ops->recalc_rate (clk->hw, best_parent_rate);else - clk->rate = clk->parent->rate; + clk->rate = best_parent_rate;if (clk->notifier_count && old_rate != clk->rate)__clk_notify (clk,POST_RATE_CHANGE , old_rate, clk->rate);
PATCH 29/37 cfg80211: check iface combinations only when iface is running
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michal Kazior <[email protected]>
commit f8cdddb8d61d16a156229f0910f7ecfc7a82c003 upstream.
Don't validate interface combinations on a stopped interface. Otherwise we might end up being able to create a new interface with a certain type, but won't be able to change an existing interface into that type.
This also skips some other functions when interface is stopped and changing interface type.
--- net/wireless/util.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/wireless/util.c +1 -1
@@ -805,7 +805,7 @@ int cfg80211_change_iface(struct cfg8021 ntype == NL80211_IFTYPE_P2P_CLIENT))return -EBUSY ; -if (ntype != otype) { +if (ntype != otype &&netif_running (dev)) { err =cfg80211_can_change_interface (rdev, dev->ieee80211_ptr, ntype);if (err)
PATCH 30/37 hrtimer: Provide clock_was_set_delayed()
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: John Stultz <[email protected]>
This is a backport of f55a6faa384304c89cfef162768e88374d3312cb
clock_was_set() cannot be called from hard interrupt context because it calls on_each_cpu().
For fixing the widely reported leap seconds issue it is necessary to call it from hard interrupt context, i.e. the timer tick code, which does the timekeeping updates.
Provide a new function which denotes it in the hrtimer cpu base structure of the cpu on which it is called and raise the hrtimer softirq. We then execute the clock_was_set() notificiation from softirq context in run_hrtimer_softirq(). The hrtimer softirq is rarely used, so polling the flag there is not a performance issue.
[ tglx: Made it depend on CONFIG_HIGH_RES_TIMERS. We really should get
rid of all this ifdeffery ASAP ]
--- include/linux/hrtimer.h | 9 ++++++++- kernel/hrtimer.c | 20 ++++++++++++++++++++ 2 files changed, 28 insertions(+), 1 deletion(-)
include/linux/hrtimer.h +8 -1
@@ -165,6 +165,7 @@ enum hrtimer_base_type {* @lock: lock protecting the base and associated clock bases * and timers * @active_bases: Bitfield to mark bases with active timers +* @clock_was_set: Indicates that clock was set from irq context. * @expires_next: absolute time of the next event which was scheduled * via clock_set_next_event() * @hres_active: State of high resolution mode
@@ -177,7 +178,8 @@ enum hrtimer_base_type {*/ struct hrtimer_cpu_base {raw_spinlock_t lock; -unsigned long active_bases; +unsigned int active_bases; +unsigned int clock_was_set;#ifdef CONFIG_HIGH_RES_TIMERS ktime_t expires_next;int hres_active;
@@ -286,6 +288,8 @@ extern void hrtimer_peek_ahead_timers(vo# define MONOTONIC_RES_NSEC HIGH_RES_NSEC# define KTIME_MONOTONIC_RES KTIME_HIGH_RES +extern void clock_was_set_delayed (void ); +#else # define MONOTONIC_RES_NSEC LOW_RES_NSEC
@@ -306,6 +310,9 @@ static inline int hrtimer_is_hres_active {return 0 ; } + +static inline void clock_was_set_delayed (void ) { } +#endif extern void clock_was_set (void );
kernel/hrtimer.c +20 -0
@@ -717,6 +717,19 @@ static int hrtimer_switch_to_hres(void) return 1; } +/* +* Called from timekeeping code to reprogramm the hrtimer interrupt +* device. If called from the timer interrupt context we defer it to +* softirq context. +*/ +void clock_was_set_delayed (void ) +{ +struct hrtimer_cpu_base *cpu_base = &__get_cpu_var (hrtimer_bases); + + cpu_base->clock_was_set =1 ; +__raise_softirq_irqoff (HRTIMER_SOFTIRQ ); +} +#else static inline int hrtimer_hres_active (void ) {return 0 ; }
@@ -1395,6 +1408,13 @@ void hrtimer_peek_ahead_timers(void)static void run_hrtimer_softirq (struct softirq_action *h) { +struct hrtimer_cpu_base *cpu_base = &__get_cpu_var (hrtimer_bases); + +if (cpu_base->clock_was_set) { + cpu_base->clock_was_set =0 ; +clock_was_set (); + } +hrtimer_peek_ahead_timers (); }
PATCH 31/37 timekeeping: Fix leapsecond triggered load spike issue
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: John Stultz <[email protected]>
This is a backport of 4873fa070ae84a4115f0b3c9dfabc224f1bc7c51
The timekeeping code misses an update of the hrtimer subsystem after a leap second happened. Due to that timers based on CLOCK_REALTIME are either expiring a second early or late depending on whether a leap second has been inserted or deleted until an operation is initiated which causes that update. Unless the update happens by some other means this discrepancy between the timekeeping and the hrtimer data stays forever and timers are expired either early or late.
The reported immediate workaround - $ data -s "date" - is causing a call to clock_was_set() which updates the hrtimer data structures.
See: http://www.sheeri.com/content/mysql-and-leap-second-high-cpu-and-fix
Add the missing clock_was_set() call to update_wall_time() in case of a leap second event. The actual update is deferred to softirq context as the necessary smp function call cannot be invoked from hard interrupt context.
--- kernel/time/timekeeping.c | 4 ++++ 1 file changed, 4 insertions(+)
kernel/time/timekeeping.c +4 -0
@@ -965,6 +965,8 @@ static cycle_t logarithmic_accumulation( leap =second_overflow (timekeeper.xtime.tv_sec); timekeeper.xtime.tv_sec += leap; timekeeper.wall_to_monotonic.tv_sec -= leap; +if (leap) +clock_was_set_delayed (); }/* Accumulate raw time */
@@ -1081,6 +1083,8 @@ static void update_wall_time(void) leap =second_overflow (timekeeper.xtime.tv_sec); timekeeper.xtime.tv_sec += leap; timekeeper.wall_to_monotonic.tv_sec -= leap; +if (leap) +clock_was_set_delayed (); }timekeeping_update (false);
PATCH 32/37 timekeeping: Maintain ktime_t based offsets for hrtimers
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <[email protected]>
This is a backport of 5b9fe759a678e05be4937ddf03d50e950207c1c0
We need to update the hrtimer clock offsets from the hrtimer interrupt context. To avoid conversions from timespec to ktime_t maintain a ktime_t based representation of those offsets in the timekeeper. This puts the conversion overhead into the code which updates the underlying offsets and provides fast accessible values in the hrtimer interrupt.
--- kernel/time/timekeeping.c | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-)
kernel/time/timekeeping.c +23 -2
@@ -70,6 +70,12 @@ struct timekeeper {/* The raw monotonic time for the CLOCK_MONOTONIC_RAW posix clock. */ struct timespec raw_time; +/* Offset clock monotonic -> clock realtime */ +ktime_t offs_real; + +/* Offset clock monotonic -> clock boottime */ +ktime_t offs_boot; +/* Seqlock for all timekeeper values */ seqlock_t lock; };
@@ -172,6 +178,14 @@ static inline s64 timekeeping_get_ns_rawreturn clocksource_cyc2ns (cycle_delta, clock->mult, clock->shift); } +static void update_rt_offset (void ) +{ +struct timespec tmp, *wtm = &timekeeper.wall_to_monotonic; + +set_normalized_timespec (&tmp, -wtm->tv_sec, -wtm->tv_nsec); + timekeeper.offs_real =timespec_to_ktime (tmp); +} +/* must hold write on timekeeper.lock */ static void timekeeping_update (bool clearntp) {
@@ -179,6 +193,7 @@ static void timekeeping_update(bool clea timekeeper.ntp_error =0 ;ntp_clear (); } +update_rt_offset ();update_vsyscall (&timekeeper.xtime, &timekeeper.wall_to_monotonic, timekeeper.clock, timekeeper.mult); }
@@ -606,6 +621,7 @@ void __init timekeeping_init(void) }set_normalized_timespec (&timekeeper.wall_to_monotonic, -boot.tv_sec, -boot.tv_nsec); +update_rt_offset (); timekeeper.total_sleep_time.tv_sec =0 ; timekeeper.total_sleep_time.tv_nsec =0 ;write_sequnlock_irqrestore (&timekeeper.lock, flags);
@@ -614,6 +630,12 @@ void __init timekeeping_init(void)/* time in seconds when suspend began */ static struct timespec timekeeping_suspend_time; +static void update_sleep_time (struct timespec t) +{ + timekeeper.total_sleep_time = t; + timekeeper.offs_boot =timespec_to_ktime (t); +} +/** * __timekeeping_inject_sleeptime - Internal function to add sleep interval * @delta: pointer to a timespec delta value
@@ -632,8 +654,7 @@ static void __timekeeping_inject_sleepti timekeeper.xtime =timespec_add (timekeeper.xtime, *delta); timekeeper.wall_to_monotonic =timespec_sub (timekeeper.wall_to_monotonic, *delta); - timekeeper.total_sleep_time =timespec_add ( - timekeeper.total_sleep_time, *delta); +update_sleep_time (timespec_add (timekeeper.total_sleep_time, *delta)); }
PATCH 33/37 hrtimers: Move lock held region in hrtimer_interrupt()
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <[email protected]>
This is a backport of 196951e91262fccda81147d2bcf7fdab08668b40
We need to update the base offsets from this code and we need to do that under base->lock. Move the lock held region around the ktime_get() calls. The ktime_get() calls are going to be replaced with a function which gets the time and the offsets atomically.
--- kernel/hrtimer.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
kernel/hrtimer.c +3 -2
@@ -1263,11 +1263,10 @@ void hrtimer_interrupt(struct clock_even cpu_base->nr_events++; dev->next_event.tv64 =KTIME_MAX ; +raw_spin_lock (&cpu_base->lock); entry_time = now =ktime_get (); retry: expires_next.tv64 =KTIME_MAX ; - -raw_spin_lock (&cpu_base->lock);/* * We set expires_next to KTIME_MAX here with cpu_base->lock * held to prevent that a timer is enqueued in our queue via
@@ -1344,6 +1343,7 @@ retry:* interrupt routine. We give it 3 attempts to avoid * overreacting on some spurious event. */ +raw_spin_lock (&cpu_base->lock); now =ktime_get (); cpu_base->nr_retries++;if (++retries <3 )
@@ -1356,6 +1356,7 @@ retry:*/ cpu_base->nr_hangs++; cpu_base->hang_detected =1 ; +raw_spin_unlock (&cpu_base->lock); delta =ktime_sub (now, entry_time);if (delta.tv64 > cpu_base->max_hang_time.tv64) cpu_base->max_hang_time = delta;
PATCH 34/37 timekeeping: Provide hrtimer update function
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <[email protected]>
This is a backport of f6c06abfb3972ad4914cef57d8348fcb2932bc3b
To finally fix the infamous leap second issue and other race windows caused by functions which change the offsets between the various time bases (CLOCK_MONOTONIC, CLOCK_REALTIME and CLOCK_BOOTTIME) we need a function which atomically gets the current monotonic time and updates the offsets of CLOCK_REALTIME and CLOCK_BOOTTIME with minimalistic overhead. The previous patch which provides ktime_t offsets allows us to make this function almost as cheap as ktime_get() which is going to be replaced in hrtimer_interrupt().
--- include/linux/hrtimer.h | 1 + kernel/time/timekeeping.c | 34 ++++++++++++++++++++++++++++++++++ 2 files changed, 35 insertions(+)
include/linux/hrtimer.h +1 -0
@@ -327,6 +327,7 @@ extern ktime_t ktime_get(void);extern ktime_t ktime_get_real (void );extern ktime_t ktime_get_boottime (void );extern ktime_t ktime_get_monotonic_offset (void ); +extern ktime_t ktime_get_update_offsets (ktime_t *offs_real,ktime_t *offs_boot); DECLARE_PER_CPU(struct tick_device, tick_cpu_device);
kernel/time/timekeeping.c +34 -0
@@ -1273,6 +1273,40 @@ void get_xtime_and_monotonic_and_sleep_o }while (read_seqretry (&timekeeper.lock, seq)); } +#ifdef CONFIG_HIGH_RES_TIMERS +/** +* ktime_get_update_offsets - hrtimer helper +* @offs_real: pointer to storage for monotonic -> realtime offset +* @offs_boot: pointer to storage for monotonic -> boottime offset +* +* Returns current monotonic time and updates the offsets +* Called from hrtimer_interupt() or retrigger_next_event() +*/ +ktime_t ktime_get_update_offsets (ktime_t *offs_real,ktime_t *offs_boot) +{ +ktime_t now; +unsigned int seq; +u64 secs, nsecs; + +do { + seq =read_seqbegin (&timekeeper.lock); + + secs = timekeeper.xtime.tv_sec; + nsecs = timekeeper.xtime.tv_nsec; + nsecs +=timekeeping_get_ns (); +/* If arch requires, add in gettimeoffset() */ + nsecs +=arch_gettimeoffset (); + + *offs_real = timekeeper.offs_real; + *offs_boot = timekeeper.offs_boot; + }while (read_seqretry (&timekeeper.lock, seq)); + + now =ktime_add_ns (ktime_set (secs,0 ), nsecs); + now =ktime_sub (now, *offs_real); +return now; +} +#endif +/** * ktime_get_monotonic_offset() - get wall_to_monotonic in ktime_t format */
PATCH 35/37 hrtimer: Update hrtimer base offsets each hrtimer_interrupt
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: John Stultz <[email protected]>
This is a backport of 5baefd6d84163443215f4a99f6a20f054ef11236
The update of the hrtimer base offsets on all cpus cannot be made atomically from the timekeeper.lock held and interrupt disabled region as smp function calls are not allowed there.
clock_was_set(), which enforces the update on all cpus, is called either from preemptible process context in case of do_settimeofday() or from the softirq context when the offset modification happened in the timer interrupt itself due to a leap second.
In both cases there is a race window for an hrtimer interrupt between dropping timekeeper lock, enabling interrupts and clock_was_set() issuing the updates. Any interrupt which arrives in that window will see the new time but operate on stale offsets.
So we need to make sure that an hrtimer interrupt always sees a consistent state of time and offsets.
ktime_get_update_offsets() allows us to get the current monotonic time and update the per cpu hrtimer base offsets from hrtimer_interrupt() to capture a consistent state of monotonic time and the offsets. The function replaces the existing ktime_get() calls in hrtimer_interrupt().
The overhead of the new function vs. ktime_get() is minimal as it just adds two store operations.
This ensures that any changes to realtime or boottime offsets are noticed and stored into the per-cpu hrtimer base structures, prior to any hrtimer expiration and guarantees that timers are not expired early.
--- kernel/hrtimer.c | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-)
kernel/hrtimer.c +14 -14
@@ -657,6 +657,14 @@ static inline int hrtimer_enqueue_reprogreturn 0 ; } +static inline ktime_t hrtimer_update_base (struct hrtimer_cpu_base *base) +{ +ktime_t *offs_real = &base->clock_base[HRTIMER_BASE_REALTIME ].offset; +ktime_t *offs_boot = &base->clock_base[HRTIMER_BASE_BOOTTIME ].offset; + +return ktime_get_update_offsets (offs_real, offs_boot); +} +/* * Retrigger next event is called after clock was set *
@@ -665,22 +673,12 @@ static inline int hrtimer_enqueue_reprogstatic void retrigger_next_event (void *arg) {struct hrtimer_cpu_base *base = &__get_cpu_var (hrtimer_bases); -struct timespec realtime_offset, xtim, wtm, sleep;if (!hrtimer_hres_active ())return ; -/* Optimized out for !HIGH_RES */ -get_xtime_and_monotonic_and_sleep_offset (&xtim, &wtm, &sleep); -set_normalized_timespec (&realtime_offset, -wtm.tv_sec, -wtm.tv_nsec); - -/* Adjust CLOCK_REALTIME offset */ raw_spin_lock (&base->lock); - base->clock_base[HRTIMER_BASE_REALTIME ].offset = -timespec_to_ktime (realtime_offset); - base->clock_base[HRTIMER_BASE_BOOTTIME ].offset = -timespec_to_ktime (sleep); - +hrtimer_update_base (base);hrtimer_force_reprogram (base,0 );raw_spin_unlock (&base->lock); }
@@ -710,7 +708,6 @@ static int hrtimer_switch_to_hres(void) base->clock_base[i].resolution =KTIME_HIGH_RES ;tick_setup_sched_timer (); -/* "Retrigger" the interrupt to get things going */ retrigger_next_event (NULL );local_irq_restore (flags);
@@ -1264,7 +1261,7 @@ void hrtimer_interrupt(struct clock_even dev->next_event.tv64 =KTIME_MAX ;raw_spin_lock (&cpu_base->lock); - entry_time = now =ktime_get (); + entry_time = now =hrtimer_update_base (cpu_base); retry: expires_next.tv64 =KTIME_MAX ;/*
@@ -1342,9 +1339,12 @@ retry:* We need to prevent that we loop forever in the hrtimer * interrupt routine. We give it 3 attempts to avoid * overreacting on some spurious event. +* +* Acquire base lock for updating the offsets and retrieving +* the current time. */ raw_spin_lock (&cpu_base->lock); - now =ktime_get (); + now =hrtimer_update_base (cpu_base); cpu_base->nr_retries++;if (++retries <3 ) goto retry;
PATCH 37/37 NFC: Export nfc.h to userland
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Samuel Ortiz <[email protected]>
commit dbd4fcaf8d664fab4163b1f8682e41ad8bff3444 upstream.
The netlink commands and attributes, along with the socket structure definitions need to be exported.
--- include/linux/Kbuild | 1 + 1 file changed, 1 insertion(+)
include/linux/Kbuild +1 -0
@@ -272,6 +272,7 @@ header-y += netfilter_ipv4.h header-y += netfilter_ipv6.h header-y += netlink.h header-y += netrom.h +header-y += nfc.h header-y += nfs.h header-y += nfs2.h header-y += nfs3.h
Re: [ 01/37] Remove easily user-triggerable BUG from generic_setlease
In reply to Greg Kroah-HartmanQuoted 5 lines · Greg Kroah-Hartman
From: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
Argh, I give up, I just can't get message threading working properly these days. These are the 3.4 patches, in response to the 3.0 patches, and it took 2 tries to send them out due to formail doing wierd things.
Sorry about this people, I'll just give up and use 'git send-email' from now on, as it doesn't cause as many problems as my old scripts seem to.
greg k-h
Re: [ 01/37] Remove easily user-triggerable BUG from generic_setlease
Hi Greg,
Quoted 6 lines · Greg KH
Argh, I give up, I just can't get message threading working properly these days. These are the 3.4 patches, in response to the 3.0 patches, and it took 2 tries to send them out due to formail doing wierd things.
Sorry about this people, I'll just give up and use 'git send-email' from now on, as it doesn't cause as many problems as my old scripts seem to.
In addition to the threading problems, patch 23/23 from the 3.0-stable series seems to have never made it to the list. All the rest are there.
Cheers,
Signature · 1 line
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
Re: formail doing weird things (was: [ 01/37] Remove easily user-triggerable BUG from generic_setlease)
In reply to Greg KHQuoted 10 lines · On 2012-07-17 Tuesday at 17:14 -0700 Greg KH wrote:
Quoted 5 lines · Greg Kroah-Hartman
From: Greg KH <[email protected]>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
Argh, I give up, I just can't get message threading working properly these days. These are the 3.4 patches, in response to the 3.0 patches, and it took 2 tries to send them out due to formail doing wierd things.
A few months ago I could fix my “formail troubles” by removing option “-d” from formail calls in my scripts. formail manpage conceals nasty consequences of “do not require strict mbox format”: nearly any “from” nearby an empty line and probably other things will trigger message splitting.
Maybe this helps you or somebody else.
Sorry for being slightly OT, and many thanks for your great maintainance work on stable kernel releases.
Signature · 1 line
Roland Eggner
PATCH 1/23 hwmon: (it87) Preserve configuration register bits on init
In reply to Greg KHFrom: Greg KH <[email protected]>
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jean Delvare <[email protected]>
commit 41002f8dd5938d5ad1d008ce5bfdbfe47fa7b4e8 upstream.
We were accidentally losing one bit in the configuration register on device initialization. It was reported to freeze one specific system right away. Properly preserve all bits we don't explicitly want to change in order to prevent that.
--- drivers/hwmon/it87.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hwmon/it87.c +1 -1
@@ -2057,7 +2057,7 @@ static void __devinit it87_init_device(s/* Start monitoring */ it87_write_value (data,IT87_REG_CONFIG , - (it87_read_value (data,IT87_REG_CONFIG ) &0x36 ) + (it87_read_value (data,IT87_REG_CONFIG ) &0x3e ) | (update_vbat ?0x41 :0x01 )); }
PATCH 2/23 block: fix infinite loop in __getblk_slow
From: Greg KH <[email protected]>
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jeff Moyer <[email protected]>
commit 91f68c89d8f35fe98ea04159b9a3b42d0149478f upstream.
Commit 080399aaaf35 ("block: don't mark buffers beyond end of disk as mapped") exposed a bug in __getblk_slow that causes mount to hang as it loops infinitely waiting for a buffer that lies beyond the end of the disk to become uptodate.
The problem was initially reported by Torsten Hilbrich here:
https://lkml.org/lkml/2012/6/18/54
and also reported independently here:
http://www.sysresccd.org/forums/viewtopic.php?f=13&t=4511
and then Richard W.M. Jones and Marcos Mello noted a few separate bugzillas also associated with the same issue. This patch has been confirmed to fix:
https://bugzilla.redhat.com/show_bug.cgi?id=835019
The main problem is here, in __getblk_slow:
for (;;) {
struct buffer_head * bh;
int ret;
bh = __find_get_block(bdev, block, size);
if (bh)
return bh;
ret = grow_buffers(bdev, block, size);
if (ret < 0)
return NULL;
if (ret == 0)
free_more_memory();
}__find_get_block does not find the block, since it will not be marked as mapped, and so grow_buffers is called to fill in the buffers for the associated page. I believe the for (;;) loop is there primarily to retry in the case of memory pressure keeping grow_buffers from succeeding. However, we also continue to loop for other cases, like the block lying beond the end of the disk. So, the fix I came up with is to only loop when grow_buffers fails due to memory allocation issues (return value of 0).
The attached patch was tested by myself, Torsten, and Rich, and was found to resolve the problem in call cases.
--- fs/buffer.c | 22 +++++++++++++--------- 1 file changed, 13 insertions(+), 9 deletions(-)
fs/buffer.c +13 -9
@@ -1084,6 +1084,9 @@ grow_buffers(struct block_device *bdev,static struct buffer_head *__getblk_slow (struct block_device *bdev,sector_t block,int size) { +int ret; +struct buffer_head *bh; +/* Size must be multiple of hard sectorsize */ if (unlikely (size & (bdev_logical_block_size (bdev)-1 ) || (size <512 || size >PAGE_SIZE ))) {
@@ -1096,20 +1099,21 @@ __getblk_slow(struct block_device *bdev,return NULL ; } -for (;;) { -struct buffer_head * bh; -int ret; +retry: + bh =__find_get_block (bdev, block, size); +if (bh) +return bh; + ret =grow_buffers (bdev, block, size); +if (ret ==0 ) { +free_more_memory (); + goto retry; + }else if (ret >0 ) { bh =__find_get_block (bdev, block, size);if (bh)return bh; - - ret =grow_buffers (bdev, block, size); -if (ret <0 ) -return NULL ; -if (ret ==0 ) -free_more_memory (); } +return NULL ; }/*
PATCH 3/23 media: dvb-core: Release semaphore on error path dvb_register_device()
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Santosh Nayak <[email protected]>
commit 82163edcdfa4eb3d74516cc8e9f38dd3d039b67d upstream.
There is a missing "up_write()" here. Semaphore should be released before returning error value.
--- drivers/media/dvb/dvb-core/dvbdev.c | 1 + 1 file changed, 1 insertion(+)
drivers/media/dvb/dvb-core/dvbdev.c +1 -0
@@ -243,6 +243,7 @@ int dvb_register_device(struct dvb_adaptif (minor ==MAX_DVB_MINORS ) {kfree (dvbdevfops);kfree (dvbdev); +up_write (&minor_rwsem);mutex_unlock (&dvbdev_register_lock);return -EINVAL ; }
PATCH 4/23 mtd: nandsim: dont open code a do_div helper
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Herton Ronaldo Krzesinski <[email protected]>
commit 596fd46268634082314b3af1ded4612e1b7f3f03 upstream.
We don't need to open code the divide function, just use div_u64 that already exists and do the same job. While this is a straightforward clean up, there is more to that, the real motivation for this.
While building on a cross compiling environment in armel, using gcc 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5), I was getting the following build error:
ERROR: "__aeabi_uldivmod" [drivers/mtd/nand/nandsim.ko] undefined!
After investigating with objdump and hand built assembly version generated with the compiler, I narrowed __aeabi_uldivmod as being generated from the divide function. When nandsim.c is built with -fno-inline-functions-called-once, that happens when CONFIG_DEBUG_SECTION_MISMATCH is enabled, the do_div optimization in arch/arm/include/asm/div64.h doesn't work as expected with the open coded divide function: even if the do_div we are using doesn't have a constant divisor, the compiler still includes the else parts of the optimized do_div macro, and translates the divisions there to use __aeabi_uldivmod, instead of only calling __do_div_asm -> __do_div64 and optimizing/removing everything else out.
So to reproduce, gcc 4.6 plus CONFIG_DEBUG_SECTION_MISMATCH=y and CONFIG_MTD_NAND_NANDSIM=m should do it, building on armel.
After this change, the compiler does the intended thing even with -fno-inline-functions-called-once, and optimizes out as expected the constant handling in the optimized do_div on arm. As this also avoids a build issue, I'm marking for Stable, as I think is applicable for this case.
--- drivers/mtd/nand/nandsim.c | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-)
drivers/mtd/nand/nandsim.c +3 -9
@@ -28,7 +28,7 @@#include <linux/module.h> #include <linux/moduleparam.h> #include <linux/vmalloc.h> -#include <asm/div64.h> +#include <linux/math64.h> #include <linux/slab.h> #include <linux/errno.h> #include <linux/string.h>
@@ -547,12 +547,6 @@ static char *get_partition_name(int i)return kstrdup (buf,GFP_KERNEL ); } -static uint64_t divide (uint64_t n,uint32_t d) -{ -do_div (n, d); -return n; -} -/* * Initialize the nandsim structure. *
@@ -581,7 +575,7 @@ static int init_nandsim(struct mtd_info ns->geom.oobsz = mtd->oobsize; ns->geom.secsz = mtd->erasesize; ns->geom.pgszoob = ns->geom.pgsz + ns->geom.oobsz; - ns->geom.pgnum =divide (ns->geom.totsz, ns->geom.pgsz); + ns->geom.pgnum =div_u64 (ns->geom.totsz, ns->geom.pgsz); ns->geom.totszoob = ns->geom.totsz + (uint64_t )ns->geom.pgnum * ns->geom.oobsz; ns->geom.secshift =ffs (ns->geom.secsz) -1 ; ns->geom.pgshift = chip->page_shift;
@@ -924,7 +918,7 @@ static int setup_wear_reporting(struct mif (!rptwear)return 0 ; - wear_eb_count =divide (mtd->size, mtd->erasesize); + wear_eb_count =div_u64 (mtd->size, mtd->erasesize); mem = wear_eb_count *sizeof (unsigned long );if (mem /sizeof (unsigned long ) != wear_eb_count) {NS_ERR ("Too many erase blocks for wear reporting\n" );
PATCH 5/23 ARM: SAMSUNG: fix race in s3c_adc_start for ADC
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Todd Poynor <[email protected]>
commit 8265981bb439f3ecc5356fb877a6c2a6636ac88a upstream.
Checking for adc->ts_pend already claimed should be done with the lock held.
--- arch/arm/plat-samsung/adc.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
arch/arm/plat-samsung/adc.c +5 -3
@@ -143,11 +143,13 @@ int s3c_adc_start(struct s3c_adc_clientreturn -EINVAL ; } -if (client->is_ts && adc->ts_pend) -return -EAGAIN ; -spin_lock_irqsave (&adc->lock, flags); +if (client->is_ts && adc->ts_pend) { +spin_unlock_irqrestore (&adc->lock, flags); +return -EAGAIN ; + } + client->channel = channel; client->nr_samples = nr_samples;
PATCH 6/23 intel_ips: blacklist HP ProBook laptops
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit 88ca518b0bb4161e5f20f8a1d9cc477cae294e54 upstream.
intel_ips driver spews the warning message
"ME failed to update for more than 1s, likely hung"
at each second endlessly on HP ProBook laptops with IronLake.
As this has never worked, better to blacklist the driver for now.
--- drivers/platform/x86/intel_ips.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+)
drivers/platform/x86/intel_ips.c +22 -0
@@ -72,6 +72,7 @@#include <linux/string.h> #include <linux/tick.h> #include <linux/timer.h> +#include <linux/dmi.h> #include <drm/i915_drm.h> #include <asm/msr.h> #include <asm/processor.h>
@@ -1505,6 +1506,24 @@ static DEFINE_PCI_DEVICE_TABLE(ips_id_taMODULE_DEVICE_TABLE (pci, ips_id_table); +static int ips_blacklist_callback (const struct dmi_system_id *id) +{ +pr_info ("Blacklisted intel_ips for %s\n" , id->ident); +return 1 ; +} + +static const struct dmi_system_id ips_blacklist[] = { + { + .callback = ips_blacklist_callback, + .ident ="HP ProBook" , + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"Hewlett-Packard" ), +DMI_MATCH (DMI_PRODUCT_NAME ,"HP ProBook" ), + }, + }, + { }/* terminating entry */ +}; +static int ips_probe (struct pci_dev *dev,const struct pci_device_id *id) {u64 platform_info;
@@ -1514,6 +1533,9 @@ static int ips_probe(struct pci_dev *devu16 htshi, trc, trc_required_mask;u8 tse; +if (dmi_check_system (ips_blacklist)) +return -ENODEV ; + ips =kzalloc (sizeof (struct ips_driver ),GFP_KERNEL );if (!ips)return -ENOMEM ;
PATCH 7/23 fifo: Do not restart open() if it already found a partner
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anders Kaseorg <[email protected]>
commit 05d290d66be6ef77a0b962ebecf01911bd984a78 upstream.
If a parent and child process open the two ends of a fifo, and the child immediately exits, the parent may receive a SIGCHLD before its open() returns. In that case, we need to make sure that open() will return successfully after the SIGCHLD handler returns, instead of throwing EINTR or being restarted. Otherwise, the restarted open() would incorrectly wait for a second partner on the other end.
The following test demonstrates the EINTR that was wrongly thrown from the parent’s open(). Change .sa_flags = 0 to .sa_flags = SA_RESTART to see a deadlock instead, in which the restarted open() waits for a second reader that will never come. (On my systems, this happens pretty reliably within about 5 to 500 iterations. Others report that it manages to loop ~forever sometimes; YMMV.)
#include <sys/stat.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <fcntl.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#define CHECK(x) do if ((x) == -1) {perror(#x); abort();} while(0)void handler(int signum) {}
int main()
{
struct sigaction act = {.sa_handler = handler, .sa_flags = 0};
CHECK(sigaction(SIGCHLD, &act, NULL));
CHECK(mknod("fifo", S_IFIFO | S_IRWXU, 0));
for (;;) {
int fd;
pid_t pid;
putc('.', stderr);
CHECK(pid = fork());
if (pid == 0) {
CHECK(fd = open("fifo", O_RDONLY));
_exit(0);
}
CHECK(fd = open("fifo", O_WRONLY));
CHECK(close(fd));
CHECK(waitpid(pid, NULL, 0));
}
}This is what I suspect was causing the Git test suite to fail in t9010-svn-fe.sh:
http://bugs.debian.org/678852
--- fs/fifo.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-)
fs/fifo.c +4 -5
@@ -14,7 +14,7 @@#include <linux/sched.h> #include <linux/pipe_fs_i.h> -static void wait_for_partner (struct inode * inode,unsigned int *cnt) +static int wait_for_partner (struct inode * inode,unsigned int *cnt) {int cur = *cnt;
@@ -23,6 +23,7 @@ static void wait_for_partner(struct inodif (signal_pending (current))break ; } +return cur == *cnt ? -ERESTARTSYS :0 ; }static void wake_up_partner (struct inode * inode)
@@ -67,8 +68,7 @@ static int fifo_open(struct inode *inode* seen a writer */ filp->f_version = pipe->w_counter; }else { -wait_for_partner (inode, &pipe->w_counter); -if (signal_pending (current)) +if (wait_for_partner (inode, &pipe->w_counter)) goto err_rd; } }
@@ -90,8 +90,7 @@ static int fifo_open(struct inode *inodewake_up_partner (inode);if (!pipe->readers) { -wait_for_partner (inode, &pipe->r_counter); -if (signal_pending (current)) +if (wait_for_partner (inode, &pipe->r_counter)) goto err_wr; }break ;
PATCH 8/23 rt2x00usb: fix indexes ordering on RX queue kick
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stanislaw Gruszka <[email protected]>
commit efd821182cec8c92babef6e00a95066d3252fda4 upstream.
On rt2x00_dmastart() we increase index specified by Q_INDEX and on rt2x00_dmadone() we increase index specified by Q_INDEX_DONE. So entries between Q_INDEX_DONE and Q_INDEX are those we currently process in the hardware. Entries between Q_INDEX and Q_INDEX_DONE are those we can submit to the hardware.
According to that fix rt2x00usb_kick_queue(), as we need to submit RX entries that are not processed by the hardware. It worked before only for empty queue, otherwise was broken.
Note that for TX queues indexes ordering are ok. We need to kick entries that have filled skb, but was not submitted to the hardware, i.e. started from Q_INDEX_DONE and have ENTRY_DATA_PENDING bit set.
Quoted 1 line
From practical standpoint this fixes RX queue stall, usually reproducible
in AP mode, like for example reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=828824
--- drivers/net/wireless/rt2x00/rt2x00usb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/wireless/rt2x00/rt2x00usb.c +1 -1
@@ -426,8 +426,8 @@ void rt2x00usb_kick_queue(struct data_qucase QID_RX :if (!rt2x00queue_full (queue))rt2x00queue_for_each_entry (queue, -Q_INDEX_DONE ,Q_INDEX , +Q_INDEX_DONE ,NULL , rt2x00usb_kick_rx_entry);break ;
PATCH 9/23 e1000e: Correct link check logic for 82571 serdes
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tushar Dave <[email protected]>
commit d0efa8f23a644f7cb7d1f8e78dd9a223efa412a3 upstream.
SYNCH bit and IV bit of RXCW register are sticky. Before examining these bits, RXCW should be read twice to filter out one-time false events and have correct values for these bits. Incorrect values of these bits in link check logic can cause weird link stability issues if auto-negotiation fails.
--- drivers/net/e1000e/82571.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/net/e1000e/82571.c +3 -0
@@ -1573,6 +1573,9 @@ static s32 e1000_check_for_serdes_link_8 ctrl =er32 (CTRL ); status =er32 (STATUS ); rxcw =er32 (RXCW ); +/* SYNCH bit and IV bit are sticky */ +udelay (10 ); + rxcw =er32 (RXCW );if ((rxcw &E1000_RXCW_SYNCH ) && !(rxcw &E1000_RXCW_IV )) {
PATCH 10/23 Input: xpad - add Andamiro Pump It Up pad
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yuri Khan <[email protected]>
commit e76b8ee25e034ab601b525abb95cea14aa167ed3 upstream.
I couldn't find the vendor ID in any of the online databases, but this mat has a Pump It Up logo on the top side of the controller compartment, and a disclaimer stating that Andamiro will not be liable on the bottom.
--- drivers/input/joystick/xpad.c | 1 + 1 file changed, 1 insertion(+)
drivers/input/joystick/xpad.c +1 -0
@@ -142,6 +142,7 @@ static const struct xpad_device { { 0x0c12, 0x880a, "Pelican Eclipse PL-2023", 0, XTYPE_XBOX }, { 0x0c12, 0x8810, "Zeroplus Xbox Controller", 0, XTYPE_XBOX }, { 0x0c12, 0x9902, "HAMA VibraX - *FAULTY HARDWARE*", 0, XTYPE_XBOX }, + { 0x0d2f, 0x0002, "Andamiro Pump It Up pad", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX }, { 0x0e4c, 0x1097, "Radica Gamester Controller", 0, XTYPE_XBOX }, { 0x0e4c, 0x2390, "Radica Games Jtech Controller", 0, XTYPE_XBOX }, { 0x0e6f, 0x0003, "Logic3 Freebird wireless Controller", 0, XTYPE_XBOX },
PATCH 11/23 tcp: drop SYN+FIN messages
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
commit fdf5af0daf8019cec2396cdef8fb042d80fe71fa upstream.
Denys Fedoryshchenko reported that SYN+FIN attacks were bringing his linux machines to their limits.
Dont call conn_request() if the TCP flags includes SYN flag
--- net/ipv4/tcp_input.c | 2 ++ 1 file changed, 2 insertions(+)
net/ipv4/tcp_input.c +2 -0
@@ -5761,6 +5761,8 @@ int tcp_rcv_state_process(struct sock *s goto discard;if (th->syn) { +if (th->fin) + goto discard;if (icsk->icsk_af_ops->conn_request (sk, skb) <0 )return 1 ;
PATCH 12/23 cfg80211: check iface combinations only when iface is running
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michal Kazior <[email protected]>
commit f8cdddb8d61d16a156229f0910f7ecfc7a82c003 upstream.
Don't validate interface combinations on a stopped interface. Otherwise we might end up being able to create a new interface with a certain type, but won't be able to change an existing interface into that type.
This also skips some other functions when interface is stopped and changing interface type.
--- net/wireless/util.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/wireless/util.c +1 -1
@@ -807,7 +807,7 @@ int cfg80211_change_iface(struct cfg8021 ntype == NL80211_IFTYPE_P2P_CLIENT))return -EBUSY ; -if (ntype != otype) { +if (ntype != otype &&netif_running (dev)) { err =cfg80211_can_change_interface (rdev, dev->ieee80211_ptr, ntype);if (err)
PATCH 13/23 ntp: Fix leap-second hrtimer livelock
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: John Stultz <[email protected]>
This is a backport of 6b43ae8a619d17c4935c3320d2ef9e92bdeed05d
This should have been backported when it was commited, but I mistook the problem as requiring the ntp_lock changes that landed in 3.4 in order for it to occur.
Unfortunately the same issue can happen (with only one cpu) as follows:do_adjtimex()
write_seqlock_irq(&xtime_lock);
process_adjtimex_modes()
process_adj_status()
ntp_start_leap_timer()
hrtimer_start()
hrtimer_reprogram()
tick_program_event()
clockevents_program_event()
ktime_get()
seq = req_seqbegin(xtime_lock); [DEADLOCK]
This deadlock will no always occur, as it requires the leap_timer to force a hrtimer_reprogram which only happens if its set and there's no sooner timer to expire.
NOTE: This patch, being faithful to the original commit, introduces a bug (we don't update wall_to_monotonic), which will be resovled by backporting a following fix.
Original commit message below:
Since commit 7dffa3c673fbcf835cd7be80bb4aec8ad3f51168 the ntp subsystem has used an hrtimer for triggering the leapsecond adjustment. However, this can cause a potential livelock.
Thomas diagnosed this as the following pattern:
CPU 0 CPU 1do_adjtimex()
spin_lock_irq(&ntp_lock);
process_adjtimex_modes(); timer_interrupt()
process_adj_status(); do_timer()
ntp_start_leap_timer(); write_lock(&xtime_lock);
hrtimer_start(); update_wall_time();
hrtimer_reprogram(); ntp_tick_length()
tick_program_event() spin_lock(&ntp_lock);
clockevents_program_event()
ktime_get()
seq = req_seqbegin(xtime_lock);This patch tries to avoid the problem by reverting back to not using an hrtimer to inject leapseconds, and instead we handle the leapsecond processing in the second_overflow() function.
The downside to this change is that on systems that support highres timers, the leap second processing will occur on a HZ tick boundary, (ie: ~1-10ms, depending on HZ) after the leap second instead of possibly sooner (~34us in my tests w/ x86_64 lapic).
This patch applies on top of tip/timers/core.
--- include/linux/timex.h | 2 kernel/time/ntp.c | 122 +++++++++++++++------------------------------- kernel/time/timekeeping.c | 18 ++---- 3 files changed, 48 insertions(+), 94 deletions(-)
include/linux/timex.h +1 -1
@@ -266,7 +266,7 @@ static inline int ntp_synced(void)/* Returns how long ticks are at present, in ns / 2^NTP_SCALE_SHIFT. */ extern u64 tick_length; -extern void second_overflow (void ); +extern int second_overflow (unsigned long secs);extern void update_ntp_one_tick (void );extern int do_adjtimex (struct timex *);extern void hardpps (const struct timespec *,const struct timespec *);
kernel/time/ntp.c +40 -82
195 lines not on this page · raw message
kernel/time/timekeeping.c +7 -11
@@ -169,15 +169,6 @@ static struct timespec raw_time;/* flag for if timekeeping is suspended */ int __read_mostly timekeeping_suspended; -/* must hold xtime_lock */ -void timekeeping_leap_insert (int leapsecond) -{ - xtime.tv_sec += leapsecond; - wall_to_monotonic.tv_sec -= leapsecond; -update_vsyscall (&xtime, &wall_to_monotonic, timekeeper.clock, - timekeeper.mult); -} -/** * timekeeping_forward_now - update clock to the current time *
@@ -828,9 +819,11 @@ static cycle_t logarithmic_accumulation( timekeeper.xtime_nsec += timekeeper.xtime_interval << shift;while (timekeeper.xtime_nsec >= nsecps) { +int leap; timekeeper.xtime_nsec -= nsecps; xtime.tv_sec++; -second_overflow (); + leap =second_overflow (xtime.tv_sec); + xtime.tv_sec += leap; }/* Accumulate raw time */
@@ -936,9 +929,12 @@ static void update_wall_time(void)* xtime.tv_nsec isn't larger then NSEC_PER_SEC */ if (unlikely (xtime.tv_nsec >=NSEC_PER_SEC )) { +int leap; xtime.tv_nsec -=NSEC_PER_SEC ; xtime.tv_sec++; -second_overflow (); + leap =second_overflow (xtime.tv_sec); + xtime.tv_sec += leap; + }/* check to see if there is a new clocksource to use */
PATCH 14/23 ntp: Correct TAI offset during leap second
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Richard Cochran <[email protected]>
This is a backport of dd48d708ff3e917f6d6b6c2b696c3f18c019feed
When repeating a UTC time value during a leap second (when the UTC time should be 23:59:60), the TAI timescale should not stop. The kernel NTP code increments the TAI offset one second too late. This patch fixes the issue by incrementing the offset during the leap second itself.
--- kernel/time/ntp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/time/ntp.c +1 -1
@@ -378,6 +378,7 @@ int second_overflow(unsigned long secs)if (secs %86400 ==0 ) { leap =-1 ; time_state =TIME_OOP ; + time_tai++;printk (KERN_NOTICE "Clock: inserting leap second 23:59:60 UTC\n" ); }
@@ -392,7 +393,6 @@ int second_overflow(unsigned long secs) }break ;case TIME_OOP : - time_tai++; time_state =TIME_WAIT ;break ;
PATCH 15/23 timekeeping: Fix CLOCK_MONOTONIC inconsistency during leapsecond
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: John Stultz <[email protected]>
This is a backport of fad0c66c4bb836d57a5f125ecd38bed653ca863a which resolves a bug the previous commit.
Commit 6b43ae8a61 (ntp: Fix leap-second hrtimer livelock) broke the leapsecond update of CLOCK_MONOTONIC. The missing leapsecond update to wall_to_monotonic causes discontinuities in CLOCK_MONOTONIC.
Adjust wall_to_monotonic when NTP inserted a leapsecond.
--- kernel/time/timekeeping.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
kernel/time/timekeeping.c +2 -1
@@ -824,6 +824,7 @@ static cycle_t logarithmic_accumulation( xtime.tv_sec++; leap =second_overflow (xtime.tv_sec); xtime.tv_sec += leap; + wall_to_monotonic.tv_sec -= leap; }/* Accumulate raw time */
@@ -934,7 +935,7 @@ static void update_wall_time(void) xtime.tv_sec++; leap =second_overflow (xtime.tv_sec); xtime.tv_sec += leap; - + wall_to_monotonic.tv_sec -= leap; }/* check to see if there is a new clocksource to use */
PATCH 16/23 time: Move common updates to a function
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <[email protected]>
This is a backport of cc06268c6a87db156af2daed6e96a936b955cc82
While not a bugfix itself, it allows following fixes to backport in a more straightforward manner.
--- kernel/time/timekeeping.c | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-)
kernel/time/timekeeping.c +17 -17
@@ -166,6 +166,19 @@ static struct timespec total_sleep_time;*/ static struct timespec raw_time; +/* must hold write on xtime_lock */ +static void timekeeping_update (bool clearntp) +{ +if (clearntp) { + timekeeper.ntp_error =0 ; +ntp_clear (); + } +update_vsyscall (&xtime, &wall_to_monotonic, + timekeeper.clock, timekeeper.mult); +} + + +/* flag for if timekeeping is suspended */ int __read_mostly timekeeping_suspended;
@@ -366,11 +379,7 @@ int do_settimeofday(const struct timespe xtime = *tv; - timekeeper.ntp_error =0 ; -ntp_clear (); - -update_vsyscall (&xtime, &wall_to_monotonic, timekeeper.clock, - timekeeper.mult); +timekeeping_update (true);write_sequnlock_irqrestore (&xtime_lock, flags);
@@ -403,11 +412,7 @@ int timekeeping_inject_offset(struct tim xtime =timespec_add (xtime, *ts); wall_to_monotonic =timespec_sub (wall_to_monotonic, *ts); - timekeeper.ntp_error =0 ; -ntp_clear (); - -update_vsyscall (&xtime, &wall_to_monotonic, timekeeper.clock, - timekeeper.mult); +timekeeping_update (true);write_sequnlock_irqrestore (&xtime_lock, flags);
@@ -630,10 +635,7 @@ void timekeeping_inject_sleeptime(struct__timekeeping_inject_sleeptime (delta); - timekeeper.ntp_error =0 ; -ntp_clear (); -update_vsyscall (&xtime, &wall_to_monotonic, timekeeper.clock, - timekeeper.mult); +timekeeping_update (true);write_sequnlock_irqrestore (&xtime_lock, flags);
@@ -938,9 +940,7 @@ static void update_wall_time(void) wall_to_monotonic.tv_sec -= leap; } -/* check to see if there is a new clocksource to use */ -update_vsyscall (&xtime, &wall_to_monotonic, timekeeper.clock, - timekeeper.mult); +timekeeping_update (false); }/**
PATCH 17/23 hrtimer: Provide clock_was_set_delayed()
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: John Stultz <[email protected]>
This is a backport of f55a6faa384304c89cfef162768e88374d3312cb
clock_was_set() cannot be called from hard interrupt context because it calls on_each_cpu().
For fixing the widely reported leap seconds issue it is necessary to call it from hard interrupt context, i.e. the timer tick code, which does the timekeeping updates.
Provide a new function which denotes it in the hrtimer cpu base structure of the cpu on which it is called and raise the hrtimer softirq. We then execute the clock_was_set() notificiation from softirq context in run_hrtimer_softirq(). The hrtimer softirq is rarely used, so polling the flag there is not a performance issue.
[ tglx: Made it depend on CONFIG_HIGH_RES_TIMERS. We really should get
rid of all this ifdeffery ASAP ]
--- include/linux/hrtimer.h | 9 ++++++++- kernel/hrtimer.c | 20 ++++++++++++++++++++ 2 files changed, 28 insertions(+), 1 deletion(-)
include/linux/hrtimer.h +8 -1
@@ -165,6 +165,7 @@ enum hrtimer_base_type {* @lock: lock protecting the base and associated clock bases * and timers * @active_bases: Bitfield to mark bases with active timers +* @clock_was_set: Indicates that clock was set from irq context. * @expires_next: absolute time of the next event which was scheduled * via clock_set_next_event() * @hres_active: State of high resolution mode
@@ -177,7 +178,8 @@ enum hrtimer_base_type {*/ struct hrtimer_cpu_base {raw_spinlock_t lock; -unsigned long active_bases; +unsigned int active_bases; +unsigned int clock_was_set;#ifdef CONFIG_HIGH_RES_TIMERS ktime_t expires_next;int hres_active;
@@ -286,6 +288,8 @@ extern void hrtimer_peek_ahead_timers(vo# define MONOTONIC_RES_NSEC HIGH_RES_NSEC# define KTIME_MONOTONIC_RES KTIME_HIGH_RES +extern void clock_was_set_delayed (void ); +#else # define MONOTONIC_RES_NSEC LOW_RES_NSEC
@@ -306,6 +310,9 @@ static inline int hrtimer_is_hres_active {return 0 ; } + +static inline void clock_was_set_delayed (void ) { } +#endif extern void clock_was_set (void );
kernel/hrtimer.c +20 -0
@@ -717,6 +717,19 @@ static int hrtimer_switch_to_hres(void) return 1; } +/* +* Called from timekeeping code to reprogramm the hrtimer interrupt +* device. If called from the timer interrupt context we defer it to +* softirq context. +*/ +void clock_was_set_delayed (void ) +{ +struct hrtimer_cpu_base *cpu_base = &__get_cpu_var (hrtimer_bases); + + cpu_base->clock_was_set =1 ; +__raise_softirq_irqoff (HRTIMER_SOFTIRQ ); +} +#else static inline int hrtimer_hres_active (void ) {return 0 ; }
@@ -1395,6 +1408,13 @@ void hrtimer_peek_ahead_timers(void)static void run_hrtimer_softirq (struct softirq_action *h) { +struct hrtimer_cpu_base *cpu_base = &__get_cpu_var (hrtimer_bases); + +if (cpu_base->clock_was_set) { + cpu_base->clock_was_set =0 ; +clock_was_set (); + } +hrtimer_peek_ahead_timers (); }
PATCH 18/23 timekeeping: Fix leapsecond triggered load spike issue
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: John Stultz <[email protected]>
This is a backport of 4873fa070ae84a4115f0b3c9dfabc224f1bc7c51
The timekeeping code misses an update of the hrtimer subsystem after a leap second happened. Due to that timers based on CLOCK_REALTIME are either expiring a second early or late depending on whether a leap second has been inserted or deleted until an operation is initiated which causes that update. Unless the update happens by some other means this discrepancy between the timekeeping and the hrtimer data stays forever and timers are expired either early or late.
The reported immediate workaround - $ data -s "date" - is causing a call to clock_was_set() which updates the hrtimer data structures.
See: http://www.sheeri.com/content/mysql-and-leap-second-high-cpu-and-fix
Add the missing clock_was_set() call to update_wall_time() in case of a leap second event. The actual update is deferred to softirq context as the necessary smp function call cannot be invoked from hard interrupt context.
--- kernel/time/timekeeping.c | 4 ++++ 1 file changed, 4 insertions(+)
kernel/time/timekeeping.c +4 -0
@@ -827,6 +827,8 @@ static cycle_t logarithmic_accumulation( leap =second_overflow (xtime.tv_sec); xtime.tv_sec += leap; wall_to_monotonic.tv_sec -= leap; +if (leap) +clock_was_set_delayed (); }/* Accumulate raw time */
@@ -938,6 +940,8 @@ static void update_wall_time(void) leap =second_overflow (xtime.tv_sec); xtime.tv_sec += leap; wall_to_monotonic.tv_sec -= leap; +if (leap) +clock_was_set_delayed (); }timekeeping_update (false);
PATCH 19/23 timekeeping: Maintain ktime_t based offsets for hrtimers
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <[email protected]>
This is a backport of 5b9fe759a678e05be4937ddf03d50e950207c1c0
We need to update the hrtimer clock offsets from the hrtimer interrupt context. To avoid conversions from timespec to ktime_t maintain a ktime_t based representation of those offsets in the timekeeper. This puts the conversion overhead into the code which updates the underlying offsets and provides fast accessible values in the hrtimer interrupt.
--- kernel/time/timekeeping.c | 25 ++++++++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-)
kernel/time/timekeeping.c +24 -1
@@ -161,18 +161,34 @@ static struct timespec xtime __attribute static struct timespec wall_to_monotonic __attribute__ ((aligned (16)));static struct timespec total_sleep_time; +/* Offset clock monotonic -> clock realtime */ +static ktime_t offs_real; + +/* Offset clock monotonic -> clock boottime */ +static ktime_t offs_boot; +/* * The raw monotonic time for the CLOCK_MONOTONIC_RAW posix clock. */ static struct timespec raw_time;/* must hold write on xtime_lock */ +static void update_rt_offset (void ) +{ +struct timespec tmp, *wtm = &wall_to_monotonic; + +set_normalized_timespec (&tmp, -wtm->tv_sec, -wtm->tv_nsec); + offs_real =timespec_to_ktime (tmp); +} + +/* must hold write on xtime_lock */ static void timekeeping_update (bool clearntp) {if (clearntp) { timekeeper.ntp_error =0 ;ntp_clear (); } +update_rt_offset ();update_vsyscall (&xtime, &wall_to_monotonic, timekeeper.clock, timekeeper.mult); }
@@ -587,6 +603,7 @@ void __init timekeeping_init(void) }set_normalized_timespec (&wall_to_monotonic, -boot.tv_sec, -boot.tv_nsec); +update_rt_offset (); total_sleep_time.tv_sec =0 ; total_sleep_time.tv_nsec =0 ;write_sequnlock_irqrestore (&xtime_lock, flags);
@@ -595,6 +612,12 @@ void __init timekeeping_init(void)/* time in seconds when suspend began */ static struct timespec timekeeping_suspend_time; +static void update_sleep_time (struct timespec t) +{ + total_sleep_time = t; + offs_boot =timespec_to_ktime (t); +} +/** * __timekeeping_inject_sleeptime - Internal function to add sleep interval * @delta: pointer to a timespec delta value
@@ -606,7 +629,7 @@ static void __timekeeping_inject_sleepti { xtime =timespec_add (xtime, *delta); wall_to_monotonic =timespec_sub (wall_to_monotonic, *delta); - total_sleep_time =timespec_add (total_sleep_time, *delta); +update_sleep_time (timespec_add (total_sleep_time, *delta)); }
PATCH 20/23 hrtimers: Move lock held region in hrtimer_interrupt()
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <[email protected]>
This is a backport of 196951e91262fccda81147d2bcf7fdab08668b40
We need to update the base offsets from this code and we need to do that under base->lock. Move the lock held region around the ktime_get() calls. The ktime_get() calls are going to be replaced with a function which gets the time and the offsets atomically.
--- kernel/hrtimer.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
kernel/hrtimer.c +3 -2
@@ -1263,11 +1263,10 @@ void hrtimer_interrupt(struct clock_even cpu_base->nr_events++; dev->next_event.tv64 =KTIME_MAX ; +raw_spin_lock (&cpu_base->lock); entry_time = now =ktime_get (); retry: expires_next.tv64 =KTIME_MAX ; - -raw_spin_lock (&cpu_base->lock);/* * We set expires_next to KTIME_MAX here with cpu_base->lock * held to prevent that a timer is enqueued in our queue via
@@ -1344,6 +1343,7 @@ retry:* interrupt routine. We give it 3 attempts to avoid * overreacting on some spurious event. */ +raw_spin_lock (&cpu_base->lock); now =ktime_get (); cpu_base->nr_retries++;if (++retries <3 )
@@ -1356,6 +1356,7 @@ retry:*/ cpu_base->nr_hangs++; cpu_base->hang_detected =1 ; +raw_spin_unlock (&cpu_base->lock); delta =ktime_sub (now, entry_time);if (delta.tv64 > cpu_base->max_hang_time.tv64) cpu_base->max_hang_time = delta;
PATCH 21/23 timekeeping: Provide hrtimer update function
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <[email protected]>
This is a backport of f6c06abfb3972ad4914cef57d8348fcb2932bc3b
To finally fix the infamous leap second issue and other race windows caused by functions which change the offsets between the various time bases (CLOCK_MONOTONIC, CLOCK_REALTIME and CLOCK_BOOTTIME) we need a function which atomically gets the current monotonic time and updates the offsets of CLOCK_REALTIME and CLOCK_BOOTTIME with minimalistic overhead. The previous patch which provides ktime_t offsets allows us to make this function almost as cheap as ktime_get() which is going to be replaced in hrtimer_interrupt().
--- include/linux/hrtimer.h | 1 + kernel/time/timekeeping.c | 34 ++++++++++++++++++++++++++++++++++ 2 files changed, 35 insertions(+)
include/linux/hrtimer.h +1 -0
@@ -327,6 +327,7 @@ extern ktime_t ktime_get(void);extern ktime_t ktime_get_real (void );extern ktime_t ktime_get_boottime (void );extern ktime_t ktime_get_monotonic_offset (void ); +extern ktime_t ktime_get_update_offsets (ktime_t *offs_real,ktime_t *offs_boot); DECLARE_PER_CPU(struct tick_device, tick_cpu_device);
kernel/time/timekeeping.c +34 -0
@@ -1126,6 +1126,40 @@ void get_xtime_and_monotonic_and_sleep_o }while (read_seqretry (&xtime_lock, seq)); } +#ifdef CONFIG_HIGH_RES_TIMERS +/** +* ktime_get_update_offsets - hrtimer helper +* @real: pointer to storage for monotonic -> realtime offset +* @_boot: pointer to storage for monotonic -> boottime offset +* +* Returns current monotonic time and updates the offsets +* Called from hrtimer_interupt() or retrigger_next_event() +*/ +ktime_t ktime_get_update_offsets (ktime_t *real,ktime_t *boot) +{ +ktime_t now; +unsigned int seq; +u64 secs, nsecs; + +do { + seq =read_seqbegin (&xtime_lock); + + secs = xtime.tv_sec; + nsecs = xtime.tv_nsec; + nsecs +=timekeeping_get_ns (); +/* If arch requires, add in gettimeoffset() */ + nsecs +=arch_gettimeoffset (); + + *real = offs_real; + *boot = offs_boot; + }while (read_seqretry (&xtime_lock, seq)); + + now =ktime_add_ns (ktime_set (secs,0 ), nsecs); + now =ktime_sub (now, *real); +return now; +} +#endif +/** * ktime_get_monotonic_offset() - get wall_to_monotonic in ktime_t format */
PATCH 22/23 hrtimer: Update hrtimer base offsets each hrtimer_interrupt
In reply to Greg Kroah-HartmanFrom: Greg KH <[email protected]>
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: John Stultz <[email protected]>
This is a backport of 5baefd6d84163443215f4a99f6a20f054ef11236
The update of the hrtimer base offsets on all cpus cannot be made atomically from the timekeeper.lock held and interrupt disabled region as smp function calls are not allowed there.
clock_was_set(), which enforces the update on all cpus, is called either from preemptible process context in case of do_settimeofday() or from the softirq context when the offset modification happened in the timer interrupt itself due to a leap second.
In both cases there is a race window for an hrtimer interrupt between dropping timekeeper lock, enabling interrupts and clock_was_set() issuing the updates. Any interrupt which arrives in that window will see the new time but operate on stale offsets.
So we need to make sure that an hrtimer interrupt always sees a consistent state of time and offsets.
ktime_get_update_offsets() allows us to get the current monotonic time and update the per cpu hrtimer base offsets from hrtimer_interrupt() to capture a consistent state of monotonic time and the offsets. The function replaces the existing ktime_get() calls in hrtimer_interrupt().
The overhead of the new function vs. ktime_get() is minimal as it just adds two store operations.
This ensures that any changes to realtime or boottime offsets are noticed and stored into the per-cpu hrtimer base structures, prior to any hrtimer expiration and guarantees that timers are not expired early.
--- kernel/hrtimer.c | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-)
kernel/hrtimer.c +14 -14
@@ -657,6 +657,14 @@ static inline int hrtimer_enqueue_reprogreturn 0 ; } +static inline ktime_t hrtimer_update_base (struct hrtimer_cpu_base *base) +{ +ktime_t *offs_real = &base->clock_base[HRTIMER_BASE_REALTIME ].offset; +ktime_t *offs_boot = &base->clock_base[HRTIMER_BASE_BOOTTIME ].offset; + +return ktime_get_update_offsets (offs_real, offs_boot); +} +/* * Retrigger next event is called after clock was set *
@@ -665,22 +673,12 @@ static inline int hrtimer_enqueue_reprogstatic void retrigger_next_event (void *arg) {struct hrtimer_cpu_base *base = &__get_cpu_var (hrtimer_bases); -struct timespec realtime_offset, xtim, wtm, sleep;if (!hrtimer_hres_active ())return ; -/* Optimized out for !HIGH_RES */ -get_xtime_and_monotonic_and_sleep_offset (&xtim, &wtm, &sleep); -set_normalized_timespec (&realtime_offset, -wtm.tv_sec, -wtm.tv_nsec); - -/* Adjust CLOCK_REALTIME offset */ raw_spin_lock (&base->lock); - base->clock_base[HRTIMER_BASE_REALTIME ].offset = -timespec_to_ktime (realtime_offset); - base->clock_base[HRTIMER_BASE_BOOTTIME ].offset = -timespec_to_ktime (sleep); - +hrtimer_update_base (base);hrtimer_force_reprogram (base,0 );raw_spin_unlock (&base->lock); }
@@ -710,7 +708,6 @@ static int hrtimer_switch_to_hres(void) base->clock_base[i].resolution =KTIME_HIGH_RES ;tick_setup_sched_timer (); -/* "Retrigger" the interrupt to get things going */ retrigger_next_event (NULL );local_irq_restore (flags);
@@ -1264,7 +1261,7 @@ void hrtimer_interrupt(struct clock_even dev->next_event.tv64 =KTIME_MAX ;raw_spin_lock (&cpu_base->lock); - entry_time = now =ktime_get (); + entry_time = now =hrtimer_update_base (cpu_base); retry: expires_next.tv64 =KTIME_MAX ;/*
@@ -1342,9 +1339,12 @@ retry:* We need to prevent that we loop forever in the hrtimer * interrupt routine. We give it 3 attempts to avoid * overreacting on some spurious event. +* +* Acquire base lock for updating the offsets and retrieving +* the current time. */ raw_spin_lock (&cpu_base->lock); - now =ktime_get (); + now =hrtimer_update_base (cpu_base); cpu_base->nr_retries++;if (++retries <3 ) goto retry;