2.6.33.9-longterm review
Subsystems (28)
cover 2.6.33.9-longterm review
This is the start of the longterm review cycle for the 2.6.33.9 release. There are 35 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 Sunday, March 17, 2011, 23: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/longterm-review/patch-2.6.33.9-rc1.gz
and the diffstat can be found below.
thanks,
greg k-h
Documentation/i2c/instantiating-devices | 2 +- Makefile | 2 +- arch/parisc/kernel/irq.c | 2 +- arch/powerpc/kernel/crash.c | 27 ++++++++++++++++++ arch/powerpc/kernel/rtas_flash.c | 39 ++++++++++++++------------ arch/x86/kernel/entry_64.S | 2 +- arch/x86/kernel/head64.c | 3 -- arch/x86/kernel/setup.c | 5 +++ arch/x86/mm/init.c | 19 ------------- arch/x86/mm/init_64.c | 11 ++++--- arch/x86/xen/mmu.c | 13 +++++---- drivers/firmware/dcdbas.c | 4 ++- drivers/hwmon/sht15.c | 4 +- drivers/input/xen-kbdfront.c | 45 ++++++++++++++++-------------- drivers/media/video/uvc/uvc_driver.c | 8 +++++ drivers/media/video/uvc/uvc_video.c | 14 ++++++--- drivers/mmc/core/sdio.c | 8 +++++ drivers/pci/hotplug/acpiphp_glue.c | 1 + drivers/pci/pci-sysfs.c | 7 ++++- drivers/pci/quirks.c | 20 ------------- drivers/usb/class/cdc-acm.c | 7 ++++- drivers/usb/host/ehci-q.c | 12 -------- drivers/usb/misc/uss720.c | 7 ++--- drivers/video/console/tileblit.c | 2 +- fs/aio.c | 4 +- fs/dcache.c | 3 ++ fs/ext3/super.c | 7 +++++ fs/nfsd/nfs4proc.c | 4 +- fs/nfsd/nfs4xdr.c | 5 +--- fs/proc/array.c | 4 +- fs/proc/task_mmu.c | 4 +- kernel/signal.c | 16 ++++++++--- kernel/smp.c | 13 +++++++-- mm/shmem.c | 1 + net/sunrpc/xprtsock.c | 2 + sound/pci/hda/patch_via.c | 14 +++++++-- 36 files changed, 196 insertions(+), 145 deletions(-)
PATCH 1/35 smp_call_function_many: handle concurrent clearing of mask
2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Milton Miller <[email protected]>
commit 723aae25d5cdb09962901d36d526b44d4be1051c upstream.
Mike Galbraith reported finding a lockup ("perma-spin bug") where the cpumask passed to smp_call_function_many was cleared by other cpu(s) while a cpu was preparing its call_data block, resulting in no cpu to clear the last ref and unlock the block.
Having cpus clear their bit asynchronously could be useful on a mask of cpus that might have a translation context, or cpus that need a push to complete an rcu window.
Instead of adding a BUG_ON and requiring yet another cpumask copy, just detect the race and handle it.
Note: arch_send_call_function_ipi_mask must still handle an empty cpumask because the data block is globally visible before the that arch callback is made. And (obviously) there are no guarantees to which cpus are notified if the mask is changed during the call; only cpus that were online and had their mask bit set during the whole call are guaranteed to be called.
--- kernel/smp.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-)
kernel/smp.c +10 -3
@@ -428,7 +428,7 @@ void smp_call_function_many(const struct {struct call_function_data *data;unsigned long flags; -int cpu, next_cpu, this_cpu =smp_processor_id (); +int refs, cpu, next_cpu, this_cpu =smp_processor_id ();/* * Can deadlock when called with interrupts disabled.
@@ -439,7 +439,7 @@ void smp_call_function_many(const structWARN_ON_ONCE (cpu_online (this_cpu) &&irqs_disabled () && !oops_in_progress); -/* So, what's a CPU they want? Ignoring this one. */ +/* Try to fastpath. So, what's a CPU they want? Ignoring this one. */ cpu =cpumask_first_and (mask, cpu_online_mask);if (cpu == this_cpu) cpu =cpumask_next_and (cpu, mask, cpu_online_mask);
@@ -497,6 +497,13 @@ void smp_call_function_many(const struct/* We rely on the "and" being processed before the store */ cpumask_and (data->cpumask, mask, cpu_online_mask);cpumask_clear_cpu (this_cpu, data->cpumask); + refs =cpumask_weight (data->cpumask); + +/* Some callers race with other cpus changing the passed mask */ +if (unlikely (!refs)) { +csd_unlock (&data->csd); +return ; + }raw_spin_lock_irqsave (&call_function.lock, flags);/*
@@ -510,7 +517,7 @@ void smp_call_function_many(const struct* to the cpumask before this write to refs, which indicates * data is on the list and is ready to be processed. */ -atomic_set (&data->refs,cpumask_weight (data->cpumask)); +atomic_set (&data->refs, refs);raw_spin_unlock_irqrestore (&call_function.lock, flags);/*
PATCH 2/35 fix per-cpu flag problem in the cpu affinity checkers
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Thomas Gleixner <[email protected]>
commit 9804c9eaeacfe78651052c5ddff31099f60ef78c upstream.
The CHECK_IRQ_PER_CPU is wrong, it should be checking irq_to_desc(irq)->status not just irq.
--- arch/parisc/kernel/irq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/parisc/kernel/irq.c +1 -1
@@ -117,7 +117,7 @@ int cpu_check_affinity(unsigned int irq,int cpu_dest;/* timer and ipi have to always be received on all CPUs */ -if (CHECK_IRQ_PER_CPU (irq)) { +if (CHECK_IRQ_PER_CPU (irq_to_desc (irq)->status)) {/* Bad linux design decision. The mask has already * been set; we must reset it */ cpumask_setall (irq_desc[irq].affinity);
PATCH 3/35 i2c: Fix typo in instantiating-devices document
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Roman Fietze <[email protected]>
commit 6ced9e6b3901af4ab6ac0a11231402c888286ea6 upstream.
The struct i2c_board_info member holding the name is "type", not "name".
--- Documentation/i2c/instantiating-devices | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Documentation/i2c/instantiating-devices +1 -1
@@ -100,7 +100,7 @@ static int __devinit usb_hcd_pnx4008_pro (...) i2c_adap = i2c_get_adapter(2); memset(&i2c_info, 0, sizeof(struct i2c_board_info)); - strlcpy(i2c_info.name, "isp1301_pnx", I2C_NAME_SIZE); + strlcpy(i2c_info.type, "isp1301_pnx", I2C_NAME_SIZE); isp1301_i2c_client = i2c_new_probed_device(i2c_adap, &i2c_info, normal_i2c); i2c_put_adapter(i2c_adap);
PATCH 4/35 mmc: sdio: remember new card RCA when redetecting card
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Stefan Nilsson XK <[email protected]>
commit 0aab3995485b8a994bf29a995a008c9ea4a28054 upstream.
During redetection of a SDIO card, a request for a new card RCA was submitted to the card, but was then overwritten by the old RCA. This caused the card to be deselected instead of selected when using the incorrect RCA. This bug's been present since the "oldcard" handling was introduced in 2.6.32.
--- drivers/mmc/core/sdio.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/mmc/core/sdio.c +8 -0
@@ -267,6 +267,14 @@ static int mmc_sdio_init_card(struct mmcif (err) goto remove; +/* +* Update oldcard with the new RCA received from the SDIO +* device -- we're doing this so that it's updated in the +* "card" struct when oldcard overwrites that later. +*/ +if (oldcard) + oldcard->rca = card->rca; +mmc_set_bus_mode (host,MMC_BUSMODE_PUSHPULL ); }
PATCH 5/35 powerpc/kdump: Fix race in kdump shutdown
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Michael Neuling <[email protected]>
commit 60adec6226bbcf061d4c2d10944fced209d1847d upstream.
When we are crashing, the crashing/primary CPU IPIs the secondaries to turn off IRQs, go into real mode and wait in kexec_wait. While this is happening, the primary tears down all the MMU maps. Unfortunately the primary doesn't check to make sure the secondaries have entered real mode before doing this.
On PHYP machines, the secondaries can take a long time shutting down the IRQ controller as RTAS calls are need. These RTAS calls need to be serialised which resilts in the secondaries contending in lock_rtas() and hence taking a long time to shut down.
We've hit this on large POWER7 machines, where some secondaries are still waiting in lock_rtas(), when the primary tears down the HPTEs.
This patch makes sure all secondaries are in real mode before the primary tears down the MMU. It uses the new kexec_state entry in the paca. It times out if the secondaries don't reach real mode after 10sec.
--- arch/powerpc/kernel/crash.c | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+)
arch/powerpc/kernel/crash.c +27 -0
@@ -162,6 +162,32 @@ static void crash_kexec_prepare_cpus(int/* Leave the IPI callback set */ } +/* wait for all the CPUs to hit real mode but timeout if they don't come in */ +static void crash_kexec_wait_realmode (int cpu) +{ +unsigned int msecs; +int i; + + msecs =10000 ; +for (i=0 ; i <NR_CPUS && msecs >0 ; i++) { +if (i == cpu) +continue ; + +while (paca[i].kexec_state <KEXEC_STATE_REAL_MODE ) { +barrier (); +if (!cpu_possible (i)) { +break ; + } +if (!cpu_online (i)) { +break ; + } + msecs--; +mdelay (1 ); + } + } +mb (); +} +/* * This function will be called by secondary cpus or by kexec cpu * if soft-reset is activated to stop some CPUs.
@@ -419,6 +445,7 @@ void default_machine_crash_shutdown(strucrash_kexec_prepare_cpus (crashing_cpu);cpu_set (crashing_cpu, cpus_in_crash);crash_kexec_stop_spus (); +crash_kexec_wait_realmode (crashing_cpu);if (ppc_md.kexec_cpu_down) ppc_md.kexec_cpu_down (1 ,0 ); }
Re: [05/35] powerpc/kdump: Fix race in kdump shutdown
Quoted 7 lines · Greg KH
2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Michael Neuling <[email protected]>
commit
60adec6226bbcf061d4c2d10944fced209d1847dupstream.
Hi Greg,
It looks like this introduces an issue for ppc32 unless we also take the upstream c2be05481f612525 commit. There is an e500 kexec patch in between that modifies context; here is the one I've tentatively queued for 2.6.34 without a dependency on the e500 patch context.
Paul.
Quoted 79 lines
When we are crashing, the crashing/primary CPU IPIs the secondaries to turn off IRQs, go into real mode and wait in
kexec_wait. While this is happening, the primary tears down all the MMU maps. Unfortunately the primary doesn't check to make sure the secondaries have entered real mode before doing this.On PHYP machines, the secondaries can take a long time shutting down the IRQ controller as RTAS calls are need. These RTAS calls need to be serialised which resilts in the secondaries contending in
lock_rtas()and hence taking a long time to shut down.We've hit this on large POWER7 machines, where some secondaries are still waiting in
lock_rtas(), when the primary tears down the HPTEs.This patch makes sure all secondaries are in real mode before the primary tears down the MMU. It uses the new
kexec_stateentry in the paca. It times out if the secondaries don't reach real mode after 10sec.Signed-off-by Michael Neuling <[email protected]>Signed-off-by Benjamin Herrenschmidt <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>---
arch/powerpc/kernel/crash.c | 27 +++++++++++++++++++++++++++1 file changed, 27 insertions(+)arch/powerpc/kernel/crash.c +27
-1@@ -162,6 +162,32 @@ static void crash_kexec_prepare_cpus(int /* Leave the IPI callback set */ } +/* wait for all the CPUs to hit real mode but timeout if they don't come in */ +static void crash_kexec_wait_realmode (int cpu) +{ + unsigned int msecs; + int i; + + msecs = 10000; + for (i=0; i < NR_CPUS && msecs > 0; i++) { + if (i == cpu) + continue; + + while (paca[i].kexec_state < KEXEC_STATE_REAL_MODE) { + barrier(); + if (!cpu_possible(i)) { + break; + } + if (!cpu_online(i)) { + break; + } + msecs--; + mdelay(1); + } + } + mb(); +} + /** This function will be called by secondary cpus or by kexec cpu * if soft-reset is activated to stop some CPUs. @@ -419,6 +445,7 @@ void default_machine_crash_shutdown(stru crash_kexec_prepare_cpus(crashing_cpu); cpu_set(crashing_cpu, cpus_in_crash); crash_kexec_stop_spus(); + crash_kexec_wait_realmode(crashing_cpu); if (ppc_md.kexec_cpu_down) ppc_md.kexec_cpu_down(1, 0); } --To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] [05/35] powerpc/kdump: Fix race in kdump shutdown
Quoted 9 lines · Paul Gortmaker
Quoted 7 lines · Greg KH
2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Michael Neuling <[email protected]>
commit
60adec6226bbcf061d4c2d10944fced209d1847dupstream.
Quoted 8 lines
Hi Greg,
It looks like this introduces an issue for ppc32 unless we also take the upstream
c2be05481f612525commit. There is an e500 kexec patch in between that modifies context; here is the one I've tentatively queued for 2.6.34 without a dependency on the e500 patch context.
Yes, I now have updated patches from Kamalesh in the tree to resolve this.
thanks,
greg k-h
Quoted 87 lines
Paul.
Quoted 74 lines
When we are crashing, the crashing/primary CPU IPIs the secondaries to turn off IRQs, go into real mode and wait in
kexec_wait. While this is happening, the primary tears down all the MMU maps. Unfortunately the primary doesn't check to make sure the secondaries have entered real mode before doing this.On PHYP machines, the secondaries can take a long time shutting down the IRQ controller as RTAS calls are need. These RTAS calls need to be serialised which resilts in the secondaries contending in
lock_rtas()and hence taking a long time to shut down.We've hit this on large POWER7 machines, where some secondaries are still waiting in
lock_rtas(), when the primary tears down the HPTEs.This patch makes sure all secondaries are in real mode before the primary tears down the MMU. It uses the new
kexec_stateentry in the paca. It times out if the secondaries don't reach real mode after 10sec.Signed-off-by Michael Neuling <[email protected]>Signed-off-by Benjamin Herrenschmidt <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>---
arch/powerpc/kernel/crash.c | 27 +++++++++++++++++++++++++++1 file changed, 27 insertions(+)arch/powerpc/kernel/crash.c +27
-1@@ -162,6 +162,32 @@ static void crash_kexec_prepare_cpus(int /* Leave the IPI callback set */ } +/* wait for all the CPUs to hit real mode but timeout if they don't come in */ +static void crash_kexec_wait_realmode (int cpu) +{ + unsigned int msecs; + int i; + + msecs = 10000; + for (i=0; i < NR_CPUS && msecs > 0; i++) { + if (i == cpu) + continue; + + while (paca[i].kexec_state < KEXEC_STATE_REAL_MODE) { + barrier(); + if (!cpu_possible(i)) { + break; + } + if (!cpu_online(i)) { + break; + } + msecs--; + mdelay(1); + } + } + mb(); +} + /** This function will be called by secondary cpus or by kexec cpu * if soft-reset is activated to stop some CPUs. @@ -419,6 +445,7 @@ void default_machine_crash_shutdown(stru crash_kexec_prepare_cpus(crashing_cpu); cpu_set(crashing_cpu, cpus_in_crash); crash_kexec_stop_spus(); + crash_kexec_wait_realmode(crashing_cpu); if (ppc_md.kexec_cpu_down) ppc_md.kexec_cpu_down(1, 0); } --Quoted 5 lines
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/_______________________________________________
stable mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/stable
PATCH 6/35 powerpc: rtas_flash needs to use rtas_data_buf
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Milton Miller <[email protected]>
commit bd2b64a12bf55bec0d1b949e3dca3f8863409646 upstream.
When trying to flash a machine via the update_flash command, Anton received the following error:
Restarting system.
FLASH: kernel bug...flash list header addr above 4GB
The code in question has a comment that the flash list should be in the kernel data and therefore under 4GB:
/* NOTE: the "first" block list is a global var with no data
* blocks in the kernel data segment. We do this because
* we want to ensure this block_list addr is under 4GB. */
Unfortunately the Kconfig option is marked tristate which means the variable may not be in the kernel data and could be above 4GB.
Instead of relying on the data segment being below 4GB, use the static data buffer allocated by the kernel for use by rtas. Since we don't use the header struct directly anymore, convert it to a simple pointer.
--- arch/powerpc/kernel/rtas_flash.c | 39 +++++++++++++++++++++------------------ 1 file changed, 21 insertions(+), 18 deletions(-)
arch/powerpc/kernel/rtas_flash.c +21 -18
@@ -93,12 +93,8 @@ struct flash_block_list {struct flash_block_list *next;struct flash_block blocks[FLASH_BLOCKS_PER_NODE ]; }; -struct flash_block_list_header {/* just the header of flash_block_list */ -unsigned long num_blocks; -struct flash_block_list *next; -}; -static struct flash_block_list_header rtas_firmware_flash_list = {0 ,NULL }; +static struct flash_block_list *rtas_firmware_flash_list;/* Use slab cache to guarantee 4k alignment */ static struct kmem_cache *flash_block_cache =NULL ;
@@ -107,13 +103,14 @@ static struct kmem_cache *flash_block_ca/* Local copy of the flash block list. * We only allow one open of the flash proc file and create this -* list as we go. This list will be put in the -* rtas_firmware_flash_list var once it is fully read. +* list as we go. The rtas_firmware_flash_list varable will be +* set once the data is fully read. * * For convenience as we build the list we use virtual addrs, * we do not fill in the version number, and the length field * is treated as the number of entries currently in the block -* (i.e. not a byte count). This is all fixed on release. +* (i.e. not a byte count). This is all fixed when calling +* the flash routine. */ /* Status int must be first member of struct */
@@ -200,16 +197,16 @@ static int rtas_flash_release(struct inoif (uf->flist) {/* File was opened in write mode for a new flash attempt */ /* Clear saved list */ -if (rtas_firmware_flash_list.next) { -free_flash_list (rtas_firmware_flash_list.next); - rtas_firmware_flash_list.next =NULL ; +if (rtas_firmware_flash_list) { +free_flash_list (rtas_firmware_flash_list); + rtas_firmware_flash_list =NULL ; }if (uf->status !=FLASH_AUTH ) uf->status =flash_list_valid (uf->flist);if (uf->status ==FLASH_IMG_READY ) - rtas_firmware_flash_list.next = uf->flist; + rtas_firmware_flash_list = uf->flist;else free_flash_list (uf->flist);
@@ -592,7 +589,7 @@ static void rtas_flash_firmware(int rebounsigned long rtas_block_list;int i, status, update_token; -if (rtas_firmware_flash_list.next ==NULL ) +if (rtas_firmware_flash_list ==NULL )return ;/* nothing to do */ if (reboot_type !=SYS_RESTART ) {
@@ -609,20 +606,25 @@ static void rtas_flash_firmware(int reboreturn ; } -/* NOTE: the "first" block list is a global var with no data -* blocks in the kernel data segment. We do this because -* we want to ensure this block_list addr is under 4GB. +/* +* NOTE: the "first" block must be under 4GB, so we create +* an entry with no data blocks in the reserved buffer in +* the kernel data segment. */ - rtas_firmware_flash_list.num_blocks =0 ; - flist = (struct flash_block_list *)&rtas_firmware_flash_list; +spin_lock (&rtas_data_buf_lock); + flist = (struct flash_block_list *)&rtas_data_buf[0 ]; + flist->num_blocks =0 ; + flist->next = rtas_firmware_flash_list; rtas_block_list =virt_to_abs (flist);if (rtas_block_list >=4UL *1024 *1024 *1024 ) {printk (KERN_ALERT "FLASH: kernel bug...flash list header addr above 4GB\n" ); +spin_unlock (&rtas_data_buf_lock);return ; }printk (KERN_ALERT "FLASH: preparing saved firmware image for flash\n" );/* Update the block_list in place. */ + rtas_firmware_flash_list =NULL ;/* too hard to backout on error */ image_size =0 ;for (f = flist; f; f = next) {/* Translate data addrs to absolute */
@@ -663,6 +665,7 @@ static void rtas_flash_firmware(int reboprintk (KERN_ALERT "FLASH: unknown flash return code %d\n" , status);break ; } +spin_unlock (&rtas_data_buf_lock); }static void remove_flash_pde (struct proc_dir_entry *dp)
PATCH 7/35 x86, binutils, xen: Fix another wrong size directive
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Alexander van Heukelum <[email protected]>
commit 371c394af27ab7d1e58a66bc19d9f1f3ac1f67b4 upstream.
The latest binutils (2.21.0.20110302/Ubuntu) breaks the build yet another time, under CONFIG_XEN=y due to a .size directive that refers to a slightly differently named (hence, to the now very strict and unforgiving assembler, non-existent) symbol.
[ mingo:
This unnecessary build breakage caused by new binutils version 2.21 gets escallated back several kernel releases spanning several years of Linux history, affecting over 130,000 upstream kernel commits (!), on CONFIG_XEN=y 64-bit kernels (i.e. essentially affecting all major Linux distro kernel configs).
Git annotate tells us that this slight debug symbol code mismatch bug has been introduced in 2008 in commit 3d75e1b8:
3d75e1b8 (Jeremy Fitzhardinge 2008-07-08 15:06:49 -0700 1231) ENTRY(xen_do_hypervisor_callback) # do_hypervisor_callback(struct *pt_regs)
The 'bug' is just a slight assymetry in ENTRY()/END() debug-symbols sequences, with lots of assembly code between the ENTRY() and the END():
ENTRY(xen_do_hypervisor_callback) # do_hypervisor_callback(struct *pt_regs)
...
END(do_hypervisor_callback)
Human reviewers almost never catch such small mismatches, and binutils never even warned about it either.
This new binutils version thus breaks the Xen build on all upstream kernels since v2.6.27, out of the blue.
This makes a straightforward Git bisection of all 64-bit Xen-enabled kernels impossible on such binutils, for a bisection window of over hundred thousand historic commits. (!)
This is a major fail on the side of binutils and binutils needs to turn this show-stopper build failure into a warning ASAP. ]
LKML-Reference: <[email protected]>
--- arch/x86/kernel/entry_64.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/kernel/entry_64.S +1 -1
@@ -1268,7 +1268,7 @@ ENTRY(xen_do_hypervisor_callback) # do decl PER_CPU_VAR(irq_count) jmp error_exit CFI_ENDPROC -END(do_hypervisor_callback) +END(xen_do_hypervisor_callback) /* * Hypervisor uses this for application faults while it executes.
PATCH 8/35 hwmon: (sht15) Fix integer overflow in humidity calculation
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Vivien Didelot <[email protected]>
commit ccd32e735de7a941906e093f8dca924bb05c5794 upstream.
An integer overflow occurs in the calculation of RHlinear when the relative humidity is greater than around 30%. The consequence is a subtle (but noticeable) error in the resulting humidity measurement.
--- drivers/hwmon/sht15.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/hwmon/sht15.c +2 -2
@@ -332,11 +332,11 @@ static inline int sht15_calc_humid(strucconst int c1 =-4 ;const int c2 =40500 ;/* x 10 ^ -6 */ -const int c3 =-2800 ;/* x10 ^ -9 */ +const int c3 =-28 ;/* x 10 ^ -7 */ RHlinear = c1*1000 + c2 * data->val_humid/1000 - + (data->val_humid * data->val_humid * c3)/1000000 ; + + (data->val_humid * data->val_humid * c3) /10000 ;return (temp -25000 ) * (10000 +80 * data->val_humid) /1000000 + RHlinear; }
PATCH 9/35 ALSA: hda - VIA: Fix stereo mixer recording no sound issue
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Lydia Wang <[email protected]>
commit bff5fbf50bd498c217994bd2d41a53ac3141185a upstream.
Modify function via_mux_enum_put() to fix stereo mixer recording no sound issue.
--- sound/pci/hda/patch_via.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
sound/pci/hda/patch_via.c +6 -3
@@ -1060,6 +1060,7 @@ static int via_mux_enum_put(struct snd_kstruct hda_codec *codec =snd_kcontrol_chip (kcontrol);struct via_spec *spec = codec->spec;unsigned int adc_idx =snd_ctl_get_ioffidx (kcontrol, &ucontrol->id); +int ret;if (!spec->mux_nids[adc_idx])return -EINVAL ;
@@ -1068,12 +1069,14 @@ static int via_mux_enum_put(struct snd_k AC_VERB_GET_POWER_STATE, 0x00) != AC_PWRST_D0)snd_hda_codec_write (codec, spec->mux_nids[adc_idx],0 ,AC_VERB_SET_POWER_STATE ,AC_PWRST_D0 ); -/* update jack power state */ -set_jack_power_state (codec); -return snd_hda_input_mux_put (codec, spec->input_mux, ucontrol, + ret =snd_hda_input_mux_put (codec, spec->input_mux, ucontrol, spec->mux_nids[adc_idx], &spec->cur_mux[adc_idx]); +/* update jack power state */ +set_jack_power_state (codec); + +return ret; } static int via_independent_hp_info(struct snd_kcontrol *kcontrol,
PATCH 10/35 ALSA: hda - VIA: Add missing support for VT1718S in A-A path
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Lydia Wang <[email protected]>
commit ab657e0cacc39d88145871c6a3c844597c02d406 upstream.
Modify mute_aa_path() function to support VT1718S codec.
--- sound/pci/hda/patch_via.c | 5 +++++ 1 file changed, 5 insertions(+)
sound/pci/hda/patch_via.c +5 -0
@@ -1265,6 +1265,11 @@ static void mute_aa_path(struct hda_code start_idx =2 ; end_idx =4 ;break ; +case VT1718S : + nid_mixer =0x21 ; + start_idx =1 ; + end_idx =3 ; +break ;default :return ; }
PATCH 11/35 aio: wake all waiters when destroying ctx
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Roland Dreier <[email protected]>
commit e91f90bb0bb10be9cc8efd09a3cf4ecffcad0db1 upstream.
The test program below will hang because io_getevents() uses add_wait_queue_exclusive(), which means the wake_up() in io_destroy() only wakes up one of the threads. Fix this by using wake_up_all() in the aio code paths where we want to make sure no one gets stuck.
// t.c -- compile with gcc -lpthread -laio t.c
#include <libaio.h>
#include <pthread.h>
#include <stdio.h>
#include <unistd.h>
static const int nthr = 2;
void *getev(void *ctx)
{
struct io_event ev;
io_getevents(ctx, 1, 1, &ev, NULL);
printf("io_getevents returned\n");
return NULL;
}
int main(int argc, char *argv[])
{
io_context_t ctx = 0;
pthread_t thread[nthr];
int i;
io_setup(1024, &ctx);
for (i = 0; i < nthr; ++i)
pthread_create(&thread[i], NULL, getev, ctx);
sleep(1);
io_destroy(ctx);
for (i = 0; i < nthr; ++i)
pthread_join(thread[i], NULL);
return 0;
}--- fs/aio.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
fs/aio.c +2 -2
@@ -511,7 +511,7 @@ static inline void really_put_req(struct ctx->reqs_active--;if (unlikely (!ctx->reqs_active && ctx->dead)) -wake_up (&ctx->wait); +wake_up_all (&ctx->wait); }static void aio_fput_routine (struct work_struct *data)
@@ -1224,7 +1224,7 @@ static void io_destroy(struct kioctx *io* by other CPUs at this point. Right now, we rely on the * locking done by the above calls to ensure this consistency. */ -wake_up (&ioctx->wait); +wake_up_all (&ioctx->wait);put_ioctx (ioctx);/* once for the lookup */ }
PATCH 12/35 shmem: let shared anonymous be nonlinear again
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Hugh Dickins <[email protected]>
commit bee4c36a5cf5c9f63ce1d7372aa62045fbd16d47 upstream.
Up to 2.6.22, you could use remap_file_pages(2) on a tmpfs file or a shared mapping of /dev/zero or a shared anonymous mapping. In 2.6.23 we disabled it by default, but set VM_CAN_NONLINEAR to enable it on safe mappings. We made sure to set it in shmem_mmap() for tmpfs files, but missed it in shmem_zero_setup() for the others. Fix that at last.
--- mm/shmem.c | 1 + 1 file changed, 1 insertion(+)
mm/shmem.c +1 -0
@@ -2701,5 +2701,6 @@ int shmem_zero_setup(struct vm_area_strufput (vma->vm_file); vma->vm_file = file; vma->vm_ops = &shmem_vm_ops; + vma->vm_flags |=VM_CAN_NONLINEAR ;return 0 ; }
PATCH 13/35 PCI hotplug: acpiphp: set current_state to D0 in register_slot
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Stefano Stabellini <[email protected]>
commit 47e9037ac16637cd7f12b8790ea7ce6680e42168 upstream.
If a device doesn't support power management (pm_cap == 0) but it is acpi_pci_power_manageable() because there is a _PS0 method declared for it and _EJ0 is also declared for the slot then nobody is going to set current_state = PCI_D0 for this device. This is what I think it is happening:
pci_enable_device
|
__pci_enable_device_flags
/* here we do not set current_state because !pm_cap */
|
do_pci_enable_device
|
pci_set_power_state
|
__pci_start_power_transition
|
pci_platform_power_transition
/* platform_pci_power_manageable() calls acpi_pci_power_manageable that
* returns true */
|platform_pci_set_power_state
/* acpi_pci_set_power_state gets called and does nothing because the
* acpi device has _EJ0, see the comment "If the ACPI device has _EJ0,
* ignore the device" */
at this point if we refer to the commit message that introduced the comment above (10b3dcae0f275e2546e55303d64ddbb58cec7599), it is up to the hotplug driver to set the state to D0.
However AFAICT the pci hotplug driver never does, in fact drivers/pci/hotplug/acpiphp_glue.c:register_slot sets the slot flags to (SLOT_ENABLED | SLOT_POWEREDON) but it does not set the pci device current state to PCI_D0.
So my proposed fix is also to set current_state = PCI_D0 in register_slot.
Comments are very welcome.
--- drivers/pci/hotplug/acpiphp_glue.c | 1 + 1 file changed, 1 insertion(+)
drivers/pci/hotplug/acpiphp_glue.c +1 -0
@@ -211,6 +211,7 @@ register_slot(acpi_handle handle, u32 lv pdev =pci_get_slot (pbus,PCI_DEVFN (device, function));if (pdev) { + pdev->current_state =PCI_D0 ; slot->flags |= (SLOT_ENABLED |SLOT_POWEREDON );pci_dev_put (pdev); }
PATCH 14/35 xen: set max_pfn_mapped to the last pfn mapped
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Stefano Stabellini <[email protected]>
commit 14988a4d350ce3b41ecad4f63c4f44c56f5ae34d upstream.
Do not set max_pfn_mapped to the end of the initial memory mappings, that also contain pages that don't belong in pfn space (like the mfn list).
Set max_pfn_mapped to the last real pfn mapped in the initial memory mappings that is the pfn backing _end.
LKML-Reference: <alpine.DEB.2.00.1103171739050.3382@kaball-desktop>
--- arch/x86/xen/mmu.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-)
arch/x86/xen/mmu.c +7 -6
@@ -1658,9 +1658,6 @@ static __init void xen_map_identity_earlfor (pteidx =0 ; pteidx <PTRS_PER_PTE ; pteidx++, pfn++) {pte_t pte; -if (pfn > max_pfn_mapped) - max_pfn_mapped = pfn; -if (!pte_none (pte_page[pteidx]))continue ;
@@ -1704,6 +1701,12 @@ __init pgd_t *xen_setup_kernel_pagetablepud_t *l3;pmd_t *l2; +/* max_pfn_mapped is the last pfn mapped in the initial memory +* mappings. Considering that on Xen after the kernel mappings we +* have the mappings of some pages that don't exist in pfn space, we +* set max_pfn_mapped to the last real pfn mapped. */ + max_pfn_mapped =PFN_DOWN (__pa (xen_start_info->mfn_list)); +/* Zap identity mapping */ init_level4_pgt[0 ] =__pgd (0 );
@@ -1767,9 +1770,7 @@ __init pgd_t *xen_setup_kernel_pagetable {pmd_t *kernel_pmd; - max_pfn_mapped =PFN_DOWN (__pa (xen_start_info->pt_base) + - xen_start_info->nr_pt_frames *PAGE_SIZE + -512 *1024 ); + max_pfn_mapped =PFN_DOWN (__pa (xen_start_info->mfn_list)); kernel_pmd =m2v (pgd[KERNEL_PGD_BOUNDARY ].pgd);memcpy (level2_kernel_pgt, kernel_pmd,sizeof (pmd_t) *PTRS_PER_PMD );
PATCH 15/35 PCI: return correct value when writing to the "reset" attribute
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Michal Schmidt <[email protected]>
commit 447c5dd7338638f526e9bcf7dcf69b4da5835c7d upstream.
A successful write() to the "reset" sysfs attribute should return the number of bytes written, not 0. Otherwise userspace (bash) retries the write over and over again.
--- drivers/pci/pci-sysfs.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/pci/pci-sysfs.c +6 -1
@@ -966,7 +966,12 @@ static ssize_t reset_store(struct deviceif (val !=1 )return -EINVAL ; -return pci_reset_function (pdev); + + result =pci_reset_function (pdev); +if (result <0 ) +return result; + +return count; }static struct device_attribute reset_attr =__ATTR (reset,0200 ,NULL , reset_store);
PATCH 16/35 Revert "intel_idle: PCI quirk to prevent Lenovo Ideapad s10-3 boot hang"
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
This reverts commit 05f7676dc3559c2b9061fda4e44c085a8d32fb05.
To quote Len Brown:
intel_idle was deemed a "feature", and thus not included in 2.6.33.stable, and thus 2.6.33.stable does not need this patch.
so I'm removing it.
--- drivers/pci/quirks.c | 20 -------------------- 1 file changed, 20 deletions(-)
drivers/pci/quirks.c +0 -20
@@ -155,26 +155,6 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NEDECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_NEC ,PCI_DEVICE_ID_NEC_CBUS_3 , quirk_isa_dma_hangs);/* -* Intel NM10 "TigerPoint" LPC PM1a_STS.BM_STS must be clear -* for some HT machines to use C4 w/o hanging. -*/ -static void __devinit quirk_tigerpoint_bm_sts (struct pci_dev *dev) -{ -u32 pmbase; -u16 pm1a; - -pci_read_config_dword (dev,0x40 , &pmbase); - pmbase = pmbase &0xff80 ; - pm1a =inw (pmbase); - -if (pm1a &0x10 ) { -dev_info (&dev->dev,FW_BUG "TigerPoint LPC.BM_STS cleared\n" ); -outw (0x10 , pmbase); - } -} -DECLARE_PCI_FIXUP_HEADER (PCI_VENDOR_ID_INTEL ,PCI_DEVICE_ID_INTEL_TGP_LPC , quirk_tigerpoint_bm_sts); - -/* * Chipsets where PCI->PCI transfers vanish or hang */ static void __devinit quirk_nopcipci (struct pci_dev *dev)
PATCH 17/35 Prevent rt_sigqueueinfo and rt_tgsigqueueinfo from spoofing the signal code
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Julien Tinnes <[email protected]>
commit da48524eb20662618854bb3df2db01fc65f3070c upstream.
Userland should be able to trust the pid and uid of the sender of a signal if the si_code is SI_TKILL.
Unfortunately, the kernel has historically allowed sigqueueinfo() to send any si_code at all (as long as it was negative - to distinguish it from kernel-generated signals like SIGILL etc), so it could spoof a SI_TKILL with incorrect siginfo values.
Happily, it looks like glibc has always set si_code to the appropriate SI_QUEUE, so there are probably no actual user code that ever uses anything but the appropriate SI_QUEUE flag.
So just tighten the check for si_code (we used to allow any negative value), and add a (one-time) warning in case there are binaries out there that might depend on using other si_code values.
--- kernel/signal.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-)
kernel/signal.c +12 -4
@@ -2406,9 +2406,13 @@ SYSCALL_DEFINE3(rt_sigqueueinfo, pid_t,return -EFAULT ;/* Not even root can pretend to send signals from the kernel. -Nor can they impersonate a kill(), which adds source info. */ -if (info.si_code >=0 ) +* Nor can they impersonate a kill()/tgkill(), which adds source info. +*/ +if (info.si_code !=SI_QUEUE ) { +/* We used to allow any < 0 si_code */ +WARN_ON_ONCE (info.si_code <0 );return -EPERM ; + } info.si_signo = sig;/* POSIX.1b doesn't mention process groups. */
@@ -2422,9 +2426,13 @@ long do_rt_tgsigqueueinfo(pid_t tgid, pireturn -EINVAL ;/* Not even root can pretend to send signals from the kernel. -Nor can they impersonate a kill(), which adds source info. */ -if (info->si_code >=0 ) +* Nor can they impersonate a kill()/tgkill(), which adds source info. +*/ +if (info->si_code !=SI_QUEUE ) { +/* We used to allow any < 0 si_code */ +WARN_ON_ONCE (info->si_code <0 );return -EPERM ; + } info->si_signo = sig;return do_send_specific (tgid, pid, sig, info);
PATCH 18/35 ext3: skip orphan cleanup on rocompat fs
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Amir Goldstein <[email protected]>
commit ce654b37f87980d95f339080e4c3bdb2370bdf22 upstream.
Orphan cleanup is currently executed even if the file system has some number of unknown ROCOMPAT features, which deletes inodes and frees blocks, which could be very bad for some RO_COMPAT features.
This patch skips the orphan cleanup if it contains readonly compatible features not known by this ext3 implementation, which would prevent the fs from being mounted (or remounted) readwrite.
--- fs/ext3/super.c | 7 +++++++ 1 file changed, 7 insertions(+)
fs/ext3/super.c +7 -0
@@ -1440,6 +1440,13 @@ static void ext3_orphan_cleanup (structreturn ; } +/* Check if feature set allows readwrite operations */ +if (EXT3_HAS_RO_COMPAT_FEATURE (sb, ~EXT3_FEATURE_RO_COMPAT_SUPP )) { +ext3_msg (sb,KERN_INFO ,"Skipping orphan cleanup due to " +"unknown ROCOMPAT features" ); +return ; + } +if (EXT3_SB (sb)->s_mount_state &EXT3_ERROR_FS ) {if (es->s_last_orphan) jbd_debug(1, "Errors on filesystem, "
PATCH 19/35 procfs: fix /proc/<pid>/maps heap check
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Aaro Koskinen <[email protected]>
commit 0db0c01b53a1a421513f91573241aabafb87802a upstream.
The current code fails to print the "[heap]" marking if the heap is split into multiple mappings.
Fix the check so that the marking is displayed in all possible cases:
1. vma matches exactly the heap
2. the heap vma is merged e.g. with bss
3. the heap vma is splitted e.g. due to locked pages
Test cases. In all cases, the process should have mapping(s) with [heap] marking:
(1) vma matches exactly the heap
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
int main (void)
{
if (sbrk(4096) != (void *)-1) {
printf("check /proc/%d/maps\n", (int)getpid());
while (1)
sleep(1);
}
return 0;
}
# ./test1
check /proc/553/maps
[1] + Stopped ./test1
# cat /proc/553/maps | head -4
00008000-00009000 r-xp 00000000 01:00 3113640 /test1
00010000-00011000 rw-p 00000000 01:00 3113640 /test1
00011000-00012000 rw-p 00000000 00:00 0 [heap]
4006f000-40070000 rw-p 00000000 00:00 0
(2) the heap vma is merged
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
char foo[4096] = "foo";
char bar[4096];
int main (void)
{
if (sbrk(4096) != (void *)-1) {
printf("check /proc/%d/maps\n", (int)getpid());
while (1)
sleep(1);
}
return 0;
}
# ./test2
check /proc/556/maps
[2] + Stopped ./test2
# cat /proc/556/maps | head -4
00008000-00009000 r-xp 00000000 01:00 3116312 /test2
00010000-00012000 rw-p 00000000 01:00 3116312 /test2
00012000-00014000 rw-p 00000000 00:00 0 [heap]
4004a000-4004b000 rw-p 00000000 00:00 0
(3) the heap vma is splitted (this fails without the patch)
#include <stdio.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/types.h>
int main (void)
{
if ((sbrk(4096) != (void *)-1) && !mlockall(MCL_FUTURE) &&
(sbrk(4096) != (void *)-1)) {
printf("check /proc/%d/maps\n", (int)getpid());
while (1)
sleep(1);
}
return 0;
}
# ./test3
check /proc/559/maps
[1] + Stopped ./test3
# cat /proc/559/maps|head -4
00008000-00009000 r-xp 00000000 01:00 3119108 /test3
00010000-00011000 rw-p 00000000 01:00 3119108 /test3
00011000-00012000 rw-p 00000000 00:00 0 [heap]
00012000-00013000 rw-p 00000000 00:00 0 [heap]It looks like the bug has been there forever, and since it only results in some information missing from a procfile, it does not fulfil the -stable "critical issue" criteria.
--- fs/proc/task_mmu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
fs/proc/task_mmu.c +2 -2
@@ -243,8 +243,8 @@ static void show_map_vma(struct seq_fileconst char *name =arch_vma_name (vma);if (!name) {if (mm) { -if (vma->vm_start <= mm->start_brk && - vma->vm_end >= mm->brk) { +if (vma->vm_start <= mm->brk && + vma->vm_end >= mm->start_brk) { name ="[heap]" ; }else if (vma->vm_start <= mm->start_stack && vma->vm_end >= mm->start_stack) {
PATCH 20/35 proc: protect mm start_code/end_code in /proc/pid/stat
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Kees Cook <[email protected]>
commit 5883f57ca0008ffc93e09cbb9847a1928e50c6f3 upstream.
While mm->start_stack was protected from cross-uid viewing (commit f83ce3e6b02d5 ("proc: avoid information leaks to non-privileged processes")), the start_code and end_code values were not. This would allow the text location of a PIE binary to leak, defeating ASLR.
Note that the value "1" is used instead of "0" for a protected value since "ps", "killall", and likely other readers of /proc/pid/stat, take start_code of "0" to mean a kernel thread and will misbehave. Thanks to Brad Spengler for pointing this out.
Addresses CVE-2011-0726
--- fs/proc/array.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
fs/proc/array.c +2 -2
@@ -488,8 +488,8 @@ static int do_task_stat(struct seq_file vsize, mm ?get_mm_rss (mm) :0 , rsslim, - mm ? mm->start_code :0 , - mm ? mm->end_code :0 , + mm ? (permitted ? mm->start_code :1 ) :0 , + mm ? (permitted ? mm->end_code :1 ) :0 , (permitted && mm) ? mm->start_stack :0 , esp, eip,
PATCH 21/35 fbcon: Bugfix soft cursor detection in Tile Blitting
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Henry Nestler <[email protected]>
commit d6244bc0ed0c52a795e6f4dcab3886daf3e74fac upstream.
Use mask 0x10 for "soft cursor" detection on in function tile_cursor. (Tile Blitting Operation in framebuffer console).
The old mask 0x01 for vc_cursor_type detects CUR_NONE, CUR_LOWER_THIRD and every second mode value as "software cursor". This hides the cursor for these modes (cursor.mode = 0). But, only CUR_NONE or "software cursor" should hide the cursor.
See also 0x10 in functions add_softcursor, bit_cursor and cw_cursor.
--- drivers/video/console/tileblit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/video/console/tileblit.c +1 -1
@@ -83,7 +83,7 @@ static void tile_cursor(struct vc_data * int softback_lines, int fg, int bg) { struct fb_tilecursor cursor; -int use_sw = (vc->vc_cursor_type &0x01 ); +int use_sw = (vc->vc_cursor_type &0x10 ); cursor.sx = vc->vc_x; cursor.sy = vc->vc_y;
PATCH 22/35 nfsd41: modify the members value of nfsd4_op_flags
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Mi Jinlong <[email protected]>
commit 5ece3cafbd88d4da5c734e1810c4a2e6474b57b2 upstream.
The members of nfsd4_op_flags, (ALLOWED_WITHOUT_FH | ALLOWED_ON_ABSENT_FS) equals to ALLOWED_AS_FIRST_OP, maybe that's not what we want.
OP_PUTROOTFH with op_flags = ALLOWED_WITHOUT_FH | ALLOWED_ON_ABSENT_FS, can't appears as the first operation with out SEQUENCE ops.
This patch modify the wrong value of ALLOWED_WITHOUT_FH etc which was introduced by f9bb94c4.
--- fs/nfsd/nfs4proc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
fs/nfsd/nfs4proc.c +2 -2
@@ -953,8 +953,8 @@ typedef __be32(*nfsd4op_func)(struct svc void *);enum nfsd4_op_flags {ALLOWED_WITHOUT_FH =1 <<0 ,/* No current filehandle required */ -ALLOWED_ON_ABSENT_FS =2 <<0 ,/* ops processed on absent fs */ -ALLOWED_AS_FIRST_OP =3 <<0 ,/* ops reqired first in compound */ +ALLOWED_ON_ABSENT_FS =1 <<1 ,/* ops processed on absent fs */ +ALLOWED_AS_FIRST_OP =1 <<2 ,/* ops reqired first in compound */ };struct nfsd4_operation {
PATCH 23/35 nfsd: wrong index used in inner loop
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Mi Jinlong <[email protected]>
commit 5a02ab7c3c4580f94d13c683721039855b67cda6 upstream.
We must not use dummy for index.
After the first index, READ32(dummy) will change dummy!!!!
--- fs/nfsd/nfs4xdr.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
fs/nfsd/nfs4xdr.c +1 -4
@@ -1106,7 +1106,7 @@ nfsd4_decode_create_session(struct nfsd4u32 dummy;char *machine_name; -int i, j; +int i;int nr_secflavs;READ_BUF (16 );
@@ -1179,8 +1179,6 @@ nfsd4_decode_create_session(struct nfsd4READ_BUF (4 );READ32 (dummy);READ_BUF (dummy *4 ); -for (j =0 ; j < dummy; ++j) -READ32 (dummy);break ;case RPC_AUTH_GSS : dprintk("RPC_AUTH_GSS callback secflavor "
@@ -1196,7 +1194,6 @@ nfsd4_decode_create_session(struct nfsd4READ_BUF (4 );READ32 (dummy);READ_BUF (dummy); - p +=XDR_QUADLEN (dummy);break ;default :dprintk ("Illegal callback secflavor\n" );
PATCH 24/35 uvcvideo: Fix uvc_fixup_video_ctrl() format search
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Stephan Lachowsky <[email protected]>
commit 38a66824d96de8aeeb915e6f46f0d3fe55828eb1 upstream.
The scheme used to index format in uvc_fixup_video_ctrl() is not robust:
format index is based on descriptor ordering, which does not necessarily match bFormatIndex ordering. Searching for first matching format will prevent uvc_fixup_video_ctrl() from using the wrong format/frame to make adjustments.
--- drivers/media/video/uvc/uvc_video.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-)
drivers/media/video/uvc/uvc_video.c +9 -5
@@ -64,15 +64,19 @@ int uvc_query_ctrl(struct uvc_device *destatic void uvc_fixup_video_ctrl (struct uvc_streaming *stream,struct uvc_streaming_control *ctrl) { -struct uvc_format *format; +struct uvc_format *format =NULL ;struct uvc_frame *frame =NULL ;unsigned int i; -if (ctrl->bFormatIndex <=0 || - ctrl->bFormatIndex > stream->nformats) -return ; +for (i =0 ; i < stream->nformats; ++i) { +if (stream->format[i].index == ctrl->bFormatIndex) { + format = &stream->format[i]; +break ; + } + } - format = &stream->format[ctrl->bFormatIndex -1 ]; +if (format ==NULL ) +return ;for (i =0 ; i < format->nframes; ++i) {if (format->frame[i].bFrameIndex == ctrl->bFrameIndex) {
PATCH 25/35 uvcvideo: Fix descriptor parsing for video output devices
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Laurent Pinchart <[email protected]>
commit 4093a5c4a3f59cba1a085bbf87b6ffdddc5a443d upstream.
Commit 4057ac6ca9a77c4275b34b5925ab5c99557913b1
V4L/DVB (13505): uvcvideo: Refactor chain scan
broke output terminals parsing. Fix it.
--- drivers/media/video/uvc/uvc_driver.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/media/video/uvc/uvc_driver.c +8 -0
@@ -1260,6 +1260,14 @@ static int uvc_scan_chain_entity(structbreak ; +case UVC_OTT_VENDOR_SPECIFIC : +case UVC_OTT_DISPLAY : +case UVC_OTT_MEDIA_TRANSPORT_OUTPUT : +if (uvc_trace_param &UVC_TRACE_PROBE ) +printk (" OT %d" , entity->id); + +break ; +case UVC_TT_STREAMING :if (UVC_ENTITY_IS_ITERM (entity)) {if (uvc_trace_param &UVC_TRACE_PROBE )
PATCH 26/35 ehci-hcd: Bug fix: dont set a QHs Halt bit
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Alan Stern <[email protected]>
commit b5a3b3d985493c173925907adfebf3edab236fe7 upstream.
This patch (as1453) fixes a long-standing bug in the ehci-hcd driver.
There is no need to set the Halt bit in the overlay region for an unlinked or blocked QH. Contrary to what the comment says, setting the Halt bit does not cause the QH to be patched later; that decision (made in qh_refresh()) depends only on whether the QH is currently pointing to a valid qTD. Likewise, setting the Halt bit does not prevent completions from activating the QH while it is "stopped"; they are prevented by the fact that qh_completions() temporarily changes qh->qh_state to QH_STATE_COMPLETING.
On the other hand, there are circumstances in which the QH will be reactivated _without_ being patched; this happens after an URB beyond the head of the queue is unlinked. Setting the Halt bit will then cause the hardware to see the QH with both the Active and Halt bits set, an invalid combination that will prevent the queue from advancing and may even crash some controllers.
Apparently the only reason this hasn't been reported before is that unlinking URBs from the middle of a running queue is quite uncommon. However Test 17, recently added to the usbtest driver, does exactly this, and it confirms the presence of the bug.
In short, there is no reason to set the Halt bit for an unlinked or blocked QH, and there is a very good reason not to set it. Therefore the code that sets it is removed.
--- drivers/usb/host/ehci-q.c | 12 ------------ 1 file changed, 12 deletions(-)
drivers/usb/host/ehci-q.c +0 -12
@@ -315,7 +315,6 @@ qh_completions (struct ehci_hcd *ehci, sint stopped;unsigned count =0 ;u8 state; -const __le32 halt =HALT_BIT (ehci);struct ehci_qh_hw *hw = qh->hw;if (unlikely (list_empty (&qh->qtd_list)))
@@ -422,7 +421,6 @@ qh_completions (struct ehci_hcd *ehci, s && !(qtd->hw_alt_next & EHCI_LIST_END(ehci))) { stopped =1 ; - goto halt; }/* stop scanning when we reach qtds the hc is using */
@@ -456,16 +454,6 @@ qh_completions (struct ehci_hcd *ehci, s*/ ehci_clear_tt_buffer (ehci, qh, urb, token); } - -/* force halt for unlinked or blocked qh, so we'll -* patch the qh later and so that completions can't -* activate it while we "know" it's stopped. -*/ -if ((halt & hw->hw_token) ==0 ) { -halt: - hw->hw_token |= halt; -wmb (); - } }/* unless we already know the urb's status, collect qtd status
PATCH 27/35 USB: uss720 fixup refcount position
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Peter Holik <[email protected]>
commit adaa3c6342b249548ea830fe8e02aa5b45be8688 upstream.
My testprog do a lot of bitbang - after hours i got following warning and my machine lockups:
WARNING: at /build/buildd/linux-2.6.38/lib/kref.c:34
After debugging uss720 driver i discovered that the completion callback was called before usb_submit_urb returns. The callback frees the request structure that is krefed on return by usb_submit_urb.
--- drivers/usb/misc/uss720.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)
drivers/usb/misc/uss720.c +3 -4
@@ -176,12 +176,11 @@ static struct uss720_async_request *submspin_lock_irqsave (&priv->asynclock, flags);list_add_tail (&rq->asynclist, &priv->asynclist);spin_unlock_irqrestore (&priv->asynclock, flags); +kref_get (&rq->ref_count); ret =usb_submit_urb (rq->urb, mem_flags); -if (!ret) { -kref_get (&rq->ref_count); +if (!ret)return rq; - } -kref_put (&rq->ref_count, destroy_async); +destroy_async (&rq->ref_count);err ("submit_async_request submit_urb failed with %d" , ret);return NULL ; }
PATCH 28/35 USB: cdc-acm: fix memory corruption / panic
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Johan Hovold <[email protected]>
commit 23b80550e2aa61d0ba3af98b831b9195be0db9ee upstream.
Prevent read urbs from being resubmitted from tasklet after port close.
The receive tasklet was not disabled on port close, which could lead to corruption of receive lists on consecutive port open. In particular, read urbs could be re-submitted before port open, added to free list in open, and then added a second time to the free list in the completion handler.
cdc-acm.c: Entering acm_tty_open.cdc-acm.c: acm_control_msg: rq: 0x22 val: 0x3 len: 0x0 result: 0 cdc-acm.c: Entering acm_rx_taskletcdc-acm.c: acm_rx_tasklet: sending urb 0xf50da280, rcv 0xf57fbc24, buf 0xf57fbd64 cdc-acm.c: set line: 115200 0 0 8cdc-acm.c: acm_control_msg: rq: 0x20 val: 0x0 len: 0x7 result: 7 cdc-acm.c: acm_tty_closecdc-acm.c: acm_port_downcdc-acm.c: acm_control_msg: rq: 0x22 val: 0x0 len: 0x0 result: 0 cdc-acm.c: acm_ctrl_irq - urb shutting down with status: -2 cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da300, rcv 0xf57fbc10, buf 0xf57fbd50 cdc-acm.c: Entering acm_read_bulk with status -2cdc_acm 4-1:1.1: Aborting, acm not readycdc-acm.c: Entering acm_read_bulk with status -2cdc_acm 4-1:1.1: Aborting, acm not readycdc-acm.c: acm_rx_tasklet: sending urb 0xf50da380, rcv 0xf57fbbfc, buf 0xf57fbd3c cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da400, rcv 0xf57fbbe8, buf 0xf57fbd28 cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da480, rcv 0xf57fbbd4, buf 0xf57fbd14 cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da900, rcv 0xf57fbbc0, buf 0xf57fbd00 cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da980, rcv 0xf57fbbac, buf 0xf57fbcec cdc-acm.c: acm_rx_tasklet: sending urb 0xf50daa00, rcv 0xf57fbb98, buf 0xf57fbcd8 cdc-acm.c: acm_rx_tasklet: sending urb 0xf50daa80, rcv 0xf57fbb84, buf 0xf57fbcc4 cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dab00, rcv 0xf57fbb70, buf 0xf57fbcb0 cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dab80, rcv 0xf57fbb5c, buf 0xf57fbc9c cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dac00, rcv 0xf57fbb48, buf 0xf57fbc88 cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dac80, rcv 0xf57fbb34, buf 0xf57fbc74 cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dad00, rcv 0xf57fbb20, buf 0xf57fbc60 cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dad80, rcv 0xf57fbb0c, buf 0xf57fbc4c cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da880, rcv 0xf57fbaf8, buf 0xf57fbc38 cdc-acm.c: Entering acm_tty_open.cdc-acm.c: acm_control_msg: rq: 0x22 val: 0x3 len: 0x0 result: 0 cdc-acm.c: Entering acm_rx_taskletcdc-acm.c: acm_rx_tasklet: sending urb 0xf50da280, rcv 0xf57fbc24, buf 0xf57fbd64 cdc-acm.c: Entering acm_tty_write to write 3 bytes,cdc-acm.c: Get 3 bytes...cdc-acm.c: acm_write_start susp_count: 0cdc-acm.c: Entering acm_read_bulk with status 0
------------[ cut here ]------------ WARNING: at /home/johan/src/linux/linux-2.6/lib/list_debug.c:57 list_del+0x10c/0x120() Hardware name: Vostro 1520 list_del corruption. next->prev should be f57fbc10, but was f57fbaf8 Modules linked in: cdc_acm Pid: 3, comm: ksoftirqd/0 Not tainted 2.6.37+ #39 Call Trace: [<c103c7e2>] warn_slowpath_common+0x72/0xa0 [<c11dd8ac>] ? list_del+0x10c/0x120 [<c11dd8ac>] ? list_del+0x10c/0x120 [<c103c8b3>] warn_slowpath_fmt+0x33/0x40 [<c11dd8ac>] list_del+0x10c/0x120 [<f8051dbf>] acm_rx_tasklet+0xef/0x3e0 [cdc_acm] [<c135465d>] ? net_rps_action_and_irq_enable+0x6d/0x80 [<c1042bb6>] tasklet_action+0xe6/0x140 [<c104342f>] __do_softirq+0xaf/0x210 [<c1043380>] ? __do_softirq+0x0/0x210 <IRQ> [<c1042c9a>] ? run_ksoftirqd+0x8a/0x1c0 [<c1042c10>] ? run_ksoftirqd+0x0/0x1c0 [<c105ac24>] ? kthread+0x74/0x80 [<c105abb0>] ? kthread+0x0/0x80 [<c100337a>] ? kernel_thread_helper+0x6/0x10 ---[ end trace efd9a11434f0082e ]--- ------------[ cut here ]------------ WARNING: at /home/johan/src/linux/linux-2.6/lib/list_debug.c:57 list_del+0x10c/0x120() Hardware name: Vostro 1520 list_del corruption. next->prev should be f57fbd50, but was f57fbdb0 Modules linked in: cdc_acm Pid: 3, comm: ksoftirqd/0 Tainted: G W 2.6.37+ #39 Call Trace: [<c103c7e2>] warn_slowpath_common+0x72/0xa0 [<c11dd8ac>] ? list_del+0x10c/0x120 [<c11dd8ac>] ? list_del+0x10c/0x120 [<c103c8b3>] warn_slowpath_fmt+0x33/0x40 [<c11dd8ac>] list_del+0x10c/0x120 [<f8051dd6>] acm_rx_tasklet+0x106/0x3e0 [cdc_acm] [<c135465d>] ? net_rps_action_and_irq_enable+0x6d/0x80 [<c1042bb6>] tasklet_action+0xe6/0x140 [<c104342f>] __do_softirq+0xaf/0x210 [<c1043380>] ? __do_softirq+0x0/0x210 <IRQ> [<c1042c9a>] ? run_ksoftirqd+0x8a/0x1c0 [<c1042c10>] ? run_ksoftirqd+0x0/0x1c0 [<c105ac24>] ? kthread+0x74/0x80 [<c105abb0>] ? kthread+0x0/0x80 [<c100337a>] ? kernel_thread_helper+0x6/0x10 ---[ end trace efd9a11434f0082f ]---
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da300, rcv 0xf57fbc10, buf 0xf57fbd50 cdc-acm.c: disconnected from networkcdc-acm.c: acm_rx_tasklet: sending urb 0xf50da380, rcv 0xf57fbbfc, buf 0xf57fbd3c cdc-acm.c: Entering acm_rx_tasklet
------------[ cut here ]------------ WARNING: at /home/johan/src/linux/linux-2.6/lib/list_debug.c:48 list_del+0xd5/0x120() Hardware name: Vostro 1520 list_del corruption, next is LIST_POISON1 (00100100) Modules linked in: cdc_acm Pid: 3, comm: ksoftirqd/0 Tainted: G W 2.6.37+ #39 Call Trace: [<c103c7e2>] warn_slowpath_common+0x72/0xa0 [<c11dd875>] ? list_del+0xd5/0x120 [<c11dd875>] ? list_del+0xd5/0x120 [<c103c8b3>] warn_slowpath_fmt+0x33/0x40 [<c11dd875>] list_del+0xd5/0x120 [<f8051fac>] acm_rx_tasklet+0x2dc/0x3e0 [cdc_acm] [<c106dbab>] ? trace_hardirqs_on+0xb/0x10 [<c1042b30>] ? tasklet_action+0x60/0x140 [<c1042bb6>] tasklet_action+0xe6/0x140 [<c104342f>] __do_softirq+0xaf/0x210 [<c1043380>] ? __do_softirq+0x0/0x210 <IRQ> [<c1042c9a>] ? run_ksoftirqd+0x8a/0x1c0 [<c1042c10>] ? run_ksoftirqd+0x0/0x1c0 [<c105ac24>] ? kthread+0x74/0x80 [<c105abb0>] ? kthread+0x0/0x80 [<c100337a>] ? kernel_thread_helper+0x6/0x10 ---[ end trace efd9a11434f00830 ]--- BUG: unable to handle kernel paging request at 00200200 IP: [<c11dd7bd>] list_del+0x1d/0x120 *pde = 00000000 Oops: 0000 [#1] PREEMPT SMP last sysfs file: /sys/devices/pci0000:00/0000:00:1a.1/usb4/4-1/4-1:1.0/tty/ttyACM0/uevent Modules linked in: cdc_acm
Pid: 3, comm: ksoftirqd/0 Tainted: G W 2.6.37+ #39 0T816J/Vostro 1520
EIP: 0060:[<c11dd7bd>] EFLAGS: 00010046 CPU: 0
EIP is at list_del+0x1d/0x120
EAX: f57fbd3c EBX: f57fb800 ECX: ffff8000 EDX: 00200200
ESI: f57fbe90 EDI: f57fbd3c EBP: f600bf54 ESP: f600bf3c
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process ksoftirqd/0 (pid: 3, ti=f600a000 task=f60791c0 task.ti=f6082000)
Stack: c1527e84 00000030 c1527e54 00100100 f57fb800 f57fbd3c f600bf98 f8051fac f8053104 f8052b94 f600bf6c c106dbab f600bf80 00000286 f60791c0 c1042b30 f57fbda8 f57f5800 f57fbdb0 f57fbd80 f57fbe7c c1656b04 00000000 f600bfb0 Call Trace: [<f8051fac>] ? acm_rx_tasklet+0x2dc/0x3e0 [cdc_acm] [<c106dbab>] ? trace_hardirqs_on+0xb/0x10 [<c1042b30>] ? tasklet_action+0x60/0x140 [<c1042bb6>] ? tasklet_action+0xe6/0x140 [<c104342f>] ? __do_softirq+0xaf/0x210 [<c1043380>] ? __do_softirq+0x0/0x210 <IRQ> [<c1042c9a>] ? run_ksoftirqd+0x8a/0x1c0 [<c1042c10>] ? run_ksoftirqd+0x0/0x1c0 [<c105ac24>] ? kthread+0x74/0x80 [<c105abb0>] ? kthread+0x0/0x80 [<c100337a>] ? kernel_thread_helper+0x6/0x10 Code: ff 48 14 e9 57 ff ff ff 90 90 90 90 90 90 55 89 e5 83 ec 18 81 38 00 01 10 00 0f 84 9c 00 00 00 8b 50 04 81 fa 00 02 20 00 74 33 <8b> 12 39 d0 75 5c 8b 10 8b 4a 04 39 c8 0f 85 b5 00 00 00 8b 48 EIP: [<c11dd7bd>] list_del+0x1d/0x120 SS:ESP 0068:f600bf3c CR2: 0000000000200200 ---[ end trace efd9a11434f00831 ]--- Kernel panic - not syncing: Fatal exception in interrupt Pid: 3, comm: ksoftirqd/0 Tainted: G D W 2.6.37+ #39 Call Trace: [<c13fede1>] ? printk+0x1d/0x24 [<c13fecce>] panic+0x66/0x15c [<c10067df>] oops_end+0x8f/0x90 [<c1025476>] no_context+0xc6/0x160 [<c10255a8>] __bad_area_nosemaphore+0x98/0x140 [<c103cf68>] ? release_console_sem+0x1d8/0x210 [<c1025667>] bad_area_nosemaphore+0x17/0x20 [<c1025a49>] do_page_fault+0x279/0x420 [<c1006a8f>] ? show_trace+0x1f/0x30 [<c13fede1>] ? printk+0x1d/0x24 [<c10257d0>] ? do_page_fault+0x0/0x420 [<c140333b>] error_code+0x5f/0x64 [<c103007b>] ? select_task_rq_fair+0x37b/0x6a0 [<c10257d0>] ? do_page_fault+0x0/0x420 [<c11dd7bd>] ? list_del+0x1d/0x120 [<f8051fac>] acm_rx_tasklet+0x2dc/0x3e0 [cdc_acm] [<c106dbab>] ? trace_hardirqs_on+0xb/0x10 [<c1042b30>] ? tasklet_action+0x60/0x140 [<c1042bb6>] tasklet_action+0xe6/0x140 [<c104342f>] __do_softirq+0xaf/0x210 [<c1043380>] ? __do_softirq+0x0/0x210 <IRQ> [<c1042c9a>] ? run_ksoftirqd+0x8a/0x1c0 [<c1042c10>] ? run_ksoftirqd+0x0/0x1c0 [<c105ac24>] ? kthread+0x74/0x80 [<c105abb0>] ? kthread+0x0/0x80 [<c100337a>] ? kernel_thread_helper+0x6/0x10 panic occurred, switching back to text console ------------[ cut here ]------------
--- drivers/usb/class/cdc-acm.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/usb/class/cdc-acm.c +2 -0
@@ -652,8 +652,10 @@ static void acm_port_down(struct acm *acusb_kill_urb (acm->ctrlurb);for (i =0 ; i <ACM_NW ; i++)usb_kill_urb (acm->wb[i].urb); +tasklet_disable (&acm->urb_task);for (i =0 ; i < nr; i++)usb_kill_urb (acm->ru[i].urb); +tasklet_enable (&acm->urb_task); acm->control->needs_remote_wakeup =0 ;usb_autopm_put_interface (acm->control); }
PATCH 29/35 USB: cdc-acm: fix potential null-pointer dereference
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Johan Hovold <[email protected]>
commit 15e5bee33ffc11d0e5c6f819a65e7881c5c407be upstream.
Must check return value of tty_port_tty_get.
--- drivers/usb/class/cdc-acm.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/usb/class/cdc-acm.c +2 -0
@@ -534,6 +534,8 @@ static void acm_softint(struct work_struif (!ACM_READY (acm))return ; tty =tty_port_tty_get (&acm->port); +if (!tty) +return ;tty_wakeup (tty);tty_kref_put (tty); }
PATCH 30/35 USB: cdc-acm: fix potential null-pointer dereference on disconnect
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Johan Hovold <[email protected]>
commit 7e7797e7f6f7bfab73fca02c65e40eaa5bb9000c upstream.
Fix potential null-pointer exception on disconnect introduced by commit 11ea859d64b69a747d6b060b9ed1520eab1161fe (USB: additional power savings for cdc-acm devices that support remote wakeup).
Only access acm->dev after making sure it is non-null in control urb completion handler.
--- drivers/usb/class/cdc-acm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/usb/class/cdc-acm.c +2 -1
@@ -297,6 +297,8 @@ static void acm_ctrl_irq(struct urb *urbif (!ACM_READY (acm)) goto exit; +usb_mark_last_busy (acm->dev); + data = (unsigned char *)(dr +1 );switch (dr->bNotificationType) {case USB_CDC_NOTIFY_NETWORK_CONNECTION :
@@ -336,7 +338,6 @@ static void acm_ctrl_irq(struct urb *urbbreak ; } exit: -usb_mark_last_busy (acm->dev); retval =usb_submit_urb (urb,GFP_ATOMIC );if (retval) dev_err(&urb->dev->dev, "%s - usb_submit_urb failed with "
PATCH 31/35 Input: xen-kbdfront - advertise either absolute or relative coordinates
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Olaf Hering <[email protected]>
commit 8c3c283e6bf463ab498d6e7823aff6c4762314b6 upstream.
A virtualized display device is usually viewed with the vncviewer application, either by 'xm vnc domU' or with vncviewer localhost:port. vncviewer and the RFB protocol provides absolute coordinates to the virtual display. These coordinates are either passed through to a PV guest or converted to relative coordinates for a HVM guest.
A PV guest receives these coordinates and passes them to the kernels evdev driver. There it can be picked up by applications such as the xorg-input drivers. Using absolute coordinates avoids issues such as guest mouse pointer not tracking host mouse pointer due to wrong mouse acceleration settings in the guests X display.
Advertise either absolute or relative coordinates to the input system and the evdev driver, depending on what dom0 provides. The xorg-input driver prefers relative coordinates even if a devices provides both.
--- drivers/input/xen-kbdfront.c | 45 ++++++++++++++++++++++--------------------- 1 file changed, 24 insertions(+), 21 deletions(-)
drivers/input/xen-kbdfront.c +24 -21
@@ -108,7 +108,7 @@ static irqreturn_t input_handler(int rq,static int __devinit xenkbd_probe (struct xenbus_device *dev,const struct xenbus_device_id *id) { -int ret, i; +int ret, i, abs;struct xenkbd_info *info;struct input_dev *kbd, *ptr;
@@ -126,6 +126,11 @@ static int __devinit xenkbd_probe(structif (!info->page) goto error_nomem; +if (xenbus_scanf (XBT_NIL , dev->otherend,"feature-abs-pointer" ,"%d" , &abs) <0 ) + abs =0 ; +if (abs) +xenbus_printf (XBT_NIL , dev->nodename,"request-abs-pointer" ,"1" ); +/* keyboard */ kbd =input_allocate_device ();if (!kbd)
@@ -135,11 +140,12 @@ static int __devinit xenkbd_probe(struct kbd->id.bustype =BUS_PCI ; kbd->id.vendor =0x5853 ; kbd->id.product =0xffff ; - kbd->evbit[0 ] =BIT (EV_KEY ); + +__set_bit (EV_KEY , kbd->evbit);for (i =KEY_ESC ; i <KEY_UNKNOWN ; i++) -set_bit (i, kbd->keybit); +__set_bit (i, kbd->keybit);for (i =KEY_OK ; i <KEY_MAX ; i++) -set_bit (i, kbd->keybit); +__set_bit (i, kbd->keybit); ret =input_register_device (kbd);if (ret) {
@@ -158,12 +164,20 @@ static int __devinit xenkbd_probe(struct ptr->id.bustype =BUS_PCI ; ptr->id.vendor =0x5853 ; ptr->id.product =0xfffe ; - ptr->evbit[0 ] =BIT (EV_KEY ) |BIT (EV_REL ) |BIT (EV_ABS ); + +if (abs) { +__set_bit (EV_ABS , ptr->evbit); +input_set_abs_params (ptr,ABS_X ,0 ,XENFB_WIDTH ,0 ,0 ); +input_set_abs_params (ptr,ABS_Y ,0 ,XENFB_HEIGHT ,0 ,0 ); + }else { +input_set_capability (ptr,EV_REL ,REL_X ); +input_set_capability (ptr,EV_REL ,REL_Y ); + } +input_set_capability (ptr,EV_REL ,REL_WHEEL ); + +__set_bit (EV_KEY , ptr->evbit);for (i =BTN_LEFT ; i <=BTN_TASK ; i++) -set_bit (i, ptr->keybit); - ptr->relbit[0 ] =BIT (REL_X ) |BIT (REL_Y ) |BIT (REL_WHEEL ); -input_set_abs_params (ptr,ABS_X ,0 ,XENFB_WIDTH ,0 ,0 ); -input_set_abs_params (ptr,ABS_Y ,0 ,XENFB_HEIGHT ,0 ,0 ); +__set_bit (i, ptr->keybit); ret =input_register_device (ptr);if (ret) {
@@ -270,7 +284,7 @@ static void xenkbd_backend_changed(struc enum xenbus_state backend_state) {struct xenkbd_info *info =dev_get_drvdata (&dev->dev); -int ret, val; +int val;switch (backend_state) {case XenbusStateInitialising:
@@ -281,17 +295,6 @@ static void xenkbd_backend_changed(struccase XenbusStateInitWait: InitWait: - ret =xenbus_scanf (XBT_NIL , info->xbdev->otherend, -"feature-abs-pointer" ,"%d" , &val); -if (ret <0 ) - val =0 ; -if (val) { - ret =xenbus_printf (XBT_NIL , info->xbdev->nodename, -"request-abs-pointer" ,"1" ); -if (ret) -printk (KERN_WARNING -"xenkbd: can't request abs-pointer" ); - }xenbus_switch_state (dev, XenbusStateConnected);break ;
PATCH 32/35 x86: Cleanup highmap after brk is concluded
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Yinghai Lu <[email protected]>
commit e5f15b45ddf3afa2bbbb10c7ea34fb32b6de0a0e upstream.
Now cleanup_highmap actually is in two steps: one is early in head64.c and only clears above _end; a second one is in init_memory_mapping() and tries to clean from _brk_end to _end.
It should check if those boundaries are PMD_SIZE aligned but currently does not.
Also init_memory_mapping() is called several times for numa or memory hotplug, so we really should not handle initial kernel mappings there.
This patch moves cleanup_highmap() down after _brk_end is settled so we can do everything in one step.
Also we honor max_pfn_mapped in the implementation of cleanup_highmap.
LKML-Reference: <alpine.DEB.2.00.1103171739050.3382@kaball-desktop>
--- arch/x86/kernel/head64.c | 3 --- arch/x86/kernel/setup.c | 5 +++++ arch/x86/mm/init.c | 19 ------------------- arch/x86/mm/init_64.c | 11 ++++++----- 4 files changed, 11 insertions(+), 27 deletions(-)
arch/x86/kernel/head64.c +0 -3
@@ -76,9 +76,6 @@ void __init x86_64_start_kernel(char * r/* Make NULL pointers segfault */ zap_identity_mappings (); -/* Cleanup the over mapped high alias */ -cleanup_highmap (); -for (i =0 ; i <NUM_EXCEPTION_VECTORS ; i++) {#ifdef CONFIG_EARLY_PRINTK set_intr_gate (i, &early_idt_handlers[i]);
arch/x86/kernel/setup.c +5 -0
@@ -295,6 +295,9 @@ static void __init init_gbpages(void)static inline void init_gbpages (void ) { } +static void __init cleanup_highmap (void ) +{ +}#endif static void __init reserve_brk (void )
@@ -895,6 +898,8 @@ void __init setup_arch(char **cmdline_p)reserve_brk (); +cleanup_highmap (); +/* * Find and reserve possible boot-time SMP configuration: */
arch/x86/mm/init.c +0 -19
@@ -283,25 +283,6 @@ unsigned long __init_refok init_memory_mload_cr3 (swapper_pg_dir);#endif -#ifdef CONFIG_X86_64 -if (!after_bootmem && !start) { -pud_t *pud; -pmd_t *pmd; - - mmu_cr4_features =read_cr4 (); - -/* -* _brk_end cannot change anymore, but it and _end may be -* located on different 2M pages. cleanup_highmap(), however, -* can only consider _end when it runs, so destroy any -* mappings beyond _brk_end here. -*/ - pud =pud_offset (pgd_offset_k (_brk_end), _brk_end); - pmd =pmd_offset (pud, _brk_end -1 ); -while (++pmd <=pmd_offset (pud, (unsigned long )_end -1 )) -pmd_clear (pmd); - } -#endif __flush_tlb_all ();if (!after_bootmem && e820_table_end > e820_table_start)
arch/x86/mm/init_64.c +6 -5
@@ -49,6 +49,7 @@#include <asm/numa.h> #include <asm/cacheflush.h> #include <asm/init.h> +#include <asm/setup.h> #include <linux/bootmem.h> static unsigned long dma_reserve__initdata ;
@@ -257,18 +258,18 @@ void __init init_extra_mapping_uc(unsign* to the compile time generated pmds. This results in invalid pmds up * to the point where we hit the physaddr 0 mapping. * -* We limit the mappings to the region from _text to _end. _end is -* rounded up to the 2MB boundary. This catches the invalid pmds as +* We limit the mappings to the region from _text to _brk_end. _brk_end +* is rounded up to the 2MB boundary. This catches the invalid pmds as * well, as they are located before _text: */ void __init cleanup_highmap (void ) {unsigned long vaddr = __START_KERNEL_map; -unsigned long end =roundup ((unsigned long )_end,PMD_SIZE ) -1 ; +unsigned long vaddr_end = __START_KERNEL_map + (max_pfn_mapped <<PAGE_SHIFT ); +unsigned long end =roundup ((unsigned long )_brk_end,PMD_SIZE ) -1 ;pmd_t *pmd = level2_kernel_pgt; -pmd_t *last_pmd = pmd +PTRS_PER_PMD ; -for (; pmd < last_pmd; pmd++, vaddr +=PMD_SIZE ) { +for (; vaddr +PMD_SIZE -1 < vaddr_end; pmd++, vaddr +=PMD_SIZE ) {if (pmd_none (*pmd))continue ;if (vaddr < (unsigned long ) _text || vaddr > end)
PATCH 33/35 SUNRPC: Never reuse the socket port after an xs_close()
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Trond Myklebust <[email protected]>
commit 246408dcd5dfeef2df437ccb0ef4d6ee87805f58 upstream.
If we call xs_close(), we're in one of two situations:
- Autoclose, which means we don't expect to resend a request
- bind+connect failed, which probably means the port is in use
--- net/sunrpc/xprtsock.c | 2 ++ 1 file changed, 2 insertions(+)
net/sunrpc/xprtsock.c +2 -0
@@ -729,6 +729,8 @@ static void xs_reset_transport(struct soif (sk ==NULL )return ; + transport->srcport =0 ; +write_lock_bh (&sk->sk_callback_lock); transport->inet =NULL ; transport->sock =NULL ;
PATCH 34/35 fs: call security_d_instantiate in d_obtain_alias V2
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Josef Bacik <[email protected]>
commit 24ff6663ccfdaf088dfa7acae489cb11ed4f43c4 upstream.
While trying to track down some NFS problems with BTRFS, I kept noticing I was getting -EACCESS for no apparent reason. Eric Paris and printk() helped me figure out that it was SELinux that was giving me grief, with the following denial
type=AVC msg=audit(1290013638.413:95): avc: denied { 0x800000 } for pid=1772 comm="nfsd" name="" dev=sda1 ino=256 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
Turns out this is because in d_obtain_alias if we can't find an alias we create one and do all the normal instantiation stuff, but we don't do the security_d_instantiate.
Usually we are protected from getting a hashed dentry that hasn't yet run security_d_instantiate() by the parent's i_mutex, but obviously this isn't an option there, so in order to deal with the case that a second thread comes in and finds our new dentry before we get to run security_d_instantiate(), we go ahead and call it if we find a dentry already. Eric assures me that this is ok as the code checks to see if the dentry has been initialized already so calling security_d_instantiate() against the same dentry multiple times is ok. With this patch I'm no longer getting errant -EACCESS values.
--- fs/dcache.c | 3 +++ 1 file changed, 3 insertions(+)
fs/dcache.c +3 -0
@@ -1176,9 +1176,12 @@ struct dentry *d_obtain_alias(struct inospin_unlock (&tmp->d_lock);spin_unlock (&dcache_lock); +security_d_instantiate (tmp, inode);return tmp; out_iput: +if (res && !IS_ERR (res)) +security_d_instantiate (res, inode);iput (inode);return res; }
Re: [34/35] fs: call security_d_instantiate in d_obtain_alias V2
Quoted 21 lines · Greg KH
2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Josef Bacik <[email protected]>
commit
24ff6663ccfdaf088dfa7acae489cb11ed4f43c4upstream.While trying to track down some NFS problems with BTRFS, I kept noticing I was getting
-EACCESSfor no apparent reason. Eric Paris andprintk()helped me figure out that it was SELinux that was giving me grief, with the following denialtype=AVC msg=audit(1290013638.413:95): avc: denied {
0x800000} for pid=1772 comm="nfsd" name="" dev=sda1 ino=256 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=fileTurns out this is because in
d_obtain_aliasif we can't find an alias we create one and do all the normal instantiation stuff, but we don't do thesecurity_d_instantiate.
Quoted 8 lines
Usually we are protected from getting a hashed dentry that hasn't yet run
security_d_instantiate()by the parent'si_mutex, but obviously this isn't an option there, so in order to deal with the case that a second thread comes in and finds our new dentry before we get to runsecurity_d_instantiate(), we go ahead and call it if we find a dentry already. Eric assures me that this is ok as the code checks to see if the dentry has been initialized already so callingsecurity_d_instantiate()against the same dentry multiple times is ok. With this patch I'm no longer getting errant-EACCESSvalues.
Not to be a bother, but did you try this with Smack as well as SELinux? Smack should be fine with the change, but if you're not going to try Smack I need to know.
Quoted 33 lines
Signed-off-by Josef Bacik <[email protected]>Signed-off-by Al Viro <[email protected]>Cc Chuck Ebbert <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- fs/dcache.c | 3 +++ 1 file changed, 3 insertions(+)fs/dcache.c +3
-1@@ -1176,9 +1176,12 @@ struct dentry *d_obtain_alias(struct inospin_unlock (&tmp->d_lock);spin_unlock (&dcache_lock); +security_d_instantiate (tmp, inode);return tmp; out_iput: +if (res && !IS_ERR (res)) +security_d_instantiate (res, inode);iput (inode);return res; } --To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [34/35] fs: call security_d_instantiate in d_obtain_alias V2
Quoted 31 lines · Casey Schaufler
Quoted 21 lines · Greg KH
2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Josef Bacik <[email protected]>
commit
24ff6663ccfdaf088dfa7acae489cb11ed4f43c4upstream.While trying to track down some NFS problems with BTRFS, I kept noticing I was getting
-EACCESSfor no apparent reason. Eric Paris andprintk()helped me figure out that it was SELinux that was giving me grief, with the following denialtype=AVC msg=audit(1290013638.413:95): avc: denied {
0x800000} for pid=1772 comm="nfsd" name="" dev=sda1 ino=256 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=fileTurns out this is because in
d_obtain_aliasif we can't find an alias we create one and do all the normal instantiation stuff, but we don't do thesecurity_d_instantiate.Quoted 8 lines
Usually we are protected from getting a hashed dentry that hasn't yet run
security_d_instantiate()by the parent'si_mutex, but obviously this isn't an option there, so in order to deal with the case that a second thread comes in and finds our new dentry before we get to runsecurity_d_instantiate(), we go ahead and call it if we find a dentry already. Eric assures me that this is ok as the code checks to see if the dentry has been initialized already so callingsecurity_d_instantiate()against the same dentry multiple times is ok. With this patch I'm no longer getting errant-EACCESSvalues.
Quoted 4 lines
Not to be a bother, but did you try this with Smack as well as SELinux? Smack should be fine with the change, but if you're not going to try Smack I need to know.
I only tested SELinux since it's on by default in fedora. Thanks,
Josef
PATCH 35/35 dcdbas: force SMI to happen when expected
In reply to Greg KH2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Stuart Hayes <[email protected]>
commit dd65c736d1b5312c80c88a64bf521db4959eded5 upstream.
The dcdbas driver can do an I/O write to cause a SMI to occur. The SMI handler looks at certain registers and memory locations, so the SMI needs to happen immediately. On some systems I/O writes are posted, though, causing the SMI to happen well after the "outb" occurred, which causes random failures. Following the "outb" with an "inb" forces the write to go through even if it is posted.
--- drivers/firmware/dcdbas.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/firmware/dcdbas.c +3 -1
@@ -267,8 +267,10 @@ int dcdbas_smi_request(struct smi_cmd *s }/* generate SMI */ +/* inb to force posted write through and make SMI happen now */ asm volatile ( - "outb %b0,%w1" + "outb %b0,%w1\n" + "inb %w1" : /* no output args */ : "a" (smi_cmd->command_code), "d" (smi_cmd->command_address),