commit 4b7a6d2528bfb625cc359d89ac16439b0ec744ea Author: Greg Kroah-Hartman Date: Fri Jun 3 10:35:11 2011 +0900 Linux 2.6.38.8 commit 035165d752508146f79fe90631fe6b95022d8833 Author: Kees Cook Date: Tue May 31 11:31:41 2011 -0700 AppArmor: fix oops in apparmor_setprocattr commit a5b2c5b2ad5853591a6cac6134cd0f599a720865 upstream. When invalid parameters are passed to apparmor_setprocattr a NULL deref oops occurs when it tries to record an audit message. This is because it is passing NULL for the profile parameter for aa_audit. But aa_audit now requires that the profile passed is not NULL. Fix this by passing the current profile on the task that is trying to setprocattr. Signed-off-by: Kees Cook Signed-off-by: John Johansen Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit ad106f8c9b2493de31e4b560b9aac000aa81ba10 Author: Lukas Czerner Date: Fri May 20 13:49:04 2011 -0400 ext4: Use schedule_timeout_interruptible() for waiting in lazyinit thread commit 4ed5c033c11b33149d993734a6a8de1016e8f03f upstream. In order to make lazyinit eat approx. 10% of io bandwidth at max, we are sleeping between zeroing each single inode table. For that purpose we are using timer which wakes up thread when it expires. It is set via add_timer() and this may cause troubles in the case that thread has been woken up earlier and in next iteration we call add_timer() on still running timer hence hitting BUG_ON in add_timer(). We could fix that by using mod_timer() instead however we can use schedule_timeout_interruptible() for waiting and hence simplifying things a lot. This commit exchange the old "waiting mechanism" with simple schedule_timeout_interruptible(), setting the time to sleep. Hence we do not longer need li_wait_daemon waiting queue and others, so get rid of it. Addresses-Red-Hat-Bugzilla: #699708 Signed-off-by: Lukas Czerner Signed-off-by: "Theodore Ts'o" Reviewed-by: Eric Sandeen Signed-off-by: Greg Kroah-Hartman commit abe87a0b0ba5a0cddfab30bbafc6e2b121537b15 Author: Tian, Kevin Date: Thu May 12 10:56:08 2011 +0800 xen mmu: fix a race window causing leave_mm BUG() commit 7899891c7d161752f29abcc9bc0a9c6c3a3af26c upstream. There's a race window in xen_drop_mm_ref, where remote cpu may exit dirty bitmap between the check on this cpu and the point where remote cpu handles drop request. So in drop_other_mm_ref we need check whether TLB state is still lazy before calling into leave_mm. This bug is rarely observed in earlier kernel, but exaggerated by the commit 831d52bc153971b70e64eccfbed2b232394f22f8 ("x86, mm: avoid possible bogus tlb entries by clearing prev mm_cpumask after switching mm") which clears bitmap after changing the TLB state. the call trace is as below: --------------------------------- kernel BUG at arch/x86/mm/tlb.c:61! invalid opcode: 0000 [#1] SMP last sysfs file: /sys/devices/system/xen_memory/xen_memory0/info/current_kb CPU 1 Modules linked in: 8021q garp xen_netback xen_blkback blktap blkback_pagemap nbd bridge stp llc autofs4 ipmi_devintf ipmi_si ipmi_msghandler lockd sunrpc bonding ipv6 xenfs dm_multipath video output sbs sbshc parport_pc lp parport ses enclosure snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device serio_raw bnx2 snd_pcm_oss snd_mixer_oss snd_pcm snd_timer iTCO_wdt snd soundcore snd_page_alloc i2c_i801 iTCO_vendor_support i2c_core pcs pkr pata_acpi ata_generic ata_piix shpchp mptsas mptscsih mptbase [last unloaded: freq_table] Pid: 25581, comm: khelper Not tainted 2.6.32.36fixxen #1 Tecal RH2285 RIP: e030:[] [] leave_mm+0x15/0x46 RSP: e02b:ffff88002805be48 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88015f8e2da0 RDX: ffff88002805be78 RSI: 0000000000000000 RDI: 0000000000000001 RBP: ffff88002805be48 R08: ffff88009d662000 R09: dead000000200200 R10: dead000000100100 R11: ffffffff814472b2 R12: ffff88009bfc1880 R13: ffff880028063020 R14: 00000000000004f6 R15: 0000000000000000 FS: 00007f62362d66e0(0000) GS:ffff880028058000(0000) knlGS:0000000000000000 CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000003aabc11909 CR3: 000000009b8ca000 CR4: 0000000000002660 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000000 00 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process khelper (pid: 25581, threadinfo ffff88007691e000, task ffff88009b92db40) Stack: ffff88002805be68 ffffffff8100e4ae 0000000000000001 ffff88009d733b88 <0> ffff88002805be98 ffffffff81087224 ffff88002805be78 ffff88002805be78 <0> ffff88015f808360 00000000000004f6 ffff88002805bea8 ffffffff81010108 Call Trace: [] drop_other_mm_ref+0x2a/0x53 [] generic_smp_call_function_single_interrupt+0xd8/0xfc [] xen_call_function_single_interrupt+0x13/0x28 [] handle_IRQ_event+0x66/0x120 [] handle_percpu_irq+0x41/0x6e [] __xen_evtchn_do_upcall+0x1ab/0x27d [] xen_evtchn_do_upcall+0x33/0x46 [] xen_do_hyper visor_callback+0x1e/0x30 [] ? _spin_unlock_irqrestore+0x15/0x17 [] ? xen_restore_fl_direct_end+0x0/0x1 [] ? flush_old_exec+0x3ac/0x500 [] ? load_elf_binary+0x0/0x17ef [] ? load_elf_binary+0x0/0x17ef [] ? load_elf_binary+0x398/0x17ef [] ? need_resched+0x23/0x2d [] ? process_measurement+0xc0/0xd7 [] ? load_elf_binary+0x0/0x17ef [] ? search_binary_handler+0xc8/0x255 [] ? do_execve+0x1c3/0x29e [] ? sys_execve+0x43/0x5d [] ? __call_usermodehelper+0x0/0x6f [] ? kernel_execve+0x68/0xd0 [] ? __call_usermodehelper+0x0/0x6f [] ? xen_restore_fl_direct_end+0x0/0x1 [] ? ____call_usermodehelper+0x113/0x11e [] ? child_rip+0xa/0x20 [] ? __call_usermodehelper+0x0/0x6f [] ? int_ret_from_sys_call+0x7/0x1b [] ? retint_restore_args+0x5/0x6 [] ? child_rip+0x0/0x20 Code: 41 5e 41 5f c9 c3 55 48 89 e5 0f 1f 44 00 00 e8 17 ff ff ff c9 c3 55 48 89 e5 0f 1f 44 00 00 65 8b 04 25 c8 55 01 00 ff c8 75 04 <0f> 0b eb fe 65 48 8b 34 25 c0 55 01 00 48 81 c6 b8 02 00 00 e8 RIP [] leave_mm+0x15/0x46 RSP ---[ end trace ce9cee6832a9c503 ]--- Tested-by: Maoxiaoyun Signed-off-by: Kevin Tian [v1: Fleshed out the git description a bit] Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit 872b58c1256fa27e17c52b098a55a4d6c92b2584 Author: Hemant Pedanekar Date: Tue Apr 5 12:32:50 2011 +0530 PCI: Add quirk for setting valid class for TI816X Endpoint commit 63c4408074cbcc070ac17fc10e524800eb9bd0b0 upstream. TI816X (common name for DM816x/C6A816x/AM389x family) devices configured to boot as PCIe Endpoint have class code = 0. This makes kernel PCI bus code to skip allocating BARs to these devices resulting into following type of error when trying to enable them: "Device 0000:01:00.0 not available because of resource collisions" The device cannot be operated because of the above issue. This patch adds a ID specific (TI VENDOR ID and 816X DEVICE ID based) 'early' fixup quirk to replace class code with PCI_CLASS_MULTIMEDIA_VIDEO as class. Signed-off-by: Hemant Pedanekar Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit 0ab692407602f96ad71d62f9c551fdba4529c803 Author: Trond Myklebust Date: Thu May 26 14:26:35 2011 -0400 NFSv4.1: Fix the handling of NFS4ERR_SEQ_MISORDERED errors commit 444f72fe7e7b5f4db34cee933fa3546ebb8e9122 upstream. Currently, the call to nfs4_schedule_session_recovery() will actually just result in a test of the lease when what we really want is to force a session reset. Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 6844274a3ca81e5643b53c9844796f3dc11b5518 Author: Trond Myklebust Date: Thu May 26 14:26:35 2011 -0400 NFSv4: Handle expired stateids when the lease is still valid commit 0ced63d1a245ac11241a5d37932e6d04d9c8040d upstream. Currently, if the server returns NFS4ERR_EXPIRED in reply to a READ or WRITE, but the RENEW test determines that the lease is still active, we fail to recover and end up looping forever in a READ/WRITE + RENEW death spiral. Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit a0a238f7cb684c0ea76a5817d1c92e2c7b0b7bd2 Author: Trond Myklebust Date: Fri Mar 18 20:21:23 2011 -0400 SUNRPC: Deal with the lack of a SYN_SENT sk->sk_state_change callback... commit fe19a96b10032035a35779f42ad59e35d6dd8ffd upstream. The TCP connection state code depends on the state_change() callback being called when the SYN_SENT state is set. However the networking layer doesn't actually call us back in that case. Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 00871cab71537bed0eef99e014f690263f6c1286 Author: Dave Airlie Date: Thu May 19 14:14:43 2011 +1000 drm/radeon/kms: add wait idle ioctl for eg->cayman commit 97bfd0acd32e9639c9136e03955d574655d5cc2b upstream. None of the latest GPUs had this hooked up, this is necessary for correct operation in a lot of cases, however we should test this on a few GPUs in these families as we've had problems in this area before. Reviewed-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit ee2e1006af9c8ed994adeaa6cb60b76a6650ff7a Author: Alex Deucher Date: Thu May 19 11:07:57 2011 -0400 drm/radeon/evergreen/btc/fusion: setup hdp to invalidate and flush when asked commit f25a5c63bfa017498c9adecb24d649ae96ba5c68 upstream. This needs to be explicitly set on btc. It's set by default on evergreen/fusion, so it fine to just unconditionally enable it for all chips. Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit cd9c43f0be334f028e2c8e969e6bd90b51fcdebb Author: Boqun Feng Date: Mon May 16 16:02:39 2011 +0800 drm/i915: fix user irq miss in BSD ring on g4x commit 5bfa1063a775836a84f97e4df863fc36e1f856ad upstream. On g4x, user interrupt in BSD ring is missed. This is because though g4x and ironlake share the same bsd_ring, their interrupt control interfaces have _two_ differences. 1.different irq enable/disable functions: On g4x are i915_enable_irq and i915_disable_irq. On ironlake are ironlake_enable_irq and ironlake_disable_irq. 2.different irq flag: On g4x user interrupt flag in BSD ring on is I915_BSD_USER_INTERRUPT. On ironlake is GT_BSD_USER_INTERRUPT Old bsd_ring_get/put_irq call ring_get_irq and ring_get_irq. ring_get_irq and ring_put_irq only call ironlake_enable/disable_irq. So comes the irq miss on g4x. To fix this, as other rings' code do, conditionally call different functions(i915_enable/disable_irq and ironlake_enable/disable_irq) and use different interrupt flags in bsd_ring_get/put_irq. Signed-off-by: Boqun Feng Reviewed-by: Xiang, Haihao Signed-off-by: Keith Packard Signed-off-by: Greg Kroah-Hartman commit a3a9ec868705f8c00c9ddac569f2a3f2f241b2b6 Author: Namhyung Kim Date: Thu May 26 21:06:50 2011 +0200 brd: handle on-demand devices correctly commit af46566885a373b0a526932484cd8fef8de7b598 upstream. When finding or allocating a ram disk device, brd_probe() did not take partition numbers into account so that it can result to a different device. Consider following example (I set CONFIG_BLK_DEV_RAM_COUNT=4 for simplicity) : $ sudo modprobe brd max_part=15 $ ls -l /dev/ram* brw-rw---- 1 root disk 1, 0 2011-05-25 15:41 /dev/ram0 brw-rw---- 1 root disk 1, 16 2011-05-25 15:41 /dev/ram1 brw-rw---- 1 root disk 1, 32 2011-05-25 15:41 /dev/ram2 brw-rw---- 1 root disk 1, 48 2011-05-25 15:41 /dev/ram3 $ sudo mknod /dev/ram4 b 1 64 $ sudo dd if=/dev/zero of=/dev/ram4 bs=4k count=256 256+0 records in 256+0 records out 1048576 bytes (1.0 MB) copied, 0.00215578 s, 486 MB/s namhyung@leonhard:linux$ ls -l /dev/ram* brw-rw---- 1 root disk 1, 0 2011-05-25 15:41 /dev/ram0 brw-rw---- 1 root disk 1, 16 2011-05-25 15:41 /dev/ram1 brw-rw---- 1 root disk 1, 32 2011-05-25 15:41 /dev/ram2 brw-rw---- 1 root disk 1, 48 2011-05-25 15:41 /dev/ram3 brw-r--r-- 1 root root 1, 64 2011-05-25 15:45 /dev/ram4 brw-rw---- 1 root disk 1, 1024 2011-05-25 15:44 /dev/ram64 After this patch, /dev/ram4 - instead of /dev/ram64 - was accessed correctly. In addition, 'range' passed to blk_register_region() should include all range of dev_t that RAMDISK_MAJOR can address. It does not need to be limited by partition numbers unless 'rd_nr' param was specified. Signed-off-by: Namhyung Kim Cc: Laurent Vivier Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 367ecefc8ad6e652b22199403da04742feb96156 Author: Namhyung Kim Date: Thu May 26 21:06:50 2011 +0200 brd: limit 'max_part' module param to DISK_MAX_PARTS commit 315980c8688c4b06713c1a5fe9d64cdf8ab57a72 upstream. The 'max_part' parameter controls the number of maximum partition a brd device can have. However if a user specifies very large value it would exceed the limitation of device minor number and can cause a kernel panic (or, at least, produce invalid device nodes in some cases). On my desktop system, following command kills the kernel. On qemu, it triggers similar oops but the kernel was alive: $ sudo modprobe brd max_part=100000 BUG: unable to handle kernel NULL pointer dereference at 0000000000000058 IP: [] sysfs_create_dir+0x2d/0xae PGD 7af1067 PUD 7b19067 PMD 0 Oops: 0000 [#1] SMP last sysfs file: CPU 0 Modules linked in: brd(+) Pid: 44, comm: insmod Tainted: G W 2.6.39-qemu+ #158 Bochs Bochs RIP: 0010:[] [] sysfs_create_dir+0x2d/0xae RSP: 0018:ffff880007b15d78 EFLAGS: 00000286 RAX: ffff880007b05478 RBX: ffff880007a52760 RCX: ffff880007b15dc8 RDX: ffff880007a4f900 RSI: ffff880007b15e48 RDI: ffff880007a52760 RBP: ffff880007b15da8 R08: 0000000000000002 R09: 0000000000000000 R10: ffff880007b15e48 R11: ffff880007b05478 R12: 0000000000000000 R13: ffff880007b05478 R14: 0000000000400920 R15: 0000000000000063 FS: 0000000002160880(0063) GS:ffff880007c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000058 CR3: 0000000007b1c000 CR4: 00000000000006b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000 Process insmod (pid: 44, threadinfo ffff880007b14000, task ffff880007acb980) Stack: ffff880007b15dc8 ffff880007b05478 ffff880007b15da8 00000000fffffffe ffff880007a52760 ffff880007b05478 ffff880007b15de8 ffffffff81143c0a 0000000000400920 ffff880007a52760 ffff880007b05478 0000000000000000 Call Trace: [] kobject_add_internal+0xdf/0x1a0 [] kobject_add_varg+0x41/0x50 [] kobject_add+0x64/0x66 [] blk_register_queue+0x5f/0xb8 [] add_disk+0xdf/0x289 [] brd_init+0xdf/0x1aa [brd] [] ? 0xffffffffa0003fff [] ? 0xffffffffa0003fff [] do_one_initcall+0x7a/0x12e [] sys_init_module+0x9c/0x1dc [] system_call_fastpath+0x16/0x1b Code: 89 e5 41 55 41 54 53 48 89 fb 48 83 ec 18 48 85 ff 75 04 0f 0b eb fe 48 8b 47 18 49 c7 c4 70 1e 4d 81 48 85 c0 74 04 4c 8b 60 30 8b 44 24 58 45 31 ed 0f b6 c4 85 c0 74 0d 48 8b 43 28 48 89 RIP [] sysfs_create_dir+0x2d/0xae RSP CR2: 0000000000000058 ---[ end trace aebb1175ce1f6739 ]--- Signed-off-by: Namhyung Kim Cc: Laurent Vivier Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 9854d5778eb446a332fb34ad17ff4d04c6440999 Author: Dan Williams Date: Fri May 27 04:51:54 2011 +0000 atm: expose ATM device index in sysfs commit e7a46b4d0839c2a3aa2e0ae0b145f293f6738498 upstream. It's currently exposed only through /proc which, besides requiring screen-scraping, doesn't allow userspace to distinguish between two identical ATM adapters with different ATM indexes. The ATM device index is required when using PPPoATM on a system with multiple ATM adapters. Signed-off-by: Dan Williams Reviewed-by: Eric Dumazet Tested-by: David Woodhouse Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 213c900d693b87e709e32b046858843fad0332ea Author: Hugh Dickins Date: Sat May 28 13:14:09 2011 -0700 tmpfs: fix race between truncate and writepage commit 826267cf1e6c6899eda1325a19f1b1d15c558b20 upstream. While running fsx on tmpfs with a memhog then swapoff, swapoff was hanging (interruptibly), repeatedly failing to locate the owner of a 0xff entry in the swap_map. Although shmem_writepage() does abandon when it sees incoming page index is beyond eof, there was still a window in which shmem_truncate_range() could come in between writepage's dropping lock and updating swap_map, find the half-completed swap_map entry, and in trying to free it, leave it in a state that swap_shmem_alloc() could not correct. Arguably a bug in __swap_duplicate()'s and swap_entry_free()'s handling of the different cases, but easiest to fix by moving swap_shmem_alloc() under cover of the lock. More interesting than the bug: it's been there since 2.6.33, why could I not see it with earlier kernels? The mmotm of two weeks ago seems to have some magic for generating races, this is just one of three I found. With yesterday's git I first saw this in mainline, bisected in search of that magic, but the easy reproducibility evaporated. Oh well, fix the bug. Signed-off-by: Hugh Dickins Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f311af550d6d24b03c1c911572192bc95fe58404 Author: Will Deacon Date: Thu May 26 11:20:19 2011 +0100 ARM: 6941/1: cache: ensure MVA is cacheline aligned in flush_kern_dcache_area commit a248b13b21ae00b97638b4f435c8df3075808b5d upstream. The v6 and v7 implementations of flush_kern_dcache_area do not align the passed MVA to the size of a cacheline in the data cache. If a misaligned address is used, only a subset of the requested area will be flushed. This has been observed to cause failures in SMP boot where the secondary_data initialised by the primary CPU is not cacheline aligned, causing the secondary CPUs to read incorrect values for their pgd and stack pointers. This patch ensures that the base address is cacheline aligned before flushing the d-cache. Acked-by: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 5bbf11bd6cac2d02b6054eb1ecba1ead7dc7191b Author: Milan Broz Date: Sun May 29 13:02:52 2011 +0100 dm table: reject devices without request fns commit f4808ca99a203f20b4475601748e44b25a65bdec upstream. This patch adds a check that a block device has a request function defined before it is used. Otherwise, misconfiguration can cause an oops. Because we are allowing devices with zero size e.g. an offline multipath device as in commit 2cd54d9bedb79a97f014e86c0da393416b264eb3 ("dm: allow offline devices") there needs to be an additional check to ensure devices are initialised. Some block devices, like a loop device without a backing file, exist but have no request function. Reproducer is trivial: dm-mirror on unbound loop device (no backing file on loop devices) dmsetup create x --table "0 8 mirror core 2 8 sync 2 /dev/loop0 0 /dev/loop1 0" and mirror resync will immediatelly cause OOps. BUG: unable to handle kernel NULL pointer dereference at (null) ? generic_make_request+0x2bd/0x590 ? kmem_cache_alloc+0xad/0x190 submit_bio+0x53/0xe0 ? bio_add_page+0x3b/0x50 dispatch_io+0x1ca/0x210 [dm_mod] ? read_callback+0x0/0xd0 [dm_mirror] dm_io+0xbb/0x290 [dm_mod] do_mirror+0x1e0/0x748 [dm_mirror] Signed-off-by: Milan Broz Reported-by: Zdenek Kabelac Acked-by: Mike Snitzer Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit a1722e9acd8083e85d0ba54409c630ac61dec985 Author: Tim Chen Date: Fri Feb 11 12:49:04 2011 -0800 idle governor: Avoid lock acquisition to read pm_qos before entering idle commit 333c5ae9948194428fe6c5ef5c088304fc98263b upstream. Thanks to the reviews and comments by Rafael, James, Mark and Andi. Here's version 2 of the patch incorporating your comments and also some update to my previous patch comments. I noticed that before entering idle state, the menu idle governor will look up the current pm_qos target value according to the list of qos requests received. This look up currently needs the acquisition of a lock to access the list of qos requests to find the qos target value, slowing down the entrance into idle state due to contention by multiple cpus to access this list. The contention is severe when there are a lot of cpus waking and going into idle. For example, for a simple workload that has 32 pair of processes ping ponging messages to each other, where 64 cpu cores are active in test system, I see the following profile with 37.82% of cpu cycles spent in contention of pm_qos_lock: - 37.82% swapper [kernel.kallsyms] [k] _raw_spin_lock_irqsave - _raw_spin_lock_irqsave - 95.65% pm_qos_request menu_select cpuidle_idle_call - cpu_idle 99.98% start_secondary A better approach will be to cache the updated pm_qos target value so reading it does not require lock acquisition as in the patch below. With this patch the contention for pm_qos_lock is removed and I saw a 2.2X increase in throughput for my message passing workload. Signed-off-by: Tim Chen Acked-by: Andi Kleen Acked-by: James Bottomley Acked-by: mark gross Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 4a1163dff6592dcee594b2bee597aafd749b93ee Author: Tero Kristo Date: Thu Feb 24 17:19:23 2011 +0200 cpuidle: menu: fixed wrapping timers at 4.294 seconds commit 7467571f4480b273007517b26297c07154c73924 upstream. Cpuidle menu governor is using u32 as a temporary datatype for storing nanosecond values which wrap around at 4.294 seconds. This causes errors in predicted sleep times resulting in higher than should be C state selection and increased power consumption. This also breaks cpuidle state residency statistics. Signed-off-by: Tero Kristo Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit f48e373ba0df22c98e0d8e9d8888d888b845e061 Author: Luca Tettamanti Date: Wed May 25 20:43:31 2011 +0200 i8k: Avoid lahf in 64-bit code commit bc1f419c76a2d6450413ce4349f4e4a07be011d5 upstream. i8k uses lahf to read the flag register in 64-bit code; early x86-64 CPUs, however, lack this instruction and we get an invalid opcode exception at runtime. Use pushf to load the flag register into the stack instead. Signed-off-by: Luca Tettamanti Reported-by: Jeff Rickman Tested-by: Jeff Rickman Tested-by: Harry G McGavran Jr Cc: Massimo Dal Zotto Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 77a75aa402d6021f2b0059ef1c2f92cb6b10fbaf Author: Kevin Cernekee Date: Tue May 10 15:47:16 2011 -0700 kbuild: Fix GNU make v3.80 compatibility commit 43f67c98161c65f1b2e3af3a9ce6741850072c06 upstream. According to Documentation/Changes, the kernel should be buildable with GNU make 3.80+. Commit 88d7be031f9f975bb3f50a0b5ef3796a671e7edf (kbuild: Use a single clean rule for kernel and external modules) introduced the "$(or" construct, which requires make 3.81. This causes "make clean" to malfunction when it is used with external modules. Replace "$(or" with an equivalent "$(if" expression, to restore backward compatibility. Signed-off-by: Kevin Cernekee Signed-off-by: Michal Marek Signed-off-by: Greg Kroah-Hartman commit c02eace342342b3156426e7a5ffe1ddc93552c51 Author: Artem Bityutskiy Date: Fri May 6 17:08:56 2011 +0300 UBIFS: fix a rare memory leak in ro to rw remounting path commit eaeee242c531cd4b0a4a46e8b5dd7ef504380c42 upstream. When re-mounting from R/O mode to R/W mode and the LEB count in the superblock is not up-to date, because for the underlying UBI volume became larger, we re-write the superblock. We allocate RAM for these purposes, but never free it. So this is a memory leak, although very rare one. Signed-off-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman commit b93e342044640789e34a48893c120875afbcb07d Author: Tyler Hicks Date: Tue May 17 00:50:33 2011 -0500 eCryptfs: Allow 2 scatterlist entries for encrypted filenames commit 8d08dab786ad5cc2aca2bf870de370144b78c85a upstream. The buffers allocated while encrypting and decrypting long filenames can sometimes straddle two pages. In this situation, virt_to_scatterlist() will return -ENOMEM, causing the operation to fail and the user will get scary error messages in their logs: kernel: ecryptfs_write_tag_70_packet: Internal error whilst attempting to convert filename memory to scatterlist; expected rc = 1; got rc = [-12]. block_aligned_filename_size = [272] kernel: ecryptfs_encrypt_filename: Error attempting to generate tag 70 packet; rc = [-12] kernel: ecryptfs_encrypt_and_encode_filename: Error attempting to encrypt filename; rc = [-12] kernel: ecryptfs_lookup: Error attempting to encrypt and encode filename; rc = [-12] The solution is to allow up to 2 scatterlist entries to be used. Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman commit d0f7955df4d1fac108e5edfd6a9ebe9135b1597f Author: Christian Lamparter Date: Fri May 13 21:47:23 2011 +0200 p54usb: add zoom 4410 usbid commit 9368a9a2378ab721f82f59430a135b4ce4ff5109 upstream. Reported-by: Mark Davis Signed-off-by: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 3a0d69ad4e806eb4aba6cb5ce167dc28a74f0e4c Author: Kuninori Morimoto Date: Fri Apr 15 16:44:27 2011 +0900 sh: fixup fpu.o compile order commit a375b15164dd9264f724ad941825e52c90145151 upstream. arch_ptrace() was modified to reference init_fpu() to fix up xstate initialization, which overlooked the fact that there are configurations that don't enable any of hard FPU support or emulation, resulting in build errors on DSP parts. Given that init_fpu() simply sets up the xstate slab cache and is side-stepped entirely for the DSP case, we can simply always build in the helper and fix up the references. Reported-by: Nobuhiro Iwamatsu Signed-off-by: Kuninori Morimoto Signed-off-by: Paul Mundt Signed-off-by: Greg Kroah-Hartman commit 4e3ce1d6df72b3b6bf871c9d2ea78711d3a9d724 Author: Kuninori Morimoto Date: Thu Apr 14 17:13:53 2011 +0900 sh: clkfwk: fixup clk_rate_table_build parameter in div6 clock commit 52c10ad22b7e317960b4d411c9a9ddeaf3d5ae39 upstream. div6 clock should not use arch_flags for clk_rate_table_build, because SH_CLK_DIV6_EXT doesn't care .arch_flags. clk->freq_table[] will be all CPUFREQ_ENTRY_INVALID without this patch. Signed-off-by: Kuninori Morimoto Signed-off-by: Paul Mundt Signed-off-by: Greg Kroah-Hartman commit 80e0c7a68e493495c9006824dc7d476ab2ff3776 Author: Jonathan Nieder Date: Sun May 1 06:29:56 2011 -0300 cx88: hold device lock during sub-driver initialization commit 1d6213ab995c61f7d1d81cf6cf876acf15d6e714 upstream. cx8802_blackbird_probe makes a device node for the mpeg sub-device before it has been added to dev->drvlist. If the device is opened during that time, the open succeeds but request_acquire cannot be called, so the reference count remains zero. Later, when the device is closed, the reference count becomes negative --- uh oh. Close the race by holding core->lock during probe and not releasing until the device is in drvlist and initialization finished. Previously the BKL prevented this race. Reported-by: Andreas Huber Tested-by: Andi Huber Tested-by: Marlon de Boer Signed-off-by: Jonathan Nieder Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit d47b389e7b2de4086cbf1d811d6803245c3798fc Author: Jonathan Nieder Date: Sun May 1 06:29:37 2011 -0300 cx88: fix locking of sub-driver operations commit 1fe70e963028f34ba5e32488a7870ff4b410b19b upstream. The BKL conversion of this driver seems to have gone wrong. Loading the cx88-blackbird driver deadlocks. The cause: mpeg_ops::open in the cx2388x blackbird driver acquires the device lock and calls the sub-driver's request_acquire, which tries to acquire the lock again. Fix it by clarifying the semantics of request_acquire, request_release, advise_acquire, and advise_release: now all will rely on the caller to acquire the device lock. Based on work by Ben Hutchings . Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=31962 Reported-by: Andi Huber Tested-by: Andi Huber Tested-by: Marlon de Boer Signed-off-by: Jonathan Nieder Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 18dc0de0c7e41be4fe0ca22c6aa384cc38fa45d5 Author: Jonathan Nieder Date: Sun May 1 06:29:16 2011 -0300 cx88: protect per-device driver list with device lock commit 8a317a8760cfffa8185b56ff59fb4b6c58488d79 upstream. The BKL conversion of this driver seems to have gone wrong. Various uses of the sub-device and driver lists appear to be subject to race conditions. In particular, some functions access drvlist without a relevant lock held, which will race against removal of drivers. Let's start with that --- clean up by consistently protecting dev->drvlist with dev->core->lock, noting driver functions that require the device lock to be held or not to be held. After this patch, there are still some races --- e.g., cx8802_blackbird_remove can run between the time the blackbird driver is acquired and the time it is used in mpeg_release, and there's a similar race in cx88_dvb_bus_ctrl. Later patches will address the remaining known races and the deadlock noticed by Andi. This patch just makes the semantics clearer in preparation for those later changes. Based on work by Ben Hutchings . Tested-by: Andi Huber Tested-by: Marlon de Boer Signed-off-by: Jonathan Nieder Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit d8fe0246330b97a736c7c9986c70eadc7b014581 Author: Alan Stern Date: Tue May 17 17:27:12 2011 -0400 USB: remove remaining usages of hcd->state from usbcore and fix regression commit 69fff59de4d844f8b4c2454c3c23d32b69dcbfd7 upstream. This patch (as1467) removes the last usages of hcd->state from usbcore. We no longer check to see if an interrupt handler finds that a controller has died; instead we rely on host controller drivers to make an explicit call to usb_hc_died(). This fixes a regression introduced by commit 9b37596a2e860404503a3f2a6513db60c296bfdc (USB: move usbcore away from hcd->state). It used to be that when a controller shared an IRQ with another device and an interrupt arrived while hcd->state was set to HC_STATE_HALT, the interrupt handler would be skipped. The commit removed that test; as a result the current code doesn't skip calling the handler and ends up believing the controller has died, even though it's only temporarily stopped. The solution is to ignore HC_STATE_HALT following the handler's return. As a consequence of this change, several of the host controller drivers need to be modified. They can no longer implicitly rely on usbcore realizing that a controller has died because of hcd->state. The patch adds calls to usb_hc_died() in the appropriate places. The patch also changes a few of the interrupt handlers. They don't expect to be called when hcd->state is equal to HC_STATE_HALT, even if the controller is still alive. Early returns were added to avoid any confusion. Signed-off-by: Alan Stern Tested-by: Manuel Lauss CC: Rodolfo Giometti CC: Olav Kongas Signed-off-by: Greg Kroah-Hartman commit a6cde63c3d193a021257ce07fe16b4936902a2b7 Author: Alan Stern Date: Mon May 16 12:15:19 2011 -0400 OHCI: fix regression caused by nVidia shutdown workaround commit 2b7aaf503d56216b847c8265421d2a7d9b42df3e upstream. This patch (as1463) fixes a regression caused by commit 3df7169e73fc1d71a39cffeacc969f6840cdf52b (OHCI: work around for nVidia shutdown problem). The original problem encountered by people using NVIDIA chipsets was that USB devices were not turning off when the system shut down. For example, the LED on an optical mouse would remain on, draining a laptop's battery. The problem was caused by a bug in the chipset; an OHCI controller in the Reset state would continue to drive a bus reset signal even after system shutdown. The workaround was to put the controllers into the Suspend state instead. It turns out that later NVIDIA chipsets do not suffer from this bug. Instead some have the opposite bug: If a system is shut down while an OHCI controller is in the Suspend state, USB devices remain powered! On other systems, shutting down with a Suspended controller causes the system to reboot immediately. Thus, working around the original bug on some machines exposes other bugs on other machines. The best solution seems to be to limit the workaround to OHCI controllers with a low-numbered PCI product ID. I don't know exactly at what point NVIDIA changed their chipsets; the value used here is a guess. So far it was worked out okay for all the people who have tested it. This fixes Bugzilla #35032. Signed-off-by: Alan Stern Tested-by: Andre "Osku" Schmidt Tested-by: Yury Siamashka Signed-off-by: Greg Kroah-Hartman commit 371b30ea7c1e31126c9775935fa7c9a113a394d8 Author: Marcin Gałczyński Date: Sun May 15 11:41:54 2011 +0200 USB: option: add support for Huawei E353 device commit 610ba42f29c3dfa46a05ff8c2cadc29f544ff76d upstream. I am sharing patch to the devices/usb/serial/option.c. This allows operation of Huawei E353 broadband modem using the “option” driver. The patch simply adds new constant with proper product ID and an entry to usb_device_id. I worked on the 2.6.38.6 sources. Tested on Dell inspiron 1764 (i3 core cpu) and brand new Huawei E353 modem, Fedora 15 beta. Looking at the type of change, i doubt it has potential to introduce problems in other parts of kernel or the driver itself. Signed-off-by: Marcin Galczynski Signed-off-by: Greg Kroah-Hartman commit 6f10f1a521400f591dade45ded73d3573df7778f Author: Sarah Sharp Date: Thu May 12 18:06:37 2011 -0700 xhci: Fix memory leak bug when dropping endpoints commit 834cb0fc4712a3b21c6b8c5cb55bd13607191311 upstream. When the USB core wants to change to an alternate interface setting that doesn't include an active endpoint, or de-configuring the device, the xHCI driver needs to issue a Configure Endpoint command to tell the host to drop some endpoints from the schedule. After the command completes, the xHCI driver needs to free rings for any endpoints that were dropped. Unfortunately, the xHCI driver wasn't actually freeing the endpoint rings for dropped endpoints. The rings would be freed if the endpoint's information was simply changed (and a new ring was installed), but dropped endpoints never had their rings freed. This caused errors when the ring segment DMA pool was freed when the xHCI driver was unloaded: [ 5582.883995] xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff88003371d000 busy [ 5582.884002] xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff880033716000 busy [ 5582.884011] xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff880033455000 busy [ 5582.884018] xhci_hcd 0000:06:00.0: Freed segment pool [ 5582.884026] xhci_hcd 0000:06:00.0: Freed device context pool [ 5582.884033] xhci_hcd 0000:06:00.0: Freed small stream array pool [ 5582.884038] xhci_hcd 0000:06:00.0: Freed medium stream array pool [ 5582.884048] xhci_hcd 0000:06:00.0: xhci_stop completed - status = 1 [ 5582.884061] xhci_hcd 0000:06:00.0: USB bus 3 deregistered [ 5582.884193] xhci_hcd 0000:06:00.0: PCI INT A disabled Fix this issue and free endpoint rings when their endpoints are successfully dropped. This patch should be backported to kernels as old as 2.6.31. Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit a66ccccb5525a5606a2000066889a71e0c8a9867 Author: Sarah Sharp Date: Mon May 16 13:09:08 2011 -0700 xhci: Fix memory leak in ring cache deallocation. commit 30f89ca021c3e584b61bc5a14eede89f74b2e826 upstream. When an endpoint ring is freed, it is either cached in a per-device ring cache, or simply freed if the ring cache is full. If the ring was added to the cache, then virt_dev->num_rings_cached is incremented. The cache is designed to hold up to 31 endpoint rings, in array indexes 0 to 30. When the device is freed (when the slot was disabled), xhci_free_virt_device() is called, it would free the cached rings in array indexes 0 to virt_dev->num_rings_cached. Unfortunately, the original code in xhci_free_or_cache_endpoint_ring() would put the first entry into the ring cache in array index 1, instead of array index 0. This was caused by the second assignment to rings_cached: rings_cached = virt_dev->num_rings_cached; if (rings_cached < XHCI_MAX_RINGS_CACHED) { virt_dev->num_rings_cached++; rings_cached = virt_dev->num_rings_cached; virt_dev->ring_cache[rings_cached] = virt_dev->eps[ep_index].ring; This meant that when the device was freed, cached rings with indexes 0 to N would be freed, and the last cached ring in index N+1 would not be freed. When the driver was unloaded, this caused interesting messages like: xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff880063040000 busy This should be queued to stable kernels back to 2.6.33. Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit b8f653f794ec459132a903c7b7d6aa40bbe5c2a1 Author: Sarah Sharp Date: Fri May 13 13:10:01 2011 -0700 xhci: Fix full speed bInterval encoding. commit b513d44751bfb609a3c20463f764c8ce822d63e9 upstream. Dmitry's patch dfa49c4ad120a784ef1ff0717168aa79f55a483a USB: xhci - fix math in xhci_get_endpoint_interval() introduced a bug. The USB 2.0 spec says that full speed isochronous endpoints' bInterval must be decoded as an exponent to a power of two (e.g. interval = 2^(bInterval - 1)). Full speed interrupt endpoints, on the other hand, don't use exponents, and the interval in frames is encoded straight into bInterval. Dmitry's patch was supposed to fix up the full speed isochronous to parse bInterval as an exponent, but instead it changed the *interrupt* endpoint bInterval decoding. The isochronous endpoint encoding was the same. This caused full speed devices with interrupt endpoints (including mice, hubs, and USB to ethernet devices) to fail under NEC 0.96 xHCI host controllers: [ 100.909818] xhci_hcd 0000:06:00.0: add ep 0x83, slot id 1, new drop flags = 0x0, new add flags = 0x99, new slot info = 0x38100000 [ 100.909821] xhci_hcd 0000:06:00.0: xhci_check_bandwidth called for udev ffff88011f0ea000 ... [ 100.910187] xhci_hcd 0000:06:00.0: ERROR: unexpected command completion code 0x11. [ 100.910190] xhci_hcd 0000:06:00.0: xhci_reset_bandwidth called for udev ffff88011f0ea000 When the interrupt endpoint was added and a Configure Endpoint command was issued to the host, the host controller would return a very odd error message (0x11 means "Slot Not Enabled", which isn't true because the slot was enabled). Probably the host controller was getting very confused with the bad encoding. Signed-off-by: Sarah Sharp Cc: Dmitry Torokhov Reported-by: Thomas Lindroth Tested-by: Thomas Lindroth Signed-off-by: Greg Kroah-Hartman commit ac57b58b06df77d17383f14e87da85ddc5e7c35b Author: Felipe Balbi Date: Fri May 13 16:53:48 2011 +0300 usb: gadget: rndis: don't test against req->length commit 472b91274a6c6857877b5caddb875dcb5ecdfcb8 upstream. composite.c always sets req->length to zero and expects function driver's setup handlers to return the amount of bytes to be used on req->length. If we test against req->length w_length will always be greater than req->length thus making us always stall that particular SEND_ENCAPSULATED_COMMAND request. Tested against a Windows XP SP3. Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 73758f998dc8b4528e031d3428573bb3aef5c77b Author: Jean-Christophe PLAGNIOL-VILLARD Date: Fri May 13 17:03:02 2011 +0200 usb/gadget: at91sam9g20 fix end point max packet size commit bf1f0a05d472e33dda8e5e69525be1584cdbd03a upstream. on 9g20 they are the same as the 9260 Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD Acked-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman commit 0f63996abc2163c56997ade41cb01632a66beb28 Author: Sarah Sharp Date: Thu May 5 19:08:09 2011 -0700 xhci: Fix bug in control transfer cancellation. commit 3abeca998a44205cfd837fa0bf1f7c24f8294acb upstream. When the xHCI driver attempts to cancel a transfer, it issues a Stop Endpoint command and waits for the host controller to indicate which TRB it was in the middle of processing. The host will put an event TRB with completion code COMP_STOP on the event ring if it stops on a control transfer TRB (or other types of transfer TRBs). The ring handling code is supposed to set ep->stopped_trb to the TRB that the host stopped on when this happens. Unfortunately, there is a long-standing bug in the control transfer completion code. It doesn't actually check to see if COMP_STOP is set before attempting to process the transfer based on which part of the control TD completed. So when we get an event on the data phase of the control TRB with COMP_STOP set, it thinks it's a normal completion of the transfer and doesn't set ep->stopped_td or ep->stopped_trb. When the ring handling code goes on to process the completion of the Stop Endpoint command, it sees that ep->stopped_trb is not a part of the TD it's trying to cancel. It thinks the hardware has its enqueue pointer somewhere further up in the ring, and thinks it's safe to turn the control TRBs into no-op TRBs. Since the hardware was in the middle of the control TRBs to be cancelled, the proper software behavior is to issue a Set TR dequeue pointer command. It turns out that the NEC host controllers can handle active TRBs being set to no-op TRBs after a stop endpoint command, but other host controllers have issues with this out-of-spec software behavior. Fix this behavior. This patch should be backported to kernels as far back as 2.6.31, but it may be a bit challenging, since process_ctrl_td() was introduced in some refactoring done in 2.6.36, and some endian-safe patches added in 2.6.40 that touch the same lines. Signed-off-by: Sarah Sharp Cc: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit ed25d77e109b1c90e999e77f51f00b6bf6b75bae Author: Erik Slagter Date: Wed May 11 12:06:55 2011 +0200 USB: cdc_acm: Fix oops when Droids MuIn LCD is connected commit fd5054c169d29747a44b4e1419ff47f57ae82dbc upstream. The Droids MuIn LCD operates like a serial remote terminal. Data received are displayed directly on the LCD. This patch fixes the kernel null pointer oops when it is plugged in. Add NO_DATA_INTERFACE quirk to tell the driver that "control" and "data" interfaces are not separated for this device, which prevents dereferencing a null pointer in the device probe code. Signed-off-by: Erik Slagter Signed-off-by: Maxin B. John Tested-by: Erik Slagter Signed-off-by: Greg Kroah-Hartman commit 33730250bc0b5d432e7fb37e5a95ff77e10e1364 Author: Marius B. Kotsbak Date: Mon Mar 21 23:27:21 2011 +0100 Bind only modem AT command endpoint to option module. commit 15b2f3204a5c878c32939094775fb7349f707263 upstream. Network interface is handled by upcoming gt_b3730 module. Removed "GT-B3710" from comment, it is another modem with another USB ID. Signed-off-by: Marius B. Kotsbak Signed-off-by: Greg Kroah-Hartman commit 1dc080723321b37c5451f381ffad52e4cf52a89d Author: Hermann Kneissel Date: Fri Apr 29 08:58:43 2011 +0200 USB: gamin_gps: Fix for data transfer problems in native mode commit b4026c4584cd70858d4d3450abfb1cd0714d4f32 upstream. This patch fixes a problem where data received from the gps is sometimes transferred incompletely to the serial port. If used in native mode now all data received via the bulk queue will be forwarded to the serial port. Signed-off-by: Hermann Kneissel Signed-off-by: Greg Kroah-Hartman commit 3c9e61a5a06bbcf9be1d015eab2bc928ab619de1 Author: Michal Nazarewicz Date: Tue Apr 26 19:08:36 2011 +0200 USB: gadget: g_multi: fixed vendor and product ID in inf files commit 7701846fd52f86dffe50715e0e63154088b7c982 upstream. Commit 1c6529e92b "USB: gadget: g_multi: fixed vendor and product ID" replaced g_multi's vendor and product ID with proper ID's from Linux Foundation. This commit now updates INF files in the Documentation/usb directory which were omitted in the original commit. Signed-off-by: Michal Nazarewicz Signed-off-by: Greg Kroah-Hartman commit c682a5150e502427f882d063cbd3ad3b497bb558 Author: Benedek László Date: Wed Apr 20 03:22:21 2011 +0200 USB: serial: ftdi_sio: adding support for TavIR STK500 commit 37909fe588c9e09ab57cd267e98678a17ceda64a upstream. Adding support for the TavIR STK500 (id 0403:FA33) Atmel AVR programmer device based on FTDI FT232RL. Signed-off-by: Benedek László Signed-off-by: Greg Kroah-Hartman commit 936798e04ac9246256f7a378786c47b3dc24988b Author: Elizabeth Jennifer Myers Date: Sat Apr 16 14:49:51 2011 -0400 USB: moto_modem: Add USB identifier for the Motorola VE240. commit 3938a0b32dc12229e76735679b37095bc2bc1578 upstream. Tested on my phone, the ttyUSB device is created and is fully functional. Signed-off-by: Elizabeth Jennifer Myers Signed-off-by: Greg Kroah-Hartman commit 6ce06305461d90dbc5b23589127ed1a06f70bb51 Author: Craig Shelley Date: Sun Mar 20 13:51:13 2011 +0000 USB: CP210x Add 4 Device IDs for AC-Services Devices commit 4eff0b40a7174896b860312910e0db51f2dcc567 upstream. This patch adds 4 device IDs for CP2102 based devices manufactured by AC-Services. See http://www.ac-services.eu for further info. Signed-off-by: Craig Shelley Signed-off-by: Greg Kroah-Hartman commit 2617bae63c8a99987a2eb05739bd1ee087167351 Author: Vikram Narayanan Date: Tue May 24 20:58:48 2011 +0200 i2c/writing-clients: Fix foo_driver.id_table commit 3116c86033079a1d4d4e84c40028f96b614843b8 upstream. The i2c_device_id structure variable's name is not used in the i2c_driver structure. Signed-off-by: Vikram Narayanan Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 05ebf3493e8f0b71131a52b3bdc3d2a7e9c1f12b Author: Namhyung Kim Date: Tue May 24 16:48:55 2011 +0200 loop: handle on-demand devices correctly commit a1c15c59feee36267c43142a41152fbf7402afb6 upstream. When finding or allocating a loop device, loop_probe() did not take partition numbers into account so that it can result to a different device. Consider following example: $ sudo modprobe loop max_part=15 $ ls -l /dev/loop* brw-rw---- 1 root disk 7, 0 2011-05-24 22:16 /dev/loop0 brw-rw---- 1 root disk 7, 16 2011-05-24 22:16 /dev/loop1 brw-rw---- 1 root disk 7, 32 2011-05-24 22:16 /dev/loop2 brw-rw---- 1 root disk 7, 48 2011-05-24 22:16 /dev/loop3 brw-rw---- 1 root disk 7, 64 2011-05-24 22:16 /dev/loop4 brw-rw---- 1 root disk 7, 80 2011-05-24 22:16 /dev/loop5 brw-rw---- 1 root disk 7, 96 2011-05-24 22:16 /dev/loop6 brw-rw---- 1 root disk 7, 112 2011-05-24 22:16 /dev/loop7 $ sudo mknod /dev/loop8 b 7 128 $ sudo losetup /dev/loop8 ~/temp/disk-with-3-parts.img $ sudo losetup -a /dev/loop128: [0805]:278201 (/home/namhyung/temp/disk-with-3-parts.img) $ ls -l /dev/loop* brw-rw---- 1 root disk 7, 0 2011-05-24 22:16 /dev/loop0 brw-rw---- 1 root disk 7, 16 2011-05-24 22:16 /dev/loop1 brw-rw---- 1 root disk 7, 2048 2011-05-24 22:18 /dev/loop128 brw-rw---- 1 root disk 7, 2049 2011-05-24 22:18 /dev/loop128p1 brw-rw---- 1 root disk 7, 2050 2011-05-24 22:18 /dev/loop128p2 brw-rw---- 1 root disk 7, 2051 2011-05-24 22:18 /dev/loop128p3 brw-rw---- 1 root disk 7, 32 2011-05-24 22:16 /dev/loop2 brw-rw---- 1 root disk 7, 48 2011-05-24 22:16 /dev/loop3 brw-rw---- 1 root disk 7, 64 2011-05-24 22:16 /dev/loop4 brw-rw---- 1 root disk 7, 80 2011-05-24 22:16 /dev/loop5 brw-rw---- 1 root disk 7, 96 2011-05-24 22:16 /dev/loop6 brw-rw---- 1 root disk 7, 112 2011-05-24 22:16 /dev/loop7 brw-r--r-- 1 root root 7, 128 2011-05-24 22:17 /dev/loop8 After this patch, /dev/loop8 - instead of /dev/loop128 - was accessed correctly. In addition, 'range' passed to blk_register_region() should include all range of dev_t that LOOP_MAJOR can address. It does not need to be limited by partition numbers unless 'max_loop' param was specified. Signed-off-by: Namhyung Kim Cc: Laurent Vivier Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit c439bb66b6dd6a03511246efcc864fa635bda644 Author: Namhyung Kim Date: Tue May 24 16:48:54 2011 +0200 loop: limit 'max_part' module param to DISK_MAX_PARTS commit 78f4bb367fd147a0e7e3998ba6e47109999d8814 upstream. The 'max_part' parameter controls the number of maximum partition a loop block device can have. However if a user specifies very large value it would exceed the limitation of device minor number and can cause a kernel panic (or, at least, produce invalid device nodes in some cases). On my desktop system, following command kills the kernel. On qemu, it triggers similar oops but the kernel was alive: $ sudo modprobe loop max_part0000 ------------[ cut here ]------------ kernel BUG at /media/Linux_Data/project/linux/fs/sysfs/group.c:65! invalid opcode: 0000 [#1] SMP last sysfs file: CPU 0 Modules linked in: loop(+) Pid: 43, comm: insmod Tainted: G W 2.6.39-qemu+ #155 Bochs Bochs RIP: 0010:[] [] internal_create_group= +0x2a/0x170 RSP: 0018:ffff880007b3fde8 EFLAGS: 00000246 RAX: 00000000ffffffef RBX: ffff880007b3d878 RCX: 00000000000007b4 RDX: ffffffff8152da50 RSI: 0000000000000000 RDI: ffff880007b3d878 RBP: ffff880007b3fe38 R08: ffff880007b3fde8 R09: 0000000000000000 R10: ffff88000783b4a8 R11: ffff880007b3d878 R12: ffffffff8152da50 R13: ffff880007b3d868 R14: 0000000000000000 R15: ffff880007b3d800 FS: 0000000002137880(0063) GS:ffff880007c00000(0000) knlGS:00000000000000= 00 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000422680 CR3: 0000000007b50000 CR4: 00000000000006b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000 Process insmod (pid: 43, threadinfo ffff880007b3e000, task ffff880007afb9c= 0) Stack: ffff880007b3fe58 ffffffff811e66dd ffff880007b3fe58 ffffffff811e570b 0000000000000010 ffff880007b3d800 ffff880007a7b390 ffff880007b3d868 0000000000400920 ffff880007b3d800 ffff880007b3fe48 ffffffff8113cfc8 Call Trace: [] ? device_add+0x4bc/0x5af [] ? dev_set_name+0x3c/0x3e [] sysfs_create_group+0xe/0x12 [] blk_trace_init_sysfs+0x14/0x16 [] blk_register_queue+0x47/0xf7 [] add_disk+0xdf/0x290 [] loop_init+0xeb/0x1b8 [loop] [] ? 0xffffffffa0005fff [] do_one_initcall+0x7a/0x12e [] sys_init_module+0x9c/0x1e0 [] system_call_fastpath+0x16/0x1b Code: c3 55 48 89 e5 41 57 41 56 41 89 f6 41 55 41 54 49 89 d4 53 48 89 fb= 48 83 ec 28 48 85 ff 74 0b 85 f6 75 0b 48 83 7f 30 00 75 14 <0f> 0b eb fe = 48 83 7f 30 00 b9 ea ff ff ff 0f 84 18 01 00 00 49 RIP [] internal_create_group+0x2a/0x170 RSP ---[ end trace a123eb592043acad ]--- Signed-off-by: Namhyung Kim Cc: Laurent Vivier Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit cb29ff4edcd40f96be17b153c07eb1578f834fdf Author: Andrew Barry Date: Tue May 24 17:12:52 2011 -0700 mm/page_alloc.c: prevent unending loop in __alloc_pages_slowpath() commit cfa54a0fcfc1017c6f122b6f21aaba36daa07f71 upstream. I believe I found a problem in __alloc_pages_slowpath, which allows a process to get stuck endlessly looping, even when lots of memory is available. Running an I/O and memory intensive stress-test I see a 0-order page allocation with __GFP_IO and __GFP_WAIT, running on a system with very little free memory. Right about the same time that the stress-test gets killed by the OOM-killer, the utility trying to allocate memory gets stuck in __alloc_pages_slowpath even though most of the systems memory was freed by the oom-kill of the stress-test. The utility ends up looping from the rebalance label down through the wait_iff_congested continiously. Because order=0, __alloc_pages_direct_compact skips the call to get_page_from_freelist. Because all of the reclaimable memory on the system has already been reclaimed, __alloc_pages_direct_reclaim skips the call to get_page_from_freelist. Since there is no __GFP_FS flag, the block with __alloc_pages_may_oom is skipped. The loop hits the wait_iff_congested, then jumps back to rebalance without ever trying to get_page_from_freelist. This loop repeats infinitely. The test case is pretty pathological. Running a mix of I/O stress-tests that do a lot of fork() and consume all of the system memory, I can pretty reliably hit this on 600 nodes, in about 12 hours. 32GB/node. Signed-off-by: Andrew Barry Signed-off-by: Minchan Kim Reviewed-by: Rik van Riel Acked-by: Mel Gorman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 29dd7782519b0d07f1113f91c2d7a4f51167d88b Author: Jiri Kosina Date: Thu May 19 17:58:07 2011 +0200 HID: magicmouse: ignore 'ivalid report id' while switching modes commit 23746a66d7d9e73402c68ef00d708796b97ebd72 upstream. The device reponds with 'invalid report id' when feature report switching it into multitouch mode is sent to it. This has been silently ignored before 0825411ade ("HID: bt: Wait for ACK on Sent Reports"), but since this commit, it propagates -EIO from the _raw callback . So let the driver ignore -EIO as response to 0xd7,0x01 report, as that's how the device reacts in normal mode. Sad, but following reality. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=35022 Tested-by: Chase Douglas Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit a73155a0ff2253fd51f58f055ed1bf99a8ccfb21 Author: Mark Brown Date: Sun May 15 12:18:38 2011 -0700 ASoC: Add some missing volume update bit sets for wm_hubs devices commit fb5af53d421d80725172427e9076f6e889603df6 upstream. Signed-off-by: Mark Brown Acked-by: Liam Girdwood Signed-off-by: Greg Kroah-Hartman commit b46f2b345b5fccbc63f7454fbdc912377f027e48 Author: Mark Brown Date: Sat May 14 17:21:28 2011 -0700 ASoC: Ensure output PGA is enabled for line outputs in wm_hubs commit d0b48af6c2b887354d0893e598d92911ce52620e upstream. Also fix a left/right typo while we're at it. Signed-off-by: Mark Brown Acked-by: Liam Girdwood Signed-off-by: Greg Kroah-Hartman commit a1dadcf089c94dfc26986f3f801b1ee8ee9ed48d Author: Takashi Iwai Date: Fri May 20 16:29:09 2011 +0200 ALSA: hda - Use LPIB for ATI/AMD chipsets as default commit 50e3bbf9898840eead86f90a43b3625a2b2f4112 upstream. ATI and AMD chipsets seem not providing the proper position-buffer information, and it also doesn't provide FIFO register required by VIACOMBO fix. It's better to use LPIB for these. Reported-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d5f550c4d9eb10ae1895f837e5dbd0ae6890591d Author: Adrian Wilkins Date: Thu May 19 21:52:38 2011 +0100 ALSA: hda - Fix input-src parse in patch_analog.c commit 5a2d227fdc7a02ed1b4cebba391d8fb9ad57caaf upstream. Compare pin type enum to the pin type and not the array index. Fixes bug#0005368. Signed-off-by: Adrian Wilkins Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f130d60035bb0aedf1c9ba7a536a290a2412ee15 Author: David Henningsson Date: Mon May 23 08:26:16 2011 +0200 ALSA: HDA: Add quirk for Lenovo U350 commit d2859fd49200f1f3efd8acdb54b6d51d3ab82302 upstream. Add model=asus quirk for Lenovo Ideapad U350 to make internal mic work correctly. BugLink: http://bugs.launchpad.net/bugs/751681 Reported-by: Kent Baxley Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 5899dde6559c06d81895416c6d962b02d6c8f241 Author: David Henningsson Date: Mon May 16 12:09:29 2011 +0200 ALSA: HDA: Use one dmic only for Dell Studio 1558 commit e033ebfb399227e01686260ac271029011bc6b47 upstream. There are no signs of a dmic at node 0x0b, so the user is left with an additional internal mic which does not exist. This commit removes that non-existing mic. BugLink: http://bugs.launchpad.net/bugs/731706 Reported-by: James Page Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f6172a0875387c008bebf0fde0bd64ecc0709fe1 Author: Jesse Barnes Date: Mon Mar 28 06:36:30 2011 -0400 ips: use interruptible waits in ips-monitor commit a3424216e4935221fdaa5ca3c26e024f11297164 upstream. This is what I intended to do since: 1) the driver handles variable waits just fine, and 2) interruptible waits aren't reported as load in the load avg. Reported-and-tested-by: Andreas Hartmann Signed-off-by: Jesse Barnes Signed-off-by: Matthew Garrett Cc: Leann Ogasawara Signed-off-by: Greg Kroah-Hartman commit 2020aa625c559d371518040290b5476356e7aacf Author: Minchan Kim Date: Tue May 24 17:11:11 2011 -0700 mm: vmscan: correctly check if reclaimer should schedule during shrink_slab commit f06590bd718ed950c98828e30ef93204028f3210 upstream. It has been reported on some laptops that kswapd is consuming large amounts of CPU and not being scheduled when SLUB is enabled during large amounts of file copying. It is expected that this is due to kswapd missing every cond_resched() point because; shrink_page_list() calls cond_resched() if inactive pages were isolated which in turn may not happen if all_unreclaimable is set in shrink_zones(). If for whatver reason, all_unreclaimable is set on all zones, we can miss calling cond_resched(). balance_pgdat() only calls cond_resched if the zones are not balanced. For a high-order allocation that is balanced, it checks order-0 again. During that window, order-0 might have become unbalanced so it loops again for order-0 and returns that it was reclaiming for order-0 to kswapd(). It can then find that a caller has rewoken kswapd for a high-order and re-enters balance_pgdat() without ever calling cond_resched(). shrink_slab only calls cond_resched() if we are reclaiming slab pages. If there are a large number of direct reclaimers, the shrinker_rwsem can be contended and prevent kswapd calling cond_resched(). This patch modifies the shrink_slab() case. If the semaphore is contended, the caller will still check cond_resched(). After each successful call into a shrinker, the check for cond_resched() remains in case one shrinker is particularly slow. [mgorman@suse.de: preserve call to cond_resched after each call into shrinker] Signed-off-by: Mel Gorman Signed-off-by: Minchan Kim Cc: Rik van Riel Cc: Johannes Weiner Cc: Wu Fengguang Cc: James Bottomley Tested-by: Colin King Cc: Raghavendra D Prabhu Cc: Jan Kara Cc: Chris Mason Cc: Christoph Lameter Cc: Pekka Enberg Cc: Rik van Riel Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 28663b64187171a869bf991b20e3dc24f88067d4 Author: Johannes Weiner Date: Tue May 24 17:11:09 2011 -0700 mm: vmscan: correct use of pgdat_balanced in sleeping_prematurely commit afc7e326a3f5bafc41324d7926c324414e343ee5 upstream. There are a few reports of people experiencing hangs when copying large amounts of data with kswapd using a large amount of CPU which appear to be due to recent reclaim changes. SLUB using high orders is the trigger but not the root cause as SLUB has been using high orders for a while. The root cause was bugs introduced into reclaim which are addressed by the following two patches. Patch 1 corrects logic introduced by commit 1741c877 ("mm: kswapd: keep kswapd awake for high-order allocations until a percentage of the node is balanced") to allow kswapd to go to sleep when balanced for high orders. Patch 2 notes that it is possible for kswapd to miss every cond_resched() and updates shrink_slab() so it'll at least reach that scheduling point. Chris Wood reports that these two patches in isolation are sufficient to prevent the system hanging. AFAIK, they should also resolve similar hangs experienced by James Bottomley. This patch: Johannes Weiner poined out that the logic in commit 1741c877 ("mm: kswapd: keep kswapd awake for high-order allocations until a percentage of the node is balanced") is backwards. Instead of allowing kswapd to go to sleep when balancing for high order allocations, it keeps it kswapd running uselessly. Signed-off-by: Mel Gorman Reviewed-by: Rik van Riel Signed-off-by: Johannes Weiner Reviewed-by: Wu Fengguang Cc: James Bottomley Tested-by: Colin King Cc: Raghavendra D Prabhu Cc: Jan Kara Cc: Chris Mason Cc: Christoph Lameter Cc: Pekka Enberg Cc: Rik van Riel Reviewed-by: Minchan Kim Reviewed-by: Wu Fengguang Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 2fdcf29a363c69ec1937b0b1a402622bd99fabeb Author: NeilBrown Date: Wed May 11 14:26:30 2011 +1000 md/bitmap: fix saving of events_cleared and other state. commit 8258c53208d7a9b7207e7d4dae36d2ea384cb278 upstream. If a bitmap is found to be 'stale' the events_cleared value is set to match 'events'. However if the array is degraded this does not get stored on disk. This can subsequently lead to incorrect behaviour. So change bitmap_update_sb to always update events_cleared in the superblock from the known events_cleared. For neatness also set ->state from ->flags. This requires updating ->state whenever we update ->flags, which makes sense anyway. This is suitable for any active -stable release. Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit ff7c37c2f964d7e1f14966b3a1e5532705c7adee Author: NeilBrown Date: Tue May 10 17:49:01 2011 +1000 md: Fix race when creating a new md device. commit b0140891a8cea36469f58d23859e599b1122bd37 upstream. There is a race when creating an md device by opening /dev/mdXX. If two processes do this at much the same time they will follow the call path __blkdev_get -> get_gendisk -> kobj_lookup The first will call -> md_probe -> md_alloc -> add_disk -> blk_register_region and the race happens when the second gets to kobj_lookup after add_disk has called blk_register_region but before it returns to md_alloc. In the case the second will not call md_probe (as the probe is already done) but will get a handle on the gendisk, return to __blkdev_get which will then call md_open (via the ->open) pointer. As mddev->gendisk hasn't been set yet, md_open will think something is wrong an return with ERESTARTSYS. This can loop endlessly while the first thread makes no progress through add_disk. Nothing is blocking it, but due to scheduler behaviour it doesn't get a turn. So this is essentially a live-lock. We fix this by simply moving the assignment to mddev->gendisk before the call the add_disk() so md_open doesn't get confused. Also move blk_queue_flush earlier because add_disk should be as late as possible. To make sure that md_open doesn't complete until md_alloc has done all that is needed, we take mddev->open_mutex during the last part of md_alloc. md_open will wait for this. This can cause a lock-up on boot so Cc:ing for stable. For 2.6.36 and earlier a different patch will be needed as the 'blk_queue_flush' call isn't there. Signed-off-by: NeilBrown Reported-by: Thomas Jarosch Tested-by: Thomas Jarosch Signed-off-by: Greg Kroah-Hartman commit 8a5167a5fc4e06cc1b4281eff1b3f884003bb7e2 Author: Milton Miller Date: Thu May 12 04:13:54 2011 -0500 seqlock: Don't smp_rmb in seqlock reader spin loop commit 5db1256a5131d3b133946fa02ac9770a784e6eb2 upstream. Move the smp_rmb after cpu_relax loop in read_seqlock and add ACCESS_ONCE to make sure the test and return are consistent. A multi-threaded core in the lab didn't like the update from 2.6.35 to 2.6.36, to the point it would hang during boot when multiple threads were active. Bisection showed af5ab277ded04bd9bc6b048c5a2f0e7d70ef0867 (clockevents: Remove the per cpu tick skew) as the culprit and it is supported with stack traces showing xtime_lock waits including tick_do_update_jiffies64 and/or update_vsyscall. Experimentation showed the combination of cpu_relax and smp_rmb was significantly slowing the progress of other threads sharing the core, and this patch is effective in avoiding the hang. A theory is the rmb is affecting the whole core while the cpu_relax is causing a resource rebalance flush, together they cause an interfernce cadance that is unbroken when the seqlock reader has interrupts disabled. At first I was confused why the refactor in 3c22cd5709e8143444a6d08682a87f4c57902df3 (kernel: optimise seqlock) didn't affect this patch application, but after some study that affected seqcount not seqlock. The new seqcount was not factored back into the seqlock. I defer that the future. While the removal of the timer interrupt offset created contention for the xtime lock while a cpu does the additonal work to update the system clock, the seqlock implementation with the tight rmb spin loop goes back much further, and is just waiting for the right trigger. Signed-off-by: Milton Miller Cc: Cc: Linus Torvalds Cc: Andi Kleen Cc: Nick Piggin Cc: Benjamin Herrenschmidt Cc: Anton Blanchard Cc: Paul McKenney Acked-by: Eric Dumazet Link: http://lkml.kernel.org/r/%3Cseqlock-rmb%40mdm.bga.com%3E Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 2f026bcd6c57ca6cae4032fd0748abf6fd24c19c Author: Timo Warns Date: Thu May 19 09:24:17 2011 +0200 Fix for buffer overflow in ldm_frag_add not sufficient commit cae13fe4cc3f24820ffb990c09110626837e85d4 upstream. As Ben Hutchings discovered [1], the patch for CVE-2011-1017 (buffer overflow in ldm_frag_add) is not sufficient. The original patch in commit c340b1d64000 ("fs/partitions/ldm.c: fix oops caused by corrupted partition table") does not consider that, for subsequent fragments, previously allocated memory is used. [1] http://lkml.org/lkml/2011/5/6/407 Reported-by: Ben Hutchings Signed-off-by: Timo Warns Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ea1e05a4044e3ef488ee43098f89b4a34c034837 Author: Jeff Chua Date: Wed Apr 27 11:25:14 2011 -0500 staging: r8712u: Fix driver to support ad-hoc mode commit 62819fd9481021db7f87d5f61f2e2fd2be1dfcfa upstream. Driver r8712u is unable to handle ad-hoc mode. The issue is that when the driver first starts, there will not be an SSID for association. The fix is to always call the "select and join from scan" routine when in ad-hoc mode. Note: Ad-hoc mode worked intermittently before. If the driver had previously been associated, then things were OK. Signed-off-by: Jeff Chua Signed-off-by: Larry Finger Signed-off-by: Greg Kroah-Hartman commit 1063a9dec1316a46e264d7a86059ee6c7af09a26 Author: David Chang Date: Thu May 12 18:31:11 2011 +0800 staging: usbip: fix wrong endian conversion commit cacd18a8476ce145ca5dcd46dc5b75585fd1289c upstream. Fix number_of_packets wrong endian conversion in function correct_endian_ret_submit() Signed-off-by: David Chang Acked-by: Arjan Mels Signed-off-by: Greg Kroah-Hartman commit f1ed16123ae7b2b87b20d9bf60d179f635dba3d5 Author: Steve French Date: Thu May 26 18:38:54 2011 +0000 When mandatory encryption on share, fail mount commit 6848b7334b24b47aa3d0e70342ff839ffa95d5fa upstream. When mandatory encryption is configured in samba server on a share (smb.conf parameter "smb encrypt = mandatory") the server will hang up the tcp session when we try to send the first frame after the tree connect if it is not a QueryFSUnixInfo, this causes cifs mount to hang (it must be killed with ctl-c). Move the QueryFSUnixInfo call earlier in the mount sequence, and check whether the SetFSUnixInfo fails due to mandatory encryption so we can return a sensible error (EACCES) on mount. In a future patch (for 2.6.40) we will support mandatory encryption. Reviewed-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 8574041ad2ecac425ea510f2db86eeed27a6decb Author: Frederic Weisbecker Date: Fri May 20 02:09:54 2011 +0200 rcu: Fix unpaired rcu_irq_enter() from locking selftests commit ba9f207c9f82115aba4ce04b22e0081af0ae300f upstream. HARDIRQ_ENTER() maps to irq_enter() which calls rcu_irq_enter(). But HARDIRQ_EXIT() maps to __irq_exit() which doesn't call rcu_irq_exit(). So for every locking selftest that simulates hardirq disabled, we create an imbalance in the rcu extended quiescent state internal state. As a result, after the first missing rcu_irq_exit(), subsequent irqs won't exit dyntick-idle mode after leaving the interrupt handler. This means that RCU won't see the affected CPU as being in an extended quiescent state, resulting in long grace-period delays (as in grace periods extending for hours). To fix this, just use __irq_enter() to simulate the hardirq context. This is sufficient for the locking selftests as we don't need to exit any extended quiescent state or perform any check that irqs normally do when they wake up from idle. As a side effect, this patch makes it possible to restore "rcu: Decrease memory-barrier usage based on semi-formal proof", which eventually helped finding this bug. Reported-and-tested-by: Yinghai Lu Signed-off-by: Frederic Weisbecker Cc: Paul E. McKenney Cc: Ingo Molnar Cc: Peter Zijlstra