2.6.32.6 stable review
Subsystems (20)
cover 2.6.32.6 stable review
This is the start of the stable review cycle for the 2.6.32.6 release. There are 29 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 us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it.
Responses should be made by Monday, January 24, 00:00:00 UTC. 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/v2.6/stable-review/patch-2.6.32.6-rc1.gz
and the diffstat can be found below.
thanks,
greg k-h
Makefile | 2 +- arch/x86/kernel/cpuid.c | 5 +- arch/x86/kernel/msr.c | 4 +- arch/x86/pci/i386.c | 9 +++ block/blk-settings.c | 22 ++++++ drivers/acpi/ec.c | 125 +++++++++++++++++++++------------ drivers/char/nozomi.c | 2 +- drivers/char/tty_io.c | 2 +- drivers/gpu/drm/i915/intel_sdvo.c | 83 +++++++++++++++++++++- drivers/md/dm-table.c | 20 ++---- drivers/media/video/gspca/sunplus.c | 26 ++++---- drivers/misc/enclosure.c | 1 + drivers/serial/8250_pnp.c | 10 +--- drivers/staging/asus_oled/asus_oled.c | 12 ++- drivers/staging/hv/Hv.c | 50 +++++++------- drivers/staging/hv/Hv.h | 6 +- drivers/staging/hv/Vmbus.c | 12 ++-- drivers/usb/core/devices.c | 2 +- drivers/usb/core/hub.c | 3 + drivers/usb/core/message.c | 8 +- drivers/usb/core/sysfs.c | 6 ++ drivers/usb/host/ehci-hcd.c | 5 +- drivers/usb/host/ehci-hub.c | 20 +++++- drivers/usb/host/ehci-q.c | 11 ++- drivers/usb/host/uhci-hcd.c | 15 ++++- drivers/usb/host/uhci-hub.c | 2 +- drivers/usb/serial/generic.c | 2 + drivers/usb/storage/unusual_devs.h | 7 -- drivers/usb/storage/usb.c | 3 +- fs/ecryptfs/crypto.c | 4 +- fs/ecryptfs/file.c | 14 ++-- include/linux/blkdev.h | 2 + include/linux/enclosure.h | 2 + kernel/perf_event.c | 29 +++++++- mm/vmalloc.c | 4 +- tools/perf/builtin-timechart.c | 2 +- 36 files changed, 365 insertions(+), 167 deletions(-)
PATCH 1/29 x86, msr/cpuid: Register enough minors for the MSR and CPUID drivers
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: H. Peter Anvin <[email protected]>
commit 0b962d473af32ec334df271b54ff4973cb2b4c73 upstream.
register_chrdev() hardcodes registering 256 minors, presumably to avoid breaking old drivers. However, we need to register enough minors so that we have all possible CPUs.
checkpatch warns on this patch, but the patch is correct: NR_CPUS here is a static *upper bound* on the *maximum CPU index* (not *number of CPUs!*) and that is what we want.
LKML-Reference: <tip-*@git.kernel.org>
--- arch/x86/kernel/cpuid.c | 5 +++-- arch/x86/kernel/msr.c | 4 ++-- 2 files changed, 5 insertions(+), 4 deletions(-)
arch/x86/kernel/cpuid.c +3 -2
@@ -192,7 +192,8 @@ static int __init cpuid_init(void)int i, err =0 ; i =0 ; -if (register_chrdev (CPUID_MAJOR ,"cpu/cpuid" , &cpuid_fops)) { +if (__register_chrdev (CPUID_MAJOR ,0 ,NR_CPUS , +"cpu/cpuid" , &cpuid_fops)) {printk (KERN_ERR "cpuid: unable to get major %d for cpuid\n" ,CPUID_MAJOR ); err = -EBUSY ;
@@ -221,7 +222,7 @@ out_class: }class_destroy (cpuid_class); out_chrdev: -unregister_chrdev (CPUID_MAJOR ,"cpu/cpuid" ); +__unregister_chrdev (CPUID_MAJOR ,0 ,NR_CPUS ,"cpu/cpuid" ); out:return err; }
arch/x86/kernel/msr.c +2 -2
@@ -251,7 +251,7 @@ static int __init msr_init(void)int i, err =0 ; i =0 ; -if (register_chrdev (MSR_MAJOR ,"cpu/msr" , &msr_fops)) { +if (__register_chrdev (MSR_MAJOR ,0 ,NR_CPUS ,"cpu/msr" , &msr_fops)) {printk (KERN_ERR "msr: unable to get major %d for msr\n" ,MSR_MAJOR ); err = -EBUSY ;
@@ -279,7 +279,7 @@ out_class:msr_device_destroy (i);class_destroy (msr_class); out_chrdev: -unregister_chrdev (MSR_MAJOR ,"cpu/msr" ); +__unregister_chrdev (MSR_MAJOR ,0 ,NR_CPUS ,"cpu/msr" ); out:return err; }
PATCH 2/29 V4L/DVB (13900): gspca - sunplus: Fix bridge exchanges.
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Jean-Francois Moine <[email protected]>
commit 07d1c69b2dcfdd1b21e36af0ff8b9506234908ee upstream.
A previous code optimization inverted bridge registers and values, doing a regression in kernel 2.6.32.
--- drivers/media/video/gspca/sunplus.c | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-)
drivers/media/video/gspca/sunplus.c +13 -13
@@ -705,7 +705,7 @@ static void spca504B_SetSizeType(struct rc =spca504B_PollingDataReady (gspca_dev);/* Init the cam width height with some values get on init ? */ -reg_w_riv (dev,0x31 ,0 ,0x04 ); +reg_w_riv (dev,0x31 ,0x04 ,0 );spca504B_WaitCmdStatus (gspca_dev); rc =spca504B_PollingDataReady (gspca_dev);break ;
@@ -807,14 +807,14 @@ static void init_ctl_reg(struct gspca_dedefault :/* case BRIDGE_SPCA533: */ /* case BRIDGE_SPCA504B: */ -reg_w_riv (dev,0 ,0x00 ,0x21ad );/* hue */ -reg_w_riv (dev,0 ,0x01 ,0x21ac );/* sat/hue */ -reg_w_riv (dev,0 ,0x00 ,0x21a3 );/* gamma */ +reg_w_riv (dev,0 ,0x21ad ,0x00 );/* hue */ +reg_w_riv (dev,0 ,0x21ac ,0x01 );/* sat/hue */ +reg_w_riv (dev,0 ,0x21a3 ,0x00 );/* gamma */ break ;case BRIDGE_SPCA536 : -reg_w_riv (dev,0 ,0x40 ,0x20f5 ); -reg_w_riv (dev,0 ,0x01 ,0x20f4 ); -reg_w_riv (dev,0 ,0x00 ,0x2089 ); +reg_w_riv (dev,0 ,0x20f5 ,0x40 ); +reg_w_riv (dev,0 ,0x20f4 ,0x01 ); +reg_w_riv (dev,0 ,0x2089 ,0x00 );break ; }if (pollreg)
@@ -888,11 +888,11 @@ static int sd_init(struct gspca_dev *gspswitch (sd->bridge) {case BRIDGE_SPCA504B :reg_w_riv (dev,0x1d ,0x00 ,0 ); -reg_w_riv (dev,0 ,0x01 ,0x2306 ); -reg_w_riv (dev,0 ,0x00 ,0x0d04 ); -reg_w_riv (dev,0 ,0x00 ,0x2000 ); -reg_w_riv (dev,0 ,0x13 ,0x2301 ); -reg_w_riv (dev,0 ,0x00 ,0x2306 ); +reg_w_riv (dev,0 ,0x2306 ,0x01 ); +reg_w_riv (dev,0 ,0x0d04 ,0x00 ); +reg_w_riv (dev,0 ,0x2000 ,0x00 ); +reg_w_riv (dev,0 ,0x2301 ,0x13 ); +reg_w_riv (dev,0 ,0x2306 ,0x00 );/* fall thru */ case BRIDGE_SPCA533 :spca504B_PollingDataReady (gspca_dev);
@@ -1011,7 +1011,7 @@ static int sd_start(struct gspca_dev *gsspca504B_WaitCmdStatus (gspca_dev);break ;default : -reg_w_riv (dev,0x31 ,0 ,0x04 ); +reg_w_riv (dev,0x31 ,0x04 ,0 );spca504B_WaitCmdStatus (gspca_dev);spca504B_PollingDataReady (gspca_dev);break ;
PATCH 3/29 Staging: asus_oled: fix oops in 2.6.32.2
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Eugeni Dodonov <[email protected]>
commit 20633bf0141c5e93e3396770d5eb7d200ee4068a upstream.
After updating to 2.6.32 kernel, I started experiencing Oopses caused by the asus_oled module. After quick investigation, I wrapped this simple patch which fixes an Oops in by asus_oled module on 2.6.32.2 kernel, caused by incorrect usage of strict_strtoul function call within set_enabled and set_disabled functions. This can be triggered by simple running the userspace client for asus_old (e.g., 'asusoled -e' or 'asusoled -d').
--- drivers/staging/asus_oled/asus_oled.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
drivers/staging/asus_oled/asus_oled.c +8 -4
@@ -194,9 +194,11 @@ static ssize_t set_enabled(struct device {struct usb_interface *intf =to_usb_interface (dev);struct asus_oled_dev *odev =usb_get_intfdata (intf); -int temp =strict_strtoul (buf,10 ,NULL ); +unsigned long value; +if (strict_strtoul (buf,10 , &value)) +return -EINVAL ; -enable_oled (odev, temp); +enable_oled (odev, value);return count; }
@@ -207,10 +209,12 @@ static ssize_t class_set_enabled(struct {struct asus_oled_dev *odev = (struct asus_oled_dev *)dev_get_drvdata (device); +unsigned long value; -int temp =strict_strtoul (buf,10 ,NULL ); +if (strict_strtoul (buf,10 , &value)) +return -EINVAL ; -enable_oled (odev, temp); +enable_oled (odev, value);return count; }
PATCH 4/29 Staging: hv: fix smp problems in the hyperv core code
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Greg Kroah-Hartman <[email protected]>
commit 7692fd4d441afac728cb83fdd33349d5ba07406c upstream.
This fixes a number of SMP problems that were in the hyperv core code.
Patch originally written by K. Y. Srinivasan <[email protected]> but forward ported to the latest in-kernel code and tweaked slightly by me.
Novell, Inc. hereby disclaims all copyright in any derivative work copyright associated with this patch.
--- drivers/staging/hv/Hv.c | 50 ++++++++++++++++++++++----------------------- drivers/staging/hv/Hv.h | 6 ++--- drivers/staging/hv/Vmbus.c | 12 ++++++---- 3 files changed, 35 insertions(+), 33 deletions(-)
drivers/staging/hv/Hv.c +25 -25
@@ -386,7 +386,7 @@ u16 HvSignalEvent(void)* retrieve the initialized message and event pages. Otherwise, we create and * initialize the message and event pages. */ -int HvSynicInit (u32 irqVector) +void HvSynicInit (void *irqarg) {u64 version;union hv_synic_simp simp;
@@ -394,13 +394,14 @@ int HvSynicInit(u32 irqVector)union hv_synic_sint sharedSint;union hv_synic_scontrol sctrl;u64 guestID; -int ret =0 ; +u32 irqVector = *((u32 *)(irqarg)); +int cpu =smp_processor_id ();DPRINT_ENTER (VMBUS );if (!gHvContext.HypercallPage) {DPRINT_EXIT (VMBUS ); -return ret; +return ; }/* Check the version */
@@ -425,27 +426,27 @@ int HvSynicInit(u32 irqVector)*/ rdmsrl (HV_X64_MSR_GUEST_OS_ID , guestID);if (guestID ==HV_LINUX_GUEST_ID ) { - gHvContext.synICMessagePage[0 ] = + gHvContext.synICMessagePage[cpu] =phys_to_virt (simp.BaseSimpGpa <<PAGE_SHIFT ); - gHvContext.synICEventPage[0 ] = + gHvContext.synICEventPage[cpu] =phys_to_virt (siefp.BaseSiefpGpa <<PAGE_SHIFT ); }else {DPRINT_ERR (VMBUS ,"unknown guest id!!" ); goto Cleanup; }DPRINT_DBG (VMBUS ,"MAPPED: Simp: %p, Sifep: %p" , - gHvContext.synICMessagePage[0 ], - gHvContext.synICEventPage[0 ]); + gHvContext.synICMessagePage[cpu], + gHvContext.synICEventPage[cpu]); }else { - gHvContext.synICMessagePage[0 ] =osd_PageAlloc (1 ); -if (gHvContext.synICMessagePage[0 ] ==NULL ) { + gHvContext.synICMessagePage[cpu] = (void *)get_zeroed_page (GFP_ATOMIC ); +if (gHvContext.synICMessagePage[cpu] ==NULL ) {DPRINT_ERR (VMBUS ,"unable to allocate SYNIC message page!!" ); goto Cleanup; } - gHvContext.synICEventPage[0 ] =osd_PageAlloc (1 ); -if (gHvContext.synICEventPage[0 ] ==NULL ) { + gHvContext.synICEventPage[cpu] = (void *)get_zeroed_page (GFP_ATOMIC ); +if (gHvContext.synICEventPage[cpu] ==NULL ) {DPRINT_ERR (VMBUS ,"unable to allocate SYNIC event page!!" ); goto Cleanup;
@@ -454,7 +455,7 @@ int HvSynicInit(u32 irqVector)/* Setup the Synic's message page */ rdmsrl (HV_X64_MSR_SIMP , simp.AsUINT64); simp.SimpEnabled =1 ; - simp.BaseSimpGpa =virt_to_phys (gHvContext.synICMessagePage[0 ]) + simp.BaseSimpGpa =virt_to_phys (gHvContext.synICMessagePage[cpu]) >>PAGE_SHIFT ; DPRINT_DBG(VMBUS, "HV_X64_MSR_SIMP msr set to: %llx",
@@ -465,7 +466,7 @@ int HvSynicInit(u32 irqVector)/* Setup the Synic's event page */ rdmsrl (HV_X64_MSR_SIEFP , siefp.AsUINT64); siefp.SiefpEnabled =1 ; - siefp.BaseSiefpGpa =virt_to_phys (gHvContext.synICEventPage[0 ]) + siefp.BaseSiefpGpa =virt_to_phys (gHvContext.synICEventPage[cpu]) >>PAGE_SHIFT ; DPRINT_DBG(VMBUS, "HV_X64_MSR_SIEFP msr set to: %llx",
@@ -501,32 +502,30 @@ int HvSynicInit(u32 irqVector)DPRINT_EXIT (VMBUS ); -return ret; +return ; Cleanup: - ret =-1 ; -if (gHvContext.GuestId ==HV_LINUX_GUEST_ID ) { -if (gHvContext.synICEventPage[0 ]) -osd_PageFree (gHvContext.synICEventPage[0 ],1 ); +if (gHvContext.synICEventPage[cpu]) +osd_PageFree (gHvContext.synICEventPage[cpu],1 ); -if (gHvContext.synICMessagePage[0 ]) -osd_PageFree (gHvContext.synICMessagePage[0 ],1 ); +if (gHvContext.synICMessagePage[cpu]) +osd_PageFree (gHvContext.synICMessagePage[cpu],1 ); }DPRINT_EXIT (VMBUS ); - -return ret; +return ; }/** * HvSynicCleanup - Cleanup routine for HvSynicInit(). */ -void HvSynicCleanup (void ) +void HvSynicCleanup (void *arg) {union hv_synic_sint sharedSint;union hv_synic_simp simp;union hv_synic_siefp siefp; +int cpu =smp_processor_id ();DPRINT_ENTER (VMBUS );
@@ -539,6 +538,7 @@ void HvSynicCleanup(void) sharedSint.Masked =1 ; +/* Need to correctly cleanup in the case of SMP!!! */ /* Disable the interrupt */ wrmsrl (HV_X64_MSR_SINT0 +VMBUS_MESSAGE_SINT , sharedSint.AsUINT64);
@@ -560,8 +560,8 @@ void HvSynicCleanup(void)wrmsrl (HV_X64_MSR_SIEFP , siefp.AsUINT64); -osd_PageFree (gHvContext.synICMessagePage[0 ],1 ); -osd_PageFree (gHvContext.synICEventPage[0 ],1 ); +osd_PageFree (gHvContext.synICMessagePage[cpu],1 ); +osd_PageFree (gHvContext.synICEventPage[cpu],1 ); }DPRINT_EXIT (VMBUS );
drivers/staging/hv/Hv.h +3 -3
@@ -93,7 +93,7 @@ static const struct hv_guid VMBUS_SERVIC }, }; -#define MAX_NUM_CPUS 1 +#define MAX_NUM_CPUS 32struct hv_input_signal_event_buffer {
@@ -137,8 +137,8 @@ extern u16 HvPostMessage(union hv_connecextern u16 HvSignalEvent (void ); -extern int HvSynicInit (u32 irqVector); +extern void HvSynicInit (void *irqarg); -extern void HvSynicCleanup (void ); +extern void HvSynicCleanup (void *arg);#endif /* __HV_H__ */
drivers/staging/hv/Vmbus.c +7 -5
@@ -129,7 +129,7 @@ static int VmbusOnDeviceAdd(struct hv_de/* strcpy(dev->name, "vmbus"); */ /* SynIC setup... */ - ret =HvSynicInit (*irqvector); +on_each_cpu (HvSynicInit, (void *)irqvector,1 );/* Connect to VMBus in the root partition */ ret =VmbusConnect ();
@@ -150,7 +150,7 @@ static int VmbusOnDeviceRemove(struct hvDPRINT_ENTER (VMBUS );VmbusChannelReleaseUnattachedChannels ();VmbusDisconnect (); -HvSynicCleanup (); +on_each_cpu (HvSynicCleanup,NULL ,1 );DPRINT_EXIT (VMBUS );return ret;
@@ -173,7 +173,8 @@ static void VmbusOnCleanup(struct hv_dri*/ static void VmbusOnMsgDPC (struct hv_driver *drv) { -void *page_addr = gHvContext.synICMessagePage[0 ]; +int cpu =smp_processor_id (); +void *page_addr = gHvContext.synICMessagePage[cpu];struct hv_message *msg = (struct hv_message *)page_addr +VMBUS_MESSAGE_SINT ;struct hv_message *copied;
@@ -230,11 +231,12 @@ static void VmbusOnEventDPC(struct hv_drstatic int VmbusOnISR (struct hv_driver *drv) {int ret =0 ; +int cpu =smp_processor_id ();void *page_addr;struct hv_message *msg;union hv_synic_event_flags *event; - page_addr = gHvContext.synICMessagePage[0 ]; + page_addr = gHvContext.synICMessagePage[cpu]; msg = (struct hv_message *)page_addr +VMBUS_MESSAGE_SINT ;DPRINT_ENTER (VMBUS );
@@ -248,7 +250,7 @@ static int VmbusOnISR(struct hv_driver * }/* TODO: Check if there are events to be process */ - page_addr = gHvContext.synICEventPage[0 ]; + page_addr = gHvContext.synICEventPage[cpu]; event = (union hv_synic_event_flags *)page_addr +VMBUS_MESSAGE_SINT ;/* Since we are a child, we only need to check bit 0 */
PATCH 5/29 tty: fix race in tty_fasync
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Greg Kroah-Hartman <[email protected]>
commit 703625118069f9f8960d356676662d3db5a9d116 upstream.
We need to keep the lock held over the call to __f_setown() to prevent a PID race.
Thanks to Al Viro for pointing out the problem, and to Travis for making us look here in the first place.
--- drivers/char/tty_io.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/char/tty_io.c +1 -1
@@ -1930,8 +1930,8 @@ static int tty_fasync(int fd, struct fil pid =task_pid (current); type =PIDTYPE_PID ; } -spin_unlock_irqrestore (&tty->ctrl_lock, flags); retval =__f_setown (filp, pid, type,0 ); +spin_unlock_irqrestore (&tty->ctrl_lock, flags);if (retval) goto out; }else {
PATCH 6/29 ecryptfs: use after free
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Dan Carpenter <[email protected]>
commit ece550f51ba175c14ec3ec047815927d7386ea1f upstream.
The "full_alg_name" variable is used on a couple error paths, so we shouldn't free it until the end.
--- fs/ecryptfs/crypto.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
fs/ecryptfs/crypto.c +2 -2
@@ -1748,7 +1748,7 @@ ecryptfs_process_key_cipher(struct crypt char *cipher_name, size_t *key_size) { char dummy_key[ECRYPTFS_MAX_KEY_BYTES]; -char *full_alg_name; +char *full_alg_name =NULL ;int rc; *key_tfm =NULL ;
@@ -1763,7 +1763,6 @@ ecryptfs_process_key_cipher(struct cryptif (rc) goto out; *key_tfm =crypto_alloc_blkcipher (full_alg_name,0 ,CRYPTO_ALG_ASYNC ); -kfree (full_alg_name);if (IS_ERR (*key_tfm)) { rc =PTR_ERR (*key_tfm); printk(KERN_ERR "Unable to allocate crypto cipher with name "
@@ -1786,6 +1785,7 @@ ecryptfs_process_key_cipher(struct crypt goto out; } out: +kfree (full_alg_name);return rc; }
PATCH 7/29 ecryptfs: initialize private persistent file before dereferencing pointer
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Erez Zadok <[email protected]>
commit e27759d7a333d1f25d628c4f7caf845c51be51c2 upstream.
Ecryptfs_open dereferences a pointer to the private lower file (the one stored in the ecryptfs inode), without checking if the pointer is NULL. Right afterward, it initializes that pointer if it is NULL. Swap order of statements to first initialize. Bug discovered by Duckjin Kang.
--- fs/ecryptfs/file.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
fs/ecryptfs/file.c +7 -7
@@ -191,13 +191,6 @@ static int ecryptfs_open(struct inode *i | ECRYPTFS_ENCRYPTED); }mutex_unlock (&crypt_stat->cs_mutex); -if ((ecryptfs_inode_to_private (inode)->lower_file->f_flags &O_RDONLY ) - && !(file->f_flags &O_RDONLY )) { - rc = -EPERM ; -printk (KERN_WARNING "%s: Lower persistent file is RO; eCryptfs " -"file must hence be opened RO\n" , __func__); - goto out; - }if (!ecryptfs_inode_to_private (inode)->lower_file) { rc =ecryptfs_init_persistent_file (ecryptfs_dentry);if (rc) {
@@ -208,6 +201,13 @@ static int ecryptfs_open(struct inode *i goto out; } } +if ((ecryptfs_inode_to_private (inode)->lower_file->f_flags &O_RDONLY ) + && !(file->f_flags &O_RDONLY )) { + rc = -EPERM ; +printk (KERN_WARNING "%s: Lower persistent file is RO; eCryptfs " +"file must hence be opened RO\n" , __func__); + goto out; + }ecryptfs_set_file_lower ( file,ecryptfs_inode_to_private (inode)->lower_file);if (S_ISDIR (ecryptfs_dentry->d_inode->i_mode)) {
PATCH 8/29 nozomi: quick fix for the close/close bug
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Alan Cox <[email protected]>
commit eeec32a731631a9bad9abb21c626b9f2840bee0d upstream.
Nozomi goes wrong if you get the sequence
open open close [stuff] close
which turns out to occur on some ppp type setups.
This is a quick patch up for the problem. It's not really fixing Nozomi which completely fails to implement tty open/close semantics and all the other needed stuff. Doing it right is a rather more invasive patch set and not one that will backport.
--- drivers/char/nozomi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/char/nozomi.c +1 -1
@@ -1629,10 +1629,10 @@ static void ntty_close(struct tty_struct dc->open_ttys--; port->count--; -tty_port_tty_set (port,NULL );if (port->count ==0 ) {DBG1 ("close: %d" , nport->token_dl); +tty_port_tty_set (port,NULL );spin_lock_irqsave (&dc->spin_mutex, flags); dc->last_ier &= ~(nport->token_dl);writew (dc->last_ier, dc->reg_ier);
PATCH 9/29 serial: 8250_pnp: use wildcard for serial Wacom tablets
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Matthew Garrett <[email protected]>
commit 6d34855d9aa281f72c533ecb827405139d1b0fe9 upstream.
Wacom claims that the WACF namespace will always be devoted to serial Wacom tablets. Remove the existing entries and add a wildcard to avoid having to update the kernel every time they add a new device.
--- drivers/serial/8250_pnp.c | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-)
drivers/serial/8250_pnp.c +1 -9
@@ -328,15 +328,7 @@ static const struct pnp_device_id pnp_de/* U.S. Robotics 56K Voice INT PnP*/ { "USR9190", 0 },/* Wacom tablets */ - { "WACF004", 0 }, - { "WACF005", 0 }, - { "WACF006", 0 }, - { "WACF007", 0 }, - { "WACF008", 0 }, - { "WACF009", 0 }, - { "WACF00A", 0 }, - { "WACF00B", 0 }, - { "WACF00C", 0 }, + { "WACFXXX", 0 },/* Compaq touchscreen */ { "FPI2002", 0 },/* Fujitsu Stylistic touchscreens */
PATCH 10/29 usb: serial: fix memory leak in generic driver
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Johan Hovold <[email protected]>
commit 2591530204a76fecc843529ade56afe865dd2657 upstream.
Fix a regression introduced by commit 715b1dc01fe44537e8fce9566e4bb48d6821d84b ("USB: usb_debug,usb_generic_serial: implement multi urb write").
URB transfer buffer was never freed when using multi-urb writes. Currently the only driver enabling multi-urb writes is usb_debug.
--- drivers/usb/serial/generic.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/usb/serial/generic.c +2 -0
@@ -489,6 +489,8 @@ void usb_serial_generic_write_bulk_callbdbg ("%s - port %d" , __func__, port->number);if (port->serial->type->max_in_flight_urbs) { +kfree (urb->transfer_buffer); +spin_lock_irqsave (&port->lock, flags); --port->urbs_in_flight; port->tx_bytes_flight -= urb->transfer_buffer_length;
PATCH 11/29 USB: fix bitmask merge error
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Alan Stern <[email protected]>
commit a91b593edd4b3e8aa91f671b763b27b8119eb49d upstream.
This patch adds a mask bit which was mistakenly omitted from the as1311 patch (usb-storage: add BAD_SENSE flag).
--- drivers/usb/storage/usb.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/usb/storage/usb.c +2 -1
@@ -430,7 +430,8 @@ static void adjust_quirks(struct us_datau16 vid =le16_to_cpu (us->pusb_dev->descriptor.idVendor);u16 pid =le16_to_cpu (us->pusb_dev->descriptor.idProduct);unsigned f =0 ; - unsigned int mask = (US_FL_SANE_SENSE | US_FL_FIX_CAPACITY | + unsigned int mask = (US_FL_SANE_SENSE | US_FL_BAD_SENSE | + US_FL_FIX_CAPACITY | US_FL_CAPACITY_HEURISTICS | US_FL_IGNORE_DEVICE | US_FL_NOT_LOCKABLE | US_FL_MAX_SECTORS_64 | US_FL_CAPACITY_OK | US_FL_IGNORE_RESIDUE |
PATCH 12/29 USB: Dont use GFP_KERNEL while we cannot reset a storage device
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Oliver Neukum <[email protected]>
commit acbe2febe71abb2360b008e9ab3ee5c44169f78c upstream.
Memory allocations with GFP_KERNEL can cause IO to a storage device which can fail resulting in a need to reset the device. Therefore GFP_KERNEL cannot be safely used between usb_lock_device() and usb_unlock_device(). Replace by GFP_NOIO.
--- drivers/usb/core/devices.c | 2 +- drivers/usb/core/message.c | 8 ++++---- 2 files changed, 5 insertions(+), 5 deletions(-)
drivers/usb/core/devices.c +1 -1
@@ -494,7 +494,7 @@ static ssize_t usb_device_dump(char __usreturn 0 ;/* allocate 2^1 pages = 8K (on i386); * should be more than enough for one device */ - pages_start = (char *)__get_free_pages (GFP_KERNEL ,1 ); + pages_start = (char *)__get_free_pages (GFP_NOIO ,1 );if (!pages_start)return -ENOMEM ;
drivers/usb/core/message.c +4 -4
@@ -911,11 +911,11 @@ char *usb_cache_string(struct usb_deviceif (index <=0 )return NULL ; - buf =kmalloc (MAX_USB_STRING_SIZE ,GFP_KERNEL ); + buf =kmalloc (MAX_USB_STRING_SIZE ,GFP_NOIO );if (buf) { len =usb_string (udev, index, buf,MAX_USB_STRING_SIZE );if (len >0 ) { - smallbuf =kmalloc (++len,GFP_KERNEL ); + smallbuf =kmalloc (++len,GFP_NOIO );if (!smallbuf)return buf;memcpy (smallbuf, buf, len);
@@ -1682,7 +1682,7 @@ int usb_set_configuration(struct usb_devif (cp) { nintf = cp->desc.bNumInterfaces; new_interfaces =kmalloc (nintf *sizeof (*new_interfaces), -GFP_KERNEL ); +GFP_NOIO );if (!new_interfaces) {dev_err (&dev->dev,"Out of memory\n" );return -ENOMEM ;
@@ -1691,7 +1691,7 @@ int usb_set_configuration(struct usb_devfor (; n < nintf; ++n) { new_interfaces[n] =kzalloc (sizeof (struct usb_interface ), -GFP_KERNEL ); +GFP_NOIO );if (!new_interfaces[n]) {dev_err (&dev->dev,"Out of memory\n" ); ret = -ENOMEM ;
PATCH 13/29 USB: EHCI: fix handling of unusual interrupt intervals
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Alan Stern <[email protected]>
commit 1b9a38bfa6e664ff02511314f5586d711c83cc91 upstream.
This patch (as1320) fixes two problems related to interrupt-URB scheduling in ehci-hcd.
URBs with an interval of 2 or 4 microframes aren't handled. For the time being, the patch reduces to interval to 1 uframe.
URBs are constrained to have an interval no larger than 1024 frames by usb_submit_urb(). But some EHCI controllers allow use of a schedule as short as 256 frames; for these controllers we may have to decrease the interval to the actual schedule length.
The second problem isn't very significant since few devices expose interrupt endpoints with an interval larger than 256 frames. But the first problem is critical; it will prevent the kernel from working with devices having interrupt intervals of 2 or 4 uframes.
--- drivers/usb/host/ehci-q.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
drivers/usb/host/ehci-q.c +8 -3
@@ -827,9 +827,10 @@ qh_make (* But interval 1 scheduling is simpler, and * includes high bandwidth. */ -dbg ("intr period %d uframes, NYET!" , - urb->interval); - goto done; + urb->interval =1 ; + }else if (qh->period > ehci->periodic_size) { + qh->period = ehci->periodic_size; + urb->interval = qh->period <<3 ; } }else {int think_time;
@@ -852,6 +853,10 @@ qh_make (usb_calc_bus_time (urb->dev->speed, is_input, 0, max_packet (maxp))); qh->period = urb->interval; +if (qh->period > ehci->periodic_size) { + qh->period = ehci->periodic_size; + urb->interval = qh->period; + } } }
PATCH 14/29 USB: EHCI & UHCI: fix race between root-hub suspend and port resume
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Alan Stern <[email protected]>
commit cec3a53c7fe794237b582e8e77fc0e48465e65ee upstream.
This patch (as1321) fixes a problem with EHCI and UHCI root-hub
suspends: If the suspend occurs while a port is trying to resume, the resume doesn't finish and simply gets lost. When remote wakeup is enabled, this is undesirable behavior.
The patch checks first to see if any port resumes are in progress, and if they are then it fails the root-hub suspend with -EBUSY.
--- drivers/usb/host/ehci-hub.c | 20 +++++++++++++++++++- drivers/usb/host/uhci-hcd.c | 15 ++++++++++++++- 2 files changed, 33 insertions(+), 2 deletions(-)
drivers/usb/host/ehci-hub.c +19 -1
@@ -120,9 +120,26 @@ static int ehci_bus_suspend (struct usb_del_timer_sync (&ehci->watchdog);del_timer_sync (&ehci->iaa_watchdog); - port =HCS_N_PORTS (ehci->hcs_params);spin_lock_irq (&ehci->lock); +/* Once the controller is stopped, port resumes that are already +* in progress won't complete. Hence if remote wakeup is enabled +* for the root hub and any ports are in the middle of a resume or +* remote wakeup, we must fail the suspend. +*/ +if (hcd->self.root_hub->do_remote_wakeup) { + port =HCS_N_PORTS (ehci->hcs_params); +while (port--) { +if (ehci->reset_done[port] !=0 ) { +spin_unlock_irq (&ehci->lock); +ehci_dbg (ehci,"suspend failed because " +"port %d is resuming\n" , + port +1 ); +return -EBUSY ; + } + } + } +/* stop schedules, clean any completed work */ if (HC_IS_RUNNING (hcd->state)) {ehci_quiesce (ehci);
@@ -138,6 +155,7 @@ static int ehci_bus_suspend (struct usb_*/ ehci->bus_suspended =0 ; ehci->owned_ports =0 ; + port =HCS_N_PORTS (ehci->hcs_params);while (port--) {u32 __iomem *reg = &ehci->regs->port_status [port];u32 t1 =ehci_readl (ehci, reg) & ~PORT_RWC_BITS ;
drivers/usb/host/uhci-hcd.c +14 -1
@@ -749,7 +749,20 @@ static int uhci_rh_suspend(struct usb_hcspin_lock_irq (&uhci->lock);if (!test_bit (HCD_FLAG_HW_ACCESSIBLE , &hcd->flags)) rc = -ESHUTDOWN ; -else if (!uhci->dead) +else if (uhci->dead) + ;/* Dead controllers tell no tales */ + +/* Once the controller is stopped, port resumes that are already +* in progress won't complete. Hence if remote wakeup is enabled +* for the root hub and any ports are in the middle of a resume or +* remote wakeup, we must fail the suspend. +*/ +else if (hcd->self.root_hub->do_remote_wakeup && + uhci->resuming_ports) { +dev_dbg (uhci_dev (uhci),"suspend failed because a port " +"is resuming\n" ); + rc = -EBUSY ; + }else suspend_rh (uhci,UHCI_RH_SUSPENDED );spin_unlock_irq (&uhci->lock);return rc;
PATCH 15/29 USB: add missing delay during remote wakeup
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Alan Stern <[email protected]>
commit 49d0f078f494b9d81e820a13dd8093a9bfb0b6b1 upstream.
This patch (as1330) fixes a bug in khbud's handling of remote wakeups. When a device sends a remote-wakeup request, the parent hub (or the host controller driver, for directly attached devices) begins the resume sequence and notifies khubd when the sequence finishes. At this point the port's SUSPEND feature is automatically turned off.
However the device needs an additional 10-ms resume-recovery time (TRSMRCY in the USB spec). Khubd does not wait for this delay if the SUSPEND feature is off, and as a result some devices fail to behave properly following a remote wakeup. This patch adds the missing delay to the remote-wakeup path.
It also extends the resume-signalling delay used by ehci-hcd and uhci-hcd from 20 ms (the value in the spec) to 25 ms (the value we use for non-remote-wakeup resumes). The extra time appears to help some devices.
--- drivers/usb/core/hub.c | 3 +++ drivers/usb/host/ehci-hcd.c | 5 +++-- drivers/usb/host/uhci-hub.c | 2 +- 3 files changed, 7 insertions(+), 3 deletions(-)
drivers/usb/core/hub.c +3 -0
@@ -3286,6 +3286,9 @@ static void hub_events(void) USB_PORT_FEAT_C_SUSPEND); udev = hdev->children[i-1 ];if (udev) { +/* TRSMRCY = 10 msec */ +msleep (10 ); +usb_lock_device (udev); ret =remote_wakeup (hdev-> children[i-1 ]);
drivers/usb/host/ehci-hcd.c +3 -2
@@ -785,9 +785,10 @@ static irqreturn_t ehci_irq (struct usb_/* start 20 msec resume signaling from this port, * and make khubd collect PORT_STAT_C_SUSPEND to -* stop that signaling. +* stop that signaling. Use 5 ms extra for safety, +* like usb_port_resume() does. */ - ehci->reset_done [i] = jiffies +msecs_to_jiffies (20 ); + ehci->reset_done[i] = jiffies +msecs_to_jiffies (25 );ehci_dbg (ehci,"port %d remote wakeup\n" , i +1 );mod_timer (&hcd->rh_timer, ehci->reset_done[i]); }
drivers/usb/host/uhci-hub.c +1 -1
@@ -167,7 +167,7 @@ static void uhci_check_ports(struct uhci/* Port received a wakeup request */ set_bit (port, &uhci->resuming_ports); uhci->ports_timeout = jiffies + -msecs_to_jiffies (20 ); +msecs_to_jiffies (25 );/* Make sure we see the port again * after the resuming period is over. */
PATCH 16/29 USB: add speed values for USB 3.0 and wireless controllers
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Greg Kroah-Hartman <[email protected]>
commit b132b04e193908a94d95065d0628f8fb0159cc55 upstream.
These controllers say "unknown" for their speed in sysfs, which obviously isn't correct.
--- drivers/usb/core/sysfs.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/usb/core/sysfs.c +6 -0
@@ -115,6 +115,12 @@ show_speed(struct device *dev, struct decase USB_SPEED_HIGH : speed ="480" ;break ; +case USB_SPEED_VARIABLE : + speed ="480" ; +break ; +case USB_SPEED_SUPER : + speed ="5000" ; +break ;default : speed ="unknown" ; }
PATCH 17/29 ACPI: EC: Accelerate query execution
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Alexey Starikovskiy <[email protected]>
commit a62e8f1978f49e52f87a711ff6711b323d4b12ff upstream.
Split EC query handling into acknowledge and execution phase. This allows much smaller pending query lattency and lowers chances of EC going "wild" and losing events.
Reference: http://bugzilla.kernel.org/show_bug.cgi?id=14858
--- drivers/acpi/ec.c | 122 ++++++++++++++++++++++++++++++++++-------------------- 1 file changed, 77 insertions(+), 45 deletions(-)
drivers/acpi/ec.c +77 -45
@@ -201,14 +201,13 @@ unlock:spin_unlock_irqrestore (&ec->curr_lock, flags); } -static void acpi_ec_gpe_query (void *ec_cxt); +static int acpi_ec_sync_query (struct acpi_ec *ec); -static int ec_check_sci (struct acpi_ec *ec,u8 state) +static int ec_check_sci_sync (struct acpi_ec *ec,u8 state) {if (state &ACPI_EC_FLAG_SCI ) {if (!test_and_set_bit (EC_FLAGS_QUERY_PENDING , &ec->flags)) -return acpi_os_execute (OSL_EC_BURST_HANDLER , - acpi_ec_gpe_query, ec); +return acpi_ec_sync_query (ec); }return 0 ; }
@@ -249,11 +248,6 @@ static int acpi_ec_transaction_unlocked( {unsigned long tmp;int ret =0 ; -pr_debug (PREFIX "transaction start\n" ); -/* disable GPE during transaction if storm is detected */ -if (test_bit (EC_FLAGS_GPE_STORM , &ec->flags)) { -acpi_disable_gpe (NULL , ec->gpe); - }if (EC_FLAGS_MSI )udelay (ACPI_EC_MSI_UDELAY );/* start transaction */
@@ -269,16 +263,6 @@ static int acpi_ec_transaction_unlocked(spin_lock_irqsave (&ec->curr_lock, tmp); ec->curr =NULL ;spin_unlock_irqrestore (&ec->curr_lock, tmp); -if (test_bit (EC_FLAGS_GPE_STORM , &ec->flags)) { -/* check if we received SCI during transaction */ -ec_check_sci (ec,acpi_ec_read_status (ec)); -/* it is safe to enable GPE outside of transaction */ -acpi_enable_gpe (NULL , ec->gpe); - }else if (t->irq_count >ACPI_EC_STORM_THRESHOLD ) { -pr_info (PREFIX "GPE storm detected, " -"transactions will use polling mode\n" ); -set_bit (EC_FLAGS_GPE_STORM , &ec->flags); - }return ret; }
@@ -321,7 +305,24 @@ static int acpi_ec_transaction(struct ac status = -ETIME ; goto end; } +pr_debug (PREFIX "transaction start\n" ); +/* disable GPE during transaction if storm is detected */ +if (test_bit (EC_FLAGS_GPE_STORM , &ec->flags)) { +acpi_disable_gpe (NULL , ec->gpe); + } + status =acpi_ec_transaction_unlocked (ec, t); + +/* check if we received SCI during transaction */ +ec_check_sci_sync (ec,acpi_ec_read_status (ec)); +if (test_bit (EC_FLAGS_GPE_STORM , &ec->flags)) { +/* it is safe to enable GPE outside of transaction */ +acpi_enable_gpe (NULL , ec->gpe); + }else if (t->irq_count >ACPI_EC_STORM_THRESHOLD ) { +pr_info (PREFIX "GPE storm detected, " +"transactions will use polling mode\n" ); +set_bit (EC_FLAGS_GPE_STORM , &ec->flags); + } end:if (ec->global_lock)acpi_release_global_lock (glk);
@@ -443,7 +444,7 @@ int ec_transaction(u8 command,EXPORT_SYMBOL (ec_transaction); -static int acpi_ec_query (struct acpi_ec *ec,u8 * data) +static int acpi_ec_query_unlocked (struct acpi_ec *ec,u8 * data) {int result;u8 d;
@@ -452,20 +453,16 @@ static int acpi_ec_query(struct acpi_ec .wlen = 0, .rlen = 1};if (!ec || !data)return -EINVAL ; -/* * Query the EC to find out which _Qxx method we need to evaluate. * Note that successful completion of the query causes the ACPI_EC_SCI * bit to be cleared (and thus clearing the interrupt source). */ - - result =acpi_ec_transaction (ec, &t); + result =acpi_ec_transaction_unlocked (ec, &t);if (result)return result; -if (!d)return -ENODATA ; - *data = d;return 0 ; }
@@ -509,43 +506,78 @@ void acpi_ec_remove_query_handler(structEXPORT_SYMBOL_GPL (acpi_ec_remove_query_handler); -static void acpi_ec_gpe_query (void *ec_cxt) +static void acpi_ec_run (void *cxt) { -struct acpi_ec *ec = ec_cxt; -u8 value =0 ; -struct acpi_ec_query_handler *handler, copy; - -if (!ec ||acpi_ec_query (ec, &value)) +struct acpi_ec_query_handler *handler = cxt; +if (!handler)return ; -mutex_lock (&ec->lock); +pr_debug (PREFIX "start query execution\n" ); +if (handler->func) + handler->func (handler->data); +else if (handler->handle) +acpi_evaluate_object (handler->handle,NULL ,NULL ,NULL ); +pr_debug (PREFIX "stop query execution\n" ); +kfree (handler); +} + +static int acpi_ec_sync_query (struct acpi_ec *ec) +{ +u8 value =0 ; +int status; +struct acpi_ec_query_handler *handler, *copy; +if ((status =acpi_ec_query_unlocked (ec, &value))) +return status;list_for_each_entry (handler, &ec->list, node) {if (value == handler->query_bit) {/* have custom handler for this bit */ -memcpy (©, handler,sizeof (copy)); -mutex_unlock (&ec->lock); -if (copy.func) { - copy.func (copy.data); - }else if (copy.handle) { -acpi_evaluate_object (copy.handle,NULL ,NULL ,NULL ); - } -return ; + copy =kmalloc (sizeof (*handler),GFP_KERNEL ); +if (!copy) +return -ENOMEM ; +memcpy (copy, handler,sizeof (*copy)); +pr_debug (PREFIX "push query execution (0x%2x) on queue\n" , value); +return acpi_os_execute (OSL_GPE_HANDLER , + acpi_ec_run, copy); } } +return 0 ; +} + +static void acpi_ec_gpe_query (void *ec_cxt) +{ +struct acpi_ec *ec = ec_cxt; +if (!ec) +return ; +mutex_lock (&ec->lock); +acpi_ec_sync_query (ec);mutex_unlock (&ec->lock); } +static void acpi_ec_gpe_query (void *ec_cxt); + +static int ec_check_sci (struct acpi_ec *ec,u8 state) +{ +if (state &ACPI_EC_FLAG_SCI ) { +if (!test_and_set_bit (EC_FLAGS_QUERY_PENDING , &ec->flags)) { +pr_debug (PREFIX "push gpe query to the queue\n" ); +return acpi_os_execute (OSL_NOTIFY_HANDLER , + acpi_ec_gpe_query, ec); + } + } +return 0 ; +} +static u32 acpi_ec_gpe_handler (void *data) {struct acpi_ec *ec = data; -u8 status;pr_debug (PREFIX "~~~> interrupt\n" ); - status =acpi_ec_read_status (ec); -advance_transaction (ec, status); -if (ec_transaction_done (ec) && (status &ACPI_EC_FLAG_IBF ) ==0 ) +advance_transaction (ec,acpi_ec_read_status (ec)); +if (ec_transaction_done (ec) && + (acpi_ec_read_status (ec) &ACPI_EC_FLAG_IBF ) ==0 ) {wake_up (&ec->wait); -ec_check_sci (ec, status); +ec_check_sci (ec,acpi_ec_read_status (ec)); + }return ACPI_INTERRUPT_HANDLED ; }
PATCH 18/29 ACPI: EC: Add wait for irq storm
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Alexey Starikovskiy <[email protected]>
commit 54070101f86ca9a6e9ba243c999d144721ec3db7 upstream.
Merge of poll and irq modes accelerated EC transaction, so that keyboard starts to suffer again. Add msleep(1) into transaction path for the storm to allow keyboard controller to do its job.
Reference: http://bugzilla.kernel.org/show_bug.cgi?id=14747
--- drivers/acpi/ec.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/acpi/ec.c +2 -1
@@ -259,7 +259,6 @@ static int acpi_ec_transaction_unlocked(clear_bit (EC_FLAGS_QUERY_PENDING , &ec->flags);spin_unlock_irqrestore (&ec->curr_lock, tmp); ret =ec_poll (ec); -pr_debug (PREFIX "transaction end\n" );spin_lock_irqsave (&ec->curr_lock, tmp); ec->curr =NULL ;spin_unlock_irqrestore (&ec->curr_lock, tmp);
@@ -316,6 +315,7 @@ static int acpi_ec_transaction(struct ac/* check if we received SCI during transaction */ ec_check_sci_sync (ec,acpi_ec_read_status (ec));if (test_bit (EC_FLAGS_GPE_STORM , &ec->flags)) { +msleep (1 );/* it is safe to enable GPE outside of transaction */ acpi_enable_gpe (NULL , ec->gpe); }else if (t->irq_count >ACPI_EC_STORM_THRESHOLD ) {
@@ -323,6 +323,7 @@ static int acpi_ec_transaction(struct ac "transactions will use polling mode\n");set_bit (EC_FLAGS_GPE_STORM , &ec->flags); } +pr_debug (PREFIX "transaction end\n" ); end:if (ec->global_lock)acpi_release_global_lock (glk);
PATCH 19/29 SCSI: enclosure: fix oops while iterating enclosure_status array
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: James Bottomley <[email protected]>
commit cc9b2e9f6603190c009e5d2629ce8e3f99571346 upstream.
Based on patch originally by Jeff Mahoney <[email protected]>
enclosure_status is expected to be a NULL terminated array of strings but isn't actually NULL terminated. When writing an invalid value to /sys/class/enclosure/.../.../status, it goes off the end of the array and Oopses.
Fix by making the assumption true and adding NULL at the end.
--- drivers/misc/enclosure.c | 1 + include/linux/enclosure.h | 2 ++ 2 files changed, 3 insertions(+)
drivers/misc/enclosure.c +1 -0
@@ -391,6 +391,7 @@ static const char *const enclosure_statu [ENCLOSURE_STATUS_NOT_INSTALLED] = "not installed", [ENCLOSURE_STATUS_UNKNOWN] = "unknown", [ENCLOSURE_STATUS_UNAVAILABLE] = "unavailable", + [ENCLOSURE_STATUS_MAX] = NULL, };static const char *const enclosure_type [] = {
include/linux/enclosure.h +2 -0
@@ -42,6 +42,8 @@ enum enclosure_status {ENCLOSURE_STATUS_NOT_INSTALLED ,ENCLOSURE_STATUS_UNKNOWN ,ENCLOSURE_STATUS_UNAVAILABLE , +/* last element for counting purposes */ + ENCLOSURE_STATUS_MAX };/* SFF-8485 activity light settings */
PATCH 20/29 drm/i915: Read the response after issuing DDC bus switch command
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Zhao Yakui <[email protected]>
commit 6a304caf0bf9c429fc261f260b86cabf5bde2cbb upstream.
For some SDVO cards based on conexant chip, we can't read the EDID if we don't read the response after issuing SDVO DDC bus switch command.
Quoted 1 line
From the SDVO spec once when another I2C transaction is finished after
completing the I2C transaction of issuing the bus switch command, it will be switched back to the SDVO internal state again. So we can't initiate a new I2C transaction to read the response after issuing the DDC bus switch command. Instead we should issue DDC bus switch command and read the response in the same I2C transaction.
https://bugs.freedesktop.org/show_bug.cgi?id=23842
https://bugs.freedesktop.org/show_bug.cgi?id=24458
https://bugs.freedesktop.org/show_bug.cgi?id=24522
https://bugs.freedesktop.org/show_bug.cgi?id=24282
--- drivers/gpu/drm/i915/intel_sdvo.c | 57 +++++++++++++++++++++++++++++++++++--- 1 file changed, 53 insertions(+), 4 deletions(-)
drivers/gpu/drm/i915/intel_sdvo.c +53 -4
@@ -472,14 +472,63 @@ static int intel_sdvo_get_pixel_multipli }/** -* Don't check status code from this as it switches the bus back to the -* SDVO chips which defeats the purpose of doing a bus switch in the first -* place. +* Try to read the response after issuie the DDC switch command. But it +* is noted that we must do the action of reading response and issuing DDC +* switch command in one I2C transaction. Otherwise when we try to start +* another I2C transaction after issuing the DDC bus switch, it will be +* switched to the internal SDVO register. */ static void intel_sdvo_set_control_bus_switch (struct intel_output *intel_output,u8 target) { -intel_sdvo_write_cmd (intel_output,SDVO_CMD_SET_CONTROL_BUS_SWITCH , &target,1 ); +struct intel_sdvo_priv *sdvo_priv = intel_output->dev_priv; +u8 out_buf[2 ], cmd_buf[2 ], ret_value[2 ], ret; +struct i2c_msg msgs[] = { + { + .addr = sdvo_priv->slave_addr >>1 , + .flags =0 , + .len =2 , + .buf = out_buf, + }, +/* the following two are to read the response */ + { + .addr = sdvo_priv->slave_addr >>1 , + .flags =0 , + .len =1 , + .buf = cmd_buf, + }, + { + .addr = sdvo_priv->slave_addr >>1 , + .flags =I2C_M_RD , + .len =1 , + .buf = ret_value, + }, + }; + +intel_sdvo_debug_write (intel_output,SDVO_CMD_SET_CONTROL_BUS_SWITCH , + &target,1 ); +/* write the DDC switch command argument */ +intel_sdvo_write_byte (intel_output,SDVO_I2C_ARG_0 , target); + + out_buf[0 ] =SDVO_I2C_OPCODE ; + out_buf[1 ] =SDVO_CMD_SET_CONTROL_BUS_SWITCH ; + cmd_buf[0 ] =SDVO_I2C_CMD_STATUS ; + cmd_buf[1 ] =0 ; + ret_value[0 ] =0 ; + ret_value[1 ] =0 ; + + ret =i2c_transfer (intel_output->i2c_bus, msgs,3 ); +if (ret !=3 ) { +/* failure in I2C transfer */ +DRM_DEBUG_KMS ("I2c transfer returned %d\n" , ret); +return ; + } +if (ret_value[0 ] !=SDVO_CMD_STATUS_SUCCESS ) { +DRM_DEBUG_KMS ("DDC switch command returns response %d\n" , + ret_value[0 ]); +return ; + } +return ; }static bool intel_sdvo_set_target_input (struct intel_output *intel_output,bool target_0,bool target_1)
PATCH 21/29 drm/i915: try another possible DDC bus for the SDVO device with multiple outputs
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Zhao Yakui <[email protected]>
commit 7c3f0a2726fed78e0e0afe3b6fc3c1f5b298e447 upstream.
There exist multiple DDC buses for the SDVO cards with multiple outputs. When we can't get the EDID by using the select DDC bus, we can try the other possible DDC bus to see whether the EDID can be obtained.
https://bugs.freedesktop.org/show_bug.cgi?id=23842
--- drivers/gpu/drm/i915/intel_sdvo.c | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+)
drivers/gpu/drm/i915/intel_sdvo.c +26 -0
@@ -1638,6 +1638,32 @@ intel_sdvo_hdmi_sink_detect(struct drm_c edid =drm_get_edid (&intel_output->base, intel_output->ddc_bus); +/* This is only applied to SDVO cards with multiple outputs */ +if (edid ==NULL &&intel_sdvo_multifunc_encoder (intel_output)) { +uint8_t saved_ddc, temp_ddc; + saved_ddc = sdvo_priv->ddc_bus; + temp_ddc = sdvo_priv->ddc_bus >>1 ; +/* +* Don't use the 1 as the argument of DDC bus switch to get +* the EDID. It is used for SDVO SPD ROM. +*/ +while (temp_ddc >1 ) { + sdvo_priv->ddc_bus = temp_ddc; + edid =drm_get_edid (&intel_output->base, + intel_output->ddc_bus); +if (edid) { +/* +* When we can get the EDID, maybe it is the +* correct DDC bus. Update it. +*/ + sdvo_priv->ddc_bus = temp_ddc; +break ; + } + temp_ddc >>=1 ; + } +if (edid ==NULL ) + sdvo_priv->ddc_bus = saved_ddc; + }/* when there is no edid and no monitor is connected with VGA * port, try to use the CRT ddc to read the EDID for DVI-connector */
PATCH 22/29 block: bdev_stack_limits wrapper
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Martin K. Petersen <[email protected]>
commit 17be8c245054b9c7786545af3ba3ca4e54cd4ad9 upstream.
DM does not want to know about partition offsets. Add a partition-aware wrapper that DM can use when stacking block devices.
--- block/blk-settings.c | 22 ++++++++++++++++++++++ include/linux/blkdev.h | 2 ++ 2 files changed, 24 insertions(+)
block/blk-settings.c +22 -0
@@ -560,6 +560,28 @@ int blk_stack_limits(struct queue_limitsEXPORT_SYMBOL (blk_stack_limits);/** +* bdev_stack_limits - adjust queue limits for stacked drivers +* @t: the stacking driver limits (top device) +* @bdev: the component block_device (bottom) +* @start: first data sector within component device +* +* Description: +* Merges queue limits for a top device and a block_device. Returns +* 0 if alignment didn't change. Returns -1 if adding the bottom +* device caused misalignment. +*/ +int bdev_stack_limits (struct queue_limits *t,struct block_device *bdev, +sector_t start) +{ +struct request_queue *bq =bdev_get_queue (bdev); + + start +=get_start_sect (bdev); + +return blk_stack_limits (t, &bq->limits, start <<9 ); +} +EXPORT_SYMBOL (bdev_stack_limits); + +/** * disk_stack_limits - adjust queue limits for stacked drivers * @disk: MD/DM gendisk (top) * @bdev: the underlying block device (bottom)
include/linux/blkdev.h +2 -0
@@ -942,6 +942,8 @@ extern void blk_queue_io_opt(struct requextern void blk_set_default_limits (struct queue_limits *lim);extern int blk_stack_limits (struct queue_limits *t,struct queue_limits *b,sector_t offset); +extern int bdev_stack_limits (struct queue_limits *t,struct block_device *bdev, +sector_t offset);extern void disk_stack_limits (struct gendisk *disk,struct block_device *bdev,sector_t offset);extern void blk_queue_stack_limits (struct request_queue *t,struct request_queue *b);
PATCH 23/29 DM: Fix device mapper topology stacking
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Martin K. Petersen <[email protected]>
commit b27d7f16d3c6c27345d4280a739809c1c2c4c0b5 upstream.
Make DM use bdev_stack_limits() function so that partition offsets get taken into account when calculating alignment. Clarify stacking warnings.
Also remove obsolete clearing of final alignment_offset and misalignment flag.
--- drivers/md/dm-table.c | 20 +++++--------------- 1 file changed, 5 insertions(+), 15 deletions(-)
drivers/md/dm-table.c +5 -15
@@ -499,16 +499,15 @@ int dm_set_device_limits(struct dm_targereturn 0 ; } -if (blk_stack_limits (limits, &q->limits, start <<9 ) <0 ) -DMWARN ("%s: target device %s is misaligned: " +if (bdev_stack_limits (limits, bdev, start) <0 ) +DMWARN ("%s: adding target device %s caused an alignment inconsistency: " "physical_block_size=%u, logical_block_size=%u, " "alignment_offset=%u, start=%llu" ,dm_device_name (ti->table->md),bdevname (bdev, b), q->limits.physical_block_size, q->limits.logical_block_size, q->limits.alignment_offset, - (unsigned long long ) start <<9 ); - + (unsigned long long ) start <<SECTOR_SHIFT );/* * Check if merge fn is supported.
@@ -1025,9 +1024,9 @@ combine_limits:* for the table. */ if (blk_stack_limits (limits, &ti_limits,0 ) <0 ) -DMWARN ("%s: target device " +DMWARN ("%s: adding target device " "(start sect %llu len %llu) " -"is misaligned" , +"caused an alignment inconsistency" ,dm_device_name (table->md), (unsigned long long ) ti->begin, (unsigned long long ) ti->len);
@@ -1079,15 +1078,6 @@ void dm_table_set_restrictions(struct dm struct queue_limits *limits) {/* -* Each target device in the table has a data area that should normally -* be aligned such that the DM device's alignment_offset is 0. -* FIXME: Propagate alignment_offsets up the stack and warn of -* sub-optimal or inconsistent settings. -*/ - limits->alignment_offset =0 ; - limits->misaligned =0 ; - -/* * Copy table's limits to the DM device's request_queue */ q->limits = *limits;
PATCH 24/29 x86/PCI/PAT: return EINVAL for pci mmap WC request for !pat_enabled
In reply to Greg KHFrom: Suresh Siddha <[email protected]>
commit 2992e545ea006992ec9dc91c4fa996ce1e15f921 upstream.
Thomas Schlichter reported:
Quoted 5 lines
X.org uses libpciaccess which tries to mmap with write combining enabled via
/sys/bus/pci/devices/*/resource0_wc. Currently, when PAT is not enabled, the kernel does fall back to uncached mmap. Then libpciaccess thinks it succeeded mapping with write combining enabled and does not set up suited MTRR entries. ;-(
Instead of silently mapping pci mmap region as UC minus in the case of !pat_enabled and wc request, we can return error. Eric Anholt mentioned that caller (like X) typically follows up with UC minus pci mmap request and if there is a free mtrr slot, caller will manage adding WC mtrr.
Jesse Barnes says:
Quoted 3 lines
Older versions of libpciaccess will behave better if we do it that way (iirc it only allocates an MTRR if the
resource_wcfile doesn't exist or fails to get mapped).
--- arch/x86/pci/i386.c | 9 +++++++++ 1 file changed, 9 insertions(+)
arch/x86/pci/i386.c +9 -0
@@ -282,6 +282,15 @@ int pci_mmap_page_range(struct pci_dev *return -EINVAL ; prot =pgprot_val (vma->vm_page_prot); + +/* +* Return error if pat is not enabled and write_combine is requested. +* Caller can followup with UC MINUS request and add a WC mtrr if there +* is a free mtrr slot. +*/ +if (!pat_enabled && write_combine) +return -EINVAL ; +if (pat_enabled && write_combine) prot |= _PAGE_CACHE_WC;else if (pat_enabled || boot_cpu_data.x86 >3 )
PATCH 25/29 USB: fix usbstorage for 2770:915d delivers no FAT
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Ryan May <[email protected]>
commit 10d2cdb6102669279bee2d9a00a22431b74583d5 upstream.
Resolves kernel.org bug 14914.
Remove entry for 2770:915d (usb digital camera with mass storage support) from unusual_devs.h. The fix triggered by the entry causes the file system on the camera to be completely inaccessible (no partition table, the device is not mountable).
The patch works, but let me clarify a few things about it. All the patch does is remove the entry for this device from the drivers/usb/storage/unusual_devs.h, which is supposed to help with a problem with the device's reported size (I think). I'm pretty sure it was originally added for a reason, so I'm not sure removing it won't cause other problems to reappear. Also, I should note that this unusual_devs.h entry was present (and activating workarounds) in 2.6.29, but in that version everything works fine. Starting with 2.6.30, things no longer work.
--- drivers/usb/storage/unusual_devs.h | 7 ------- 1 file changed, 7 deletions(-)
drivers/usb/storage/unusual_devs.h +0 -7
@@ -1807,13 +1807,6 @@ UNUSUAL_DEV( 0x2735, 0x100b, 0x0000, 0xUS_SC_DEVICE ,US_PR_DEVICE ,NULL , US_FL_GO_SLOW ), -/* Reported by Rohan Hart <[email protected]> */ -UNUSUAL_DEV (0x2770 ,0x915d ,0x0010 ,0x0010 , -"INTOVA" , -"Pixtreme" , -US_SC_DEVICE ,US_PR_DEVICE ,NULL , - US_FL_FIX_CAPACITY ), -/* Reported by Frederic Marchal <[email protected]> * Mio Moov 330 */
Re: [Stable-review] [25/29] USB: fix usbstorage for 2770:915d delivers no FAT
Quoted 15 lines · Greg KH
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Ryan May <[email protected]>
commit
10d2cdb6102669279bee2d9a00a22431b74583d5upstream.Resolves kernel.org bug 14914.
Remove entry for 2770:915d (usb digital camera with mass storage support) from
unusual_devs.h. The fix triggered by the entry causes the file system on the camera to be completely inaccessible (no partition table, the device is not mountable).
Quoted 9 lines
The patch works, but let me clarify a few things about it. All the patch does is remove the entry for this device from the
drivers/usb/storage/unusual_devs.h, which is supposed to help with a problem with the device's reported size (I think). I'm pretty sure it was originally added for a reason, so I'm not sure removing it won't cause other problems to reappear. Also, I should note that thisunusual_devs.hentry was present (and activating workarounds) in 2.6.29, but in that version everything works fine. Starting with 2.6.30, things no longer work.
[...]
It doesn't sound like this bug or fix are sufficiently well understood yet to be suitable for a stable update. The bug report is currently marked as invalid!
Ben.
Signature · 2 lines
Ben Hutchings Any smoothly functioning technology is indistinguishable from a rigged demo.
Re: [Stable-review] [25/29] USB: fix usbstorage for 2770:915d delivers no FAT
Quoted 25 lines · Ben Hutchings
Quoted 15 lines · Greg KH
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Ryan May <[email protected]>
commit
10d2cdb6102669279bee2d9a00a22431b74583d5upstream.Resolves kernel.org bug 14914.
Remove entry for 2770:915d (usb digital camera with mass storage support) from
unusual_devs.h. The fix triggered by the entry causes the file system on the camera to be completely inaccessible (no partition table, the device is not mountable).Quoted 9 lines
The patch works, but let me clarify a few things about it. All the patch does is remove the entry for this device from the
drivers/usb/storage/unusual_devs.h, which is supposed to help with a problem with the device's reported size (I think). I'm pretty sure it was originally added for a reason, so I'm not sure removing it won't cause other problems to reappear. Also, I should note that thisunusual_devs.hentry was present (and activating workarounds) in 2.6.29, but in that version everything works fine. Starting with 2.6.30, things no longer work.
Quoted 5 lines
[...]
It doesn't sound like this bug or fix are sufficiently well understood yet to be suitable for a stable update. The bug report is currently marked as invalid!
It was marked that way as we couldn't take a patch through a bug report. The email thread for it said it solved the problem, and I have had a number of other users report that it solves their problem as well.
So I do think it needs to remain, unless someone has a report to the contrary? And if so, I'll be glad to take it out of the main tree, and then take that back to the -stable tree.
thanks,
greg k-h
PATCH 26/29 vmalloc: remove BUG_ON due to racy counting of VM_LAZY_FREE
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Yongseok Koh <[email protected]>
commit 88f5004430babb836cfce886d5d54c82166f8ba4 upstream.
In free_unmap_area_noflush(), va->flags is marked as VM_LAZY_FREE first, and then vmap_lazy_nr is increased atomically.
But, in __purge_vmap_area_lazy(), while traversing of vmap_are_list, nr is counted by checking VM_LAZY_FREE is set to va->flags. After counting the variable nr, kernel reads vmap_lazy_nr atomically and checks a BUG_ON condition whether nr is greater than vmap_lazy_nr to prevent vmap_lazy_nr from being negative.
The problem is that, if interrupted right after marking VM_LAZY_FREE, increment of vmap_lazy_nr can be delayed. Consequently, BUG_ON condition can be met because nr is counted more than vmap_lazy_nr.
It is highly probable when vmalloc/vfree are called frequently. This scenario have been verified by adding delay between marking VM_LAZY_FREE and increasing vmap_lazy_nr in free_unmap_area_noflush().
Even the vmap_lazy_nr is for checking high watermark, it never be the strict watermark. Although the BUG_ON condition is to prevent vmap_lazy_nr from being negative, vmap_lazy_nr is signed variable. So, it could go down to negative value temporarily.
Consequently, removing the BUG_ON condition is proper.
A possible BUG_ON message is like the below.
kernel BUG at mm/vmalloc.c:517!
invalid opcode: 0000 [#1] SMP
EIP: 0060:[<c04824a4>] EFLAGS: 00010297 CPU: 3 EIP is at __purge_vmap_area_lazy+0x144/0x150
EAX: ee8a8818 EBX: c08e77d4 ECX: e7c7ae40 EDX: c08e77ec
ESI: 000081fe EDI: e7c7ae60 EBP: e7c7ae64 ESP: e7c7ae3c
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Call Trace: [<c0482ad9>] free_unmap_vmap_area_noflush+0x69/0x70 [<c0482b02>] remove_vm_area+0x22/0x70 [<c0482c15>] __vunmap+0x45/0xe0 [<c04831ec>] vmalloc+0x2c/0x30 Code: 8d 59 e0 eb 04 66 90 89 cb 89 d0 e8 87 fe ff ff 8b 43 20 89 da 8d 48 e0 8d 43 20 3b 04 24 75 e7 fe 05 a8 a5 a3 c0 e9 78 ff ff ff <0f> 0b eb fe 90 8d b4 26 00 00 00 00 56 89 c6 b8 ac a5 a3 c0 31 EIP: [<c04824a4>] __purge_vmap_area_lazy+0x144/0x150 SS:ESP 0068:e7c7ae3c
[ See also http://marc.info/?l=linux-kernel&m=126335856228090&w=2 ]
--- mm/vmalloc.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
mm/vmalloc.c +1 -3
@@ -555,10 +555,8 @@ static void __purge_vmap_area_lazy(unsig }rcu_read_unlock (); -if (nr) { -BUG_ON (nr >atomic_read (&vmap_lazy_nr)); +if (nr)atomic_sub (nr, &vmap_lazy_nr); - }if (nr || force_flush)flush_tlb_kernel_range (*start, *end);
PATCH 27/29 perf timechart: Use tid not pid for COMM change
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Arjan van de Ven <[email protected]>
commit 8f06d7e6e1bbfb32698d6d455583ab7460c090e2 upstream.
A process that changes its comm field, does this on a per kernel task struct basis. The timechart tool used, incorrectly, the pid to track this, and should have used the tid instead...
LKML-Reference: <[email protected]>
--- tools/perf/builtin-timechart.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/perf/builtin-timechart.c +1 -1
@@ -275,7 +275,7 @@ static u64 cpus_pstate_state[MAX_CPUS];static int process_comm_event (event_t *event) { -pid_set_comm (event->comm.pid, event->comm.comm); +pid_set_comm (event->comm.tid, event->comm.comm);return 0 ; } static int
PATCH 28/29 perf events: Dont report side-band events on each cpu for per-task-per-cpu events
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Peter Zijlstra <[email protected]>
commit 5d27c23df09b702868d9a3bff86ec6abd22963ac upstream.
Acme noticed that his FORK/MMAP numbers were inflated by about the same factor as his cpu-count.
This led to the discovery of a few more sites that need to respect the event->cpu filter.
LKML-Reference: <[email protected]>
--- kernel/perf_event.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-)
kernel/perf_event.c +18 -2
@@ -1359,6 +1359,9 @@ static void perf_ctx_adjust_freq(structif (event->state !=PERF_EVENT_STATE_ACTIVE )continue ; +if (event->cpu !=-1 && event->cpu !=smp_processor_id ()) +continue ; + hwc = &event->hw; interrupts = hwc->interrupts;
@@ -3226,6 +3229,9 @@ static void perf_event_task_output(strucstatic int perf_event_task_match (struct perf_event *event) { +if (event->cpu !=-1 && event->cpu !=smp_processor_id ()) +return 0 ; +if (event->attr.comm || event->attr.mmap || event->attr.task)return 1 ;
@@ -3262,6 +3268,7 @@ static void perf_event_task_event(struct ctx =rcu_dereference (task_event->task->perf_event_ctxp);if (ctx)perf_event_task_ctx (ctx, task_event); +put_cpu_var (perf_cpu_context);rcu_read_unlock (); }
@@ -3338,6 +3345,9 @@ static void perf_event_comm_output(strucstatic int perf_event_comm_match (struct perf_event *event) { +if (event->cpu !=-1 && event->cpu !=smp_processor_id ()) +return 0 ; +if (event->attr.comm)return 1 ;
@@ -3378,7 +3388,6 @@ static void perf_event_comm_event(struct cpuctx = &get_cpu_var (perf_cpu_context);perf_event_comm_ctx (&cpuctx->ctx, comm_event); -put_cpu_var (perf_cpu_context);rcu_read_lock ();/*
@@ -3388,6 +3397,7 @@ static void perf_event_comm_event(struct ctx =rcu_dereference (current->perf_event_ctxp);if (ctx)perf_event_comm_ctx (ctx, comm_event); +put_cpu_var (perf_cpu_context);rcu_read_unlock (); }
@@ -3462,6 +3472,9 @@ static void perf_event_mmap_output(strucstatic int perf_event_mmap_match (struct perf_event *event,struct perf_mmap_event *mmap_event) { +if (event->cpu !=-1 && event->cpu !=smp_processor_id ()) +return 0 ; +if (event->attr.mmap)return 1 ;
@@ -3539,7 +3552,6 @@ got_name: cpuctx = &get_cpu_var (perf_cpu_context);perf_event_mmap_ctx (&cpuctx->ctx, mmap_event); -put_cpu_var (perf_cpu_context);rcu_read_lock ();/*
@@ -3549,6 +3561,7 @@ got_name: ctx =rcu_dereference (current->perf_event_ctxp);if (ctx)perf_event_mmap_ctx (ctx, mmap_event); +put_cpu_var (perf_cpu_context);rcu_read_unlock ();kfree (buf);
@@ -3811,6 +3824,9 @@ static int perf_swevent_match(struct per enum perf_type_id type, u32 event_id, struct pt_regs *regs) { + if (event->cpu != -1 && event->cpu != smp_processor_id()) + return 0; + if (!perf_swevent_is_counting(event)) return 0;
Re: [Stable-review] [28/29] perf events: Dont report side-band events on each cpu for per-task-per-cpu events
Quoted 49 lines · Greg KH
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Peter Zijlstra <[email protected]>
commit
5d27c23df09b702868d9a3bff86ec6abd22963acupstream.Acme noticed that his FORK/MMAP numbers were inflated by about the same factor as his cpu-count.
This led to the discovery of a few more sites that need to respect the
event->cpufilter.Reported-by Arnaldo Carvalho de Melo <[email protected]>Signed-off-by Peter Zijlstra <[email protected]>Cc Paul Mackerras <[email protected]>LKML-Reference: <[email protected]>
Signed-off-by Ingo Molnar <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- kernel/perf_event.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-)kernel/perf_event.c +6
-0@@ -1359,6 +1359,9 @@ static void perf_ctx_adjust_freq(structif (event->state !=PERF_EVENT_STATE_ACTIVE )continue ; +if (event->cpu !=-1 && event->cpu !=smp_processor_id ()) +continue ; + hwc = &event->hw; interrupts = hwc->interrupts;@@ -3226,6 +3229,9 @@ static void perf_event_task_output(strucstatic int perf_event_task_match (struct perf_event *event) { +if (event->cpu !=-1 && event->cpu !=smp_processor_id ()) +return 0 ; +if (event->attr.comm || event->attr.mmap || event->attr.task)return 1 ;
kernel/perf_event.c static void perf_event_task_event(struct · line 3273
Quoted 6 lines
kernel/perf_event.c +1
-0@@ -3262,6 +3268,7 @@ static void perf_event_task_event(struct ctx =rcu_dereference (task_event->task->perf_event_ctxp);if (ctx)perf_event_task_ctx (ctx, task_event); +put_cpu_var (perf_cpu_context);rcu_read_unlock (); }
I believe this hunk drops the move of put_cpu_var. The upstream hunk looks like this:
@ -3290,12 +3296,11 @@ static void perf_event_task_event(struct perf_task_event
rcu_read_lock();
cpuctx = &get_cpu_var(perf_cpu_context);
perf_event_task_ctx(&cpuctx->ctx, task_event);
- put_cpu_var(perf_cpu_context);
-
if (!ctx)
ctx = rcu_dereference(task_event->task->perf_event_ctxp);
if (ctx)
perf_event_task_ctx(ctx, task_event);
+ put_cpu_var(perf_cpu_context);
rcu_read_unlock();}
Quoted 68 lines
kernel/perf_event.c +11
-2@@ -3338,6 +3345,9 @@ static void perf_event_comm_output(strucstatic int perf_event_comm_match (struct perf_event *event) { +if (event->cpu !=-1 && event->cpu !=smp_processor_id ()) +return 0 ; +if (event->attr.comm)return 1 ;@@ -3378,7 +3388,6 @@ static void perf_event_comm_event(struct cpuctx = &get_cpu_var (perf_cpu_context);perf_event_comm_ctx (&cpuctx->ctx, comm_event); -put_cpu_var (perf_cpu_context);rcu_read_lock ();/* @@ -3388,6 +3397,7 @@ static void perf_event_comm_event(struct ctx =rcu_dereference (current->perf_event_ctxp);if (ctx)perf_event_comm_ctx (ctx, comm_event); +put_cpu_var (perf_cpu_context);rcu_read_unlock (); }@@ -3462,6 +3472,9 @@ static void perf_event_mmap_output(strucstatic int perf_event_mmap_match (struct perf_event *event,struct perf_mmap_event *mmap_event) { +if (event->cpu !=-1 && event->cpu !=smp_processor_id ()) +return 0 ; +if (event->attr.mmap)return 1 ;@@ -3539,7 +3552,6 @@ got_name: cpuctx = &get_cpu_var (perf_cpu_context);perf_event_mmap_ctx (&cpuctx->ctx, mmap_event); -put_cpu_var (perf_cpu_context);rcu_read_lock ();/* @@ -3549,6 +3561,7 @@ got_name: ctx =rcu_dereference (current->perf_event_ctxp);if (ctx)perf_event_mmap_ctx (ctx, mmap_event); +put_cpu_var (perf_cpu_context);rcu_read_unlock ();kfree (buf);@@ -3811,6 +3824,9 @@ static int perf_swevent_match(struct per enum perf_type_id type, u32 event_id, struct pt_regs *regs) { + if (event->cpu != -1 && event->cpu != smp_processor_id()) + return 0; + if (!perf_swevent_is_counting(event)) return 0;_______________________________________________
Stable-review mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/stable-review
Re: [Stable-review] [28/29] perf events: Dont report side-band events on each cpu for per-task-per-cpu events
Quoted 64 lines · Stefan Bader
Quoted 49 lines · Greg KH
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Peter Zijlstra <[email protected]>
commit
5d27c23df09b702868d9a3bff86ec6abd22963acupstream.Acme noticed that his FORK/MMAP numbers were inflated by about the same factor as his cpu-count.
This led to the discovery of a few more sites that need to respect the
event->cpufilter.Reported-by Arnaldo Carvalho de Melo <[email protected]>Signed-off-by Peter Zijlstra <[email protected]>Cc Paul Mackerras <[email protected]>LKML-Reference: <[email protected]>
Signed-off-by Ingo Molnar <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- kernel/perf_event.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-)kernel/perf_event.c +6
-0@@ -1359,6 +1359,9 @@ static void perf_ctx_adjust_freq(structif (event->state !=PERF_EVENT_STATE_ACTIVE )continue ; +if (event->cpu !=-1 && event->cpu !=smp_processor_id ()) +continue ; + hwc = &event->hw; interrupts = hwc->interrupts;@@ -3226,6 +3229,9 @@ static void perf_event_task_output(strucstatic int perf_event_task_match (struct perf_event *event) { +if (event->cpu !=-1 && event->cpu !=smp_processor_id ()) +return 0 ; +if (event->attr.comm || event->attr.mmap || event->attr.task)return 1 ;kernel/perf_event.c static void perf_event_task_event(struct · line 3273
Quoted 6 lines
kernel/perf_event.c +1
-0@@ -3262,6 +3268,7 @@ static void perf_event_task_event(struct ctx =rcu_dereference (task_event->task->perf_event_ctxp);if (ctx)perf_event_task_ctx (ctx, task_event); +put_cpu_var (perf_cpu_context);rcu_read_unlock (); }I believe this hunk drops the move of
put_cpu_var. The upstream hunk looks like this:@ -3290,12 +3296,11 @@ static void perf_event_task_event(struct
perf_task_eventrcu_read_lock(); cpuctx = &get_cpu_var(perf_cpu_context); perf_event_task_ctx(&cpuctx->ctx, task_event);
kernel/perf_event.c static void perf_event_task_event(struct · line 3273
Quoted 9 lines
kernel/perf_event.c +1
-2-put_cpu_var (perf_cpu_context); -if (!ctx) ctx =rcu_dereference (task_event->task->perf_event_ctxp);if (ctx)perf_event_task_ctx (ctx, task_event); +put_cpu_var (perf_cpu_context);rcu_read_unlock (); }
Good catch, thanks, I merged this by hand (it was needed by the patch after this), and I missed this chunk.
thanks,
greg k-h
Re: [Stable-review] [28/29] perf events: Dont report side-band events on each cpu for per-task-per-cpu events
In reply to Stefan BaderQuoted 64 lines · Stefan Bader
Quoted 49 lines · Greg KH
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Peter Zijlstra <[email protected]>
commit
5d27c23df09b702868d9a3bff86ec6abd22963acupstream.Acme noticed that his FORK/MMAP numbers were inflated by about the same factor as his cpu-count.
This led to the discovery of a few more sites that need to respect the
event->cpufilter.Reported-by Arnaldo Carvalho de Melo <[email protected]>Signed-off-by Peter Zijlstra <[email protected]>Cc Paul Mackerras <[email protected]>LKML-Reference: <[email protected]>
Signed-off-by Ingo Molnar <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- kernel/perf_event.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-)kernel/perf_event.c +6
-0@@ -1359,6 +1359,9 @@ static void perf_ctx_adjust_freq(structif (event->state !=PERF_EVENT_STATE_ACTIVE )continue ; +if (event->cpu !=-1 && event->cpu !=smp_processor_id ()) +continue ; + hwc = &event->hw; interrupts = hwc->interrupts;@@ -3226,6 +3229,9 @@ static void perf_event_task_output(strucstatic int perf_event_task_match (struct perf_event *event) { +if (event->cpu !=-1 && event->cpu !=smp_processor_id ()) +return 0 ; +if (event->attr.comm || event->attr.mmap || event->attr.task)return 1 ;kernel/perf_event.c static void perf_event_task_event(struct · line 3273
Quoted 6 lines
kernel/perf_event.c +1
-0@@ -3262,6 +3268,7 @@ static void perf_event_task_event(struct ctx =rcu_dereference (task_event->task->perf_event_ctxp);if (ctx)perf_event_task_ctx (ctx, task_event); +put_cpu_var (perf_cpu_context);rcu_read_unlock (); }I believe this hunk drops the move of
put_cpu_var. The upstream hunk looks like this:@ -3290,12 +3296,11 @@ static void perf_event_task_event(struct
perf_task_eventrcu_read_lock(); cpuctx = &get_cpu_var(perf_cpu_context); perf_event_task_ctx(&cpuctx->ctx, task_event);
kernel/perf_event.c static void perf_event_task_event(struct · line 3273
Quoted 9 lines
kernel/perf_event.c +1
-2-put_cpu_var (perf_cpu_context); -if (!ctx) ctx =rcu_dereference (task_event->task->perf_event_ctxp);if (ctx)perf_event_task_ctx (ctx, task_event); +put_cpu_var (perf_cpu_context);rcu_read_unlock (); }
All fixed up now, thanks again for the review.
greg k-h
PATCH 29/29 perf: Honour event state for aux stream data
In reply to Greg KH2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Peter Zijlstra <[email protected]>
commit 22e190851f8709c48baf00ed9ce6144cdc54d025 upstream.
Anton reported that perf record kept receiving events even after calling ioctl(PERF_EVENT_IOC_DISABLE). It turns out that FORK,COMM and MMAP events didn't respect the disabled state and kept flowing in.
LKML-Reference: <1263459187.4244.265.camel@laptop>
--- kernel/perf_event.c | 9 +++++++++ 1 file changed, 9 insertions(+)
kernel/perf_event.c +9 -0
@@ -3229,6 +3229,9 @@ static void perf_event_task_output(strucstatic int perf_event_task_match (struct perf_event *event) { +if (event->state !=PERF_EVENT_STATE_ACTIVE ) +return 0 ; +if (event->cpu !=-1 && event->cpu !=smp_processor_id ())return 0 ;
@@ -3345,6 +3348,9 @@ static void perf_event_comm_output(strucstatic int perf_event_comm_match (struct perf_event *event) { +if (event->state !=PERF_EVENT_STATE_ACTIVE ) +return 0 ; +if (event->cpu !=-1 && event->cpu !=smp_processor_id ())return 0 ;
@@ -3472,6 +3478,9 @@ static void perf_event_mmap_output(strucstatic int perf_event_mmap_match (struct perf_event *event,struct perf_mmap_event *mmap_event) { +if (event->state !=PERF_EVENT_STATE_ACTIVE ) +return 0 ; +if (event->cpu !=-1 && event->cpu !=smp_processor_id ())return 0 ;
Andrew Morton
maintainerQuoted 8 lines · On Fri, 22 Jan 2010 16:11:45 -0800 Greg KH <[email protected]> wrote:
This is the start of the stable review cycle for the 2.6.32.6 release. There are 29 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 us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it.
Responses should be made by Monday, January 24, 00:00:00 UTC. Anything received after that time might be too late.
2.6.32.6 will still contain the regression described in (for example)
http://bugzilla.kernel.org/show_bug.cgi?id=15117
http://bugzilla.kernel.org/show_bug.cgi?id=15005
It's fixed with the below revert which has been in -mm (and only in -mm) for ten days.
I don't what's going on - perhaps we're waiting for Thomas, and he's otherwise engaged. There's a fix in the lkml thread "Re: [RFC PATCH 0/4] clockevents: fix clockevent_devices list corruption after cpu hotplug" to which Thomas replied
I just applied your patch, but kept the cpuweight check. This is the least intrusive solution for now. The logic needs an overhaul, but thats neither rc4 nor stable material"
but no such patch is present in linux-next.
From: Andrew Morton <[email protected]>
Revert
: commit bb6eddf7676e1c1f3e637aa93c5224488d99036f
: Author: Thomas Gleixner <[email protected]>
: AuthorDate: Thu Dec 10 15:35:10 2009 +0100
: Commit: Thomas Gleixner <[email protected]>
: CommitDate: Fri Dec 11 10:28:08 2009 +0100
:
: clockevents: Prevent clockevent_devices list corruption on cpu hotplug
due to the regression reported in
http://bugzilla.kernel.org/show_bug.cgi?id=15005
---
kernel/time/clockevents.c | 18 +++--------------- 1 file changed, 3 insertions(+), 15 deletions(-)
kernel/time/clockevents.c renamed from kernel/time/clockevents.c~revert-clockevents-prevent-clockevent_devices-list-corruption-on-cpu-hotplug +3 -15
@@ -238,9 +238,8 @@ void clockevents_exchange_device(struct*/ void clockevents_notify (unsigned long reason,void *arg) { -struct clock_event_device *dev, *tmp; +struct list_head *node, *tmp;unsigned long flags; -int cpu;raw_spin_lock_irqsave (&clockevents_lock, flags);clockevents_do_notify (reason, arg);
@@ -251,19 +250,8 @@ void clockevents_notify(unsigned long re* Unregister the clock event devices which were * released from the users in the notify chain. */ -list_for_each_entry_safe (dev, tmp, &clockevents_released, list) -list_del (&dev->list); -/* -* Now check whether the CPU has left unused per cpu devices -*/ - cpu = *((int *)arg); -list_for_each_entry_safe (dev, tmp, &clockevent_devices, list) { -if (cpumask_test_cpu (cpu, dev->cpumask) && -cpumask_weight (dev->cpumask) ==1 ) { -BUG_ON (dev->mode !=CLOCK_EVT_MODE_UNUSED ); -list_del (&dev->list); - } - } +list_for_each_safe (node, tmp, &clockevents_released) +list_del (node);break ;default :break ;
_
Quoted 19 lines · Andrew Morton
Quoted 8 lines · On Fri, 22 Jan 2010 16:11:45 -0800 Greg KH <[email protected]> wrote:
This is the start of the stable review cycle for the 2.6.32.6 release. There are 29 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 us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it.
Responses should be made by Monday, January 24, 00:00:00 UTC. Anything received after that time might be too late.
2.6.32.6 will still contain the regression described in (for example)
http://bugzilla.kernel.org/show_bug.cgi?id=15117
http://bugzilla.kernel.org/show_bug.cgi?id=15005It's fixed with the below revert which has been in -mm (and only in -mm) for ten days.
Quoted 8 lines
I don't what's going on - perhaps we're waiting for Thomas, and he's otherwise engaged. There's a fix in the lkml thread "Re: [RFC PATCH 0/4] clockevents: fix
clockevent_deviceslist corruption after cpu hotplug" to which Thomas repliedI just applied your patch, but kept the cpuweight check. This is the least intrusive solution for now. The logic needs an overhaul, but thats neither rc4 nor stable material"
Just sent the pull request for it. Sorry for the delay. The patch needs to go into 32.6 as well.
Thanks,
tglx
Thomas Gleixner wrote On 24-01-2010 18:29:
Quoted 25 lines · Andrew Morton
Quoted 24 lines · On Fri, 22 Jan 2010 16:11:45 -0800 Greg KH <[email protected]> wrote:
Quoted 9 lines
This is the start of the stable review cycle for the 2.6.32.6 release. There are 29 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 us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it.
Responses should be made by Monday, January 24, 00:00:00 UTC. Anything received after that time might be too late.
2.6.32.6 will still contain the regression described in (for example)
http://bugzilla.kernel.org/show_bug.cgi?id=15117
http://bugzilla.kernel.org/show_bug.cgi?id=15005It's fixed with the below revert which has been in -mm (and only in -mm) for ten days.
I don't what's going on - perhaps we're waiting for Thomas, and he's otherwise engaged. There's a fix in the lkml thread "Re: [RFC PATCH 0/4] clockevents: fix
clockevent_deviceslist corruption after cpu hotplug" to which Thomas replied
Quoted 6 lines
Quoted 3 lines
I just applied your patch, but kept the cpuweight check. This is the least intrusive solution for now. The logic needs an overhaul, but thats neither rc4 nor stable material"
Just sent the pull request for it. Sorry for the delay. The patch needs to go into 32.6 as well.
tick-internal.h should be included for this to fix build failure. Already included in 2.6.33 with 8e1a928a2ed7e8.
Regards,
Quoted 30 lines · Ozan Çağlayan
Thomas Gleixner wrote On 24-01-2010 18:29:
Quoted 29 lines · Andrew Morton
Quoted 27 lines · On Fri, 22 Jan 2010 16:11:45 -0800 Greg KH <[email protected]> wrote:
Quoted 9 lines
This is the start of the stable review cycle for the 2.6.32.6 release. There are 29 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 us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it.
Responses should be made by Monday, January 24, 00:00:00 UTC. Anything received after that time might be too late.
2.6.32.6 will still contain the regression described in (for example)
http://bugzilla.kernel.org/show_bug.cgi?id=15117
http://bugzilla.kernel.org/show_bug.cgi?id=15005It's fixed with the below revert which has been in -mm (and only in -mm) for ten days.
I don't what's going on - perhaps we're waiting for Thomas, and he's otherwise engaged. There's a fix in the lkml thread "Re: [RFC PATCH 0/4] clockevents: fix
clockevent_deviceslist corruption after cpu hotplug" to which Thomas repliedI just applied your patch, but kept the cpuweight check. This is the least intrusive solution for now. The logic needs an overhaul, but thats neither rc4 nor stable material"
Quoted 5 lines
Quoted 2 lines
Just sent the pull request for it. Sorry for the delay. The patch needs to go into 32.6 as well.
tick-internal.hshould be included for this to fix build failure. Already included in 2.6.33 with8e1a928a2ed7e8.
Huh? That says:
clockevents: Add missing include to pacify sparse
and does not sound like a problem that needs to be fixed for "real" users, right?
Or does .32.6 have a build problem somewhere?
confused,
greg k-h
Quoted 10 lines · Greg KH
On Mon, Jan 25, 2010 at 10:40:35AM +0200, Ozan Çağlayan wrote:
Huh? That says:
clockevents: Add missing include to pacify sparseand does not sound like a problem that needs to be fixed for "real" users, right?
Or does .32.6 have a build problem somewhere?
Applying the patch on top of 2.6.32.y causes build failure as the fix calls a macro from "tick-internal.h".
#include "tick-internal.h"
was added to clockevents.c with 8e1a928a2ed7e8 in linux-2.6/master for another reason e.g. the patch is OK for linux-2.6/master but should be modified to add #include directive for .32.y when backporting.
Regards,
Quoted 12 lines · Ozan Çağlayan
Quoted 10 lines · Greg KH
On Mon, Jan 25, 2010 at 10:40:35AM +0200, Ozan Çağlayan wrote:
Huh? That says:
clockevents: Add missing include to pacify sparseand does not sound like a problem that needs to be fixed for "real" users, right?
Or does .32.6 have a build problem somewhere?
Quoted 8 lines
Applying the patch on top of 2.6.32.y causes build failure as the fix calls a macro from "
tick-internal.h".#include "
tick-internal.h"was added to
clockevents.cwith8e1a928a2ed7e8in linux-2.6/master for another reason e.g. the patch is OK for linux-2.6/master but should be modified to add #include directive for .32.y when backporting.
Hm, please, can someone give me _exactly_ which git commit ids they wish to see in the .32-stable tree to resolve this issue?
thanks,
greg k-h
Quoted 16 lines · Greg KH
Quoted 15 lines · Ozan Çağlayan
Quoted 10 lines · Greg KH
On Mon, Jan 25, 2010 at 10:40:35AM +0200, Ozan Çağlayan wrote:
Huh? That says:
clockevents: Add missing include to pacify sparseand does not sound like a problem that needs to be fixed for "real" users, right?
Or does .32.6 have a build problem somewhere?
Applying the patch on top of 2.6.32.y causes build failure as the fix calls a macro from "
tick-internal.h".
Quoted 8 lines
Quoted 5 lines
#include "
tick-internal.h"was added to
clockevents.cwith8e1a928a2ed7e8in linux-2.6/master for another reason e.g. the patch is OK for linux-2.6/master but should be modified to add #include directive for .32.y when backporting.Hm, please, can someone give me _exactly_ which git commit ids they wish to see in the .32-stable tree to resolve this issue?
Ok, I think I got it now, nevermind...
thanks,
greg k-h
Quoted 37 lines · Greg KH
Quoted 30 lines · Ozan Çağlayan
Thomas Gleixner wrote On 24-01-2010 18:29:
Quoted 29 lines · Andrew Morton
Quoted 27 lines · On Fri, 22 Jan 2010 16:11:45 -0800 Greg KH <[email protected]> wrote:
Quoted 9 lines
This is the start of the stable review cycle for the 2.6.32.6 release. There are 29 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 us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it.
Responses should be made by Monday, January 24, 00:00:00 UTC. Anything received after that time might be too late.
2.6.32.6 will still contain the regression described in (for example)
http://bugzilla.kernel.org/show_bug.cgi?id=15117
http://bugzilla.kernel.org/show_bug.cgi?id=15005It's fixed with the below revert which has been in -mm (and only in -mm) for ten days.
I don't what's going on - perhaps we're waiting for Thomas, and he's otherwise engaged. There's a fix in the lkml thread "Re: [RFC PATCH 0/4] clockevents: fix
clockevent_deviceslist corruption after cpu hotplug" to which Thomas repliedI just applied your patch, but kept the cpuweight check. This is the least intrusive solution for now. The logic needs an overhaul, but thats neither rc4 nor stable material"
Quoted 5 lines
Quoted 2 lines
Just sent the pull request for it. Sorry for the delay. The patch needs to go into 32.6 as well.
tick-internal.hshould be included for this to fix build failure. Already included in 2.6.33 with8e1a928a2ed7e8.
Quoted 7 lines
Huh? That says:
clockevents: Add missing include to pacify sparseand does not sound like a problem that needs to be fixed for "real" users, right?
Or does .32.6 have a build problem somewhere?
If you pick ea9d8e3f45404d411c00ae67b45cc35c58265bb7 then you need that include.
Thanks,
tglx
Quoted 26 lines · Thomas Gleixner
Quoted 24 lines · Andrew Morton
Quoted 8 lines · On Fri, 22 Jan 2010 16:11:45 -0800 Greg KH <[email protected]> wrote:
This is the start of the stable review cycle for the 2.6.32.6 release. There are 29 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 us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it.
Responses should be made by Monday, January 24, 00:00:00 UTC. Anything received after that time might be too late.
2.6.32.6 will still contain the regression described in (for example)
http://bugzilla.kernel.org/show_bug.cgi?id=15117
http://bugzilla.kernel.org/show_bug.cgi?id=15005It's fixed with the below revert which has been in -mm (and only in -mm) for ten days.
I don't what's going on - perhaps we're waiting for Thomas, and he's otherwise engaged. There's a fix in the lkml thread "Re: [RFC PATCH 0/4] clockevents: fix
clockevent_deviceslist corruption after cpu hotplug" to which Thomas replied
Quoted 6 lines
Quoted 3 lines
I just applied your patch, but kept the cpuweight check. This is the least intrusive solution for now. The logic needs an overhaul, but thats neither rc4 nor stable material"
Just sent the pull request for it. Sorry for the delay. The patch needs to go into 32.6 as well.
So that would be commit id ea9d8e3f45404d411c00ae67b45cc35c58265bb7 ?
Or something else?
I'll queue that one up for the next .32 stable update, but will refrain from having it in this specific release in an hour, as there has not been any time to test it all out. I will start up a round for the next .32 kernel right afterward, later today, with this patch in it.
thanks,
greg k-h