commit 60584ef99395a89d136399bbc127289a4aa29dc7 Author: Greg Kroah-Hartman Date: Mon May 2 09:30:53 2011 -0700 Linux 2.6.38.5 commit 80ac2fd6758b75a1f1db112821635e3411185073 Author: Igor Mammedov Date: Mon Apr 18 10:17:17 2011 -0700 Input: xen-kbdfront - fix mouse getting stuck after save/restore commit c36b58e8a9112017c2bcc322cc98e71241814303 upstream. Mouse gets "stuck" after restore of PV guest but buttons are in working condition. If driver has been configured for ABS coordinates at start it will get XENKBD_TYPE_POS events and then suddenly after restore it'll start getting XENKBD_TYPE_MOTION events, that will be dropped later and they won't get into user-space. Regression was introduced by hunk 5 and 6 of 5ea5254aa0ad269cfbd2875c973ef25ab5b5e9db ("Input: xen-kbdfront - advertise either absolute or relative coordinates"). Driver on restore should ask xen for request-abs-pointer again if it is available. So restore parts that did it before 5ea5254. Acked-by: Olaf Hering Signed-off-by: Igor Mammedov [v1: Expanded the commit description] Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Dmitry Torokhov commit 9ec3e481f696880fd11e24ff54da6252d3d1a986 Author: Stanislaw Gruszka Date: Wed Apr 13 10:56:51 2011 +0200 iwlegacy: fix tx_power initialization commit 332704a51498a7e29aa92c19dc03f11f80b71bfe upstream. priv->tx_power_next is not initialized to max supported power, but instead default value is used, what cause errors like [ 58.597834] iwl3945 0000:03:00.0: Requested user TXPOWER 15 above upper limit 14. [ 58.597839] iwl3945 0000:03:00.0: Error setting Tx power (-22). if maximum tx power read from the eeprom is smaller than default. In consequence card is unable to initialize properly. Fix the problem and cleanup tx power initialization. Reported-and-tested-by: Robin Dong Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit f8317705c4db3eaa68c9a9a7dd7dfc321f8057f3 Author: Stanislaw Gruszka Date: Tue Mar 29 11:24:21 2011 +0200 iwl3945: disable hw scan by default commit 0263aa45293838b514b8af674a03faf040991a90 upstream. After new NetworkManager 0.8.996 changes, hardware scanning is causing microcode errors as reported here: https://bugzilla.redhat.com/show_bug.cgi?id=683571 and sometimes kernel crashes: https://bugzilla.redhat.com/show_bug.cgi?id=688252 Also with hw scan there are very bad performance on some systems as reported here: https://bugzilla.redhat.com/show_bug.cgi?id=671366 Since Intel no longer supports 3945, there is no chance to get proper firmware fixes, we need workaround problems by disable hardware scanning by default. Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 87cb0add07ea816857eda33c70e274b2ec17bb2e Author: Stanislaw Gruszka Date: Mon Mar 14 14:15:06 2011 +0100 iwl3945: do not deprecate software scan commit 3bda50e3eaf58a4b9c4ce34204e5faa15c8b1b97 upstream. Software scanning can be used for workaround some performance problems, so do not deprecate it. Signed-off-by: Stanislaw Gruszka Acked-by: Wey-Yi Guy Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 21db55a9dc4e52d8d2cac30f47efcec3afccb0c5 Author: Stanislaw Gruszka Date: Fri Jan 28 16:47:44 2011 +0100 iwlwifi: do not set tx power when channel is changing commit f844a709a7d8f8be61a571afc31dfaca9e779621 upstream. Mac80211 can request for tx power and channel change in one ->config call. If that happens, *_send_tx_power functions will try to setup tx power for old channel, what can be not correct because we already change the band. I.e error "Failed to get channel info for channel 140 [0]", can be printed frequently when operating in software scanning mode. Signed-off-by: Stanislaw Gruszka Acked-by: Wey-Yi Guy Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 767a7e6906bd2b31c14bd57df8834da0cc81606e Author: Vasiliy Kulikov Date: Thu Apr 14 20:55:19 2011 +0400 agp: fix OOM and buffer overflow commit b522f02184b413955f3bc952e3776ce41edc6355 upstream. page_count is copied from userspace. agp_allocate_memory() tries to check whether this number is too big, but doesn't take into account the wrap case. Also agp_create_user_memory() doesn't check whether alloc_size is calculated from num_agp_pages variable without overflow. This may lead to allocation of too small buffer with following buffer overflow. Another problem in agp code is not addressed in the patch - kernel memory exhaustion (AGPIOC_RESERVE and AGPIOC_ALLOCATE ioctls). It is not checked whether requested pid is a pid of the caller (no check in agpioc_reserve_wrap()). Each allocation is limited to 16KB, though, there is no per-process limit. This might lead to OOM situation, which is not even solved in case of the caller death by OOM killer - the memory is allocated for another (faked) process. Signed-off-by: Vasiliy Kulikov Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 0b7c6323a28f3fde67a26bc6b2a889d3f23b12c3 Author: Vasiliy Kulikov Date: Thu Apr 14 20:55:16 2011 +0400 agp: fix arbitrary kernel memory writes commit 194b3da873fd334ef183806db751473512af29ce upstream. pg_start is copied from userspace on AGPIOC_BIND and AGPIOC_UNBIND ioctl cmds of agp_ioctl() and passed to agpioc_bind_wrap(). As said in the comment, (pg_start + mem->page_count) may wrap in case of AGPIOC_BIND, and it is not checked at all in case of AGPIOC_UNBIND. As a result, user with sufficient privileges (usually "video" group) may generate either local DoS or privilege escalation. Signed-off-by: Vasiliy Kulikov Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit f0578c398d86a9d69ef59765e55b9b56cbafb93e Author: Dave Airlie Date: Fri Apr 22 07:51:33 2011 +1000 drm: select FRAMEBUFFER_CONSOLE_PRIMARY if we have FRAMEBUFFER_CONSOLE commit bf5192edcbc1f0a7f9c054649dbf1a0b3210d9b7 upstream. Multi-gpu/switcheroo relies on this option to get the console on the correct GPU at bootup, some distros enable it but it seems some get it wrong. Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 85b79c0b5b206bc9d1f5279d007d4845ad0e03a5 Author: Richard Weinberger Date: Wed Apr 27 15:26:51 2011 -0700 um: mdd support for 64 bit atomic operations commit 57d8e02e3cd21bccf2b84b26b42feb79e1f0f83e upstream. This adds support for 64 bit atomic operations on 32 bit UML systems. XFS needs them since 2.6.38. $ make ARCH=um SUBARCH=i386 ... LD .tmp_vmlinux1 fs/built-in.o: In function `xlog_regrant_reserve_log_space': xfs_log.c:(.text+0xd8584): undefined reference to `atomic64_read_386' xfs_log.c:(.text+0xd85ac): undefined reference to `cmpxchg8b_emu' ... Addresses https://bugzilla.kernel.org/show_bug.cgi?id=32812 Reported-by: Martin Walch Tested-by: Martin Walch Cc: Martin Walch Signed-off-by: Richard Weinberger Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 20857f111ec4c3e5aea039c5c06d5254aeeb620c Author: Trond Myklebust Date: Fri Apr 15 17:34:18 2011 -0400 NFSv4.1: Ensure state manager thread dies on last umount commit 47c2199b6eb5fbe38ddb844db7cdbd914d304f9c upstream. Currently, the state manager may continue to try recovering state forever even after the last filesystem to reference that nfs_client has umounted. Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 558cc1035db8ac0a510b4582f5354de1510224d6 Author: Jeff Layton Date: Wed Apr 27 11:49:09 2011 -0400 nfs: don't lose MS_SYNCHRONOUS on remount of noac mount commit 26c4c170731f00008f4317a2888a0a07ac99d90d upstream. On a remount, the VFS layer will clear the MS_SYNCHRONOUS bit on the assumption that the flags on the mount syscall will have it set if the remounted fs is supposed to keep it. In the case of "noac" though, MS_SYNCHRONOUS is implied. A remount of such a mount will lose the MS_SYNCHRONOUS flag since "sync" isn't part of the mount options. Reported-by: Max Matveev Signed-off-by: Jeff Layton Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 146129d6d999532951565a0c25bc98e724b1b07e Author: Andrew Morton Date: Wed Apr 27 15:26:41 2011 -0700 vfs: avoid large kmalloc()s for the fdtable commit 6d4831c283530a5f2c6bd8172c13efa236eb149d upstream. Azurit reports large increases in system time after 2.6.36 when running Apache. It was bisected down to a892e2d7dcdfa6c76e6 ("vfs: use kmalloc() to allocate fdmem if possible"). That patch caused the vfs to use kmalloc() for very large allocations and this is causing excessive work (and presumably excessive reclaim) within the page allocator. Fix it by falling back to vmalloc() earlier - when the allocation attempt would have been considered "costly" by reclaim. Reported-by: azurIt Tested-by: azurIt Acked-by: Changli Gao Cc: Americo Wang Cc: Jiri Slaby Acked-by: Eric Dumazet Cc: Mel Gorman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 8858587af25efc06d5cce42676786b3d7a9160f2 Author: Michael Schmitz Date: Tue Apr 26 14:51:53 2011 +1200 m68k/mm: Set all online nodes in N_NORMAL_MEMORY commit 4aac0b4815ba592052758f4b468f253d383dc9d6 upstream. For m68k, N_NORMAL_MEMORY represents all nodes that have present memory since it does not support HIGHMEM. This patch sets the bit at the time node_present_pages has been set by free_area_init_node. At the time the node is brought online, the node state would have to be done unconditionally since information about present memory has not yet been recorded. If N_NORMAL_MEMORY is not accurate, slub may encounter errors since it uses this nodemask to setup per-cache kmem_cache_node data structures. This pach is an alternative to the one proposed by David Rientjes attempting to set node state immediately when bringing the node online. Signed-off-by: Michael Schmitz Tested-by: Thorsten Glaser Signed-off-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman commit 28785447dc596d0612513010e7bb23cce9c88e50 Author: Andrea Arcangeli Date: Wed Apr 27 15:26:45 2011 -0700 mm: thp: fix /dev/zero MAP_PRIVATE and vm_flags cleanups commit 78f11a255749d09025f54d4e2df4fbcb031530e2 upstream. The huge_memory.c THP page fault was allowed to run if vm_ops was null (which would succeed for /dev/zero MAP_PRIVATE, as the f_op->mmap wouldn't setup a special vma->vm_ops and it would fallback to regular anonymous memory) but other THP logics weren't fully activated for vmas with vm_file not NULL (/dev/zero has a not NULL vma->vm_file). So this removes the vm_file checks so that /dev/zero also can safely use THP (the other albeit safer approach to fix this bug would have been to prevent the THP initial page fault to run if vm_file was set). After removing the vm_file checks, this also makes huge_memory.c stricter in khugepaged for the DEBUG_VM=y case. It doesn't replace the vm_file check with a is_pfn_mapping check (but it keeps checking for VM_PFNMAP under VM_BUG_ON) because for a is_cow_mapping() mapping VM_PFNMAP should only be allowed to exist before the first page fault, and in turn when vma->anon_vma is null (so preventing khugepaged registration). So I tend to think the previous comment saying if vm_file was set, VM_PFNMAP might have been set and we could still be registered in khugepaged (despite anon_vma was not NULL to be registered in khugepaged) was too paranoid. The is_linear_pfn_mapping check is also I think superfluous (as described by comment) but under DEBUG_VM it is safe to stay. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=33682 Signed-off-by: Andrea Arcangeli Reported-by: Caspar Zhang Acked-by: Mel Gorman Acked-by: Rik van Riel Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 649717e59e69038212d8e28bfa5fb66bfddb9dea Author: Mel Gorman Date: Wed Apr 27 15:26:56 2011 -0700 mm: check if PTE is already allocated during page fault commit cc03638df20acbec5d0d0d9e07234aadde9e698d upstream. With transparent hugepage support, handle_mm_fault() has to be careful that a normal PMD has been established before handling a PTE fault. To achieve this, it used __pte_alloc() directly instead of pte_alloc_map as pte_alloc_map is unsafe to run against a huge PMD. pte_offset_map() is called once it is known the PMD is safe. pte_alloc_map() is smart enough to check if a PTE is already present before calling __pte_alloc but this check was lost. As a consequence, PTEs may be allocated unnecessarily and the page table lock taken. Thi useless PTE does get cleaned up but it's a performance hit which is visible in page_test from aim9. This patch simply re-adds the check normally done by pte_alloc_map to check if the PTE needs to be allocated before taking the page table lock. The effect is noticable in page_test from aim9. AIM9 2.6.38-vanilla 2.6.38-checkptenone creat-clo 446.10 ( 0.00%) 424.47 (-5.10%) page_test 38.10 ( 0.00%) 42.04 ( 9.37%) brk_test 52.45 ( 0.00%) 51.57 (-1.71%) exec_test 382.00 ( 0.00%) 456.90 (16.39%) fork_test 60.11 ( 0.00%) 67.79 (11.34%) MMTests Statistics: duration Total Elapsed Time (seconds) 611.90 612.22 (While this affects 2.6.38, it is a performance rather than a functional bug and normally outside the rules -stable. While the big performance differences are to a microbench, the difference in fork and exec performance may be significant enough that -stable wants to consider the patch) Reported-by: Raz Ben Yehuda Signed-off-by: Mel Gorman Reviewed-by: Rik van Riel Reviewed-by: Andrea Arcangeli Reviewed-by: Minchan Kim Acked-by: Johannes Weiner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3ae700492f0839d01ece23c32e9827b05c29a0a2 Author: KOSAKI Motohiro Date: Wed Apr 27 15:26:50 2011 -0700 oom: use pte pages in OOM score commit f755a042d82b51b54f3bdd0890e5ea56c0fb6807 upstream. PTE pages eat up memory just like anything else, but we do not account for them in any way in the OOM scores. They are also _guaranteed_ to get freed up when a process is OOM killed, while RSS is not. Reported-by: Dave Hansen Signed-off-by: KOSAKI Motohiro Cc: Hugh Dickins Cc: KAMEZAWA Hiroyuki Cc: Oleg Nesterov Acked-by: David Rientjes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 960b9affa8645e9cfe669295f05a8cd9b8fe77a0 Author: Amit Shah Date: Mon Mar 14 17:45:48 2011 +0530 virtio: console: Enable call to hvc_remove() on console port remove commit afa2689e19073cd2e762d0f2c1358fab1ab9f18c upstream. This call was disabled as hot-unplugging one virtconsole port led to another virtconsole port freezing. Upon testing it again, this now works, so enable it. In addition, a bug was found in qemu wherein removing a port of one type caused the guest output from another port to stop working. I doubt it was just this bug that caused it (since disabling the hvc_remove() call did allow other ports to continue working), but since it's all solved now, we're fine with hot-unplugging of virtconsole ports. Signed-off-by: Amit Shah Signed-off-by: Rusty Russell Signed-off-by: Greg Kroah-Hartman commit 725bb43507cf71e2f48ec929403abe60c35254e8 Author: Patrick Boettcher Date: Sun Apr 3 12:40:24 2011 -0300 FLEXCOP-PCI: fix __xlate_proc_name-warning for flexcop-pci commit b934c20de1398d4a82d2ecfeb588a214a910f13f upstream. This patch fixes the warning about bad names for sys-fs and other kernel-things. The flexcop-pci driver was using '/'-characters in it, which is not good. This has been fixed in several attempts by several people, but obviously never made it into the kernel. Signed-off-by: Patrick Boettcher Cc: Steffen Barszus Cc: Boris Cuber Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 6a682f634ba9615d3498d1e20a23e9d4fcb39f16 Author: David Rientjes Date: Wed Apr 20 19:27:13 2011 -0700 set memory ranges in N_NORMAL_MEMORY when onlined commit d9b41e0b54fd7e164daf1e9c539c1070398aa02e upstream. When a DISCONTIGMEM memory range is brought online as a NUMA node, it also needs to have its bet set in N_NORMAL_MEMORY. This is necessary for generic kernel code that utilizes N_NORMAL_MEMORY as a subset of N_ONLINE for memory savings. These types of hacks can hopefully be removed once DISCONTIGMEM is either removed or abstracted away from CONFIG_NUMA. Fixes a panic in the slub code which only initializes structures for N_NORMAL_MEMORY to save memory: Backtrace: [<000000004021c938>] add_partial+0x28/0x98 [<000000004021faa0>] __slab_free+0x1d0/0x1d8 [<000000004021fd04>] kmem_cache_free+0xc4/0x128 [<000000004033bf9c>] ida_get_new_above+0x21c/0x2c0 [<00000000402a8980>] sysfs_new_dirent+0xd0/0x238 [<00000000402a974c>] create_dir+0x5c/0x168 [<00000000402a9ab0>] sysfs_create_dir+0x98/0x128 [<000000004033d6c4>] kobject_add_internal+0x114/0x258 [<000000004033d9ac>] kobject_add_varg+0x7c/0xa0 [<000000004033df20>] kobject_add+0x50/0x90 [<000000004033dfb4>] kobject_create_and_add+0x54/0xc8 [<00000000407862a0>] cgroup_init+0x138/0x1f0 [<000000004077ce50>] start_kernel+0x5a0/0x840 [<000000004011fa3c>] start_parisc+0xa4/0xb8 [<00000000404bb034>] packet_ioctl+0x16c/0x208 [<000000004049ac30>] ip_mroute_setsockopt+0x260/0xf20 Signed-off-by: David Rientjes Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 7c650d5dfafac48213c0a652b7b1a18a3c391538 Author: James Bottomley Date: Tue Apr 19 16:29:36 2011 -0500 slub: fix panic with DISCONTIGMEM commit 4a5fa3590f09999f6db41bc386bce40848fa9f63 upstream. Slub makes assumptions about page_to_nid() which are violated by DISCONTIGMEM and !NUMA. This violation results in a panic because page_to_nid() can be non-zero for pages in the discontiguous ranges and this leads to a null return by get_node(). The assertion by the maintainer is that DISCONTIGMEM should only be allowed when NUMA is also defined. However, at least six architectures: alpha, ia64, m32r, m68k, mips, parisc violate this. The panic is a regression against slab, so just mark slub broken in the problem configuration to prevent users reporting these panics. Acked-by: David Rientjes Acked-by: Pekka Enberg Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 2aaf1f781cb77812e5d9678d7b126ec13cebf283 Author: Rafael J. Wysocki Date: Tue Apr 26 11:33:18 2011 +0200 ACPI / PM: Avoid infinite recurrence while registering power resources commit 7bed50c5edf5cba8dd515a31191cbfb6065ddc85 upstream. There is at least one BIOS with a DSDT containing a power resource object with a _PR0 entry pointing back to that power resource. In consequence, while registering that power resource acpi_bus_get_power_flags() sees that it depends on itself and tries to register it again, which leads to an infinitely deep recurrence. This problem was introduced by commit bf325f9538d8c89312be305b9779e (ACPI / PM: Register power resource devices as soon as they are needed). To fix this problem use the observation that power resources cannot be power manageable and prevent acpi_bus_get_power_flags() from being called for power resource objects. References: https://bugzilla.kernel.org/show_bug.cgi?id=31872 Reported-and-tested-by: Pascal Dormeau Signed-off-by: Rafael J. Wysocki Acked-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 642dbe81ce8c46e26a190ab641633858961b9ad4 Author: Heiko Carstens Date: Wed Apr 20 10:15:34 2011 +0200 pfault: fix token handling commit e35c76cd47c244eaa7a74adaabde4d0a1cadb907 upstream. f6649a7e "[S390] cleanup lowcore access from external interrupts" changed handling of external interrupts. Instead of letting the external interrupt handlers accessing the per cpu lowcore the entry code of the kernel reads already all fields that are necessary and passes them to the handlers. The pfault interrupt handler was incorrectly converted. It tries to dereference a value which used to be a pointer to a lowcore field. After the conversion however it is not anymore the pointer to the field but its content. So instead of a dereference only a cast is needed to get the task pointer that caused the pfault. Fixes a NULL pointer dereference and a subsequent kernel crash: Unable to handle kernel pointer dereference at virtual kernel address (null) Oops: 0004 [#1] SMP Modules linked in: nfsd exportfs nfs lockd fscache nfs_acl auth_rpcgss sunrpc loop qeth_l3 qeth vmur ccwgroup ext3 jbd mbcache dm_mod dasd_eckd_mod dasd_diag_mod dasd_mod CPU: 0 Not tainted 2.6.38-2-s390x #1 Process cron (pid: 1106, task: 000000001f962f78, ksp: 000000001fa0f9d0) Krnl PSW : 0404200180000000 000000000002c03e (pfault_interrupt+0xa2/0x138) R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:0 CC:2 PM:0 EA:3 Krnl GPRS: 0000000000000000 0000000000000001 0000000000000000 0000000000000001 000000001f962f78 0000000000518968 0000000090000002 000000001ff03280 0000000000000000 000000000064f000 000000001f962f78 0000000000002603 0000000006002603 0000000000000000 000000001ff7fe68 000000001ff7fe48 Krnl Code: 000000000002c036: 5820d010 l %r2,16(%r13) 000000000002c03a: 1832 lr %r3,%r2 000000000002c03c: 1a31 ar %r3,%r1 >000000000002c03e: ba23d010 cs %r2,%r3,16(%r13) 000000000002c042: a744fffc brc 4,2c03a 000000000002c046: a7290002 lghi %r2,2 000000000002c04a: e320d0000024 stg %r2,0(%r13) 000000000002c050: 07f0 bcr 15,%r0 Call Trace: ([<000000001f962f78>] 0x1f962f78) [<000000000001acda>] do_extint+0xf6/0x138 [<000000000039b6ca>] ext_no_vtime+0x30/0x34 [<000000007d706e04>] 0x7d706e04 Last Breaking-Event-Address: [<0000000000000000>] 0x0 For stable maintainers: the first kernel which contains this bug is 2.6.37. Reported-by: Stephen Powell Cc: Jonathan Nieder Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit db952a764fa4a58b374363878f9eb5aa5525b81f Author: Carsten Otte Date: Wed Apr 20 10:15:36 2011 +0200 kvm-390: Let kernel exit SIE instruction on work commit 9ff4cfb3fcfd48b49fdd9be7381b3be340853aa4 upstream. From: Christian Borntraeger This patch fixes the sie exit on interrupts. The low level interrupt handler returns to the PSW address in pt_regs and not to the PSW address in the lowcore. Without this fix a cpu bound guest might never leave guest state since the host interrupt handler would blindly return to the SIE instruction, even on need_resched and friends. Signed-off-by: Carsten Otte Signed-off-by: Christian Borntraeger Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 718731e7c909827e15dd3a43d169eeb4bf6c6f8d Author: Artem Bityutskiy Date: Wed Apr 20 18:02:45 2011 +0300 UBIFS: fix false space checking failure commit 8c230d9a5b5ec7970139acb7e2d165d7a3fe9f9e upstream. This patch fixes UBIFS mount failure when the debugging support is enabled, we are recovering from a power cut, we were first mounter R/O and we are re-mounting R/W. In this case we should not assume that the amount of free space before we have re-mounted R/W and after are equivalent, because when we have mounted R/O the file-system is in a non-committed state so the amount of free space is slightly smaller, due to the fact that we cannot predict the amount of free space precisely before we commit. This patch fixes the issue by skipping the debugging check in case of recovery. This issue was reported by Caizhiyong here: http://thread.gmane.org/gmane.linux.drivers.mtd/34350/focus=34387 Signed-off-by: Artem Bityutskiy Reported-by: Caizhiyong Signed-off-by: Greg Kroah-Hartman commit 5002397e6c6f9c2f5fb92d8990eb2663e43a3012 Author: Felix Fietkau Date: Fri Jan 14 00:06:27 2011 +0100 ath9k_hw: partially revert "fix dma descriptor rx error bit parsing" commit 115dad7a7f42e68840392767323ceb9306dbdb36 upstream. The rx error bit parsing was changed to consider PHY errors and various decryption errors separately. While correct according to the documentation, this is causing spurious decryption error reports in some situations. Fix this by restoring the original order of the checks in those places, where the errors are meant to be mutually exclusive. If a CRC error is reported, then MIC failure and decryption errors are irrelevant, and a PHY error is unlikely. Signed-off-by: Felix Fietkau Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 36d08a041f93f2c5370f95f9611c9065bb79e4fb Author: Kyle McMartin Date: Tue Mar 22 16:19:50 2011 -0400 ACPI battery: fribble sysfs files from a resume notifier commit 25be5821521640eb00b7eb219ffe59664510d073 upstream. Commit da8aeb92 re-poked the battery on resume, but Linus reports that it broke his eee and partially reverted it in b23fffd7. Unfortunately this also results in my x201s giving crack values until the sysfs files are poked again. In the revert message, it was suggested that we poke it from a PM notifier, so let's do that. With this in place, I haven't noticed the units going nutty on my gnome-power-manager across a dozen suspends or so... Signed-off-by: Kyle McMartin Acked-by: Rafael J. Wysocki Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 7bf87075b2ce9d35a99916b446622ba8825e7142 Author: Ike Panhc Date: Wed Feb 23 21:39:59 2011 +0800 ideapad: read brightness setting on brightness key notify commit 2165136585b5c7d6f118f1d90fbde550bb7de212 upstream. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=25922 On ideapad Y530, the brightness key notify will be blocked if the last notify is not responsed by getting the brightness value. Read value when we get the notify shall fix the problem and will not have any difference on other ideapads. Signed-off-by: Ike Panhc Signed-off-by: Matthew Garrett Signed-off-by: Greg Kroah-Hartman commit 75db8ad812878495309d3d0b40467e9b9b61b29a Author: Artem Bityutskiy Date: Thu Apr 21 14:49:55 2011 +0300 UBIFS: fix master node recovery commit 6e0d9fd38b750d678bf9fd07db23582f52fafa55 upstream. This patch fixes the following symptoms: 1. Unmount UBIFS cleanly. 2. Start mounting UBIFS R/W and have a power cut immediately 3. Start mounting UBIFS R/O, this succeeds 4. Try to re-mount UBIFS R/W - this fails immediately or later on, because UBIFS will write the master node to the flash area which has been written before. The analysis of the problem: 1. UBIFS is unmounted cleanly, both copies of the master node are clean. 2. UBIFS is being mounter R/W, starts changing master node copy 1, and a power cut happens. The copy N1 becomes corrupted. 3. UBIFS is being mounted R/O. It notices the copy N1 is corrupted and reads copy N2. Copy N2 is clean. 4. Because of R/O mode, UBIFS cannot recover copy 1. 5. The mount code (ubifs_mount()) sees that the master node is clean, so it decides that no recovery is needed. 6. We are re-mounting R/W. UBIFS believes no recovery is needed and starts updating the master node, but copy N1 is still corrupted and was not recovered! Fix this problem by marking the master node as dirty every time we recover it and we are in R/O mode. This forces further recovery and the UBIFS cleans-up the corruptions and recovers the copy N1 when re-mounting R/W later. Signed-off-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman commit fb57290759588bbcb60d6d9104f8947fdba5aa19 Author: Ben Hutchings Date: Sat Apr 23 18:42:56 2011 +0100 kconfig: Avoid buffer underrun in choice input commit 3ba41621156681afcdbcd624e3191cbc65eb94f4 upstream. Commit 40aee729b350 ('kconfig: fix default value for choice input') fixed some cases where kconfig would select the wrong option from a choice with a single valid option and thus enter an infinite loop. However, this broke the test for user input of the form 'N?', because when kconfig selects the single valid option the input is zero-length and the test will read the byte before the input buffer. If this happens to contain '?' (as it will in a mips build on Debian unstable today) then kconfig again enters an infinite loop. Signed-off-by: Ben Hutchings Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0ab7f6fb02a9a588974c78485c57ef2ebb7aed6f Author: Tejun Heo Date: Wed Mar 16 11:14:55 2011 +0100 libata: Implement ATA_FLAG_NO_DIPM and apply it to mcp65 commit ae01b2493c3bf03c504c32ac4ebb01d528508db3 upstream. NVIDIA mcp65 familiy of controllers cause command timeouts when DIPM is used. Implement ATA_FLAG_NO_DIPM and apply it. This problem was reported by Stefan Bader in the following thread. http://thread.gmane.org/gmane.linux.ide/48841 stable: applicable to 2.6.37 and 38. Signed-off-by: Tejun Heo Reported-by: Stefan Bader Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit 068e0202c8c0822c36025198607d1e47d779c86f Author: Maxime Bizon Date: Wed Mar 16 14:58:32 2011 +0100 ahci: don't enable port irq before handler is registered commit 7b3a24c57d2eeda8dba9c205342b12689c4679f9 upstream. The ahci_pmp_attach() & ahci_pmp_detach() unmask port irqs, but they are also called during port initialization, before ahci host irq handler is registered. On ce4100 platform, this sometimes triggers "irq 4: nobody cared" message when loading driver. Fixed this by not touching the register if the port is in frozen state, and mark all uninitialized port as frozen. Signed-off-by: Maxime Bizon Acked-by: Tejun Heo Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit cb6f6c06a5e23fe12f1898a072edc670420ebc1f Author: Takashi Iwai Date: Fri Apr 15 10:11:12 2011 +0200 ALSA: hda - Add a fix-up for Acer dmic with ALC271x codec commit 6981d184376e74391c23c116a068f8d1305f0e57 upstream. Acer laptops with ALC271x needs a magic initialization for digital-mic to make it working with mono streams (and PulseAudio). Added a fix-up applied to Acer with ALC271x generically. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b87e6b59960437a1d9c0ddb1723ec20cc33d18d2 Author: Lars-Peter Clausen Date: Tue Apr 12 19:33:28 2011 +0200 ASoC: codecs: JZ4740: Fix OOPS commit 1fdf9b49e9e7788d09bad4b08a6a821ac39798f3 upstream. Commit ce6120cc(ASoC: Decouple DAPM from CODECs) changed the signature of snd_soc_dapm_widgets_new to take an pointer to a snd_soc_dapm_context instead of a snd_soc_codec. The call to snd_soc_dapm_widgets_new in jz4740_codec_dev_probe was not updated to reflect this change, which results in a compiletime warning and a runtime OOPS. Since the core code calls snd_soc_dapm_widgets_new after the codec has been registered it can be dropped here. Signed-off-by: Lars-Peter Clausen Acked-by: Liam Girdwood Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 8196315af8f0ce8856088501beab055196e3476b Author: Mark Brown Date: Fri Apr 8 16:32:16 2011 +0900 ASoC: Fix output PGA enabling in wm_hubs CODECs commit 39cca168bdfaef9d0c496ec27f292445d6184946 upstream. The output PGA was not being powered up in headphone and speaker paths, removing the ability to offer volume control and mute with the output PGA. Signed-off-by: Mark Brown Acked-by: Liam Girdwood Signed-off-by: Greg Kroah-Hartman commit 1eb710f4e01a9afab735828c87ef13e2e6b57386 Author: Uwe Kleine-König Date: Mon Apr 11 10:59:09 2011 +0200 serial/imx: read cts state only after acking cts change irq commit 5680e94148a86e8c31fdc5cb0ea0d5c6810c05b0 upstream. If cts changes between reading the level at the cts input (USR1_RTSS) and acking the irq (USR1_RTSD) the last edge doesn't generate an irq and uart_handle_cts_change is called with a outdated value for cts. The race was introduced by commit ceca629 ([ARM] 2971/1: i.MX uart handle rts irq) Reported-by: Arwed Springer Tested-by: Arwed Springer Signed-off-by: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman commit 7b394b6f584438e9048825dd4571299945ce9b54 Author: Mikhail Kshevetskiy Date: Sun Mar 27 04:05:00 2011 +0400 tty/n_gsm: fix bug in CRC calculation for gsm1 mode commit 9db4e4381a8e881ff65a5d3400bfa471f84217e7 upstream. Problem description: gsm_queue() calculate a CRC for arrived frames. As a last step of CRC calculation it call gsm->fcs = gsm_fcs_add(gsm->fcs, gsm->received_fcs); This work perfectly for the case of GSM0 mode as gsm->received_fcs contain the last piece of data required to generate final CRC. gsm->received_fcs is not used for GSM1 mode. Thus we put an additional byte to CRC calculation. As result we get a wrong CRC and reject incoming frame. Signed-off-by: Mikhail Kshevetskiy Acked-by: Alan Cox Signed-off-by: Greg Kroah-Hartman commit 60edc65d5d2c1b61d20f28b70b3ac5140dc82f6a Author: Mathew McKernan Date: Tue Apr 12 06:51:37 2011 +0100 drm/i915/tv: Remember the detected TV type commit d5627663f2088fa4be447fdcfd52bcb233448d85 upstream. During detect() we would probe the connection bits to determine if there was a TV attached, and what video input type (Component, S-Video, Composite, etc) to use. However, we promptly discarded this vital bit of information and never propagated it to where it was used to determine the correct modes and setup the control registers. Fix it! This fixes a regression from 7b334fcb45b757ffb093696ca3de1b0c8b4a33f1. Reported-and-tested-by: Mathew McKernan Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35977 Signed-off-by: Mathew McKernan Signed-off-by: Chris Wilson Acked-by: Paul Menzel Signed-off-by: Keith Packard Signed-off-by: Greg Kroah-Hartman commit 72846ac3462c7d2bebc25c9a4d3e8f5739c5fb66 Author: Chris Wilson Date: Tue Apr 12 18:06:51 2011 +0100 drm/i915: Sanitize the output registers after resume commit f6e5b1603b8bb7131b6778d0d4e2e5dda120a379 upstream. Similar to booting, we need to inspect the state left by the BIOS and remove any conflicting bits before we take over. The example reported by Seth Forshee is very similar to the bug we encountered with the state left by grub2, that the crtc pipe<->planning mapping was reversed from our expectations and so we failed to turn off the outputs when booting or, in this case, resuming. This may be in fact the same bug, but triggered at resume time. This patch rearranges the code we already have to clear up the conflicting state upon init and calls it from reset (which is called after we have lost control of the hardware, i.e. along both the boot and resume paths) instead. Reported-and-tested-by: Seth Forshee Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35796 Signed-off-by: Chris Wilson Reviewed-by: Keith Packard Signed-off-by: Keith Packard Signed-off-by: Greg Kroah-Hartman commit fee1e99cca4a66a3d6d2983c1e1782a0e2747f57 Author: Alex Deucher Date: Thu Apr 14 11:19:50 2011 -0400 drm/radeon/kms: fix bad shift in atom iio table parser commit 8e461123f28e6b17456225e70eb834b3b30d28bb upstream. Noticed by Patrick Lowry. Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit e0b0be738453aabea3ada4617a7f30c020deb9d3 Author: Marcin Slusarz Date: Tue Apr 19 23:50:48 2011 +0200 drm/nouveau: fix notifier memory corruption bug commit a18d89ca026140eb8ac4459bf70a01c571dd9a32 upstream. nouveau_bo_wr32 expects offset to be in words, but we pass value in bytes, so after commit 73412c3854c877e5f37ad944ee8977addde4d35a ("drm/nouveau: allocate kernel's notifier object at end of block") we started to overwrite some memory after notifier buffer object (previously m2mf_ntfy was always 0, so it didn't matter it was a value in bytes). Reported-by: Dominik Brodowski Reported-by: Nigel Cunningham Signed-off-by: Marcin Slusarz Cc: Ben Skeggs Cc: Pekka Paalanen Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit c5fd52b24b7ea7ba603e99e33235857e3deeee3f Author: Alex Deucher Date: Tue Apr 19 15:24:59 2011 -0400 drm/radeon/kms: pll tweaks for r7xx commit 5785e53ffa73f77fb19e378c899027afc07272bc upstream. Prefer min m to max p only on pre-r7xx asics. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=36197 Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 5aefedf020635bfb1c1390b920c6b8e442be25b0 Author: Alex Williamson Date: Fri Mar 4 14:52:30 2011 -0700 intel-iommu: Fix get_domain_for_dev() error path commit 2fe9723df8e45fd247782adea244a5e653c30bf4 upstream. If we run out of domain_ids and fail iommu_attach_domain(), we fall into domain_exit() without having setup enough of the domain structure for this to do anything useful. In fact, it typically runs off into the weeds walking the bogus domain->devices list. Just free the domain. Signed-off-by: Alex Williamson Acked-by: Donald Dutile Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit 6a815cf43b27504d50e0153b6d60039c4558a429 Author: Alex Williamson Date: Fri Mar 4 14:52:16 2011 -0700 intel-iommu: Unlink domain from iommu commit a97590e56d0d58e1dd262353f7cbd84e81d8e600 upstream. When we remove a device, we unlink the iommu from the domain, but we never do the reverse unlinking of the domain from the iommu. This means that we never clear iommu->domain_ids, eventually leading to resource exhaustion if we repeatedly bind and unbind a device to a driver. Also free empty domains to avoid a resource leak. Signed-off-by: Alex Williamson Acked-by: Donald Dutile Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit 6a6a3e00ccd23f5b9d146a4b0591c8b61b4d0bb2 Author: Jan Kiszka Date: Tue Nov 2 08:05:51 2010 +0100 intel-iommu: Fix use after release during device attach commit 7a6610139a1e1d9297dd1c5d178022eac36839cb upstream. Obtain the new pgd pointer before releasing the page containing this value. Signed-off-by: Jan Kiszka Reviewed-by: Sheng Yang Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit a35cb5371d340fbaa459efc78e0d00ca3cd8e05e Author: Joerg Roedel Date: Mon Apr 18 15:45:46 2011 +0200 x86, gart: Make sure GART does not map physmem above 1TB commit 665d3e2af83c8fbd149534db8f57d82fa6fa6753 upstream. The GART can only map physical memory below 1TB. Make sure the gart driver in the kernel does not try to map memory above 1TB. Signed-off-by: Joerg Roedel Link: http://lkml.kernel.org/r/1303134346-5805-5-git-send-email-joerg.roedel@amd.com Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 111f02f8a5dcd4ca9ba0d9934fa1d423f735b66b Author: Joerg Roedel Date: Mon Apr 18 15:45:45 2011 +0200 x86, gart: Set DISTLBWALKPRB bit always commit c34151a742d84ae65db2088ea30495063f697fbe upstream. The DISTLBWALKPRB bit must be set for the GART because the gatt table is mapped UC. But the current code does not set the bit at boot when the BIOS setup the aperture correctly. Fix that by setting this bit when enabling the GART instead of the other places. Cc: Borislav Petkov Signed-off-by: Joerg Roedel Link: http://lkml.kernel.org/r/1303134346-5805-4-git-send-email-joerg.roedel@amd.com Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 045707f94023998aa702536bb2fb441d8a049475 Author: Amit Shah Date: Wed Mar 16 19:12:10 2011 +0530 virtio: Decrement avail idx on buffer detach commit b3258ff1d6086bd2b9eeb556844a868ad7d49bc8 upstream. When detaching a buffer from a vq, the avail.idx value should be decremented as well. This was noticed by hot-unplugging a virtio console port and then plugging in a new one on the same number (re-using the vqs which were just 'disowned'). qemu reported 'Guest moved used index from 0 to 256' when any IO was attempted on the new port. Reported-by: juzhang Signed-off-by: Amit Shah Signed-off-by: Rusty Russell Signed-off-by: Greg Kroah-Hartman commit eceb743cdc65d1b78d91f786cc2a2acb9ab2d116 Author: OGAWA Hirofumi Date: Mon Apr 18 11:48:55 2011 -0400 nfsd4: Fix filp leak commit a96e5b90804be8b540d30f4a1453fc87f95b3149 upstream. 23fcf2ec93fb8573a653408316af599939ff9a8e (nfsd4: fix oops on lock failure) The above patch breaks free path for stp->st_file. If stp was inserted into sop->so_stateids, we have to free stp->st_file refcount. Because stp->st_file refcount itself is taken whether or not any refcounts are taken on the stp->st_file->fi_fds[]. Signed-off-by: OGAWA Hirofumi Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 9acb84c8847ed2008ea86d1e0635f30b3db17026 Author: J. Bruce Fields Date: Fri Apr 15 18:08:26 2011 -0400 nfsd4: fix struct file leak on delegation commit 4ee63624fd927376b97ead3a8d00728d437bc8e8 upstream. Introduced by acfdf5c383b38f7f4dddae41b97c97f1ae058f49. Reported-by: Gerhard Heift Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit da0309a4a778c46eaba98c58a2b821349d658520 Author: Amit Kumar Salecha Date: Tue Apr 12 17:05:55 2011 +0000 qlcnic: limit skb frags for non tso packet commit 91a403caf0f26c71ce4407fd235b2d6fb225fba9 upstream. Machines are getting deadlock in four node cluster environment. All nodes are accessing (find /gfs2 -depth -print|cpio -ocv > /dev/null) 200 GB storage on a GFS2 filesystem. This result in memory fragmentation and driver receives 18 frags for 1448 byte packets. For non tso packet, fw drops the tx request, if it has >14 frags. Fixing it by pulling extra frags. Signed-off-by: Amit Kumar Salecha Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c6fedb562695213645926348c9885dcc81324e4c Author: Jason Conti Date: Thu Apr 7 21:09:57 2011 +0200 p54: Initialize extra_len in p54_tx_80211 commit a6756da9eace8b4af73e9dea43f1fc2889224c94 upstream. This patch fixes a very serious off-by-one bug in the driver, which could leave the device in an unresponsive state. The problem was that the extra_len variable [used to reserve extra scratch buffer space for the firmware] was left uninitialized. Because p54_assign_address later needs the value to reserve additional space, the resulting frame could be to big for the small device's memory window and everything would immediately come to a grinding halt. Reference: https://bugs.launchpad.net/bugs/722185 Acked-by: Christian Lamparter Signed-off-by: Jason Conti Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 343b1a2525647d9035710c03042fe7e27b91a951 Author: Liu Yuan Date: Tue Apr 19 13:47:58 2011 +0200 block, blk-sysfs: Fix an err return path in blk_register_queue() commit ed5302d3c25006a9edc7a7fbea97a30483f89ef7 upstream. We do not call blk_trace_remove_sysfs() in err return path if kobject_add() fails. This path fixes it. Signed-off-by: Liu Yuan Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit f82e213b907b6cd6113e2414f92271a0b1ecb90f Author: Christian Lamparter Date: Wed Apr 6 20:40:31 2011 +0200 ath: add missing regdomain pair 0x5c mapping commit bd39a274fb7b43374c797bafdb7f506598f36f77 upstream. Joe Culler reported a problem with his AR9170 device: > ath: EEPROM regdomain: 0x5c > ath: EEPROM indicates we should expect a direct regpair map > ath: invalid regulatory domain/country code 0x5c > ath: Invalid EEPROM contents It turned out that the regdomain 'APL7_FCCA' was not mapped yet. According to Luis R. Rodriguez [Atheros' engineer] APL7 maps to FCC_CTL and FCCA maps to FCC_CTL as well, so the attached patch should be correct. Reported-by: Joe Culler Acked-by: Luis R. Rodriguez Signed-off-by: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit f18f3747d73891ef607162a8eec4ffe211e21628 Author: amit salecha Date: Mon Apr 11 02:10:22 2011 +0000 netxen: limit skb frags for non tso packet commit c968bdf6912cad6d0fc63d7037cc1c870604a808 upstream. Machines are getting deadlock in four node cluster environment. All nodes are accessing (find /gfs2 -depth -print|cpio -ocv > /dev/null) 200 GB storage on a GFS2 filesystem. This result in memory fragmentation and driver receives 18 frags for 1448 byte packets. For non tso packet, fw drops the tx request, if it has >14 frags. Fixing it by pulling extra frags. Signed-off-by: Amit Kumar Salecha Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit faa8ee7cc9eaa6958f0c2dc532faec69c961b9d7 Author: Felix Fietkau Date: Fri Apr 8 20:13:18 2011 +0200 ath9k_hw: fix stopping rx DMA during resets commit 5882da02e9d9089b7e8c739f3e774aaeeff8b7ba upstream. During PHY errors, the MAC can sometimes fail to enter an idle state on older hardware (before AR9380) after an rx stop has been requested. This typically shows up in the kernel log with messages like these: ath: Could not stop RX, we could be confusing the DMA engine when we start RX up ------------[ cut here ]------------ WARNING: at drivers/net/wireless/ath/ath9k/recv.c:504 ath_stoprecv+0xcc/0xf0 [ath9k]() Call Trace: [<8023f0e8>] dump_stack+0x8/0x34 [<80075050>] warn_slowpath_common+0x78/0xa4 [<80075094>] warn_slowpath_null+0x18/0x24 [<80d66d60>] ath_stoprecv+0xcc/0xf0 [ath9k] [<80d642cc>] ath_set_channel+0xbc/0x270 [ath9k] [<80d65254>] ath_radio_disable+0x4a4/0x7fc [ath9k] When this happens, the state that the MAC enters is easy to identify and does not result in bogus DMA traffic, however to ensure a working state after a channel change, the hardware should still be reset. This patch adds detection for this specific MAC state, after which the above warnings completely disappear in my tests. Signed-off-by: Felix Fietkau Cc: Kyungwan Nam Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman