commit 46a55da12372398dd62629186c13b5ae619f912d Author: Jiri Slaby Date: Sat Mar 22 22:02:40 2014 +0100 Linux 3.12.15 commit 75a2a32b7501279a12e5c67686a078a0809d0eae Author: Zhang Rui Date: Tue Mar 11 22:40:27 2014 +0800 PNP / ACPI: proper handling of ACPI IO/Memory resource parsing failures commit 89935315f192abf7068d0044cefc84f162c3c81f upstream. Before commit b355cee88e3b (ACPI / resources: ignore invalid ACPI device resources), if acpi_dev_resource_memory()/acpi_dev_resource_io() returns false, it means the the resource is not a memeory/IO resource. But after commit b355cee88e3b, those functions return false if the given memory/IO resource entry is invalid (the length of the resource is zero). This breaks pnpacpi_allocated_resource(), because it now recognizes the invalid memory/io resources as resources of unknown type. Thus users see confusing warning messages on machines with zero length ACPI memory/IO resources. Fix the problem by rearranging pnpacpi_allocated_resource() so that it calls acpi_dev_resource_memory() for memory type and IO type resources only, respectively. Fixes: b355cee88e3b (ACPI / resources: ignore invalid ACPI device resources) Signed-off-by: Zhang Rui Reported-and-tested-by: Markus Trippelsdorf Reported-and-tested-by: Julian Wollrath Reported-and-tested-by: Paul Bolle [rjw: Changelog] Signed-off-by: Rafael J. Wysocki Signed-off-by: Jiri Slaby commit 3eb3391260f086f2c79252d94c7ac777dac51bd5 Author: Steve Capper Date: Tue Feb 25 11:38:53 2014 +0000 arm64: mm: Add double logical invert to pte accessors commit 84fe6826c28f69d8708bd575faed7f75e6b6f57f upstream. Page table entries on ARM64 are 64 bits, and some pte functions such as pte_dirty return a bitwise-and of a flag with the pte value. If the flag to be tested resides in the upper 32 bits of the pte, then we run into the danger of the result being dropped if downcast. For example: gather_stats(page, md, pte_dirty(*pte), 1); where pte_dirty(*pte) is downcast to an int. This patch adds a double logical invert to all the pte_ accessors to ensure predictable downcasting. Signed-off-by: Steve Capper [steve.capper@linaro.org: rebased patch to leave pte_write alone to allow for merge with 3.13 stable] Signed-off-by: Catalin Marinas Signed-off-by: Jiri Slaby commit 7cbcb219e4113e10ce4b036118992abdbc4a8273 Author: Nicholas Bellinger Date: Tue Jan 21 20:32:05 2014 -0800 bio-integrity: Fix bio_integrity_verify segment start bug commit 5837c80e870bc3b12ac6a98cdc9ce7a9522a8fb6 upstream. This patch addresses a bug in bio_integrity_verify() code that has been causing DIF READ verify operations to be silently skipped. The issue is that bio->bi_idx will have been incremented within bio_advance() code in the normal blk_update_request() -> req_bio_endio() completion path, and bio_integrity_verify() is using bio_for_each_segment() which starts the bio segment walk at the current bio->bi_idx. So instead use bio_for_each_segment_all() to always start the bio segment walk from zero, regardless of the current bio->bi_idx value after bio_advance() has been called. (Context change for v3.10.y -> v3.13.y code - nab) Cc: Martin K. Petersen Cc: Jens Axboe Cc: Christoph Hellwig Signed-off-by: Nicholas Bellinger Signed-off-by: Jens Axboe Signed-off-by: Jiri Slaby commit cf9fca41e523e859aadb6ae78a9502662f9fc7a1 Author: Qais Yousef Date: Mon Dec 9 09:49:45 2013 +0000 MIPS: include linux/types.h commit 87c99203fea897fbdd84b681ad9fced2517dcf98 upstream. The file uses u16 type but doesn't include its definition explicitly I was getting this error when including this header in my driver: arch/mips/include/asm/mipsregs.h:644:33: error: unknown type name ‘u16’ Signed-off-by: Qais Yousef Reviewed-by: Steven J. Hill Acked-by: David Daney Signed-off-by: John Crispin Patchwork: http://patchwork.linux-mips.org/patch/6212/ Signed-off-by: Jiri Slaby commit 44c5d3f4fa20751a53279cb93be4e9a2974fc01a Author: Roman Volkov Date: Fri Jan 24 16:18:11 2014 +0400 ALSA: oxygen: modify adjust_dg_dac_routing function commit 1f91ecc14deea9461aca93273d78871ec4d98fcd upstream. When selecting the audio output destinations (headphones, FP headphones, multichannel output), the channel routing should be changed depending on what destination selected. Also unnecessary I2S channels are digitally muted. This function called when the user selects the destination in the ALSA mixer. Signed-off-by: Roman Volkov Signed-off-by: Clemens Ladisch Signed-off-by: Jiri Slaby commit 41531218f30582610b5b2bdd16246526792b0cbe Author: Suresh Siddha Date: Sun Feb 2 22:56:23 2014 -0800 x86, fpu: Check tsk_used_math() in kernel_fpu_end() for eager FPU commit 731bd6a93a6e9172094a2322bd0ee964bb1f4d63 upstream. For non-eager fpu mode, thread's fpu state is allocated during the first fpu usage (in the context of device not available exception). This (math_state_restore()) can be a blocking call and hence we enable interrupts (which were originally disabled when the exception happened), allocate memory and disable interrupts etc. But the eager-fpu mode, call's the same math_state_restore() from kernel_fpu_end(). The assumption being that tsk_used_math() is always set for the eager-fpu mode and thus avoid the code path of enabling interrupts, allocating fpu state using blocking call and disable interrupts etc. But the below issue was noticed by Maarten Baert, Nate Eldredge and few others: If a user process dumps core on an ecrypt fs while aesni-intel is loaded, we get a BUG() in __find_get_block() complaining that it was called with interrupts disabled; then all further accesses to our ecrypt fs hang and we have to reboot. The aesni-intel code (encrypting the core file that we are writing) needs the FPU and quite properly wraps its code in kernel_fpu_{begin,end}(), the latter of which calls math_state_restore(). So after kernel_fpu_end(), interrupts may be disabled, which nobody seems to expect, and they stay that way until we eventually get to __find_get_block() which barfs. For eager fpu, most the time, tsk_used_math() is true. At few instances during thread exit, signal return handling etc, tsk_used_math() might be false. In kernel_fpu_end(), for eager-fpu, call math_state_restore() only if tsk_used_math() is set. Otherwise, don't bother. Kernel code path which cleared tsk_used_math() knows what needs to be done with the fpu state. Reported-by: Maarten Baert Reported-by: Nate Eldredge Suggested-by: Linus Torvalds Signed-off-by: Suresh Siddha Link: http://lkml.kernel.org/r/1391410583.3801.6.camel@europa Cc: George Spelvin Signed-off-by: H. Peter Anvin Signed-off-by: Jiri Slaby commit f27a0d9cecbc0afd12f72f79ab652feb685202b0 Author: Ales Novak Date: Thu Feb 27 11:03:30 2014 +0100 SCSI: storvsc: NULL pointer dereference fix commit b12bb60d6c350b348a4e1460cd68f97ccae9822e upstream. If the initialization of storvsc fails, the storvsc_device_destroy() causes NULL pointer dereference. storvsc_bus_scan() scsi_scan_target() __scsi_scan_target() scsi_probe_and_add_lun(hostdata=NULL) scsi_alloc_sdev(hostdata=NULL) sdev->hostdata = hostdata now the host allocation fails __scsi_remove_device(sdev) calls sdev->host->hostt->slave_destroy() == storvsc_device_destroy(sdev) access of sdev->hostdata->request_mempool Signed-off-by: Ales Novak Signed-off-by: Thomas Abraham Reviewed-by: Jiri Kosina Acked-by: K. Y. Srinivasan Signed-off-by: James Bottomley Signed-off-by: Jiri Slaby commit 108f920124944eaf21a780f588a5dc2041192244 Author: Chad Dupuis Date: Wed Feb 26 04:15:14 2014 -0500 SCSI: qla2xxx: Fix multiqueue MSI-X registration. commit f324777ea88bab2522602671e46fc0851d7d5e35 upstream. This fixes requesting of the MSI-X vectors for the base response queue. The iteration in the for loop in qla24xx_enable_msix() was incorrect. We should only iterate of the first two MSI-X vectors and not the total number of MSI-X vectors that have given to the driver for this device from pci_enable_msix() in this function. Signed-off-by: Chad Dupuis Signed-off-by: Saurav Kashyap Signed-off-by: James Bottomley Signed-off-by: Jiri Slaby commit cdc7b455e46dde6ecf150869698db9905cfbca43 Author: Giridhar Malavali Date: Wed Feb 26 04:15:12 2014 -0500 SCSI: qla2xxx: Poll during initialization for ISP25xx and ISP83xx commit b77ed25c9f8402e8b3e49e220edb4ef09ecfbb53 upstream. Signed-off-by: Giridhar Malavali Signed-off-by: Saurav Kashyap Signed-off-by: James Bottomley Signed-off-by: Jiri Slaby commit 073264369a1536945ba42f671dc7ee890d746ae1 Author: Lukasz Dorau Date: Thu Feb 6 12:23:20 2014 -0800 SCSI: isci: correct erroneous for_each_isci_host macro commit c59053a23d586675c25d789a7494adfdc02fba57 upstream. In the first place, the loop 'for' in the macro 'for_each_isci_host' (drivers/scsi/isci/host.h:314) is incorrect, because it accesses the 3rd element of 2 element array. After the 2nd iteration it executes the instruction: ihost = to_pci_info(pdev)->hosts[2] (while the size of the 'hosts' array equals 2) and reads an out of range element. In the second place, this loop is incorrectly optimized by GCC v4.8 (see http://marc.info/?l=linux-kernel&m=138998871911336&w=2). As a result, on platforms with two SCU controllers, the loop is executed more times than it can be (for i=0,1 and 2). It causes kernel panic during entering the S3 state and the following oops after 'rmmod isci': BUG: unable to handle kernel NULL pointer dereference at (null) IP: [] __list_add+0x1b/0xc0 Oops: 0000 [#1] SMP RIP: 0010:[] [] __list_add+0x1b/0xc0 Call Trace: [] __mutex_lock_slowpath+0x114/0x1b0 [] mutex_lock+0x1f/0x30 [] sas_disable_events+0x1b/0x50 [libsas] [] sas_unregister_ha+0x18/0x60 [libsas] [] isci_unregister+0x1e/0x40 [isci] [] isci_pci_remove+0x5d/0x100 [isci] [] pci_device_remove+0x3b/0xb0 [] __device_release_driver+0x7f/0xf0 [] driver_detach+0xa8/0xb0 [] bus_remove_driver+0x9b/0x120 [] driver_unregister+0x2c/0x50 [] pci_unregister_driver+0x23/0x80 [] isci_exit+0x10/0x1e [isci] [] SyS_delete_module+0x16b/0x2d0 [] ? do_notify_resume+0x61/0xa0 [] system_call_fastpath+0x16/0x1b The loop has been corrected. This patch fixes kernel panic during entering the S3 state and the above oops. Signed-off-by: Lukasz Dorau Reviewed-by: Maciej Patelczyk Tested-by: Lukasz Dorau Signed-off-by: Dan Williams Signed-off-by: James Bottomley Signed-off-by: Jiri Slaby commit 15c34d32a8d7a3d50c6cc1ea344b196074524d17 Author: Dan Williams Date: Thu Feb 6 12:23:01 2014 -0800 SCSI: isci: fix reset timeout handling commit ddfadd7736b677de2d4ca2cd5b4b655368c85a7a upstream. Remove an erroneous BUG_ON() in the case of a hard reset timeout. The reset timeout handler puts the port into the "awaiting link-up" state. The timeout causes the device to be disconnected and we need to be in the awaiting link-up state to re-connect the port. The BUG_ON() made the incorrect assumption that resets never timeout and we always complete the reset in the "resetting" state. Testing this patch also uncovered that libata continues to attempt to reset the port long after the driver has torn down the context. Once the driver has committed to abandoning the link it must indicate to libata that recovery ends by returning -ENODEV from ->lldd_I_T_nexus_reset(). Acked-by: Lukasz Dorau Reported-by: David Milburn Reported-by: Xun Ni Tested-by: Xun Ni Signed-off-by: Dan Williams Signed-off-by: James Bottomley Signed-off-by: Jiri Slaby commit 1dc74c291a73a6836bdbdcab81012bbafbb63224 Author: Marc Kleine-Budde Date: Fri Feb 28 20:48:36 2014 +0100 can: flexcan: flexcan_remove(): add missing netif_napi_del() commit d96e43e8fce28cf97df576a07af9d65657a41a6f upstream. This patch adds the missing netif_napi_del() to the flexcan_remove() function. Signed-off-by: Marc Kleine-Budde Signed-off-by: Jiri Slaby commit f314b0416e6559eb2b44637aba3a8f6d50c52301 Author: Marc Kleine-Budde Date: Fri Feb 28 17:18:27 2014 +0100 can: flexcan: factor out transceiver {en,dis}able into seperate functions commit f003698e23f6f56a791774f14d0ac35d04872490 upstream. This patch moves the transceiver enable and disable into seperate functions, where the NULL pointer check is hidden. Signed-off-by: Marc Kleine-Budde Signed-off-by: Jiri Slaby commit bd408b8c4c7f86022bd824eaf828f898e310cf12 Author: Marc Kleine-Budde Date: Fri Feb 28 15:30:18 2014 +0100 can: flexcan: fix transition from and to low power mode in chip_{en,dis}able commit 9b00b300e7bce032c467c36ca47fe2a776887fc2 upstream. In flexcan_chip_enable() and flexcan_chip_disable() fixed delays are used. Experiments have shown that the transition from and to low power mode may take several microseconds. This patch adds a while loop which polls the Low Power Mode ACK bit (LPM_ACK) that indicates a successfull mode change. If the function runs into a timeout a error value is returned. Signed-off-by: Marc Kleine-Budde Signed-off-by: Jiri Slaby commit a822076cdfb8162652a799e8038606e3bf3b1cd4 Author: Marc Kleine-Budde Date: Fri Feb 28 14:52:01 2014 +0100 can: flexcan: flexcan_open(): fix error path if flexcan_chip_start() fails commit 7e9e148af01ef388efb6e2490805970be4622792 upstream. If flexcan_chip_start() in flexcan_open() fails, the interrupt is not freed, this patch adds the missing cleanup. Signed-off-by: Marc Kleine-Budde Signed-off-by: Jiri Slaby commit e32578deab8a4d815dbb7211b47f099fb00b4bd5 Author: Marc Kleine-Budde Date: Wed Feb 19 12:00:51 2014 +0100 can: flexcan: fix shutdown: first disable chip, then all interrupts commit 5be93bdda64e85450598c6e97f79fb8f6acf30e0 upstream. When shutting down the CAN interface (ifconfig canX down) during high CAN bus loads, the CAN core might hang and freeze the whole CPU. This patch fixes the shutdown sequence by first disabling the CAN core then disabling all interrupts. Signed-off-by: Marc Kleine-Budde Signed-off-by: Jiri Slaby commit fec89336c8ee13b65d2c982b81a8b6df48656497 Author: Anton Blanchard Date: Wed Mar 5 14:29:58 2014 +1100 net: unix socket code abuses csum_partial commit 0a13404dd3bf4ea870e3d96270b5a382edca85c0 upstream. The unix socket code is using the result of csum_partial to hash into a lookup table: unix_hash_fold(csum_partial(sunaddr, len, 0)); csum_partial is only guaranteed to produce something that can be folded into a checksum, as its prototype explains: * returns a 32-bit number suitable for feeding into itself * or csum_tcpudp_magic The 32bit value should not be used directly. Depending on the alignment, the ppc64 csum_partial will return different 32bit partial checksums that will fold into the same 16bit checksum. This difference causes the following testcase (courtesy of Gustavo) to sometimes fail: #include #include int main() { int fd = socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0); int i = 1; setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &i, 4); struct sockaddr addr; addr.sa_family = AF_LOCAL; bind(fd, &addr, 2); listen(fd, 128); struct sockaddr_storage ss; socklen_t sslen = (socklen_t)sizeof(ss); getsockname(fd, (struct sockaddr*)&ss, &sslen); fd = socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0); if (connect(fd, (struct sockaddr*)&ss, sslen) == -1){ perror(NULL); return 1; } printf("OK\n"); return 0; } As suggested by davem, fix this by using csum_fold to fold the partial 32bit checksum into a 16bit checksum before using it. Signed-off-by: Anton Blanchard Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit b5ef2d0121f7494d8e06fb51e6646ac1b3693c86 Author: Heinz Mauelshagen Date: Wed Mar 12 16:13:39 2014 +0100 dm cache: fix access beyond end of origin device commit e893fba90c09f9b57fb97daae204ea9cc2c52fa5 upstream. In order to avoid wasting cache space a partial block at the end of the origin device is not cached. Unfortunately, the check for such a partial block at the end of the origin device was flawed. Fix accesses beyond the end of the origin device that occured due to attempted promotion of an undetected partial block by: - initializing the per bio data struct to allow cache_end_io to work properly - recognizing access to the partial block at the end of the origin device - avoiding out of bounds access to the discard bitset Otherwise, users can experience errors like the following: attempt to access beyond end of device dm-5: rw=0, want=20971520, limit=20971456 ... device-mapper: cache: promotion failed; couldn't copy block Signed-off-by: Heinz Mauelshagen Acked-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Jiri Slaby commit 67f1830fcdaefd65371bdd1bba38ca29cf7c2bbf Author: Heinz Mauelshagen Date: Wed Mar 12 00:40:05 2014 +0100 dm cache: fix truncation bug when copying a block to/from >2TB fast device commit 8b9d96666529a979acf4825391efcc7c8a3e9f12 upstream. During demotion or promotion to a cache's >2TB fast device we must not truncate the cache block's associated sector to 32bits. The 32bit temporary result of from_cblock() caused a 32bit multiplication when calculating the sector of the fast device in issue_copy_real(). Use an intermediate 64bit type to store the 32bit from_cblock() to allow for proper 64bit multiplication. Here is an example of how this bug manifests on an ext4 filesystem: EXT4-fs error (device dm-0): ext4_mb_generate_buddy:756: group 17136, 32768 clusters in bitmap, 30688 in gd; block bitmap corrupt. JBD2: Spotted dirty metadata buffer (dev = dm-0, blocknr = 0). There's a risk of filesystem corruption in case of system crash. Signed-off-by: Heinz Mauelshagen Acked-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Jiri Slaby commit b07b194d5cdc0f8cf63bf0039574afef416fafce Author: Joe Thornber Date: Fri Mar 7 14:57:19 2014 +0000 dm space map metadata: fix refcount decrement below 0 which caused corruption commit cebc2de44d3bce53e46476e774126c298ca2c8a9 upstream. This has been a relatively long-standing issue that wasn't nailed down until Teng-Feng Yang's meticulous bug report to dm-devel on 3/7/2014, see: http://www.redhat.com/archives/dm-devel/2014-March/msg00021.html From that report: "When decreasing the reference count of a metadata block with its reference count equals 3, we will call dm_btree_remove() to remove this enrty from the B+tree which keeps the reference count info in metadata device. The B+tree will try to rebalance the entry of the child nodes in each node it traversed, and the rebalance process contains the following steps. (1) Finding the corresponding children in current node (shadow_current(s)) (2) Shadow the children block (issue BOP_INC) (3) redistribute keys among children, and free children if necessary (issue BOP_DEC) Since the update of a metadata block's reference count could be recursive, we will stash these reference count update operations in smm->uncommitted and then process them in a FILO fashion. The problem is that step(3) could free the children which is created in step(2), so the BOP_DEC issued in step(3) will be carried out before the BOP_INC issued in step(2) since these BOPs will be processed in FILO fashion. Once the BOP_DEC from step(3) tries to decrease the reference count of newly shadow block, it will report failure for its reference equals 0 before decreasing. It looks like we can solve this issue by processing these BOPs in a FIFO fashion instead of FILO." Commit 5b564d80 ("dm space map: disallow decrementing a reference count below zero") changed the code to report an error for this temporary refcount decrement below zero. So what was previously a harmless invalid refcount became a hard failure due to the new error path: device-mapper: space map common: unable to decrement a reference count below 0 device-mapper: thin: 253:6: dm_thin_insert_block() failed: error = -22 device-mapper: thin: 253:6: switching pool to read-only mode This bug is in dm persistent-data code that is common to the DM thin and cache targets. So any users of those targets should apply this fix. Fix this by applying recursive space map operations in FIFO order rather than FILO. Resolves: https://bugzilla.kernel.org/show_bug.cgi?id=68801 Reported-by: Apollon Oikonomopoulos Reported-by: edwillam1007@gmail.com Reported-by: Teng-Feng Yang Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Jiri Slaby commit fd175558e36369176e4c64ec010f7b0daa1657f7 Author: Laura Abbott Date: Mon Mar 10 15:49:44 2014 -0700 mm/compaction: break out of loop on !PageBuddy in isolate_freepages_block commit 2af120bc040c5ebcda156df6be6a66610ab6957f upstream. We received several reports of bad page state when freeing CMA pages previously allocated with alloc_contig_range: BUG: Bad page state in process Binder_A pfn:63202 page:d21130b0 count:0 mapcount:1 mapping: (null) index:0x7dfbf page flags: 0x40080068(uptodate|lru|active|swapbacked) Based on the page state, it looks like the page was still in use. The page flags do not make sense for the use case though. Further debugging showed that despite alloc_contig_range returning success, at least one page in the range still remained in the buddy allocator. There is an issue with isolate_freepages_block. In strict mode (which CMA uses), if any pages in the range cannot be isolated, isolate_freepages_block should return failure 0. The current check keeps track of the total number of isolated pages and compares against the size of the range: if (strict && nr_strict_required > total_isolated) total_isolated = 0; After taking the zone lock, if one of the pages in the range is not in the buddy allocator, we continue through the loop and do not increment total_isolated. If in the last iteration of the loop we isolate more than one page (e.g. last page needed is a higher order page), the check for total_isolated may pass and we fail to detect that a page was skipped. The fix is to bail out if the loop immediately if we are in strict mode. There's no benfit to continuing anyway since we need all pages to be isolated. Additionally, drop the error checking based on nr_strict_required and just check the pfn ranges. This matches with what isolate_freepages_range does. Signed-off-by: Laura Abbott Acked-by: Minchan Kim Cc: Mel Gorman Acked-by: Vlastimil Babka Cc: Joonsoo Kim Acked-by: Bartlomiej Zolnierkiewicz Acked-by: Michal Nazarewicz Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit e468205ed8decafbfb61fce73753826fe679a10b Author: Arnd Bergmann Date: Thu Mar 13 10:44:34 2014 +0100 vmxnet3: fix building without CONFIG_PCI_MSI commit 0a8d8c446b5429d15ff2d48f46e00d8a08552303 upstream. Since commit d25f06ea466e "vmxnet3: fix netpoll race condition", the vmxnet3 driver fails to build when CONFIG_PCI_MSI is disabled, because it unconditionally references the vmxnet3_msix_rx() function. To fix this, use the same #ifdef in the caller that exists around the function definition. Signed-off-by: Arnd Bergmann Cc: Neil Horman Cc: Shreyas Bhatewara Cc: "VMware, Inc." Cc: "David S. Miller" Acked-by: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 56ee1332074b525adba1fab6ce99c97403b665ae Author: Neil Horman Date: Mon Mar 10 06:55:55 2014 -0400 vmxnet3: fix netpoll race condition commit d25f06ea466ea521b563b76661180b4e44714ae6 upstream. vmxnet3's netpoll driver is incorrectly coded. It directly calls vmxnet3_do_poll, which is the driver internal napi poll routine. As the netpoll controller method doesn't block real napi polls in any way, there is a potential for race conditions in which the netpoll controller method and the napi poll method run concurrently. The result is data corruption causing panics such as this one recently observed: PID: 1371 TASK: ffff88023762caa0 CPU: 1 COMMAND: "rs:main Q:Reg" #0 [ffff88023abd5780] machine_kexec at ffffffff81038f3b #1 [ffff88023abd57e0] crash_kexec at ffffffff810c5d92 #2 [ffff88023abd58b0] oops_end at ffffffff8152b570 #3 [ffff88023abd58e0] die at ffffffff81010e0b #4 [ffff88023abd5910] do_trap at ffffffff8152add4 #5 [ffff88023abd5970] do_invalid_op at ffffffff8100cf95 #6 [ffff88023abd5a10] invalid_op at ffffffff8100bf9b [exception RIP: vmxnet3_rq_rx_complete+1968] RIP: ffffffffa00f1e80 RSP: ffff88023abd5ac8 RFLAGS: 00010086 RAX: 0000000000000000 RBX: ffff88023b5dcee0 RCX: 00000000000000c0 RDX: 0000000000000000 RSI: 00000000000005f2 RDI: ffff88023b5dcee0 RBP: ffff88023abd5b48 R8: 0000000000000000 R9: ffff88023a3b6048 R10: 0000000000000000 R11: 0000000000000002 R12: ffff8802398d4cd8 R13: ffff88023af35140 R14: ffff88023b60c890 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffff88023abd5b50] vmxnet3_do_poll at ffffffffa00f204a [vmxnet3] #8 [ffff88023abd5b80] vmxnet3_netpoll at ffffffffa00f209c [vmxnet3] #9 [ffff88023abd5ba0] netpoll_poll_dev at ffffffff81472bb7 The fix is to do as other drivers do, and have the poll controller call the top half interrupt handler, which schedules a napi poll properly to recieve frames Tested by myself, successfully. Signed-off-by: Neil Horman CC: Shreyas Bhatewara CC: "VMware, Inc." CC: "David S. Miller" Reviewed-by: Shreyas N Bhatewara Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 16cd17980ba1e24c2bfef4182f43487fac62a7a1 Author: Bjorn Helgaas Date: Tue Mar 11 14:22:19 2014 -0600 PCI: Enable INTx in pci_reenable_device() only when MSI/MSI-X not enabled commit 3cdeb713dc66057b50682048c151eae07b186c42 upstream. Andreas reported that after 1f42db786b14 ("PCI: Enable INTx if BIOS left them disabled"), pciehp surprise removal stopped working. This happens because pci_reenable_device() on the hotplug bridge (used in the pciehp_configure_device() path) clears the Interrupt Disable bit, which apparently breaks the bridge's MSI hotplug event reporting. Previously we cleared the Interrupt Disable bit in do_pci_enable_device(), which is used by both pci_enable_device() and pci_reenable_device(). But we use pci_reenable_device() after the driver may have enabled MSI or MSI-X, and we *set* Interrupt Disable as part of enabling MSI/MSI-X. This patch clears Interrupt Disable only when MSI/MSI-X has not been enabled. Fixes: 1f42db786b14 PCI: Enable INTx if BIOS left them disabled Link: https://bugzilla.kernel.org/show_bug.cgi?id=71691 Reported-and-tested-by: Andreas Noever Signed-off-by: Bjorn Helgaas CC: Sarah Sharp Signed-off-by: Jiri Slaby commit 8df3fd9ab9f107e78855bf52d48e1e99e5d931b3 Author: Radim Krčmář Date: Tue Mar 11 19:11:18 2014 +0100 KVM: SVM: fix cr8 intercept window commit 596f3142d2b7be307a1652d59e7b93adab918437 upstream. We always disable cr8 intercept in its handler, but only re-enable it if handling KVM_REQ_EVENT, so there can be a window where we do not intercept cr8 writes, which allows an interrupt to disrupt a higher priority task. Fix this by disabling intercepts in the same function that re-enables them when needed. This fixes BSOD in Windows 2008. Signed-off-by: Radim Krčmář Reviewed-by: Marcelo Tosatti Signed-off-by: Paolo Bonzini Signed-off-by: Jiri Slaby commit 4abc1815f205b6d48c7ba628359fac64392ff45c Author: Michael Kerrisk Date: Mon Mar 10 14:46:07 2014 +0100 ipc: Fix 2 bugs in msgrcv() MSG_COPY implementation commit 4f87dac386cc43d5525da7a939d4b4e7edbea22c upstream. While testing and documenting the msgrcv() MSG_COPY flag that Stanislav Kinsbursky added in commit 4a674f34ba04 ("ipc: introduce message queue copy feature" => kernel 3.8), I discovered a couple of bugs in the implementation. The two bugs concern MSG_COPY interactions with other msgrcv() flags, namely: (A) MSG_COPY + MSG_EXCEPT (B) MSG_COPY + !IPC_NOWAIT The bugs are distinct (and the fix for the first one is obvious), however my fix for both is a single-line patch, which is why I'm combining them in a single mail, rather than writing two mails+patches. ===== (A) MSG_COPY + MSG_EXCEPT ===== With the addition of the MSG_COPY flag, there are now two msgrcv() flags--MSG_COPY and MSG_EXCEPT--that modify the meaning of the 'msgtyp' argument in unrelated ways. Specifying both in the same call is a logical error that is currently permitted, with the effect that MSG_COPY has priority and MSG_EXCEPT is ignored. The call should give an error if both flags are specified. The patch below implements that behavior. ===== (B) (B) MSG_COPY + !IPC_NOWAIT ===== The test code that was submitted in commit 3a665531a3b7 ("selftests: IPC message queue copy feature test") shows MSG_COPY being used in conjunction with IPC_NOWAIT. In other words, if there is no message at the position 'msgtyp'. return immediately with the error in ENOMSG. What was not (fully) tested is the behavior if MSG_COPY is specified *without* IPC_NOWAIT, and there is an odd behavior. If the queue contains less than 'msgtyp' messages, then the call blocks until the next message is written to the queue. At that point, the msgrcv() call returns a copy of the newly added message, regardless of whether that message is at the ordinal position 'msgtyp'. This is clearly bogus, and problematic for applications that might want to make use of the MSG_COPY flag. I considered the following possible solutions to this problem: (1) Force the call to block until a message *does* appear at the position 'msgtyp'. (2) If the MSG_COPY flag is specified, the kernel should implicitly add IPC_NOWAIT, so that the call fails with ENOMSG for this case. (3) If the MSG_COPY flag is specified, but IPC_NOWAIT is not, generate an error (probably, EINVAL is the right one). I do not know if any application would really want to have the functionality of solution (1), especially since an application can determine in advance the number of messages in the queue using msgctl() IPC_STAT. Obviously, this solution would be the most work to implement. Solution (2) would have the effect of silently fixing any applications that tried to employ broken behavior. However, it would mean that if we later decided to implement solution (1), then user-space could not easily detect what the kernel supports (but, since I'm somewhat doubtful that solution (1) is needed, I'm not sure that this is much of a problem). Solution (3) would have the effect of informing broken applications that they are doing something broken. The downside is that this would cause a ABI breakage for any applications that are currently employing the broken behavior. However: a) Those applications are almost certainly not getting the results they expect. b) Possibly, those applications don't even exist, because MSG_COPY is currently hidden behind CONFIG_CHECKPOINT_RESTORE. The upside of solution (3) is that if we later decided to implement solution (1), user-space could determine what the kernel supports, via the error return. In my view, solution (3) is mildly preferable to solution (2), and solution (1) could still be done later if anyone really cares. The patch below implements solution (3). PS. For anyone out there still listening, it's the usual story: documenting an API (and the thinking about, and the testing of the API, that documentation entails) is the one of the single best ways of finding bugs in the API, as I've learned from a lot of experience. Best to do that documentation before releasing the API. Signed-off-by: Michael Kerrisk Acked-by: Stanislav Kinsbursky Cc: Stanislav Kinsbursky Cc: Serge Hallyn Cc: "Eric W. Biederman" Cc: Pavel Emelyanov Cc: Al Viro Cc: KOSAKI Motohiro Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 726d5fbdd3386d9a01427b8bccbe32ca9c2af8d2 Author: Richard Weinberger Date: Sun Feb 9 19:47:40 2014 +0100 i2c: Remove usage of orphaned symbol OF_I2C commit 62c19c9d29e65086e5ae76df371ed2e6b23f00cd upstream. The symbol is an orphan, don't depend on it anymore. Signed-off-by: Richard Weinberger [wsa: enhanced commit message] Signed-off-by: Wolfram Sang Fixes: 687b81d083c0 (i2c: move OF helpers into the core) Signed-off-by: Jiri Slaby commit 9471e393d4864e4c07b973f5583de8be316c606b Author: Alex Deucher Date: Tue Feb 18 10:14:46 2014 -0500 drm/radeon/si: fix typo in dpm sq ramping setup commit 5b43c3cd07981619dbdb1fb935ef705a3e80955f upstream. inverted logic. Noticed-by: Sylvain BERTRAND Signed-off-by: Alex Deucher Signed-off-by: Jiri Slaby commit 5a075bee691728c80deff9fd404eccbb58c58ecd Author: Alex Deucher Date: Fri Jan 17 12:34:55 2014 -0500 drm/radeon: fix minor typos in si_dpm.c commit 407b6dfd9afa30cf963fa99bca91870e47965612 upstream. Copy/paste typos from the ni code. Should not have any functional change. Signed-off-by: Alex Deucher Signed-off-by: Jiri Slaby commit be9a7549a6a6fc7d2ccb32630e866c7b701dfabd Author: Alex Deucher Date: Wed Mar 12 16:20:44 2014 -0400 drm/radeon/cik: properly set compute ring status on disable commit b2b3d8d952e4f8d6ac2ce80be96b937f29f6e42e upstream. When we disable the rings, set the status properly. If not other code pathes may try and use the rings which are not functional at this point. Signed-off-by: Alex Deucher Signed-off-by: Jiri Slaby commit 609018add187a803380803a7f3b38665ec06c316 Author: Alex Deucher Date: Wed Mar 12 15:26:34 2014 -0400 drm/radeon/cik: stop the sdma engines in the enable() function commit 07ae78c9798b79bad3d3adf983c94ba23fde54d4 upstream. We always stop the rings when disabling the engines so just call the stop functions directly from the sdma enable function. This way the rings' status is set correctly on suspend so there are no problems on resume. Fixes resume failures that result in acceleration getting disabled. Signed-off-by: Alex Deucher Signed-off-by: Jiri Slaby commit 703ee1e3778f1d287b5e4d902285ab64a124f519 Author: Alex Deucher Date: Wed Mar 12 15:15:58 2014 -0400 drm/radeon/cik: properly set sdma ring status on disable commit 7b1bbe883b3ed962ca2be4daf321f318f5091340 upstream. When we disable the rings, set the status properly. If not other code pathes may try and use the rings which are not functional at this point. Signed-off-by: Alex Deucher Signed-off-by: Jiri Slaby commit 62871f155922ac201f45c7178c5e0bb568ab6d50 Author: Alex Deucher Date: Wed Dec 18 19:11:27 2013 -0500 drm/radeon: re-order firmware loading in preparation for dpm rework commit 01ac8794a77192236a4b91c33adf4177ac5a21f0 upstream. We need to reorder the driver init sequence to better accomodate dpm which needs to be loaded earlier in the init sequence. Move fw init up so that it's available for dpm init. Signed-off-by: Alex Deucher Signed-off-by: Jiri Slaby commit c846e5a072d1002eb727960b7892094c1b2d1498 Author: Ville Syrjälä Date: Mon Mar 3 11:33:36 2014 +0200 drm/i915: Reject >165MHz modes w/ DVI monitors commit 6375b768a9850b6154478993e5fb566fa4614a9c upstream. Single-link DVI max dotclock is 165MHz. Filter out modes with higher dotclock when the monitor doesn't support HDMI. Modes higher than 165 MHz were allowed in commit 7d148ef51a657fd04036c3ed7803da600dd0d451 Author: Daniel Vetter Date: Mon Jul 22 18:02:39 2013 +0200 drm/i915: fix hdmi portclock limits Also don't attempt to use 12bpc mode with DVI monitors. Cc: Adam Nielsen Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75345 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=70331 Tested-by: Ralf Jung Signed-off-by: Ville Syrjälä Signed-off-by: Jani Nikula Signed-off-by: Jiri Slaby commit f6c82e46afdf09e346ff9c7f5fe2075cc8f38a35 Author: Imre Deak Date: Fri Feb 14 20:23:54 2014 +0200 drm/i915: fix pch pci device enumeration commit bcdb72ac7c00d2b56359fc82bcc8fe50454717d5 upstream. pci_get_class(class, from) drops the refcount for 'from', so the extra pci_dev_put we do on it will result in a use after free bug starting with the WARN below. Regression introduced in commit 6a9c4b35e6696a63805b6da5e4889c6986e9ee1b Author: Rui Guo Date: Wed Jun 19 21:10:23 2013 +0800 drm/i915: Fix PCH detect with multiple ISA bridges in VM [ 164.338460] WARNING: CPU: 1 PID: 2094 at include/linux/kref.h:47 klist_next+0xae/0x110() [ 164.347731] CPU: 1 PID: 2094 Comm: modprobe Tainted: G O 3.13.0-imre+ #354 [ 164.356468] Hardware name: Intel Corp. VALLEYVIEW B0 PLATFORM/NOTEBOOK, BIOS BYTICRB1.X64.0062.R70.1310112051 10/11/2013 [ 164.368796] Call Trace: [ 164.371609] [] dump_stack+0x4e/0x7a [ 164.377447] [] warn_slowpath_common+0x7d/0xa0 [ 164.384238] [] warn_slowpath_null+0x1a/0x20 [ 164.390851] [] klist_next+0xae/0x110 [ 164.396777] [] ? pci_do_find_bus+0x70/0x70 [ 164.403286] [] bus_find_device+0x89/0xc0 [ 164.409719] [] pci_get_dev_by_id+0x63/0xa0 [ 164.416238] [] pci_get_class+0x44/0x50 [ 164.422433] [] intel_dsm_detect+0x16f/0x1f0 [i915] [ 164.429801] [] intel_register_dsm_handler+0xe/0x10 [i915] [ 164.437831] [] i915_driver_load+0xafe/0xf30 [i915] [ 164.445126] [] ? intel_alloc_coherent+0x110/0x110 [ 164.452340] [] drm_dev_register+0xc7/0x150 [drm] [ 164.459462] [] drm_get_pci_dev+0x11f/0x1f0 [drm] [ 164.466554] [] ? _raw_spin_unlock_irqrestore+0x51/0x70 [ 164.474287] [] i915_pci_probe+0x56/0x60 [i915] [ 164.481185] [] pci_device_probe+0x78/0xf0 [ 164.487603] [] driver_probe_device+0x155/0x350 [ 164.494505] [] __driver_attach+0x6e/0xa0 [ 164.500826] [] ? __device_attach+0x50/0x50 [ 164.507333] [] bus_for_each_dev+0x6e/0xc0 [ 164.513752] [] driver_attach+0x1e/0x20 [ 164.519870] [] bus_add_driver+0x138/0x260 [ 164.526289] [] ? 0xffffffffa0187fff [ 164.532116] [] driver_register+0x98/0xe0 [ 164.538558] [] ? 0xffffffffa0187fff [ 164.544389] [] __pci_register_driver+0x60/0x70 [ 164.551336] [] drm_pci_init+0x6d/0x120 [drm] [ 164.558040] [] ? 0xffffffffa0187fff [ 164.563928] [] i915_init+0x6a/0x6c [i915] [ 164.570363] [] do_one_initcall+0xaa/0x160 [ 164.576783] [] ? set_memory_nx+0x40/0x50 [ 164.583100] [] load_module+0x1fb5/0x2550 [ 164.589410] [] ? store_uevent+0x40/0x40 [ 164.595628] [] SyS_init_module+0xed/0x100 [ 164.602048] [] system_call_fastpath+0x16/0x1b v2: simplify the loop further (Chris) Signed-off-by: Imre Deak Cc: Jesse Barnes Reported-by: Jesse Barnes Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65652 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74161 Reviewed-by: Chris Wilson Signed-off-by: Jani Nikula Signed-off-by: Jiri Slaby commit 82c8672994e37ed6bb4d92613daa8c5b2d1db28e Author: Alex Deucher Date: Thu Mar 6 13:16:55 2014 -0500 drm/radeon/dpm: fix typo in EVERGREEN_SMC_FIRMWARE_HEADER_softRegisters commit 13714323f83ffa5a772fe0d8b74e0fa32ee08819 upstream. Should be at 0x8 rather than 0. fixes: https://bugzilla.kernel.org/show_bug.cgi?id=60523 Noticed by ArtForz on #radeon Signed-off-by: Alex Deucher Signed-off-by: Jiri Slaby commit 59fdd4e489f665af2b37469ffd9ffa3c97d9d391 Author: Alex Deucher Date: Thu Mar 6 18:09:52 2014 -0500 drm/radeon/atom: select the proper number of lanes in transmitter setup commit d03874c881a049a50e12f285077ab1f9fc2686e1 upstream. We need to check for DVI vs. HDMI when setting up duallink since HDMI is single link only. Fixes 4k modes on newer asics. bug: https://bugs.freedesktop.org/show_bug.cgi?id=75223 Signed-off-by: Alex Deucher Signed-off-by: Jiri Slaby commit ccd13098cecd44d9b0694270100a700c46d52c28 Author: Artem Fetishev Date: Mon Mar 10 15:49:45 2014 -0700 fs/proc/base.c: fix GPF in /proc/$PID/map_files commit 70335abb2689c8cd5df91bf2d95a65649addf50b upstream. The expected logic of proc_map_files_get_link() is either to return 0 and initialize 'path' or return an error and leave 'path' uninitialized. By the time dname_to_vma_addr() returns 0 the corresponding vma may have already be gone. In this case the path is not initialized but the return value is still 0. This results in 'general protection fault' inside d_path(). Steps to reproduce: CONFIG_CHECKPOINT_RESTORE=y fd = open(...); while (1) { mmap(fd, ...); munmap(fd, ...); } ls -la /proc/$PID/map_files Addresses https://bugzilla.kernel.org/show_bug.cgi?id=68991 Signed-off-by: Artem Fetishev Signed-off-by: Aleksandr Terekhov Reported-by: Acked-by: Pavel Emelyanov Acked-by: Cyrill Gorcunov Reviewed-by: "Eric W. Biederman" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit ed279ab0b9662a197ddd26ba248272a693f0329f Author: Nicholas Bellinger Date: Wed Feb 26 03:09:41 2014 -0800 iscsi-target: Fix iscsit_get_tpg_from_np tpg_state bug commit a2a99cea5ec7c1e47825559f0e75a4efbcf8aee3 upstream. This patch fixes a bug in iscsit_get_tpg_from_np() where the tpg->tpg_state sanity check was looking for TPG_STATE_FREE, instead of != TPG_STATE_ACTIVE. The latter is expected during a normal TPG shutdown once the tpg_state goes into TPG_STATE_INACTIVE in order to reject any new incoming login attempts. Signed-off-by: Nicholas Bellinger Signed-off-by: Jiri Slaby commit a45288994f370d0d3014332acfe65207459818d2 Author: Nicholas Bellinger Date: Thu Feb 27 09:05:03 2014 -0800 iser-target: Fix post_send_buf_count for RDMA READ/WRITE commit b6b87a1df604678ed1be40158080db012a99ccca upstream. This patch fixes the incorrect setting of ->post_send_buf_count related to RDMA WRITEs + READs where isert_rdma_rw->send_wr_num was not being taken into account. This includes incrementing ->post_send_buf_count within isert_put_datain() + isert_get_dataout(), decrementing within __isert_send_completion() + isert_response_completion(), and clearing wr->send_wr_num within isert_completion_rdma_read() This is necessary because even though IB_SEND_SIGNALED is not set for RDMA WRITEs + READs, during a QP failure event the work requests will be returned with exception status from the TX completion queue. Acked-by: Sagi Grimberg Cc: Or Gerlitz Signed-off-by: Nicholas Bellinger Signed-off-by: Jiri Slaby commit 59be23a78272e2dc17ea39f4ea47f8798c0ecd4f Author: Nicholas Bellinger Date: Thu Feb 27 07:02:48 2014 -0800 iser-target: Ignore completions for FRWRs in isert_cq_tx_work commit 9bb4ca68fc48eea618b1af1c1cde2a251ae32d1b upstream. This patch changes IB_WR_FAST_REG_MR + IB_WR_LOCAL_INV related work requests to include a ISER_FRWR_LI_WRID value in order to signal isert_cq_tx_work() that these requests should be ignored. This is necessary because even though IB_SEND_SIGNALED is not set for either work request, during a QP failure event the work requests will be returned with exception status from the TX completion queue. v2 changes: - Rename ISER_FRWR_LI_WRID -> ISER_FASTREG_LI_WRID (Sagi) Acked-by: Sagi Grimberg Cc: Or Gerlitz Signed-off-by: Nicholas Bellinger Signed-off-by: Jiri Slaby commit 2f82fa987df6b060241fc760eadf5dd02c51a979 Author: Nicholas Bellinger Date: Mon Feb 3 12:54:39 2014 -0800 iscsi/iser-target: Fix isert_conn->state hung shutdown issues commit defd884845297fd5690594bfe89656b01f16d87e upstream. This patch addresses a couple of different hug shutdown issues related to wait_event() + isert_conn->state. First, it changes isert_conn->conn_wait + isert_conn->conn_wait_comp_err from waitqueues to completions, and sets ISER_CONN_TERMINATING from within isert_disconnect_work(). Second, it splits isert_free_conn() into isert_wait_conn() that is called earlier in iscsit_close_connection() to ensure that all outstanding commands have completed before continuing. Finally, it breaks isert_cq_comp_err() into seperate TX / RX related code, and adds logic in isert_cq_rx_comp_err() to wait for outstanding commands to complete before setting ISER_CONN_DOWN and calling complete(&isert_conn->conn_wait_comp_err). Acked-by: Sagi Grimberg Cc: Or Gerlitz Signed-off-by: Nicholas Bellinger Signed-off-by: Jiri Slaby commit e150903c747b642896a2807a4567faa7f002f3a7 Author: Nicholas Bellinger Date: Mon Feb 3 12:53:51 2014 -0800 iscsi/iser-target: Use list_del_init for ->i_conn_node commit 5159d763f60af693a3fcec45dce2021f66e528a4 upstream. There are a handful of uses of list_empty() for cmd->i_conn_node within iser-target code that expect to return false once a cmd has been removed from the per connect list. This patch changes all uses of list_del -> list_del_init in order to ensure that list_empty() returns false as expected. Acked-by: Sagi Grimberg Cc: Or Gerlitz Signed-off-by: Nicholas Bellinger Signed-off-by: Jiri Slaby commit 8eb0508cc0ce870329ff9c2427fe640e903d47c0 Author: Rafael J. Wysocki Date: Thu Mar 13 22:11:39 2014 +0100 ACPI / sleep: Add extra checks for HW Reduced ACPI mode sleep states commit a4e90bed511220ff601d064c9e5d583e91308f65 upstream. If the HW Reduced ACPI mode bit is set in the FADT, ACPICA uses the optional sleep control and sleep status registers for making the system enter sleep states (including S5), so it is not possible to use system sleep states or power it off using ACPI if the HW Reduced ACPI mode bit is set and those registers are not available. For this reason, add a new function, acpi_sleep_state_supported(), checking if the HW Reduced ACPI mode bit is set and whether or not system sleep states are usable in that case in addition to checking the return value of acpi_get_sleep_type_data() and make the ACPI sleep setup routines use that function to check the availability of system sleep states. Among other things, this prevents the kernel from attempting to use ACPI for powering off HW Reduced ACPI systems without the sleep control and sleep status registers, because ACPI power off doesn't have a chance to work on them. That allows alternative power off mechanisms that may actually work to be used on those systems. The affected machines include Dell Venue 8 Pro, Asus T100TA, Haswell Desktop SDP and Ivy Bridge EP Demo depot. References: https://bugzilla.kernel.org/show_bug.cgi?id=70931 Reported-by: Adam Williamson Tested-by: Aubrey Li Signed-off-by: Rafael J. Wysocki Signed-off-by: Jiri Slaby commit ff3918ebdc2d35c0e57b6aa8c32098f40ab83bd0 Author: Trond Myklebust Date: Wed Mar 5 08:44:23 2014 -0500 NFSv4: nfs4_stateid_is_current should return 'true' for an invalid stateid commit e1253be0ece1a95a02c7f5843194877471af8179 upstream. When nfs4_set_rw_stateid() can fails by returning EIO to indicate that the stateid is completely invalid, then it makes no sense to have it trigger a retry of the READ or WRITE operation. Instead, we should just have it fall through and attempt a recovery. This fixes an infinite loop in which the client keeps replaying the same bad stateid back to the server. Reported-by: Andy Adamson Link: http://lkml.kernel.org/r/1393954269-3974-1-git-send-email-andros@netapp.com Signed-off-by: Trond Myklebust Signed-off-by: Jiri Slaby commit 793c6f9509f87e2918a551e88605d833cacc9546 Author: Trond Myklebust Date: Sun Mar 2 22:03:12 2014 -0500 NFS: Fix a delegation callback race commit 755a48a7a4eb05b9c8424e3017d947b2961a60e0 upstream. The clean-up in commit 36281caa839f ended up removing a NULL pointer check that is needed in order to prevent an Oops in nfs_async_inode_return_delegation(). Reported-by: "Yan, Zheng" Link: http://lkml.kernel.org/r/5313E9F6.2020405@intel.com Fixes: 36281caa839f (NFSv4: Further clean-ups of delegation stateid validation) Signed-off-by: Trond Myklebust Signed-off-by: Jiri Slaby commit 0a7bc8661cf5b00ed5d6db543e820972f813c442 Author: Gabor Juhos Date: Sun Mar 2 20:54:42 2014 +0100 spi: spi-ath79: fix initial GPIO CS line setup commit 61d1cf163c8653934cc8cd5d0b2a562d0990c265 upstream. The 'ath79_spi_setup_cs' function initializes the chip select line of a given SPI device in order to make sure that the device is inactive. If the SPI_CS_HIGH bit is set for a given device, it means that the CS line of that device is active HIGH so it must be set to LOW initially. In case of GPIO CS lines, the 'ath79_spi_setup_cs' function does the opposite of that due to the wrong GPIO flags. Fix the code to use the correct GPIO flags. Reported-by: Ronald Wahl Signed-off-by: Gabor Juhos Signed-off-by: Mark Brown Signed-off-by: Jiri Slaby commit d8e172f3c0a5b1456071b1f4483393fcf3deb20b Author: Philippe De Muyter Date: Thu Feb 27 10:16:15 2014 +0100 spi: spi-imx: spi_imx_remove: do not disable disabled clocks commit fd40dccb1a170ba689664481a3de83617b7194d2 upstream. Currently, at module removal, one gets the following warnings: ------------[ cut here ]------------ WARNING: at drivers/clk/clk.c:780 clk_disable+0x18/0x24() Modules linked in: spi_imx(-) [last unloaded: ev76c560] CPU: 1 PID: 16337 Comm: rmmod Tainted: G W 3.10.17-80548-g90191eb-dirty #33 [<80013b4c>] (unwind_backtrace+0x0/0xf8) from [<800115dc>] (show_stack+0x10/0x14) [<800115dc>] (show_stack+0x10/0x14) from [<800257b8>] (warn_slowpath_common+0x4c/0x68) [<800257b8>] (warn_slowpath_common+0x4c/0x68) from [<800257f0>] (warn_slowpath_null+0x1c/0x24) [<800257f0>] (warn_slowpath_null+0x1c/0x24) from [<803f60ec>] (clk_disable+0x18/0x24) [<803f60ec>] (clk_disable+0x18/0x24) from [<7f02c9cc>] (spi_imx_remove+0x54/0x9c [spi_imx]) [<7f02c9cc>] (spi_imx_remove+0x54/0x9c [spi_imx]) from [<8025868c>] (platform_drv_remove+0x18/0x1c) [<8025868c>] (platform_drv_remove+0x18/0x1c) from [<80256f60>] (__device_release_driver+0x70/0xcc) [<80256f60>] (__device_release_driver+0x70/0xcc) from [<80257770>] (driver_detach+0xcc/0xd0) [<80257770>] (driver_detach+0xcc/0xd0) from [<80256d90>] (bus_remove_driver+0x7c/0xc0) [<80256d90>] (bus_remove_driver+0x7c/0xc0) from [<80068668>] (SyS_delete_module+0x144/0x1f8) [<80068668>] (SyS_delete_module+0x144/0x1f8) from [<8000e080>] (ret_fast_syscall+0x0/0x30) ---[ end trace 1f5df9ad54996300 ]--- ------------[ cut here ]------------ WARNING: at drivers/clk/clk.c:780 clk_disable+0x18/0x24() Modules linked in: spi_imx(-) [last unloaded: ev76c560] CPU: 1 PID: 16337 Comm: rmmod Tainted: G W 3.10.17-80548-g90191eb-dirty #33 [<80013b4c>] (unwind_backtrace+0x0/0xf8) from [<800115dc>] (show_stack+0x10/0x14) [<800115dc>] (show_stack+0x10/0x14) from [<800257b8>] (warn_slowpath_common+0x4c/0x68) [<800257b8>] (warn_slowpath_common+0x4c/0x68) from [<800257f0>] (warn_slowpath_null+0x1c/0x24) [<800257f0>] (warn_slowpath_null+0x1c/0x24) from [<803f60ec>] (clk_disable+0x18/0x24) [<803f60ec>] (clk_disable+0x18/0x24) from [<7f02c9e8>] (spi_imx_remove+0x70/0x9c [spi_imx]) [<7f02c9e8>] (spi_imx_remove+0x70/0x9c [spi_imx]) from [<8025868c>] (platform_drv_remove+0x18/0x1c) [<8025868c>] (platform_drv_remove+0x18/0x1c) from [<80256f60>] (__device_release_driver+0x70/0xcc) [<80256f60>] (__device_release_driver+0x70/0xcc) from [<80257770>] (driver_detach+0xcc/0xd0) [<80257770>] (driver_detach+0xcc/0xd0) from [<80256d90>] (bus_remove_driver+0x7c/0xc0) [<80256d90>] (bus_remove_driver+0x7c/0xc0) from [<80068668>] (SyS_delete_module+0x144/0x1f8) [<80068668>] (SyS_delete_module+0x144/0x1f8) from [<8000e080>] (ret_fast_syscall+0x0/0x30) ---[ end trace 1f5df9ad54996301 ]--- Since commit 9e556dcc55774c9a1032f32baa0e5cfafede8b70, "spi: spi-imx: only enable the clocks when we start to transfer a message", clocks are always disabled except when transmitting messages. There is thus no need to disable them at module removal. Fixes: 9e556dcc55774 (spi: spi-imx: only enable the clocks when we start to transfer a message) Signed-off-by: Philippe De Muyter Acked-by: Huang Shijie Signed-off-by: Mark Brown Signed-off-by: Jiri Slaby commit c9381cae8a2072c53bea7cd87c5ec517a1545121 Author: Axel Lin Date: Fri Feb 14 12:49:12 2014 +0800 spi: fsl-dspi: Fix getting correct address for master commit 017145fef567430789e40f6a22a90ce2a766370b upstream. Current code set platform drvdata to dspi. However, the code in dspi_suspend() and dspi_resume() assumes the drvdata is the address of master. Fix it by setting platform drvdata to master. Signed-off-by: Axel Lin Signed-off-by: Mark Brown Signed-off-by: Jiri Slaby commit 4a0e004916ab80a3608e54f895af21d08ab36d08 Author: Axel Lin Date: Fri Feb 14 09:53:00 2014 +0800 spi: coldfire-qspi: Fix getting correct address for *mcfqspi commit ee73b4c6e3fc0755a91752ab8eebc8e070038b53 upstream. dev_get_drvdata() returns the address of master rather than mcfqspi. Fixes: af361079 (spi/coldfire-qspi: Drop extra calls to spi_master_get in suspend/resume functions) Signed-off-by: Axel Lin Signed-off-by: Mark Brown Signed-off-by: Jiri Slaby commit 04da573274f14d9167901f6b8b38d7cc521f08ac Author: Tejun Heo Date: Mon Mar 10 11:13:43 2014 -0400 libata: use wider match for blacklisting Crucial M500 commit 83493d7e782d2630f1a55def14a79f0e7c4faac3 upstream. We're now blacklisting "Crucial_CT???M500SSD1" and "Crucial_CT???M500SSD3". Also, "Micron_M500*" is blacklisted which is about the same devices as the crucial branded ones. Let's merge the two Crucial M500 entries and widen the match to "Crucial_CT???M500SSD*" so that we don't have to fiddle with new entries for similar devices. Signed-off-by: Tejun Heo Suggested-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 2d5a0832a2a8258291d97fcd0cee4425de1dc0a3 Author: Michele Baldessari Date: Fri Mar 7 16:34:29 2014 +0000 libata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk for Seagate Momentus SpinPoint M8 (2BA30001) commit b28a613e9138e4b3a64649bd60b13436f4b4b49b upstream. Via commit 87809942d3fa "libata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk for Seagate Momentus SpinPoint M8" we added a quirk for disks named "ST1000LM024 HN-M101MBB" with firmware revision "2AR10001". As reported on https://bugzilla.redhat.com/show_bug.cgi?id=1073901, we need to also add firmware revision 2BA30001 as it is broken as well. Reported-by: Nicholas Signed-off-by: Michele Baldessari Tested-by: Guilherme Amadio Signed-off-by: Tejun Heo Signed-off-by: Jiri Slaby commit e98da7baab3bbb4cfcc60ab24a91b64c650c39d1 Author: Marios Andreopoulos Date: Mon Mar 3 18:19:59 2014 +0200 libata: disable queued TRIM for Crucial M500 mSATA SSDs commit 2564338b13e6e132ee224edb63e1e872adf431f4 upstream. Queued TRIM commands cause problems and silent file system corruption on Crucial M500 SSDs. This patch disables them for the mSATA model of the drive. Signed-off-by: Marios Andreopoulos Signed-off-by: Tejun Heo Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=71371 Signed-off-by: Jiri Slaby commit 0f72d5c490bc4e5b84829cce251266d485663cb6 Author: Tejun Heo Date: Fri Mar 7 10:19:57 2014 -0500 firewire: don't use PREPARE_DELAYED_WORK commit 70044d71d31d6973665ced5be04ef39ac1c09a48 upstream. PREPARE_[DELAYED_]WORK() are being phased out. They have few users and a nasty surprise in terms of reentrancy guarantee as workqueue considers work items to be different if they don't have the same work function. firewire core-device and sbp2 have been been multiplexing work items with multiple work functions. Introduce fw_device_workfn() and sbp2_lu_workfn() which invoke fw_device->workfn and sbp2_logical_unit->workfn respectively and always use the two functions as the work functions and update the users to set the ->workfn fields instead of overriding work functions using PREPARE_DELAYED_WORK(). This fixes a variety of possible regressions since a2c1c57be8d9 "workqueue: consider work function when searching for busy work items" due to which fw_workqueue lost its required non-reentrancy property. Signed-off-by: Tejun Heo Acked-by: Stefan Richter Cc: linux1394-devel@lists.sourceforge.net Signed-off-by: Jiri Slaby commit b51610cdf9dc5b4e0cc09d7f239afc2d44ffd419 Author: Stefan Richter Date: Thu Mar 6 20:39:04 2014 +0100 firewire: ohci: fix probe failure with Agere/LSI controllers commit 0ca49345b6f489e95f8d6edeb0b092e257475b2a upstream. Since commit bd972688eb24 "firewire: ohci: Fix 'failed to read phy reg' on FW643 rev8", there is a high chance that firewire-ohci fails to initialize LSI née Agere controllers. https://bugzilla.kernel.org/show_bug.cgi?id=65151 Peter Hurley points out the reason: IEEE 1394a:2000 clause 5A.1 (or IEEE 1394:2008 clause 17.2.1) say: "The PHY shall insure that no more than 10 ms elapse from the reassertion of LPS until the interface is reset. The link shall not assert LReq until the reset is complete." In other words, the link needs to give the PHY at least 10 ms to get the interface operational. With just the msleep(1) in bd972688eb24, the first read_phy_reg() during ohci_enable() may happen before the phy-link interface reset was finished, and fail. Due to the high variability of msleep(n) with small n, this failure was not fully reproducible, and not apparent at all with low CONFIG_HZ setting. On the other hand, Peter can no longer reproduce the issue with FW643 rev8. The read phy reg failures that happened back then may have had an unrelated cause. So, just revert bd972688eb24, except for the valid comment on TSB82AA2 cards. Reported-by: Mikhail Gavrilov Reported-by: Jay Fenlason Reported-by: Clemens Ladisch Reported-by: Peter Hurley Signed-off-by: Stefan Richter Signed-off-by: Jiri Slaby commit 52fa2d887232da81aee604c560db9383a2d1369e Author: Stefan Richter Date: Tue Feb 18 22:25:15 2014 +0100 firewire: net: fix use after free commit 8987583366ae9e03c306c2b7d73bdb952df1d08d upstream. Commit 8408dc1c14c1 "firewire: net: use dev_printk API" introduced a use-after-free in a failure path. fwnet_transmit_packet_failed(ptask) may free ptask, then the dev_err() call dereferenced it. The fix is straightforward; simply reorder the two calls. Reported-by: Dan Carpenter Signed-off-by: Stefan Richter Signed-off-by: Jiri Slaby commit 95a3d2c55f8f15f8219816baf4e4c705ea992bbe Author: Steven Rostedt (Red Hat) Date: Wed Feb 26 13:37:38 2014 -0500 tracing: Do not add event files for modules that fail tracepoints commit 45ab2813d40d88fc575e753c38478de242d03f88 upstream. If a module fails to add its tracepoints due to module tainting, do not create the module event infrastructure in the debugfs directory. As the events will not work and worse yet, they will silently fail, making the user wonder why the events they enable do not display anything. Having a warning on module load and the events not visible to the users will make the cause of the problem much clearer. Link: http://lkml.kernel.org/r/20140227154923.265882695@goodmis.org Fixes: 6d723736e472 "tracing/events: add support for modules to TRACE_EVENT" Acked-by: Mathieu Desnoyers Cc: Rusty Russell Signed-off-by: Steven Rostedt Signed-off-by: Jiri Slaby commit b0aae58d43d0678287b5ff19560b5fb10941af6c Author: Kieran Clancy Date: Sat Mar 1 00:42:28 2014 +1030 ACPI / EC: Clear stale EC events on Samsung systems commit ad332c8a45330d170bb38b95209de449b31cd1b4 upstream. A number of Samsung notebooks (530Uxx/535Uxx/540Uxx/550Pxx/900Xxx/etc) continue to log events during sleep (lid open/close, AC plug/unplug, battery level change), which accumulate in the EC until a buffer fills. After the buffer is full (tests suggest it holds 8 events), GPEs stop being triggered for new events. This state persists on wake or even on power cycle, and prevents new events from being registered until the EC is manually polled. This is the root cause of a number of bugs, including AC not being detected properly, lid close not triggering suspend, and low ambient light not triggering the keyboard backlight. The bug also seemed to be responsible for performance issues on at least one user's machine. Juan Manuel Cabo found the cause of bug and the workaround of polling the EC manually on wake. The loop which clears the stale events is based on an earlier patch by Lan Tianyu (see referenced attachment). This patch: - Adds a function acpi_ec_clear() which polls the EC for stale _Q events at most ACPI_EC_CLEAR_MAX (currently 100) times. A warning is logged if this limit is reached. - Adds a flag EC_FLAGS_CLEAR_ON_RESUME which is set to 1 if the DMI system vendor is Samsung. This check could be replaced by several more specific DMI vendor/product pairs, but it's likely that the bug affects more Samsung products than just the five series mentioned above. Further, it should not be harmful to run acpi_ec_clear() on systems without the bug; it will return immediately after finding no data waiting. - Runs acpi_ec_clear() on initialisation (boot), from acpi_ec_add() - Runs acpi_ec_clear() on wake, from acpi_ec_unblock_transactions() References: https://bugzilla.kernel.org/show_bug.cgi?id=44161 References: https://bugzilla.kernel.org/show_bug.cgi?id=45461 References: https://bugzilla.kernel.org/show_bug.cgi?id=57271 References: https://bugzilla.kernel.org/attachment.cgi?id=126801 Suggested-by: Juan Manuel Cabo Signed-off-by: Kieran Clancy Reviewed-by: Lan Tianyu Reviewed-by: Dennis Jansen Tested-by: Kieran Clancy Tested-by: Juan Manuel Cabo Tested-by: Dennis Jansen Tested-by: Maurizio D'Addona Tested-by: San Zamoyski Signed-off-by: Rafael J. Wysocki Signed-off-by: Jiri Slaby commit 1ddeb7b86737d0ec23b230d4df0b4663646a9442 Author: Zhang Rui Date: Thu Feb 27 11:37:15 2014 +0800 ACPI / resources: ignore invalid ACPI device resources commit b355cee88e3b1a193f0e9a81db810f6f83ad728b upstream. ACPI table may export resource entry with 0 length. But the current code interprets this kind of resource in a wrong way. It will create a resource structure with res->end = acpi_resource->start + acpi_resource->len - 1; This patch fixes a problem on my machine that a platform device fails to be created because one of its ACPI IO resource entry (start = 0, end = 0, length = 0) is translated into a generic resource with start = 0, end = 0xffffffff. Signed-off-by: Zhang Rui Signed-off-by: Rafael J. Wysocki Signed-off-by: Jiri Slaby commit 44ba741a0f470c22c691586dea1e219df757fef2 Author: Li Zefan Date: Thu Feb 27 18:19:36 2014 +0800 cpuset: fix a race condition in __cpuset_node_allowed_softwall() commit 99afb0fd5f05aac467ffa85c36778fec4396209b upstream. It's not safe to access task's cpuset after releasing task_lock(). Holding callback_mutex won't help. Signed-off-by: Li Zefan Signed-off-by: Tejun Heo Signed-off-by: Jiri Slaby commit d1275b0297b1995a15aab2361f4051684c18a2ea Author: Li Zefan Date: Thu Feb 27 18:19:03 2014 +0800 cpuset: fix a locking issue in cpuset_migrate_mm() commit 4729583006772b9530404bc1bb7c3aa4a10ffd4d upstream. I can trigger a lockdep warning: # mount -t cgroup -o cpuset xxx /cgroup # mkdir /cgroup/cpuset # mkdir /cgroup/tmp # echo 0 > /cgroup/tmp/cpuset.cpus # echo 0 > /cgroup/tmp/cpuset.mems # echo 1 > /cgroup/tmp/cpuset.memory_migrate # echo $$ > /cgroup/tmp/tasks # echo 1 > /cgruop/tmp/cpuset.mems =============================== [ INFO: suspicious RCU usage. ] 3.14.0-rc1-0.1-default+ #32 Not tainted ------------------------------- include/linux/cgroup.h:682 suspicious rcu_dereference_check() usage! ... [] dump_stack+0x72/0x86 [] lockdep_rcu_suspicious+0x101/0x140 [] cpuset_migrate_mm+0xb1/0xe0 ... We used to hold cgroup_mutex when calling cpuset_migrate_mm(), but now we hold cpuset_mutex, which causes task_css() to complain. This is not a false-positive but a real issue. Holding cpuset_mutex won't prevent a task from migrating to another cpuset, and it won't prevent the original task->cgroup from destroying during this change. Fixes: 5d21cc2db040 (cpuset: replace cgroup_mutex locking with cpuset internal locking) Signed-off-by: Li Zefan Sigend-off-by: Tejun Heo Signed-off-by: Jiri Slaby commit f81d190308865eea6f2d49f1094bf534b9cd9da0 Author: Chuansheng Liu Date: Mon Feb 24 11:29:50 2014 +0800 genirq: Remove racy waitqueue_active check commit c685689fd24d310343ac33942e9a54a974ae9c43 upstream. We hit one rare case below: T1 calling disable_irq(), but hanging at synchronize_irq() always; The corresponding irq thread is in sleeping state; And all CPUs are in idle state; After analysis, we found there is one possible scenerio which causes T1 is waiting there forever: CPU0 CPU1 synchronize_irq() wait_event() spin_lock() atomic_dec_and_test(&threads_active) insert the __wait into queue spin_unlock() if(waitqueue_active) atomic_read(&threads_active) wake_up() Here after inserted the __wait into queue on CPU0, and before test if queue is empty on CPU1, there is no barrier, it maybe cause it is not visible for CPU1 immediately, although CPU0 has updated the queue list. It is similar for CPU0 atomic_read() threads_active also. So we'd need one smp_mb() before waitqueue_active.that, but removing the waitqueue_active() check solves it as wel l and it makes things simple and clear. Signed-off-by: Chuansheng Liu Cc: Xiaoming Wang Link: http://lkml.kernel.org/r/1393212590-32543-1-git-send-email-chuansheng.liu@intel.com Signed-off-by: Thomas Gleixner Signed-off-by: Jiri Slaby commit c4b97b0abae4950f772647dcf964d0fad6782515 Author: Mathias Nyman Date: Fri Mar 7 17:06:57 2014 +0200 Revert "xhci 1.0: Limit arbitrarily-aligned scatter gather." commit e2ed511400d41e0d136089d5a55ceab57c6a2426 upstream. This reverts commit 247bf557273dd775505fb9240d2d152f4f20d304. This commit, together with commit 3804fad45411b48233b48003e33a78f290d227c8 "USBNET: ax88179_178a: enable tso if usb host supports sg dma" were origially added to get xHCI 1.0 hosts and usb ethernet ax88179_178a devices working together with scatter gather. xHCI 1.0 hosts pose some requirement on how transfer buffers are aligned, setting this requirement for 1.0 hosts caused USB 3.0 mass storage devices to fail more frequently. USB 3.0 mass storage devices used to work before 3.14-rc1. Theoretically, the TD fragment rules could have caused an occasional disk glitch. Now the devices *will* fail, instead of theoretically failing. >From a user perspective, this looks like a regression; the USB device obviously fails on 3.14-rc1, and may sometimes silently fail on prior kernels. The proper soluition is to implement the TD fragment rules required, but for now this patch needs to be reverted to get USB 3.0 mass storage devices working at the level they used to. Signed-off-by: Mathias Nyman Signed-off-by: Jiri Slaby commit fe2a46537ee082b4532a0b443c1b419660aafb5a Author: Julius Werner Date: Tue Mar 4 11:27:38 2014 -0800 usb: Make DELAY_INIT quirk wait 100ms between Get Configuration requests commit d86db25e53fa69e3e97f3b55dd82a70689787c5d upstream. The DELAY_INIT quirk only reduces the frequency of enumeration failures with the Logitech HD Pro C920 and C930e webcams, but does not quite eliminate them. We have found that adding a delay of 100ms between the first and second Get Configuration request makes the device enumerate perfectly reliable even after several weeks of extensive testing. The reasons for that are anyone's guess, but since the DELAY_INIT quirk already delays enumeration by a whole second, wating for another 10th of that isn't really a big deal for the one other device that uses it, and it will resolve the problems with these webcams. Signed-off-by: Julius Werner Signed-off-by: Jiri Slaby commit 9fd702bc4b09311a7ce664d68bb9dc8ac45de7ea Author: Julius Werner Date: Tue Mar 4 10:52:39 2014 -0800 usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e commit e0429362ab15c46ea4d64c3f8c9e0933e48a143a upstream. We've encountered a rare issue when enumerating two Logitech webcams after a reboot that doesn't power cycle the USB ports. They are spewing random data (possibly some leftover UVC buffers) on the second (full-sized) Get Configuration request of the enumeration phase. Since the data is random this can potentially cause all kinds of odd behavior, and since it occasionally happens multiple times (after the kernel issues another reset due to the garbled configuration descriptor), it is not always recoverable. Set the USB_DELAY_INIT quirk that seems to work around the issue. Signed-off-by: Julius Werner Signed-off-by: Jiri Slaby commit 7e737ca2da1b7df87dc4d20eebde00a8142b0f6c Author: Mathias Nyman Date: Fri Mar 7 17:06:58 2014 +0200 Revert "USBNET: ax88179_178a: enable tso if usb host supports sg dma" commit 469d417b68958a064c09e7875646c97c6e783dfc upstream. This reverts commit 3804fad45411b48233b48003e33a78f290d227c8. This commit, together with commit 247bf557273dd775505fb9240d2d152f4f20d304 "xhci 1.0: Limit arbitrarily-aligned scatter gather." were origially added to get xHCI 1.0 hosts and usb ethernet ax88179_178a devices working together with scatter gather. xHCI 1.0 hosts pose some requirement on how transfer buffers are aligned, setting this requirement for 1.0 hosts caused USB 3.0 mass storage devices to fail more frequently. USB 3.0 mass storage devices used to work before 3.14-rc1. Theoretically, the TD fragment rules could have caused an occasional disk glitch. Now the devices *will* fail, instead of theoretically failing. >From a user perspective, this looks like a regression; the USB device obviously fails on 3.14-rc1, and may sometimes silently fail on prior kernels. The proper soluition is to implement the TD fragment rules for xHCI 1.0 hosts, but for now, revert this patch until scatter gather can be properly supported. Signed-off-by: Mathias Nyman Signed-off-by: Jiri Slaby commit df32b39b835d5aaae3867d8d02a29ee6014ca8a6 Author: Jean Delvare Date: Sun Mar 2 15:33:35 2014 +0100 x86_pkg_temp_thermal: Do not expose as a hwmon device commit 79786880a47a8c5b4c8146c03432b3387a07a169 upstream. The temperature value reported by x86_pkg_temp_thermal is already reported by the coretemp driver. So, do not expose this thermal zone as a hwmon device, because it would be redundant. Signed-off-by: Jean Delvare Cc: Zhang Rui Cc: Eduardo Valentin Acked-by: Guenter Roeck Signed-off-by: Zhang Rui Signed-off-by: Jiri Slaby commit e108610d6dcb947d4a8743f8f5bcfb008982826f Author: Daniel J Blueman Date: Thu Mar 13 19:43:01 2014 +0800 x86/amd/numa: Fix northbridge quirk to assign correct NUMA node commit 847d7970defb45540735b3fb4e88471c27cacd85 upstream. For systems with multiple servers and routed fabric, all northbridges get assigned to the first server. Fix this by also using the node reported from the PCI bus. For single-fabric systems, the northbriges are on PCI bus 0 by definition, which are on NUMA node 0 by definition, so this is invarient on most systems. Tested on fam10h and fam15h single and multi-fabric systems and candidate for stable. Signed-off-by: Daniel J Blueman Acked-by: Steffen Persvold Acked-by: Borislav Petkov Link: http://lkml.kernel.org/r/1394710981-3596-1-git-send-email-daniel@numascale.com Signed-off-by: Ingo Molnar Signed-off-by: Jiri Slaby commit f4592be7d7d62c137999e058288618398fe2babc Author: Linus Torvalds Date: Fri Mar 7 18:58:40 2014 -0800 x86: fix compile error due to X86_TRAP_NMI use in asm files commit b01d4e68933ec23e43b1046fa35d593cefcf37d1 upstream. It's an enum, not a #define, you can't use it in asm files. Introduced in commit 5fa10196bdb5 ("x86: Ignore NMIs that come in during early boot"), and sadly I didn't compile-test things like I should have before pushing out. My weak excuse is that the x86 tree generally doesn't introduce stupid things like this (and the ARM pull afterwards doesn't cause me to do a compile-test either, since I don't cross-compile). Cc: Don Zickus Cc: H. Peter Anvin Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 8ee7e9f35c9327cedcefc28ce6ad4f30b20bc579 Author: H. Peter Anvin Date: Fri Mar 7 15:05:20 2014 -0800 x86: Ignore NMIs that come in during early boot commit 5fa10196bdb5f190f595ebd048490ee52dddea0f upstream. Don Zickus reports: A customer generated an external NMI using their iLO to test kdump worked. Unfortunately, the machine hung. Disabling the nmi_watchdog made things work. I speculated the external NMI fired, caused the machine to panic (as expected) and the perf NMI from the watchdog came in and was latched. My guess was this somehow caused the hang. ---- It appears that the latched NMI stays latched until the early page table generation on 64 bits, which causes exceptions to happen which end in IRET, which re-enable NMI. Therefore, ignore NMIs that come in during early execution, until we have proper exception handling. Reported-and-tested-by: Don Zickus Link: http://lkml.kernel.org/r/1394221143-29713-1-git-send-email-dzickus@redhat.com Signed-off-by: H. Peter Anvin Signed-off-by: Jiri Slaby commit caf08ff5618812a52ae23b526349e95223856825 Author: Markus Pargmann Date: Thu Feb 20 17:36:03 2014 +0100 regulator: core: Replace direct ops->enable usage commit 30c219710358c5cca2f8bd2e9e547c6aadf7cf8b upstream. There are some direct ops->enable in the regulator core driver. This is a potential issue as the function _regulator_do_enable() handles gpio regulators and the normal ops->enable calls. These gpio regulators are simply ignored when ops->enable is called directly. One possible bug is that boot-on and always-on gpio regulators are not enabled on registration. This patch replaces all ops->enable calls by _regulator_do_enable. [Handle missing enable operations -- broonie] Signed-off-by: Markus Pargmann Signed-off-by: Mark Brown Signed-off-by: Jiri Slaby commit 8afe392ee3e84c94ecb595e435dd54f864739bac Author: Linus Walleij Date: Tue Feb 25 22:41:41 2014 +0100 ARM: 7991/1: sa1100: fix compile problem on Collie commit 052450fdc55894a39fbae93d9bbe43947956f663 upstream. Due to a problem in the MFD Kconfig it was not possible to compile the UCB battery driver for the Collie SA1100 system, in turn making it impossible to compile in the battery driver. (See patch "mfd: include all drivers in subsystem menu".) After fixing the MFD Kconfig (separate patch) a compile error appears in the Collie battery driver due to the implicitly requiring through via prior to commit 40ca061b "ARM: 7841/1: sa1100: remove complex GPIO interface". Fix this up by including the required header into . Cc: Andrea Adami Cc: Dmitry Eremin-Solenikov Signed-off-by: Linus Walleij Signed-off-by: Russell King Signed-off-by: Jiri Slaby commit 49799bba6fc2d0c3a32bf4c5c30b4d74ea689628 Author: Anton Blanchard Date: Tue Mar 4 08:31:24 2014 +1100 powerpc: Align p_dyn, p_rela and p_st symbols commit a5b2cf5b1af424ee3dd9e3ce6d5cea18cb927e67 upstream. The 64bit relocation code places a few symbols in the text segment. These symbols are only 4 byte aligned where they need to be 8 byte aligned. Add an explicit alignment. Signed-off-by: Anton Blanchard Tested-by: Laurent Dufour Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Jiri Slaby commit 2725f34b41f8e3f444688a814cc2763a1c2b138b Author: Michael Neuling Date: Mon Mar 3 14:21:40 2014 +1100 powerpc/tm: Fix crash when forking inside a transaction commit 621b5060e823301d0cba4cb52a7ee3491922d291 upstream. When we fork/clone we currently don't copy any of the TM state to the new thread. This results in a TM bad thing (program check) when the new process is switched in as the kernel does a tmrechkpt with TEXASR FS not set. Also, since R1 is from userspace, we trigger the bad kernel stack pointer detection. So we end up with something like this: Bad kernel stack pointer 0 at c0000000000404fc cpu 0x2: Vector: 700 (Program Check) at [c00000003ffefd40] pc: c0000000000404fc: restore_gprs+0xc0/0x148 lr: 0000000000000000 sp: 0 msr: 9000000100201030 current = 0xc000001dd1417c30 paca = 0xc00000000fe00800 softe: 0 irq_happened: 0x01 pid = 0, comm = swapper/2 WARNING: exception is not recoverable, can't continue The below fixes this by flushing the TM state before we copy the task_struct to the clone. To do this we go through the tmreclaim patch, which removes the checkpointed registers from the CPU and transitions the CPU out of TM suspend mode. Hence we need to call tmrechkpt after to restore the checkpointed state and the TM mode for the current task. To make this fail from userspace is simply: tbegin li r0, 2 sc Kudos to Adhemerval Zanella Neto for finding this. Signed-off-by: Michael Neuling cc: Adhemerval Zanella Neto Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Jiri Slaby commit 809dbe001fb062198dee0589f095866b6a43032f Author: Chen-Yu Tsai Date: Tue Feb 11 00:22:37 2014 +0800 pinctrl: sunxi: use chained_irq_{enter, exit} for GIC compatibility commit 905a5117e79367b7e58ae046d12ca9961f048c89 upstream. On tha Allwinner A20 SoC, the external interrupts on the pin controller device are connected to the GIC. Without chained_irq_{enter, exit}, external GPIO interrupts, such as used by mmc core card detect, cause the system to hang. This issue was first encountered during my attempt to get out-of-band interrupts for WiFi on the Cubietruck working. With David's new series of sunci-mci using mmc slot-gpio for (GPIO interrupt based) card detection, removing the SD card also causes my Cubietruck to hang. This problem should extend to all Allwinner A20 based boards. With this fix, the system no longer hangs when I remove or insert the SD card. /proc/interrupts show that the interrupt has correctly fired. However the system still does not detect card removal/insertion. I believe this is another unrelated issue. Signed-off-by: Chen-Yu Tsai Acked-by: Maxime Ripard Signed-off-by: Linus Walleij Signed-off-by: Jiri Slaby commit c3f3e9eb4aa81e725c45096dac9f897b1d311fa7 Author: Takashi Iwai Date: Fri Mar 7 08:37:19 2014 +0100 ALSA: hda - Fix loud click noise with IdeaPad 410Y commit 9b745ab897199c2af9f21ca9681ef86d5b971002 upstream. Lenovo IdeaPad 410Y with ALC282 codec makes loud click noises at boot and shutdown. Also, it wrongly misdetects the acpi_thinkpad hook. This patch adds a device-specific fixup for disabling the shutup callback that is the cause of the click noise and also avoiding the thinpad_helper calls. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=71511 Reported-and-tested-by: Guilherme Amadio Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 287673c44d98b6c191eb61915c196e36bd7f91fb Author: Takashi Iwai Date: Wed Mar 5 11:52:24 2014 +0100 ALSA: hda - Add missing loopback merge path for AD1884/1984 codecs commit c5eda4c1bf6214332c46fb2f4e7c42a85e5e5643 upstream. The mixer widget (NID 0x20) of AD1884 and AD1984 codecs isn't connected directly to the actual I/O paths but only via another mixer widget (NID 0x21). We need a similar fix as we did for AD1882. Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 2bd9aef09f2bdbd20b5fe331aee90aa22ae0c65e Author: Marius Knaust Date: Mon Mar 3 01:48:58 2014 +0100 ALSA: hda - Added inverted digital-mic handling for Acer TravelMate 8371 commit a6b92b6650d010d58b6e6fe42c6271266e0b1134 upstream. Signed-off-by: Marius Knaust Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 8b32a74f8a929b33e31ccb29cdab6c34d612349d Author: Takashi Iwai Date: Wed Mar 5 12:34:39 2014 +0100 ALSA: usb-audio: Add quirk for Logitech Webcam C500 commit e805ca8b0a9b6c91099c0eaa4b160a1196a4ae25 upstream. Logitech C500 (046d:0807) needs the same workaround like other Logitech Webcams. Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit ae85238db85bad0b7de38d524d6392501133589f Author: Roman Volkov Date: Fri Jan 24 16:18:14 2014 +0400 ALSA: oxygen: Xonar DG(X): capture from I2S channel 1, not 2 commit 3dd77654fb1d7f68b9739f3039bad8dbbc0739f8 upstream. Actually CS4245 connected to the I2S channel 1 for capture, not channel 2. Otherwise capturing and playback does not work for CS4245. Signed-off-by: Roman Volkov Signed-off-by: Clemens Ladisch Signed-off-by: Jiri Slaby commit 62d624499e0ee30b93d3910d286b1273cc64bdb2 Author: Lauri Kasanen Date: Fri Feb 28 20:50:23 2014 +0200 drm/radeon: TTM must be init with cpu-visible VRAM, v2 commit 14eedc32a3c0ec9dd70448a73763ee21feae3111 upstream. Without this, a bo may get created in the cpu-inaccessible vram. Before the CP engines get setup, all copies are done via cpu memcpy. This means that the cpu tries to read from inaccessible memory, fails, and the radeon module proceeds to disable acceleration. Doing this has no downsides, as the real VRAM size gets set as soon as the CP engines get init. This is a candidate for 3.14 fixes. v2: Add comment on why the function is used Signed-off-by: Lauri Kasanen Signed-off-by: Alex Deucher Reviewed-by: Christian König Signed-off-by: Jiri Slaby commit 0915313534cfc3256d744f2149c8363ba49bd754 Author: Amitkumar Karwar Date: Tue Mar 4 18:43:14 2014 -0800 mwifiex: save and copy AP's VHT capability info correctly commit d51246481c7f28bbfa1f814ded2da65e531cd4b2 upstream. While preparing association request, intersection of device's VHT capability information and corresponding field advertised by AP is used. This patch fixes a couple errors while saving and copying vht_cap and vht_oper fields from AP's beacon. Signed-off-by: Amitkumar Karwar Signed-off-by: Bing Zhao Signed-off-by: John W. Linville Signed-off-by: Jiri Slaby commit 6029ed2c3314d196d8ee3628472bcdf4c5d383b3 Author: Amitkumar Karwar Date: Tue Mar 4 18:43:13 2014 -0800 mwifiex: copy AP's HT capability info correctly commit c99b1861c232e1f641f13b8645e0febb3712cc71 upstream. While preparing association request, intersection of device's HT capability information and corresponding fields advertised by AP is used. This patch fixes an error while copying this field from AP's beacon. Signed-off-by: Amitkumar Karwar Signed-off-by: Bing Zhao Signed-off-by: John W. Linville Signed-off-by: Jiri Slaby commit 86b68abfb12d7e0bb79aafcc1d37a4736a13dab6 Author: Bing Zhao Date: Wed Feb 26 20:11:22 2014 -0800 mwifiex: do not advertise usb autosuspend support commit adb07df1e039e9fe43e66aeea8b4771f83659dbb upstream. As many Surface Pro I & II users have found out, the mwifiex_usb doesn't support usb autosuspend, and it has caused some system stability issues. Bug 69661 - mwifiex_usb on MS Surface Pro 1 is unstable Bug 60815 - Interface hangs in mwifiex_usb Bug 64111 - mwifiex_usb USB8797 crash failed to get signal information USB autosuspend get triggered when Surface Pro's AC power is removed or powertop enables power saving on USB8797 device. Driver's suspend handler is called here, but resume handler won't be called until the AC power is put back on or powertop disables power saving for USB8797. We need to refactor the suspend/resume handlers to support usb autosuspend properly. For now let's just remove it. Signed-off-by: Bing Zhao Signed-off-by: Amitkumar Karwar Signed-off-by: John W. Linville Signed-off-by: Jiri Slaby commit 3dabcb5b6a85b90a4d7dff89455dbc43afd0bf4b Author: Amitkumar Karwar Date: Tue Feb 18 15:41:56 2014 -0800 mwifiex: fix cmd and Tx data timeout issue for PCIe cards commit 1c97560f6d751a620978504a4a888c631192b71a upstream. We are sending sleep confirm done interrupt in the middle of sleep handshake. There is a corner case when Tx done interrupt is received from firmware during sleep handshake due to which host and firmware power states go out of sync causing cmd and Tx data timeout problem. Hence sleep confirm done interrupt is sent at the end of sleep handshake to fix the problem. Signed-off-by: Amitkumar Karwar Signed-off-by: Bing Zhao Signed-off-by: John W. Linville Signed-off-by: Jiri Slaby commit 1886824d500efeaef9144299081ff4ebe9d7752b Author: Amitkumar Karwar Date: Tue Feb 18 15:41:55 2014 -0800 mwifiex: add NULL check for PCIe Rx skb commit bb8e6a1ee881d131e404f0f1f5e8dc9281002771 upstream. We may get a NULL pointer here if skb allocation for Rx packet was failed earlier. Signed-off-by: Amitkumar Karwar Signed-off-by: Bing Zhao Signed-off-by: John W. Linville Signed-off-by: Jiri Slaby commit db5eb608ac4a1f8982a4a5dd5c486008eec16655 Author: Avinash Patil Date: Tue Feb 18 15:41:54 2014 -0800 mwifiex: clean pcie ring only when device is present commit 4f7ba432202c8330cc03ab959c6228d0de5dc4a3 upstream. Write io memory to clean PCIe buffer only when PCIe device is present else this results into crash because of invalid memory access. Signed-off-by: Avinash Patil Signed-off-by: Bing Zhao Signed-off-by: John W. Linville Signed-off-by: Jiri Slaby commit 42cbd72df7e120b2725dd7ce5ce6fa8c4d572d0f Author: Emmanuel Grumbach Date: Wed Feb 12 15:15:05 2014 +0200 iwlwifi: disable TX AMPDU by default for iwldvm commit 205e2210daa975d92ace485a65a31ccc4077fe1a upstream. NICs supported by iwldvm don't handle well TX AMPDU. Disable it by default, still leave the possibility to the user to force enable it with a debug parameter. NICs supported by iwlmvm don't suffer from the same issue, leave TX AMPDU enabled by default for these. Signed-off-by: Emmanuel Grumbach Signed-off-by: Jiri Slaby commit ec849f74cd0ddcdf61de63c8bcdd803daf1e9b02 Author: Johannes Berg Date: Tue Feb 25 10:37:15 2014 +0100 iwlwifi: fix TX status for aggregated packets commit 143582c6847cb285b361804c613127c25de60ca4 upstream. Only the first packet is currently handled correctly, but then all others are assumed to have failed which is problematic. Fix this, marking them all successful instead (since if they're not then the firmware will have transmitted them as single frames.) This fixes the lost packet reporting. Also do a tiny variable scoping cleanup. Signed-off-by: Johannes Berg [Add the dvm part] Signed-off-by: Emmanuel Grumbach Signed-off-by: Jiri Slaby commit fb625a814af36cb87fd382aee3fbf51da872c5cd Author: Emmanuel Grumbach Date: Tue Feb 18 10:30:18 2014 +0200 iwlwifi: dvm: clear IWL_STA_UCODE_INPROGRESS when assoc fails commit ec6f678c74dbdb06a6a775bbb00f1d26c17c404b upstream. We set IWL_STA_UCODE_INPROGRESS flag when we add a station and clear it when we send the LQ command for it. But the LQ command is sent only when the association succeeds. If the association doesn't succeed, we would leave this flag set and that wouldn't indicate the station entry as vacant. This probably fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1065663 Reviewed-by: Johannes Berg Signed-off-by: Emmanuel Grumbach Signed-off-by: Jiri Slaby commit ee6ec648ab09cb3f833c17de1069cc066208dd8a Author: Max Stepanov Date: Sun Feb 16 16:36:57 2014 +0200 iwlwifi: mvm: change of listen interval from 70 to 10 commit e7eb65cac0720df8b3946af7f7a9dc363cf0a814 upstream. Some APs reject STA association request if a listen interval value exceeds a threshold of 10. Thus, for example, Cisco APs may deny STA associations returning status code 12 (Association denied due to reason outside the scope of 802.11 standard) in the association response frame. Fixing the issue by setting the default IWL_CONN_MAX_LISTEN_INTERVAL value from 70 to 10. Signed-off-by: Max Stepanov Reviewed-by: Alexander Bondar Signed-off-by: Emmanuel Grumbach Signed-off-by: Jiri Slaby commit de724a52f8c47366f706206080a35f6592492d4c Author: Felix Fietkau Date: Mon Feb 24 22:26:06 2014 +0100 ath9k: fix invalid descriptor discarding commit b7b146c9c9a0248cc57da71244f672ebc54bbef1 upstream. Only set sc->rx.discard_next to rx_stats->rs_more when actually discarding the current descriptor. Also, fix a detection of broken descriptors: First the code checks if the current descriptor is not done. Then it checks if the next descriptor is done. Add a check that afterwards checks the first descriptor again, because it might have been completed in the mean time. This fixes a regression introduced in commit 723e711356b5a8a95728a890e254e8b0d47b55cf "ath9k: fix handling of broken descriptors" Reported-by: Marco André Dinis Signed-off-by: Felix Fietkau Signed-off-by: John W. Linville Signed-off-by: Jiri Slaby commit 7f60220d325b42104f40a4bec8457f3f63da8dd4 Author: Felix Fietkau Date: Sat Feb 22 13:48:19 2014 +0100 ath9k: fix ps-poll responses under a-mpdu sessions commit 558ff225de80ac95b132d3a115ddadcd64498b4f upstream. When passing tx frames to the U-APSD queue for powersave poll responses, the ath_atx_tid pointer needs to be passed to ath_tx_setup_buffer for proper sequence number accounting. This fixes high latency and connection stability issues with ath9k running as AP and a few kinds of mobile phones as client, when PS-Poll is heavily used Signed-off-by: Felix Fietkau Signed-off-by: John W. Linville Signed-off-by: Jiri Slaby commit 46e70384f21825caab1a55f64e9fe6d3d16c28cc Author: Stanislaw Gruszka Date: Wed Feb 19 13:15:17 2014 +0100 ath9k: protect tid->sched check commit 21f8aaee0c62708654988ce092838aa7df4d25d8 upstream. We check tid->sched without a lock taken on ath_tx_aggr_sleep(). That is race condition which can result of doing list_del(&tid->list) twice (second time with poisoned list node) and cause crash like shown below: [424271.637220] BUG: unable to handle kernel paging request at 00100104 [424271.637328] IP: [] ath_tx_aggr_sleep+0x62/0xe0 [ath9k] ... [424271.639953] Call Trace: [424271.639998] [] ? ath9k_get_survey+0x110/0x110 [ath9k] [424271.640083] [] ath9k_sta_notify+0x42/0x50 [ath9k] [424271.640177] [] sta_ps_start+0x8f/0x1c0 [mac80211] [424271.640258] [] ? free_compound_page+0x2e/0x40 [424271.640346] [] ieee80211_rx_handlers+0x9d5/0x2340 [mac80211] [424271.640437] [] ? kmem_cache_free+0x1d8/0x1f0 [424271.640510] [] ? kfree_skbmem+0x34/0x90 [424271.640578] [] ? put_page+0x2c/0x40 [424271.640640] [] ? kfree_skbmem+0x34/0x90 [424271.640706] [] ? kfree_skbmem+0x34/0x90 [424271.640787] [] ? ieee80211_rx_handlers_result+0x73/0x1d0 [mac80211] [424271.640897] [] ieee80211_prepare_and_rx_handle+0x520/0xad0 [mac80211] [424271.641009] [] ? ieee80211_rx_handlers+0x2ed/0x2340 [mac80211] [424271.641104] [] ? ip_output+0x7e/0xd0 [424271.641182] [] ieee80211_rx+0x307/0x7c0 [mac80211] [424271.641266] [] ath_rx_tasklet+0x88e/0xf70 [ath9k] [424271.641358] [] ? ieee80211_rx+0x1dc/0x7c0 [mac80211] [424271.641445] [] ath9k_tasklet+0xcb/0x130 [ath9k] Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=70551 Reported-and-tested-by: Max Sydorenko Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Jiri Slaby commit 218de5013fab2f830cae98b50ae97d36cf271b85 Author: Sujith Manoharan Date: Fri Feb 14 08:15:20 2014 +0530 ath9k: Fix ETSI compliance for AR9462 2.0 commit b3050248c167871ca52cfdb2ce78aa2460249346 upstream. The minimum CCA power threshold values have to be adjusted for existing cards to be in compliance with new regulations. Newer cards will make use of the values obtained from EEPROM, support for this was added earlier. To make sure that cards that are already in use and don't have proper values in EEPROM, do not violate regulations, use the initvals instead. Reported-by: Jeang Daniel Signed-off-by: Sujith Manoharan Signed-off-by: John W. Linville Signed-off-by: Jiri Slaby commit 7ab2a354488958130248f17231c57cdd41d45ce8 Author: Johannes Berg Date: Tue Mar 4 13:46:53 2014 +0100 mac80211: clear sequence/fragment number in QoS-null frames commit 864a6040f395464003af8dd0d8ca86fed19866d4 upstream. Avoid leaking data by sending uninitialized memory and setting an invalid (non-zero) fragment number (the sequence number is ignored anyway) by setting the seq_ctrl field to zero. Fixes: 3f52b7e328c5 ("mac80211: mesh power save basics") Fixes: ce662b44ce22 ("mac80211: send (QoS) Null if no buffered frames") Reviewed-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Jiri Slaby commit 11be9f31e94a196fefb37be1bd00baeaefbe7274 Author: Johannes Berg Date: Thu Feb 27 20:47:53 2014 +0100 mac80211: fix association to 20/40 MHz VHT networks commit cb664981607a6b5b3d670ad57bbda893b2528d96 upstream. When a VHT network uses 20 or 40 MHz as per the HT operation information, the channel center frequency segment 0 field in the VHT operation information is reserved, so ignore it. This fixes association with such networks when the AP puts 0 into the field, previously we'd disconnect due to an invalid channel with the message wlan0: AP VHT information is invalid, disable VHT Fixes: f2d9d270c15ae ("mac80211: support VHT association") Reported-by: Tim Nelson Signed-off-by: Johannes Berg Signed-off-by: Jiri Slaby commit 4032900fb38c1c7436f0b216a6687fc96c989f5d Author: Johannes Berg Date: Fri Feb 21 20:34:34 2014 +0100 mac80211: don't validate unchanged AP bandwidth while tracking commit 963a1852fbac4f75a2d938fa2e734ef1e6d4c044 upstream. The MLME code in mac80211 must track whether or not the AP changed bandwidth, but if there's no change while tracking it shouldn't do anything, otherwise regulatory updates can make it impossible to connect to certain APs if the regulatory database doesn't match the information from the AP. See the precise scenario described in the code. This still leaves some possible problems with CSA or if the AP actually changed bandwidth, but those cases are less common and won't completely prevent using it. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=70881 Reported-and-tested-by: Nate Carlson Signed-off-by: Johannes Berg Signed-off-by: Jiri Slaby commit 58d4310586466840dab77e56e53f4508853a5268 Author: Emmanuel Grumbach Date: Thu Feb 20 09:22:11 2014 +0200 mac80211: fix AP powersave TX vs. wakeup race commit 1d147bfa64293b2723c4fec50922168658e613ba upstream. There is a race between the TX path and the STA wakeup: while a station is sleeping, mac80211 buffers frames until it wakes up, then the frames are transmitted. However, the RX and TX path are concurrent, so the packet indicating wakeup can be processed while a packet is being transmitted. This can lead to a situation where the buffered frames list is emptied on the one side, while a frame is being added on the other side, as the station is still seen as sleeping in the TX path. As a result, the newly added frame will not be send anytime soon. It might be sent much later (and out of order) when the station goes to sleep and wakes up the next time. Additionally, it can lead to the crash below. Fix all this by synchronising both paths with a new lock. Both path are not fastpath since they handle PS situations. In a later patch we'll remove the extra skb queue locks to reduce locking overhead. BUG: unable to handle kernel NULL pointer dereference at 000000b0 IP: [] ieee80211_report_used_skb+0x11/0x3e0 [mac80211] *pde = 00000000 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC EIP: 0060:[] EFLAGS: 00210282 CPU: 1 EIP is at ieee80211_report_used_skb+0x11/0x3e0 [mac80211] EAX: e5900da0 EBX: 00000000 ECX: 00000001 EDX: 00000000 ESI: e41d00c0 EDI: e5900da0 EBP: ebe458e4 ESP: ebe458b0 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 CR0: 8005003b CR2: 000000b0 CR3: 25a78000 CR4: 000407d0 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 DR6: ffff0ff0 DR7: 00000400 Process iperf (pid: 3934, ti=ebe44000 task=e757c0b0 task.ti=ebe44000) iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command LQ_CMD (#4e), seq: 0x0903, 92 bytes at 3[3]:9 Stack: e403b32c ebe458c4 00200002 00200286 e403b338 ebe458cc c10960bb e5900da0 ff76a6ec ebe458d8 00000000 e41d00c0 e5900da0 ebe458f0 ff6f1b75 e403b210 ebe4598c ff723dc1 00000000 ff76a6ec e597c978 e403b758 00000002 00000002 Call Trace: [] ieee80211_free_txskb+0x15/0x20 [mac80211] [] invoke_tx_handlers+0x1661/0x1780 [mac80211] [] ieee80211_tx+0x75/0x100 [mac80211] [] ieee80211_xmit+0x8f/0xc0 [mac80211] [] ieee80211_subif_start_xmit+0x4fe/0xe20 [mac80211] [] dev_hard_start_xmit+0x450/0x950 [] sch_direct_xmit+0xa9/0x250 [] __qdisc_run+0x4b/0x150 [] dev_queue_xmit+0x2c2/0xca0 Reported-by: Yaara Rozenblum Signed-off-by: Emmanuel Grumbach Reviewed-by: Stanislaw Gruszka [reword commit log, use a separate lock] Signed-off-by: Johannes Berg Signed-off-by: Jiri Slaby commit b6f6dfa1267332f3995f3a8cc53a30bb300ada54 Author: Felix Fietkau Date: Tue Feb 11 16:02:47 2014 +0100 mac80211: send control port protocol frames to the VO queue commit 1bf4bbb4024dcdab5e57634dd8ae1072d42a53ac upstream. Improves reliability of wifi connections with WPA, since authentication frames are prioritized over normal traffic and also typically exempt from aggregation. Signed-off-by: Felix Fietkau Signed-off-by: Johannes Berg Signed-off-by: Jiri Slaby commit 97992a401b8e43580f7812387f74f4f1e919b800 Author: Alexandre Bounine Date: Mon Mar 3 15:38:36 2014 -0800 rapidio/tsi721: fix tasklet termination in dma channel release commit 04379dffdd4da820d51a1566ad2e86f3b1ad97ed upstream. This patch is a modification of the patch originally proposed by Xiaotian Feng : https://lkml.org/lkml/2012/11/5/413 This new version disables DMA channel interrupts and ensures that the tasklet wil not be scheduled again before calling tasklet_kill(). Unfortunately the updated patch was not released at that time due to planned rework of Tsi721 mport driver to use threaded interrupts (which has yet to happen). Recently the issue was reported again: https://lkml.org/lkml/2014/2/19/762. Description from the original Xiaotian's patch: "Some drivers use tasklet_disable in device remove/release process, tasklet_disable will inc tasklet->count and return. If the tasklet is not handled yet under some softirq pressure, the tasklet will be placed on the tasklet_vec, never have a chance to be excuted. This might lead to a heavy loaded ksoftirqd, wakeup with pending_softirq, but tasklet is disabled. tasklet_kill should be used in this case." This patch is applicable to kernel versions starting from v3.5. Signed-off-by: Alexandre Bounine Cc: Matt Porter Cc: Xiaotian Feng Reviewed-by: Thomas Gleixner Cc: Mike Galbraith Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 560877ed20d96a6223dbffe6bc618e6fba38311c Author: George McCollister Date: Tue Feb 18 17:56:51 2014 -0600 sched: Fix double normalization of vruntime commit 791c9e0292671a3bfa95286bb5c08129d8605618 upstream. dequeue_entity() is called when p->on_rq and sets se->on_rq = 0 which appears to guarentee that the !se->on_rq condition is met. If the task has done set_current_state(TASK_INTERRUPTIBLE) without schedule() the second condition will be met and vruntime will be incorrectly adjusted twice. In certain cases this can result in the task's vruntime never increasing past the vruntime of other tasks on the CFS' run queue, starving them of CPU time. This patch changes switched_from_fair() to use !p->on_rq instead of !se->on_rq. I'm able to cause a task with a priority of 120 to starve all other tasks with the same priority on an ARM platform running 3.2.51-rt72 PREEMPT RT by writing one character at time to a serial tty (16550 UART) in a tight loop. I'm also able to verify making this change corrects the problem on that platform and kernel version. Signed-off-by: George McCollister Signed-off-by: Peter Zijlstra Link: http://lkml.kernel.org/r/1392767811-28916-1-git-send-email-george.mccollister@gmail.com Signed-off-by: Ingo Molnar Signed-off-by: Jiri Slaby commit 9d865d440a5e684ce5ec54ae7866c7e58bd46a14 Author: Hugh Dickins Date: Mon Mar 3 15:38:24 2014 -0800 memcg: fix endless loop in __mem_cgroup_iter_next() commit ce48225fe3b1b0d1fc9fceb96ac3d8a879e45114 upstream. Commit 0eef615665ed ("memcg: fix css reference leak and endless loop in mem_cgroup_iter") got the interaction with the commit a few before it d8ad30559715 ("mm/memcg: iteration skip memcgs not yet fully initialized") slightly wrong, and we didn't notice at the time. It's elusive, and harder to get than the original, but for a couple of days before rc1, I several times saw a endless loop similar to that supposedly being fixed. This time it was a tighter loop in __mem_cgroup_iter_next(): because we can get here when our root has already been offlined, and the ordering of conditions was such that we then just cycled around forever. Fixes: 0eef615665ed ("memcg: fix css reference leak and endless loop in mem_cgroup_iter"). Signed-off-by: Hugh Dickins Acked-by: Michal Hocko Cc: Johannes Weiner Cc: Greg Thelen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 313bb2423954fc861816e6c06a513df6334b66d8 Author: Al Viro Date: Mon Feb 10 15:18:55 2014 -0500 ocfs2 syncs the wrong range... commit 1b56e98990bcdbb20b9fab163654b9315bf158e8 upstream. Signed-off-by: Al Viro Signed-off-by: Jiri Slaby commit 5a131c1d03f6a7bcb81101994038a4945a47c32e Author: Jan Kara Date: Mon Mar 3 15:38:32 2014 -0800 ocfs2: fix quota file corruption commit 15c34a760630ca2c803848fba90ca0646a9907dd upstream. Global quota files are accessed from different nodes. Thus we cannot cache offset of quota structure in the quota file after we drop our node reference count to it because after that moment quota structure may be freed and reallocated elsewhere by a different node resulting in corruption of quota file. Fix the problem by clearing dq_off when we are releasing dquot structure. We also remove the DB_READ_B handling because it is useless - DQ_ACTIVE_B is set iff DQ_READ_B is set. Signed-off-by: Jan Kara Cc: Goldwyn Rodrigues Cc: Joel Becker Reviewed-by: Mark Fasheh Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit ae865ad6db4dd82ed74f313ff0dd89f187318bc8 Author: Vlastimil Babka Date: Mon Mar 3 15:38:27 2014 -0800 mm: include VM_MIXEDMAP flag in the VM_SPECIAL list to avoid m(un)locking commit 9050d7eba40b3d79551668f54e68fd6f51945ef3 upstream. Daniel Borkmann reported a VM_BUG_ON assertion failing: ------------[ cut here ]------------ kernel BUG at mm/mlock.c:528! invalid opcode: 0000 [#1] SMP Modules linked in: ccm arc4 iwldvm [...] video CPU: 3 PID: 2266 Comm: netsniff-ng Not tainted 3.14.0-rc2+ #8 Hardware name: LENOVO 2429BP3/2429BP3, BIOS G4ET37WW (1.12 ) 05/29/2012 task: ffff8801f87f9820 ti: ffff88002cb44000 task.ti: ffff88002cb44000 RIP: 0010:[] [] munlock_vma_pages_range+0x2e0/0x2f0 Call Trace: do_munmap+0x18f/0x3b0 vm_munmap+0x41/0x60 SyS_munmap+0x22/0x30 system_call_fastpath+0x1a/0x1f RIP munlock_vma_pages_range+0x2e0/0x2f0 ---[ end trace a0088dcf07ae10f2 ]--- because munlock_vma_pages_range() thinks it's unexpectedly in the middle of a THP page. This can be reproduced with default config since 3.11 kernels. A reproducer can be found in the kernel's selftest directory for networking by running ./psock_tpacket. The problem is that an order=2 compound page (allocated by alloc_one_pg_vec_page() is part of the munlocked VM_MIXEDMAP vma (mapped by packet_mmap()) and mistaken for a THP page and assumed to be order=9. The checks for THP in munlock came with commit ff6a6da60b89 ("mm: accelerate munlock() treatment of THP pages"), i.e. since 3.9, but did not trigger a bug. It just makes munlock_vma_pages_range() skip such compound pages until the next 512-pages-aligned page, when it encounters a head page. This is however not a problem for vma's where mlocking has no effect anyway, but it can distort the accounting. Since commit 7225522bb429 ("mm: munlock: batch non-THP page isolation and munlock+putback using pagevec") this can trigger a VM_BUG_ON in PageTransHuge() check. This patch fixes the issue by adding VM_MIXEDMAP flag to VM_SPECIAL, a list of flags that make vma's non-mlockable and non-mergeable. The reasoning is that VM_MIXEDMAP vma's are similar to VM_PFNMAP, which is already on the VM_SPECIAL list, and both are intended for non-LRU pages where mlocking makes no sense anyway. Related Lkml discussion can be found in [2]. [1] tools/testing/selftests/net/psock_tpacket [2] https://lkml.org/lkml/2014/1/10/427 Signed-off-by: Vlastimil Babka Signed-off-by: Daniel Borkmann Reported-by: Daniel Borkmann Tested-by: Daniel Borkmann Cc: Thomas Hellstrom Cc: John David Anglin Cc: HATAYAMA Daisuke Cc: Konstantin Khlebnikov Cc: Carsten Otte Cc: Jared Hulbert Tested-by: Hannes Frederic Sowa Cc: Kirill A. Shutemov Acked-by: Rik van Riel Cc: Andrea Arcangeli Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit edbe815797df9adda740805b4791c69af919e3d0 Author: Johannes Weiner Date: Mon Mar 3 15:38:41 2014 -0800 mm: page_alloc: exempt GFP_THISNODE allocations from zone fairness commit 27329369c9ecf37771b2a65202cbf5578cff3331 upstream. Jan Stancek reports manual page migration encountering allocation failures after some pages when there is still plenty of memory free, and bisected the problem down to commit 81c0a2bb515f ("mm: page_alloc: fair zone allocator policy"). The problem is that GFP_THISNODE obeys the zone fairness allocation batches on one hand, but doesn't reset them and wake kswapd on the other hand. After a few of those allocations, the batches are exhausted and the allocations fail. Fixing this means either having GFP_THISNODE wake up kswapd, or GFP_THISNODE not participating in zone fairness at all. The latter seems safer as an acute bugfix, we can clean up later. Reported-by: Jan Stancek Signed-off-by: Johannes Weiner Acked-by: Rik van Riel Acked-by: Mel Gorman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit faf65d4dccfd705ff302e4e7b59fcb454f3b47ce Author: Minchan Kim Date: Mon Mar 3 15:38:34 2014 -0800 zram: avoid null access when fail to alloc meta commit db5d711e2db776f18219b033e5dc4fb7e4264dd7 upstream. zram_meta_alloc could fail so caller should check it. Otherwise, your system will hang. Signed-off-by: Minchan Kim Acked-by: Jerome Marchand Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit e00feda0d79196595eb0c12cd15b0b9015830190 Author: Rob Clark Date: Wed Mar 12 10:59:37 2014 -0400 drm/ttm: don't oops if no invalidate_caches() commit 9ef7506f7eff3fc42724269f62e30164c141661f upstream. A few of the simpler TTM drivers (cirrus, ast, mgag200) do not implement this function. Yet can end up somehow with an evicted bo: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [< (null)>] (null) PGD 16e761067 PUD 16e6cf067 PMD 0 Oops: 0010 [#1] SMP Modules linked in: bnep bluetooth rfkill fuse ip6t_rpfilter ip6t_REJECT ipt_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw iptable_filter ip_tables sg btrfs zlib_deflate raid6_pq xor dm_queue_length iTCO_wdt iTCO_vendor_support coretemp kvm dcdbas dm_service_time microcode serio_raw pcspkr lpc_ich mfd_core i7core_edac edac_core ses enclosure ipmi_si ipmi_msghandler shpchp acpi_power_meter mperf nfsd auth_rpcgss nfs_acl lockd uinput sunrpc dm_multipath xfs libcrc32c ata_generic pata_acpi sr_mod cdrom sd_mod usb_storage mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit lpfc drm_kms_helper ttm crc32c_intel ata_piix bfa drm ixgbe libata i2c_core mdio crc_t10dif ptp crct10dif_common pps_core scsi_transport_fc dca scsi_tgt megaraid_sas bnx2 dm_mirror dm_region_hash dm_log dm_mod CPU: 16 PID: 2572 Comm: X Not tainted 3.10.0-86.el7.x86_64 #1 Hardware name: Dell Inc. PowerEdge R810/0H235N, BIOS 0.3.0 11/14/2009 task: ffff8801799dabc0 ti: ffff88016c884000 task.ti: ffff88016c884000 RIP: 0010:[<0000000000000000>] [< (null)>] (null) RSP: 0018:ffff88016c885ad8 EFLAGS: 00010202 RAX: ffffffffa04e94c0 RBX: ffff880178937a20 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000240004 RDI: ffff880178937a00 RBP: ffff88016c885b60 R08: 00000000000171a0 R09: ffff88007cf171a0 R10: ffffea0005842540 R11: ffffffff810487b9 R12: ffff880178937b30 R13: ffff880178937a00 R14: ffff88016c885b78 R15: ffff880179929400 FS: 00007f81ba2ef980(0000) GS:ffff88007cf00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000016e763000 CR4: 00000000000007e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Stack: ffffffffa0306fae ffff8801799295c0 0000000000260004 0000000000000001 ffff88016c885b60 ffffffffa0307669 00ff88007cf17738 ffff88017cf17700 ffff880178937a00 ffff880100000000 ffff880100000000 0000000079929400 Call Trace: [] ? ttm_bo_handle_move_mem+0x54e/0x5b0 [ttm] [] ? ttm_bo_mem_space+0x169/0x340 [ttm] [] ttm_bo_move_buffer+0x117/0x130 [ttm] [] ? perf_event_init_context+0x141/0x220 [] ttm_bo_validate+0xc1/0x130 [ttm] [] mgag200_bo_pin+0x87/0xc0 [mgag200] [] mga_crtc_cursor_set+0x474/0xbb0 [mgag200] [] ? __mem_cgroup_commit_charge+0x152/0x3b0 [] ? mutex_lock+0x12/0x2f [] drm_mode_cursor_common+0x123/0x170 [drm] [] drm_mode_cursor_ioctl+0x41/0x50 [drm] [] drm_ioctl+0x502/0x630 [drm] [] ? __do_page_fault+0x1f4/0x510 [] ? __restore_xstate_sig+0x218/0x4f0 [] do_vfs_ioctl+0x2e5/0x4d0 [] ? file_has_perm+0x8e/0xa0 [] SyS_ioctl+0x81/0xa0 [] system_call_fastpath+0x16/0x1b Code: Bad RIP value. RIP [< (null)>] (null) RSP CR2: 0000000000000000 Signed-off-by: Rob Clark Reviewed-by: Jérôme Glisse Reviewed-by: Thomas Hellstrom Cc: stable@vger.kernel.org Signed-off-by: Jiri Slaby commit fda958d58e76236b5bd73a7ff858f595cd2a5b57 Author: Filipe Brandenburger Date: Mon Mar 3 15:38:25 2014 -0800 memcg: reparent charges of children before processing parent commit 4fb1a86fb5e4209a7d4426d4e586c58e9edc74ac upstream. Sometimes the cleanup after memcg hierarchy testing gets stuck in mem_cgroup_reparent_charges(), unable to bring non-kmem usage down to 0. There may turn out to be several causes, but a major cause is this: the workitem to offline parent can get run before workitem to offline child; parent's mem_cgroup_reparent_charges() circles around waiting for the child's pages to be reparented to its lrus, but it's holding cgroup_mutex which prevents the child from reaching its mem_cgroup_reparent_charges(). Further testing showed that an ordered workqueue for cgroup_destroy_wq is not always good enough: percpu_ref_kill_and_confirm's call_rcu_sched stage on the way can mess up the order before reaching the workqueue. Instead, when offlining a memcg, call mem_cgroup_reparent_charges() on all its children (and grandchildren, in the correct order) to have their charges reparented first. Fixes: e5fca243abae ("cgroup: use a dedicated workqueue for cgroup destruction") Signed-off-by: Filipe Brandenburger Signed-off-by: Hugh Dickins Reviewed-by: Tejun Heo Acked-by: Michal Hocko Cc: Johannes Weiner Cc: [v3.10+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit c880551355b056f9d23d522fe3f8b4da975d950b Author: Florian Westphal Date: Fri Sep 20 22:32:56 2013 +0200 tcp: syncookies: reduce mss table to four values commit 086293542b991fb88a2e41ae7b4f82ac65a20e1a upstream. Halve mss table size to make blind cookie guessing more difficult. This is sad since the tables were already small, but there is little alternative except perhaps adding more precise mss information in the tcp timestamp. Timestamps are unfortunately not ubiquitous. Guessing all possible cookie values still has 8-in 2**32 chance. Reported-by: Jakob Lell Signed-off-by: Florian Westphal Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 6c17205526423c520d8a708d4dbcecbdfe7e9f72 Author: Florian Westphal Date: Fri Sep 20 22:32:55 2013 +0200 tcp: syncookies: reduce cookie lifetime to 128 seconds commit 8c27bd75f04fb9cb70c69c3cfe24f4e6d8e15906 upstream. We currently accept cookies that were created less than 4 minutes ago (ie, cookies with counter delta 0-3). Combined with the 8 mss table values, this yields 32 possible values (out of 2**32) that will be valid. Reducing the lifetime to < 2 minutes halves the guessing chance while still providing a large enough period. While at it, get rid of jiffies value -- they overflow too quickly on 32 bit platforms. getnstimeofday is used to create a counter that increments every 64s. perf shows getnstimeofday cost is negible compared to sha_transform; normal tcp initial sequence number generation uses getnstimeofday, too. Reported-by: Jakob Lell Signed-off-by: Florian Westphal Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 5516d3fa4670849e446c81ddd4c00f0fd09f1173 Author: Michal Kubecek Date: Thu Oct 17 15:07:40 2013 +0200 xfrm: prevent ipcomp scratch buffer race condition commit 12e3594698f6c3ab6ebacc79f2fb2ad2bb5952b5 upstream. In ipcomp_compress(), sortirq is enabled too early, allowing the per-cpu scratch buffer to be rewritten by ipcomp_decompress() (called on the same CPU in softirq context) between populating the buffer and copying the compressed data to the skb. v2: as pointed out by Steffen Klassert, if we also move the local_bh_disable() before reading the per-cpu pointers, we can get rid of get_cpu()/put_cpu(). v3: removed ipcomp_decompress part (as explained by Herbert Xu, it cannot be called from process context), get rid of cpu variable (thanks to Eric Dumazet) Signed-off-by: Michal Kubecek Reviewed-by: Eric Dumazet Acked-by: Herbert Xu Signed-off-by: Steffen Klassert Signed-off-by: Jiri Slaby commit 03cb0a7b03eda410fb0f7e03843e60c3318a38e7 Author: Oleg Drokin Date: Fri Jan 31 15:41:58 2014 -0500 Fix mountpoint reference leakage in linkat commit d22e6338db7f613dd4f6095c190682fcc519e4b7 upstream. Recent changes to retry on ESTALE in linkat (commit 442e31ca5a49e398351b2954b51f578353fdf210) introduced a mountpoint reference leak and a small memory leak in case a filesystem link operation returns ESTALE which is pretty normal for distributed filesystems like lustre, nfs and so on. Free old_path in such a case. [AV: there was another missing path_put() nearby - on the previous goto retry] [js: the second path_put is not in 3.12 yet, hunk removed] Signed-off-by: Oleg Drokin: Signed-off-by: Al Viro Signed-off-by: Jiri Slaby commit 00c53b02cb01976b35d37670a4b5c5d7a6ad3c62 Author: Daniel Borkmann Date: Mon Mar 3 17:23:04 2014 +0100 net: sctp: fix sctp_sf_do_5_1D_ce to verify if we/peer is AUTH capable [ Upstream commit ec0223ec48a90cb605244b45f7c62de856403729 ] RFC4895 introduced AUTH chunks for SCTP; during the SCTP handshake RANDOM; CHUNKS; HMAC-ALGO are negotiated (CHUNKS being optional though): ---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ----------> <------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] --------- -------------------- COOKIE-ECHO --------------------> <-------------------- COOKIE-ACK --------------------- A special case is when an endpoint requires COOKIE-ECHO chunks to be authenticated: ---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ----------> <------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] --------- ------------------ AUTH; COOKIE-ECHO ----------------> <-------------------- COOKIE-ACK --------------------- RFC4895, section 6.3. Receiving Authenticated Chunks says: The receiver MUST use the HMAC algorithm indicated in the HMAC Identifier field. If this algorithm was not specified by the receiver in the HMAC-ALGO parameter in the INIT or INIT-ACK chunk during association setup, the AUTH chunk and all the chunks after it MUST be discarded and an ERROR chunk SHOULD be sent with the error cause defined in Section 4.1. [...] If no endpoint pair shared key has been configured for that Shared Key Identifier, all authenticated chunks MUST be silently discarded. [...] When an endpoint requires COOKIE-ECHO chunks to be authenticated, some special procedures have to be followed because the reception of a COOKIE-ECHO chunk might result in the creation of an SCTP association. If a packet arrives containing an AUTH chunk as a first chunk, a COOKIE-ECHO chunk as the second chunk, and possibly more chunks after them, and the receiver does not have an STCB for that packet, then authentication is based on the contents of the COOKIE-ECHO chunk. In this situation, the receiver MUST authenticate the chunks in the packet by using the RANDOM parameters, CHUNKS parameters and HMAC_ALGO parameters obtained from the COOKIE-ECHO chunk, and possibly a local shared secret as inputs to the authentication procedure specified in Section 6.3. If authentication fails, then the packet is discarded. If the authentication is successful, the COOKIE-ECHO and all the chunks after the COOKIE-ECHO MUST be processed. If the receiver has an STCB, it MUST process the AUTH chunk as described above using the STCB from the existing association to authenticate the COOKIE-ECHO chunk and all the chunks after it. [...] Commit bbd0d59809f9 introduced the possibility to receive and verification of AUTH chunk, including the edge case for authenticated COOKIE-ECHO. On reception of COOKIE-ECHO, the function sctp_sf_do_5_1D_ce() handles processing, unpacks and creates a new association if it passed sanity checks and also tests for authentication chunks being present. After a new association has been processed, it invokes sctp_process_init() on the new association and walks through the parameter list it received from the INIT chunk. It checks SCTP_PARAM_RANDOM, SCTP_PARAM_HMAC_ALGO and SCTP_PARAM_CHUNKS, and copies them into asoc->peer meta data (peer_random, peer_hmacs, peer_chunks) in case sysctl -w net.sctp.auth_enable=1 is set. If in INIT's SCTP_PARAM_SUPPORTED_EXT parameter SCTP_CID_AUTH is set, peer_random != NULL and peer_hmacs != NULL the peer is to be assumed asoc->peer.auth_capable=1, in any other case asoc->peer.auth_capable=0. Now, if in sctp_sf_do_5_1D_ce() chunk->auth_chunk is available, we set up a fake auth chunk and pass that on to sctp_sf_authenticate(), which at latest in sctp_auth_calculate_hmac() reliably dereferences a NULL pointer at position 0..0008 when setting up the crypto key in crypto_hash_setkey() by using asoc->asoc_shared_key that is NULL as condition key_id == asoc->active_key_id is true if the AUTH chunk was injected correctly from remote. This happens no matter what net.sctp.auth_enable sysctl says. The fix is to check for net->sctp.auth_enable and for asoc->peer.auth_capable before doing any operations like sctp_sf_authenticate() as no key is activated in sctp_auth_asoc_init_active_key() for each case. Now as RFC4895 section 6.3 states that if the used HMAC-ALGO passed from the INIT chunk was not used in the AUTH chunk, we SHOULD send an error; however in this case it would be better to just silently discard such a maliciously prepared handshake as we didn't even receive a parameter at all. Also, as our endpoint has no shared key configured, section 6.3 says that MUST silently discard, which we are doing from now onwards. Before calling sctp_sf_pdiscard(), we need not only to free the association, but also the chunk->auth_chunk skb, as commit bbd0d59809f9 created a skb clone in that case. I have tested this locally by using netfilter's nfqueue and re-injecting packets into the local stack after maliciously modifying the INIT chunk (removing RANDOM; HMAC-ALGO param) and the SCTP packet containing the COOKIE_ECHO (injecting AUTH chunk before COOKIE_ECHO). Fixed with this patch applied. Fixes: bbd0d59809f9 ("[SCTP]: Implement the receive and verification of AUTH chunk") Signed-off-by: Daniel Borkmann Cc: Vlad Yasevich Cc: Neil Horman Acked-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 2a01e9e41e868b3bc290976b9c754a9f7e6672c4 Author: Xin Long Date: Mon Mar 3 20:18:36 2014 +0800 ip_tunnel:multicast process cause panic due to skb->_skb_refdst NULL pointer [ Upstream commit 10ddceb22bab11dab10ba645c7df2e4a8e7a5db5 ] when ip_tunnel process multicast packets, it may check if the packet is looped back packet though 'rt_is_output_route(skb_rtable(skb))' in ip_tunnel_rcv(), but before that , skb->_skb_refdst has been dropped in iptunnel_pull_header(), so which leads to a panic. fix the bug: https://bugzilla.kernel.org/show_bug.cgi?id=70681 Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit baef79a5c127beade866aef4e4e92c1547f41c86 Author: Michael Chan Date: Fri Feb 28 15:05:10 2014 -0800 tg3: Don't check undefined error bits in RXBD [ Upstream commit d7b95315cc7f441418845a165ee56df723941487 ] Redefine the RXD_ERR_MASK to include only relevant error bits. This fixes a customer reported issue of randomly dropping packets on the 5719. Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 537fc749affa05f1040f48ef7a74f5115068fc6b Author: Hans Schillstrom Date: Thu Feb 27 12:57:58 2014 +0100 ipv6: ipv6_find_hdr restore prev functionality [ Upstream commit accfe0e356327da5bd53da8852b93fc22de9b5fc ] The commit 9195bb8e381d81d5a315f911904cdf0cfcc919b8 ("ipv6: improve ipv6_find_hdr() to skip empty routing headers") broke ipv6_find_hdr(). When a target is specified like IPPROTO_ICMPV6 ipv6_find_hdr() returns -ENOENT when it's found, not the header as expected. A part of IPVS is broken and possible also nft_exthdr_eval(). When target is -1 which it is most cases, it works. This patch exits the do while loop if the specific header is found so the nexthdr could be returned as expected. Reported-by: Art -kwaak- van Breemen Signed-off-by: Hans Schillstrom CC:Ansis Atteka Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 1c0267641d69bea415a8176de1ab996dfed3a510 Author: Edward Cree Date: Tue Feb 25 13:17:59 2014 +0000 sfc: check for NULL efx->ptp_data in efx_ptp_event [ Upstream commit 8f355e5cee63c2c0c145d8206c4245d0189f47ff ] If we receive a PTP event from the NIC when we haven't set up PTP state in the driver, we attempt to read through a NULL pointer efx->ptp_data, triggering a panic. Signed-off-by: Edward Cree Acked-by: Shradha Shah Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 3bbb02a1ba7a2ad0dbbd979ed715c9229b12e36a Author: Hannes Frederic Sowa Date: Fri Feb 21 02:55:35 2014 +0100 ipv6: reuse ip6_frag_id from ip6_ufo_append_data [ Upstream commit 916e4cf46d0204806c062c8c6c4d1f633852c5b6 ] Currently we generate a new fragmentation id on UFO segmentation. It is pretty hairy to identify the correct net namespace and dst there. Especially tunnels use IFF_XMIT_DST_RELEASE and thus have no skb_dst available at all. This causes unreliable or very predictable ipv6 fragmentation id generation while segmentation. Luckily we already have pregenerated the ip6_frag_id in ip6_ufo_append_data and can use it here. Signed-off-by: Hannes Frederic Sowa Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 251ed2ca436332fc6055445967e85291276346b5 Author: Jason Wang Date: Fri Feb 21 13:08:04 2014 +0800 virtio-net: alloc big buffers also when guest can receive UFO [ Upstream commit 0e7ede80d929ff0f830c44a543daa1acd590c749 ] We should alloc big buffers also when guest can receive UFO packets to let the big packets fit into guest rx buffer. Fixes 5c5167515d80f78f6bb538492c423adcae31ad65 (virtio-net: Allow UFO feature to be set and advertised.) Cc: Rusty Russell Cc: Michael S. Tsirkin Cc: Sridhar Samudrala Signed-off-by: Jason Wang Acked-by: Michael S. Tsirkin Acked-by: Rusty Russell Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit df3839f910d836f85620947f0957d40a4171afd9 Author: Duan Jiong Date: Thu Feb 27 17:14:41 2014 +0800 neigh: recompute reachabletime before returning from neigh_periodic_work() [ Upstream commit feff9ab2e7fa773b6a3965f77375fe89f7fd85cf ] If the neigh table's entries is less than gc_thresh1, the function will return directly, and the reachabletime will not be recompute, so the reachabletime can be guessed. Signed-off-by: Duan Jiong Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 10bbbd58f309101e93643637f784ee069785ace2 Author: Eric Dumazet Date: Thu Feb 20 10:09:18 2014 -0800 net-tcp: fastopen: fix high order allocations [ Upstream commit f5ddcbbb40aa0ba7fbfe22355d287603dbeeaaac ] This patch fixes two bugs in fastopen : 1) The tcp_sendmsg(..., @size) argument was ignored. Code was relying on user not fooling the kernel with iovec mismatches 2) When MTU is about 64KB, tcp_send_syn_data() attempts order-5 allocations, which are likely to fail when memory gets fragmented. Fixes: 783237e8daf13 ("net-tcp: Fast Open client - sending SYN-data") Signed-off-by: Eric Dumazet Cc: Yuchung Cheng Acked-by: Yuchung Cheng Tested-by: Yuchung Cheng Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit cbf5a3f6866d1bd105da94090ce7446ef20c610b Author: Fernando Luis Vazquez Cao Date: Tue Feb 18 21:20:09 2014 +0900 tun: remove bogus hardware vlan acceleration flags from vlan_features [ Upstream commit 6671b2240c54585d4afb5286a29f1569fe5e40a8 ] Even though only the outer vlan tag can be HW accelerated in the transmission path, in the TUN/TAP driver vlan_features mirrors hw_features, which happens to have the NETIF_F_HW_VLAN_?TAG_TX flags set. Because of this, during packet tranmisssion through a stacked vlan device dev_hard_start_xmit, (incorrectly) assuming that the vlan device supports hardware vlan acceleration, does not add the vlan header to the skb payload and the inner vlan tags are lost (vlan_tci contains the outer vlan tag when userspace reads the packet from the tap device). Signed-off-by: Fernando Luis Vazquez Cao Signed-off-by: Toshiaki Makita Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit cc9f71b2cc82f1fb66dc5d1ff3fc4eefe8b06f91 Author: Toshiaki Makita Date: Tue Feb 18 21:20:08 2014 +0900 veth: Fix vlan_features so as to be able to use stacked vlan interfaces [ Upstream commit 8d0d21f4053c07714802cbe8b1fe26913ec296cc ] Even if we create a stacked vlan interface such as veth0.10.20, it sends single tagged frames (tagged with only vid 10). Because vlan_features of a veth interface has the NETIF_F_HW_VLAN_[CTAG/STAG]_TX bits, veth0.10 also has that feature, so dev_hard_start_xmit(veth0.10) doesn't call __vlan_put_tag() and vlan_dev_hard_start_xmit(veth0.10) overwrites vlan_tci. This prevents us from using a combination of 802.1ad and 802.1Q in containers, etc. Signed-off-by: Toshiaki Makita Acked-by: Flavio Leitner Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 17d633ca63add6ccaa77e125ba1e8693635bc9f1 Author: Waiman Long Date: Tue Jul 23 17:38:41 2013 -0400 SELinux: Increase ebitmap_node size for 64-bit configuration commit a767f680e34bf14a36fefbbb6d85783eef99fd57 upstream. Currently, the ebitmap_node structure has a fixed size of 32 bytes. On a 32-bit system, the overhead is 8 bytes, leaving 24 bytes for being used as bitmaps. The overhead ratio is 1/4. On a 64-bit system, the overhead is 16 bytes. Therefore, only 16 bytes are left for bitmap purpose and the overhead ratio is 1/2. With a 3.8.2 kernel, a boot-up operation will cause the ebitmap_get_bit() function to be called about 9 million times. The average number of ebitmap_node traversal is about 3.7. This patch increases the size of the ebitmap_node structure to 64 bytes for 64-bit system to keep the overhead ratio at 1/4. This may also improve performance a little bit by making node to node traversal less frequent (< 2) as more bits are available in each node. Signed-off-by: Waiman Long Acked-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Eric Paris Signed-off-by: Jiri Slaby commit 3b32517baa8fc344dd216ed0d57f1589a041746a Author: Waiman Long Date: Tue Jul 23 17:38:41 2013 -0400 SELinux: Reduce overhead of mls_level_isvalid() function call commit fee7114298cf54bbd221cdb2ab49738be8b94f4c upstream. While running the high_systime workload of the AIM7 benchmark on a 2-socket 12-core Westmere x86-64 machine running 3.10-rc4 kernel (with HT on), it was found that a pretty sizable amount of time was spent in the SELinux code. Below was the perf trace of the "perf record -a -s" of a test run at 1500 users: 5.04% ls [kernel.kallsyms] [k] ebitmap_get_bit 1.96% ls [kernel.kallsyms] [k] mls_level_isvalid 1.95% ls [kernel.kallsyms] [k] find_next_bit The ebitmap_get_bit() was the hottest function in the perf-report output. Both the ebitmap_get_bit() and find_next_bit() functions were, in fact, called by mls_level_isvalid(). As a result, the mls_level_isvalid() call consumed 8.95% of the total CPU time of all the 24 virtual CPUs which is quite a lot. The majority of the mls_level_isvalid() function invocations come from the socket creation system call. Looking at the mls_level_isvalid() function, it is checking to see if all the bits set in one of the ebitmap structure are also set in another one as well as the highest set bit is no bigger than the one specified by the given policydb data structure. It is doing it in a bit-by-bit manner. So if the ebitmap structure has many bits set, the iteration loop will be done many times. The current code can be rewritten to use a similar algorithm as the ebitmap_contains() function with an additional check for the highest set bit. The ebitmap_contains() function was extended to cover an optional additional check for the highest set bit, and the mls_level_isvalid() function was modified to call ebitmap_contains(). With that change, the perf trace showed that the used CPU time drop down to just 0.08% (ebitmap_contains + mls_level_isvalid) of the total which is about 100X less than before. 0.07% ls [kernel.kallsyms] [k] ebitmap_contains 0.05% ls [kernel.kallsyms] [k] ebitmap_get_bit 0.01% ls [kernel.kallsyms] [k] mls_level_isvalid 0.01% ls [kernel.kallsyms] [k] find_next_bit The remaining ebitmap_get_bit() and find_next_bit() functions calls are made by other kernel routines as the new mls_level_isvalid() function will not call them anymore. This patch also improves the high_systime AIM7 benchmark result, though the improvement is not as impressive as is suggested by the reduction in CPU time spent in the ebitmap functions. The table below shows the performance change on the 2-socket x86-64 system (with HT on) mentioned above. +--------------+---------------+----------------+-----------------+ | Workload | mean % change | mean % change | mean % change | | | 10-100 users | 200-1000 users | 1100-2000 users | +--------------+---------------+----------------+-----------------+ | high_systime | +0.1% | +0.9% | +2.6% | +--------------+---------------+----------------+-----------------+ Signed-off-by: Waiman Long Acked-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Eric Paris Signed-off-by: Jiri Slaby commit 67e204a06c70c4050c2ac00532ee7d2bb4ffcc79 Author: Mel Gorman Date: Tue Nov 12 15:08:15 2013 -0800 mm: do not walk all of system memory during show_mem commit c78e93630d15b5f5774213aad9bdc9f52473a89b upstream. It has been reported on very large machines that show_mem is taking almost 5 minutes to display information. This is a serious problem if there is an OOM storm. The bulk of the cost is in show_mem doing a very expensive PFN walk to give us the following information Total RAM: Also available as totalram_pages Highmem pages: Also available as totalhigh_pages Reserved pages: Can be inferred from the zone structure Shared pages: PFN walk required Unshared pages: PFN walk required Quick pages: Per-cpu walk required Only the shared/unshared pages requires a full PFN walk but that information is useless. It is also inaccurate as page pins of unshared pages would be accounted for as shared. Even if the information was accurate, I'm struggling to think how the shared/unshared information could be useful for debugging OOM conditions. Maybe it was useful before rmap existed when reclaiming shared pages was costly but it is less relevant today. The PFN walk could be optimised a bit but why bother as the information is useless. This patch deletes the PFN walker and infers the total RAM, highmem and reserved pages count from struct zone. It omits the shared/unshared page usage on the grounds that it is useless. It also corrects the reporting of HighMem as HighMem/MovableOnly as ZONE_MOVABLE has similar problems to HighMem with respect to lowmem/highmem exhaustion. Signed-off-by: Mel Gorman Cc: David Rientjes Acked-by: KOSAKI Motohiro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 230a558c94d9f2411381bab5a5aa5be91ba53ff9 Author: Jason Baron Date: Thu Jan 2 12:58:54 2014 -0800 epoll: do not take the nested ep->mtx on EPOLL_CTL_DEL commit 4ff36ee94d93ddb4b7846177f1118d9aa33408e2 upstream. The EPOLL_CTL_DEL path of epoll contains a classic, ab-ba deadlock. That is, epoll_ctl(a, EPOLL_CTL_DEL, b, x), will deadlock with epoll_ctl(b, EPOLL_CTL_DEL, a, x). The deadlock was introduced with commmit 67347fe4e632 ("epoll: do not take global 'epmutex' for simple topologies"). The acquistion of the ep->mtx for the destination 'ep' was added such that a concurrent EPOLL_CTL_ADD operation would see the correct state of the ep (Specifically, the check for '!list_empty(&f.file->f_ep_links') However, by simply not acquiring the lock, we do not serialize behind the ep->mtx from the add path, and thus may perform a full path check when if we had waited a little longer it may not have been necessary. However, this is a transient state, and performing the full loop checking in this case is not harmful. The important point is that we wouldn't miss doing the full loop checking when required, since EPOLL_CTL_ADD always locks any 'ep's that its operating upon. The reason we don't need to do lock ordering in the add path, is that we are already are holding the global 'epmutex' whenever we do the double lock. Further, the original posting of this patch, which was tested for the intended performance gains, did not perform this additional locking. Signed-off-by: Jason Baron Cc: Nathan Zimmer Cc: Eric Wong Cc: Nelson Elhage Cc: Al Viro Cc: Davide Libenzi Cc: "Paul E. McKenney" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 107c194349992f74aece93070d4b378230b23a5a Author: Jason Baron Date: Tue Nov 12 15:10:18 2013 -0800 epoll: do not take global 'epmutex' for simple topologies commit 67347fe4e6326338ee217d7eb826bedf30b2e155 upstream. When calling EPOLL_CTL_ADD for an epoll file descriptor that is attached directly to a wakeup source, we do not need to take the global 'epmutex', unless the epoll file descriptor is nested. The purpose of taking the 'epmutex' on add is to prevent complex topologies such as loops and deep wakeup paths from forming in parallel through multiple EPOLL_CTL_ADD operations. However, for the simple case of an epoll file descriptor attached directly to a wakeup source (with no nesting), we do not need to hold the 'epmutex'. This patch along with 'epoll: optimize EPOLL_CTL_DEL using rcu' improves scalability on larger systems. Quoting Nathan Zimmer's mail on SPECjbb performance: "On the 16 socket run the performance went from 35k jOPS to 125k jOPS. In addition the benchmark when from scaling well on 10 sockets to scaling well on just over 40 sockets. ... Currently the benchmark stops scaling at around 40-44 sockets but it seems like I found a second unrelated bottleneck." [akpm@linux-foundation.org: use `bool' for boolean variables, remove unneeded/undesirable cast of void*, add missed ep_scan_ready_list() kerneldoc] Signed-off-by: Jason Baron Tested-by: Nathan Zimmer Cc: Eric Wong Cc: Nelson Elhage Cc: Al Viro Cc: Davide Libenzi Cc: "Paul E. McKenney" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 81ff0d3b03c450601fa29a49baedf826c738fc24 Author: Jason Baron Date: Tue Nov 12 15:10:16 2013 -0800 epoll: optimize EPOLL_CTL_DEL using rcu commit ae10b2b4eb01bedc91d29d5c5bb9e416fd806c40 upstream. Nathan Zimmer found that once we get over 10+ cpus, the scalability of SPECjbb falls over due to the contention on the global 'epmutex', which is taken in on EPOLL_CTL_ADD and EPOLL_CTL_DEL operations. Patch #1 removes the 'epmutex' lock completely from the EPOLL_CTL_DEL path by using rcu to guard against any concurrent traversals. Patch #2 remove the 'epmutex' lock from EPOLL_CTL_ADD operations for simple topologies. IE when adding a link from an epoll file descriptor to a wakeup source, where the epoll file descriptor is not nested. This patch (of 2): Optimize EPOLL_CTL_DEL such that it does not require the 'epmutex' by converting the file->f_ep_links list into an rcu one. In this way, we can traverse the epoll network on the add path in parallel with deletes. Since deletes can't create loops or worse wakeup paths, this is safe. This patch in combination with the patch "epoll: Do not take global 'epmutex' for simple topologies", shows a dramatic performance improvement in scalability for SPECjbb. Signed-off-by: Jason Baron Tested-by: Nathan Zimmer Cc: Eric Wong Cc: Nelson Elhage Cc: Al Viro Cc: Davide Libenzi Cc: "Paul E. McKenney" CC: Wu Fengguang Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit dd7ab8120e6709e90d7cdc5ecb66e18fd78001e4 Author: Jiri Slaby Date: Fri Oct 25 15:06:58 2013 +0200 x86/dumpstack: Fix printk_address for direct addresses commit 5f01c98859073cb512b01d4fad74b5f4e047be0b upstream. Consider a kernel crash in a module, simulated the following way: static int my_init(void) { char *map = (void *)0x5; *map = 3; return 0; } module_init(my_init); When we turn off FRAME_POINTERs, the very first instruction in that function causes a BUG. The problem is that we print IP in the BUG report using %pB (from printk_address). And %pB decrements the pointer by one to fix printing addresses of functions with tail calls. This was added in commit 71f9e59800e5ad4 ("x86, dumpstack: Use %pB format specifier for stack trace") to fix the call stack printouts. So instead of correct output: BUG: unable to handle kernel NULL pointer dereference at 0000000000000005 IP: [] my_init+0x0/0x10 [pb173] We get: BUG: unable to handle kernel NULL pointer dereference at 0000000000000005 IP: [] 0xffffffffa0151fff To fix that, we use %pS only for stack addresses printouts (via newly added printk_stack_address) and %pB for regs->ip (via printk_address). I.e. we revert to the old behaviour for all except call stacks. And since from all those reliable is 1, we remove that parameter from printk_address. Signed-off-by: Jiri Slaby Cc: Namhyung Kim Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: joe@perches.com Cc: jirislaby@gmail.com Link: http://lkml.kernel.org/r/1382706418-8435-1-git-send-email-jslaby@suse.cz Signed-off-by: Ingo Molnar Signed-off-by: Jiri Slaby commit 6456bd97dfc0bf51439de35955628e89dd8bccd7 Author: NeilBrown Date: Thu Oct 31 16:14:36 2013 +1100 SUNRPC: close a rare race in xs_tcp_setup_socket. commit 93dc41bdc5c853916610576c6b48a1704959c70d upstream. We have one report of a crash in xs_tcp_setup_socket. The call path to the crash is: xs_tcp_setup_socket -> inet_stream_connect -> lock_sock_nested. The 'sock' passed to that last function is NULL. The only way I can see this happening is a concurrent call to xs_close: xs_close -> xs_reset_transport -> sock_release -> inet_release inet_release sets: sock->sk = NULL; inet_stream_connect calls lock_sock(sock->sk); which gets NULL. All calls to xs_close are protected by XPRT_LOCKED as are most activations of the workqueue which runs xs_tcp_setup_socket. The exception is xs_tcp_schedule_linger_timeout. So presumably the timeout queued by the later fires exactly when some other code runs xs_close(). To protect against this we can move the cancel_delayed_work_sync() call from xs_destory() to xs_close(). As xs_close is never called from the worker scheduled on ->connect_worker, this can never deadlock. Signed-off-by: NeilBrown [Trond: Make it safe to call cancel_delayed_work_sync() on AF_LOCAL sockets] Signed-off-by: Trond Myklebust Signed-off-by: Jiri Slaby commit 4aef0b11ba4fa4c2cd115c312dd9f0b64cad1bf1 Author: Shawn Bohrer Date: Fri Oct 4 14:24:53 2013 -0500 sched/rt: Remove redundant nr_cpus_allowed test commit 6bfa687c19b7ab8adee03f0d43c197c2945dd869 upstream. In 76854c7e8f3f4172fef091e78d88b3b751463ac6 ("sched: Use rt.nr_cpus_allowed to recover select_task_rq() cycles") an optimization was added to select_task_rq_rt() that immediately returns when p->nr_cpus_allowed == 1 at the beginning of the function. This makes the latter p->nr_cpus_allowed > 1 check redundant, which can now be removed. Signed-off-by: Shawn Bohrer Reviewed-by: Steven Rostedt Cc: Mike Galbraith Cc: tomk@rgmadvisors.com Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1380914693-24634-1-git-send-email-shawn.bohrer@gmail.com Signed-off-by: Ingo Molnar Signed-off-by: Jiri Slaby commit d171cbfc349b897d89ae4a0fe5fb75c4e1e65097 Author: Peter Zijlstra Date: Tue Oct 15 12:35:07 2013 +0200 sched/rt: Add missing rmb() commit 7c3f2ab7b844f1a859afbc3d41925e8a0faba5fa upstream. While discussing the proposed SCHED_DEADLINE patches which in parts mimic the existing FIFO code it was noticed that the wmb in rt_set_overloaded() didn't have a matching barrier. The only site using rt_overloaded() to test the rto_count is pull_rt_task() and we should issue a matching rmb before then assuming there's an rto_mask bit set. Without that smp_rmb() in there we could actually miss seeing the rto_mask bit. Also, change to using smp_[wr]mb(), even though this is SMP only code; memory barriers without smp_ always make me think they're against hardware of some sort. Signed-off-by: Peter Zijlstra Cc: vincent.guittot@linaro.org Cc: luca.abeni@unitn.it Cc: bruce.ashfield@windriver.com Cc: dhaval.giani@gmail.com Cc: rostedt@goodmis.org Cc: hgu1972@gmail.com Cc: oleg@redhat.com Cc: fweisbec@gmail.com Cc: darren@dvhart.com Cc: johan.eker@ericsson.com Cc: p.faure@akatech.ch Cc: paulmck@linux.vnet.ibm.com Cc: raistlin@linux.it Cc: claudio@evidence.eu.com Cc: insop.song@gmail.com Cc: michael@amarulasolutions.com Cc: liming.wang@windriver.com Cc: fchecconi@gmail.com Cc: jkacur@redhat.com Cc: tommaso.cucinotta@sssup.it Cc: Juri Lelli Cc: harald.gustafsson@ericsson.com Cc: nicola.manica@disi.unitn.it Cc: tglx@linutronix.de Link: http://lkml.kernel.org/r/20131015103507.GF10651@twins.programming.kicks-ass.net Signed-off-by: Ingo Molnar Signed-off-by: Jiri Slaby commit 4edad9c1129ac6b3ad319009f005d20c6bfda3b9 Author: Mel Gorman Date: Tue Dec 17 09:21:25 2013 +0000 sched: Assign correct scheduling domain to 'sd_llc' commit 5d4cf996cf134e8ddb4f906b8197feb9267c2b77 upstream. Commit 42eb088e (sched: Avoid NULL dereference on sd_busy) corrected a NULL dereference on sd_busy but the fix also altered what scheduling domain it used for the 'sd_llc' percpu variable. One impact of this is that a task selecting a runqueue may consider idle CPUs that are not cache siblings as candidates for running. Tasks are then running on CPUs that are not cache hot. This was found through bisection where ebizzy threads were not seeing equal performance and it looked like a scheduling fairness issue. This patch mitigates but does not completely fix the problem on all machines tested implying there may be an additional bug or a common root cause. Here are the average range of performance seen by individual ebizzy threads. It was tested on top of candidate patches related to x86 TLB range flushing. 4-core machine 3.13.0-rc3 3.13.0-rc3 vanilla fixsd-v3r3 Mean 1 0.00 ( 0.00%) 0.00 ( 0.00%) Mean 2 0.34 ( 0.00%) 0.10 ( 70.59%) Mean 3 1.29 ( 0.00%) 0.93 ( 27.91%) Mean 4 7.08 ( 0.00%) 0.77 ( 89.12%) Mean 5 193.54 ( 0.00%) 2.14 ( 98.89%) Mean 6 151.12 ( 0.00%) 2.06 ( 98.64%) Mean 7 115.38 ( 0.00%) 2.04 ( 98.23%) Mean 8 108.65 ( 0.00%) 1.92 ( 98.23%) 8-core machine Mean 1 0.00 ( 0.00%) 0.00 ( 0.00%) Mean 2 0.40 ( 0.00%) 0.21 ( 47.50%) Mean 3 23.73 ( 0.00%) 0.89 ( 96.25%) Mean 4 12.79 ( 0.00%) 1.04 ( 91.87%) Mean 5 13.08 ( 0.00%) 2.42 ( 81.50%) Mean 6 23.21 ( 0.00%) 69.46 (-199.27%) Mean 7 15.85 ( 0.00%) 101.72 (-541.77%) Mean 8 109.37 ( 0.00%) 19.13 ( 82.51%) Mean 12 124.84 ( 0.00%) 28.62 ( 77.07%) Mean 16 113.50 ( 0.00%) 24.16 ( 78.71%) It's eliminated for one machine and reduced for another. Signed-off-by: Mel Gorman Signed-off-by: Peter Zijlstra Cc: Alex Shi Cc: Andrew Morton Cc: Fengguang Wu Cc: H Peter Anvin Cc: Linus Torvalds Link: http://lkml.kernel.org/r/20131217092124.GV11295@suse.de Signed-off-by: Ingo Molnar Signed-off-by: Jiri Slaby commit 8dc051a7e50b0bc7eae9a640334258e04a6d2fdd Author: Peter Zijlstra Date: Wed Dec 11 11:09:53 2013 +0100 sched: Initialize power_orig for overlapping groups commit 8e8339a3a1069141985daaa2521ba304509ddecd upstream. Yinghai reported that he saw a /0 in sg_capacity on his EX parts. Make sure to always initialize power_orig now that we actually use it. Ideally build_sched_domains() -> init_sched_groups_power() would also initialize this; but for some yet unexplained reason some setups seem to miss updates there. Reported-by: Yinghai Lu Tested-by: Yinghai Lu Signed-off-by: Peter Zijlstra Link: http://lkml.kernel.org/n/tip-l8ng2m9uml6fhibln8wqpom7@git.kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Jiri Slaby commit a2198407845fa9d85b590eafafacf3b6a82d3528 Author: Peter Zijlstra Date: Tue Nov 19 16:41:49 2013 +0100 sched: Avoid NULL dereference on sd_busy commit 42eb088ed246a5a817bb45a8b32fe234cf1c0f8b upstream. Commit 37dc6b50cee9 ("sched: Remove unnecessary iteration over sched domains to update nr_busy_cpus") forgot to clear 'sd_busy' under some conditions leading to a possible NULL deref in set_cpu_sd_state_idle(). Reported-by: Anton Blanchard Cc: Preeti U Murthy Signed-off-by: Peter Zijlstra Link: http://lkml.kernel.org/r/20131118113701.GF3866@twins.programming.kicks-ass.net Signed-off-by: Ingo Molnar Signed-off-by: Jiri Slaby commit ec6317cc7e5e333acdfa2426c96d372bfc920077 Author: Preeti U Murthy Date: Wed Oct 30 08:42:52 2013 +0530 sched: Remove unnecessary iteration over sched domains to update nr_busy_cpus commit 37dc6b50cee97954c4e6edcd5b1fa614b76038ee upstream. nr_busy_cpus parameter is used by nohz_kick_needed() to find out the number of busy cpus in a sched domain which has SD_SHARE_PKG_RESOURCES flag set. Therefore instead of updating nr_busy_cpus at every level of sched domain, since it is irrelevant, we can update this parameter only at the parent domain of the sd which has this flag set. Introduce a per-cpu parameter sd_busy which represents this parent domain. In nohz_kick_needed() we directly query the nr_busy_cpus parameter associated with the groups of sd_busy. By associating sd_busy with the highest domain which has SD_SHARE_PKG_RESOURCES flag set, we cover all lower level domains which could have this flag set and trigger nohz_idle_balancing if any of the levels have more than one busy cpu. sd_busy is irrelevant for asymmetric load balancing. However sd_asym has been introduced to represent the highest sched domain which has SD_ASYM_PACKING flag set so that it can be queried directly when required. While we are at it, we might as well change the nohz_idle parameter to be updated at the sd_busy domain level alone and not the base domain level of a CPU. This will unify the concept of busy cpus at just one level of sched domain where it is currently used. Signed-off-by: Preeti U Murthy Signed-off-by: Peter Zijlstra Cc: svaidy@linux.vnet.ibm.com Cc: vincent.guittot@linaro.org Cc: bitbucket@online.de Cc: benh@kernel.crashing.org Cc: anton@samba.org Cc: Morten.Rasmussen@arm.com Cc: pjt@google.com Cc: peterz@infradead.org Cc: mikey@neuling.org Link: http://lkml.kernel.org/r/20131030031252.23426.4417.stgit@preeti.in.ibm.com Signed-off-by: Ingo Molnar Signed-off-by: Jiri Slaby commit 66802dc66423b151f82088406a77131474341cb7 Author: Paul E. McKenney Date: Sun Aug 25 21:20:47 2013 -0700 rcu: Throttle rcu_try_advance_all_cbs() execution commit c229828ca6bc62d6c654f64b1d1b8a9ebd8a56f3 upstream. The rcu_try_advance_all_cbs() function is invoked on each attempted entry to and every exit from idle. If this function determines that there are callbacks ready to invoke, the caller will invoke the RCU core, which in turn will result in a pair of context switches. If a CPU enters and exits idle extremely frequently, this can result in an excessive number of context switches and high CPU overhead. This commit therefore causes rcu_try_advance_all_cbs() to throttle itself, refusing to do work more than once per jiffy. Reported-by: Tibor Billes Signed-off-by: Paul E. McKenney Tested-by: Tibor Billes Reviewed-by: Josh Triplett Signed-off-by: Jiri Slaby commit ac631f750ba3ccde692d0f41750002fba17a005d Author: Paul E. McKenney Date: Thu Sep 5 17:02:11 2013 -0700 rcu: Throttle invoke_rcu_core() invocations due to non-lazy callbacks commit c337f8f58ed7cf150651d232af8222421a71463d upstream. If a non-lazy callback arrives on a CPU that has previously gone idle with no non-lazy callbacks, invoke_rcu_core() forces the RCU core to run. However, it does not update the conditions, which could result in several closely spaced invocations of the RCU core, which in turn could result in an excessively high context-switch rate and resulting high overhead. This commit therefore updates the ->all_lazy and ->nonlazy_posted_snap fields to prevent closely spaced invocations. Reported-by: Tibor Billes Signed-off-by: Paul E. McKenney Tested-by: Tibor Billes Reviewed-by: Josh Triplett Signed-off-by: Jiri Slaby commit d30b39cb984459873b0fe79ba07a84e6e0c729d5 Author: Benjamin Herrenschmidt Date: Tue Nov 5 16:33:22 2013 +1100 powerpc: Fix fatal SLB miss when restoring PPR commit 0c4888ef1d8a8b82c29075ce7e257ff795af15c7 upstream. When restoring the PPR value, we incorrectly access the thread structure at a time where MSR:RI is clear, which means we cannot recover from nested faults. However the thread structure isn't covered by the "bolted" SLB entries and thus accessing can fault. This fixes it by splitting the code so that the PPR value is loaded into a GPR before MSR:RI is cleared. Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Jiri Slaby commit 82a6be9ef57b19f710dbbeac568484ce701b2e26 Author: Vaidyanathan Srinivasan Date: Wed Oct 30 08:42:42 2013 +0530 sched: Fix asymmetric scheduling for POWER7 commit 2042abe7977222ef606306faa2dce8fd51e98e65 upstream. Asymmetric scheduling within a core is a scheduler loadbalancing feature that is triggered when SD_ASYM_PACKING flag is set. The goal for the load balancer is to move tasks to lower order idle SMT threads within a core on a POWER7 system. In nohz_kick_needed(), we intend to check if our sched domain (core) is completely busy or we have idle cpu. The following check for SD_ASYM_PACKING: (cpumask_first_and(nohz.idle_cpus_mask, sched_domain_span(sd)) < cpu) already covers the case of checking if the domain has an idle cpu, because cpumask_first_and() will not yield any set bits if this domain has no idle cpu. Hence, nr_busy check against group weight can be removed. Reported-by: Michael Neuling Signed-off-by: Vaidyanathan Srinivasan Signed-off-by: Preeti U Murthy Tested-by: Michael Neuling Signed-off-by: Peter Zijlstra Cc: vincent.guittot@linaro.org Cc: bitbucket@online.de Cc: benh@kernel.crashing.org Cc: anton@samba.org Cc: Morten.Rasmussen@arm.com Cc: pjt@google.com Link: http://lkml.kernel.org/r/20131030031242.23426.13019.stgit@preeti.in.ibm.com Signed-off-by: Ingo Molnar Signed-off-by: Jiri Slaby commit 6dc265bdd04069ee1b1deda71b5bdfa4cb280e1b Author: Bjorn Helgaas Date: Tue Nov 5 13:34:51 2013 -0700 PCI: Drop warning about drivers that don't use pci_set_master() commit fbeeb822f6f45cadf154d7b7cff1c13537cd799d upstream. f41f064cf4 ("PCI: Workaround missing pci_set_master in pci drivers") made pci_enable_bridge() turn on bus mastering if the driver hadn't done so already. It also added a warning in this case. But there's no reason to warn about it unless it's actually a problem to enable bus mastering here. This patch drops the warning because I'm not aware of any such problem. Signed-off-by: Bjorn Helgaas CC: Paul Bolle Signed-off-by: Jiri Slaby commit 9321256a6cdb293512c1c723eecc54305545619e Author: Thomas Gleixner Date: Wed Nov 13 21:01:57 2013 +0100 NOHZ: Check for nohz active instead of nohz enabled commit d689fe222a858c767cb8594faf280048e532b53f upstream. RCU and the fine grained idle time accounting functions check tick_nohz_enabled. But that variable is merily telling that NOHZ has been enabled in the config and not been disabled on the command line. But it does not tell anything about nohz being active. That's what all this should check for. Matthew reported, that the idle accounting on his old P1 machine showed bogus values, when he enabled NOHZ in the config and did not disable it on the kernel command line. The reason is that his machine uses (refined) jiffies as a clocksource which explains why the "fine" grained accounting went into lala land, because it depends on when the system goes and leaves idle relative to the jiffies increment. Provide a tick_nohz_active indicator and let RCU and the accounting code use this instead of tick_nohz_enable. Reported-and-tested-by: Matthew Whitehead Signed-off-by: Thomas Gleixner Reviewed-by: Steven Rostedt Reviewed-by: Paul E. McKenney Cc: john.stultz@linaro.org Cc: mwhitehe@redhat.com Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1311132052240.30673@ionos.tec.linutronix.de Signed-off-by: Jiri Slaby commit efca618a4ebd8f751dffe10c3ba6efe146e02c5e Author: Thomas Gleixner Date: Fri Nov 29 12:18:13 2013 +0100 nohz: Fix another inconsistency between CONFIG_NO_HZ=n and nohz=off commit 0e576acbc1d9600cf2d9b4a141a2554639959d50 upstream. If CONFIG_NO_HZ=n tick_nohz_get_sleep_length() returns NSEC_PER_SEC/HZ. If CONFIG_NO_HZ=y and the nohz functionality is disabled via the command line option "nohz=off" or not enabled due to missing hardware support, then tick_nohz_get_sleep_length() returns 0. That happens because ts->sleep_length is never set in that case. Set it to NSEC_PER_SEC/HZ when the NOHZ mode is inactive. Reported-by: Michal Hocko Reported-by: Borislav Petkov Signed-off-by: Thomas Gleixner Signed-off-by: Jiri Slaby commit 319a69da974f9c46a59a49091eaf2e992a44b575 Author: Linus Torvalds Date: Thu Dec 12 09:53:51 2013 -0800 futex: move user address verification up to common code commit 5cdec2d833748fbd27d3682f7209225c504c79c5 upstream. When debugging the read-only hugepage case, I was confused by the fact that get_futex_key() did an access_ok() only for the non-shared futex case, since the user address checking really isn't in any way specific to the private key handling. Now, it turns out that the shared key handling does effectively do the equivalent checks inside get_user_pages_fast() (it doesn't actually check the address range on x86, but does check the page protections for being a user page). So it wasn't actually a bug, but the fact that we treat the address differently for private and shared futexes threw me for a loop. Just move the check up, so that it gets done for both cases. Also, use the 'rw' parameter for the type, even if it doesn't actually matter any more (it's a historical artifact of the old racy i386 "page faults from kernel space don't check write protections"). Cc: Thomas Gleixner Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 2a352e27de04e0329fa408eb256b8440ff4b4b23 Author: James Bates Date: Wed Oct 2 18:43:39 2013 +0200 efifb: prevent null-deref when iterating dmi_list commit 55aa42f2e690157e254a6a6989f5f4ac928b35c8 upstream. The dmi_list array is initialized using gnu designated initializers, and therefore may contain fewer explicitly defined entries as there are elements in it. This is because the enum above with M_xyz constants contains more items than the designated initializer. Those elements not explicitly initialized are implicitly set to 0. Now efifb_setup() loops through all these array elements, and performs a strcmp on each item. For non explicitly initialized elements this will be a null pointer: This patch swaps the check order in the if statement, thus checks first whether dmi_list[i].base is null. Signed-off-by: James Bates Signed-off-by: David Herrmann Signed-off-by: Tomi Valkeinen Signed-off-by: Jiri Slaby commit d4ea1c7ffc46aafe15eff8ed559016c0fa317dec Author: Jan Kara Date: Tue Sep 17 22:30:31 2013 +0200 blktrace: Send BLK_TN_PROCESS events to all running traces commit a404d5576bbe586a1097a8bc2f32c5f22651b0aa upstream. Currently each task sends BLK_TN_PROCESS event to the first traced device it interacts with after a new trace is started. When there are several traced devices and the task accesses more devices, this logic can result in BLK_TN_PROCESS being sent several times to some devices while it is never sent to other devices. Thus blkparse doesn't display command name when parsing some blktrace files. Fix the problem by sending BLK_TN_PROCESS event to all traced devices when a task interacts with any of them. Signed-off-by: Jan Kara Review-by: Jeff Moyer Signed-off-by: Jens Axboe Signed-off-by: Jiri Slaby commit e89b9f7e760aa33822346d27dd43792e59d373cf Author: Huang Rui Date: Thu Oct 3 23:37:13 2013 +0800 usb: ohci: use amd_chipset_type to filter for SB800 prefetch commit 02c123ee99c793f65af2dbda17d5fe87d448f808 upstream. Commit "usb: pci-quirks: refactor AMD quirk to abstract AMD chipset types" introduced a new AMD chipset type to filter AMD platforms with different chipsets. According to a recent thread [1], this patch updates SB800 prefetch routine in AMD PLL quirk. And make it use the new chipset type to represent SB800 generation. [1] http://marc.info/?l=linux-usb&m=138012321616452&w=2 Signed-off-by: Huang Rui Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby commit 6a3f0afd6a6a9949485f6d8103d96c1d33a0ae53 Author: Huang Rui Date: Thu Oct 3 23:37:12 2013 +0800 usb: ehci: use amd_chipset_type to filter for usb subsystem hang bug commit 3ad145b62a15c86150dd0cc229a39a3120d462f9 upstream. Commit "usb: pci-quirks: refactor AMD quirk to abstract AMD chipset types" introduced a new AMD chipset type to filter AMD platforms with different chipsets. According to a recent thread [1], this patch updates USB subsystem hang symptom quirk which is observed on AMD all SB600 and SB700 revision 0x3a/0x3b. And make it use the new chipset type to represent. [1] http://marc.info/?l=linux-usb&m=138012321616452&w=2 Signed-off-by: Huang Rui Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby commit 87689625579cc54ce758f4d83d7a04e4f7280920 Author: Huang Rui Date: Mon Sep 16 23:47:27 2013 +0800 usb: pci-quirks: refactor AMD quirk to abstract AMD chipset types commit 22b4f0cd1d4d98f50213e9a37ead654e80b54b9d upstream. This patch abstracts out a AMD chipset type which includes southbridge generation and its revision. When os excutes usb_amd_find_chipset_info routine to initialize AMD chipset type, driver will know which kind of chipset is used. This update has below benifits: - Driver is able to confirm which southbridge generations and their revision are used, with chipset detection once. - To describe chipset generations with enumeration types brings better readability. - It's flexible to filter AMD platforms to implement new quirks in future. Signed-off-by: Huang Rui Cc: Andiry Xu Acked-by: Alan Stern Acked-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby commit d4660f500752af8910258cfeb2756959882fcf38 Author: David Henningsson Date: Wed Dec 18 10:46:04 2013 +0100 ALSA: hda - Explicitly keep codec powered up in hdmi_present_sense commit da4a7a3926d09c13ae052ede67feb7285e01e3f5 upstream. This should help us avoid the following mutex deadlock: [] mutex_lock+0x2a/0x50 [] hdmi_present_sense+0x53/0x3a0 [snd_hda_codec_hdmi] [] generic_hdmi_resume+0x5a/0x70 [snd_hda_codec_hdmi] [] hda_call_codec_resume+0xec/0x1d0 [snd_hda_codec] [] snd_hda_power_save+0x1e4/0x280 [snd_hda_codec] [] codec_exec_verb+0x5f/0x290 [snd_hda_codec] [] snd_hda_codec_read+0x5b/0x90 [snd_hda_codec] [] snd_hdmi_get_eld_size+0x1e/0x20 [snd_hda_codec_hdmi] [] snd_hdmi_get_eld+0x2c/0xd0 [snd_hda_codec_hdmi] [] hdmi_present_sense+0x9a/0x3a0 [snd_hda_codec_hdmi] [] hdmi_repoll_eld+0x34/0x50 [snd_hda_codec_hdmi] Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit f6baee71572f4932c07484b6a1e58a31db2310e0 Author: Takashi Iwai Date: Thu Nov 7 13:38:23 2013 +0100 ALSA: hda - Delay HDMI presence reports while waiting for ELD information commit efe4710860fa6ed10dd041f13902f0e06c86e8cc upstream. There is a small gap between the jack detection unsolicited event and the time the ELD is updated. When user-space queries the HDMI ELD immediately after receiving the notification, it might fail because of this gap. For avoiding such a problem, this patch tries to delay the HDMI jack detect notification until ELD information is fully updated. The workaround is imperfect, but good enough as a starting point. Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 19c7fb3437f73dcd142f33afa93e34b75ba52de1 Author: Takashi Iwai Date: Tue Nov 5 17:54:05 2013 +0100 ALSA: hda - Name Haswell HDMI controllers better commit fab1285a51b7bf55adb4678d82e606829c9dab85 upstream. "HDA Intel MID" is no correct name for Haswell HDMI controllers. Give them a better name, "HDA Intel HDMI". Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit af3d652bc9bd7e2c804d33f6068e8048afd641ed Author: Clemens Ladisch Date: Tue Nov 5 09:27:10 2013 +0100 ALSA: hda: add device IDs for AMD Evergreen/Northern Islands HDMI commit bbaa0d6665bc14133d7eb573d2b5ff898a06f365 upstream. The device IDs of the AMD Cypress/Juniper/Redwood/Cedar/Cayman/Antilles/ Barts/Turks/Caicos HDMI HDA controllers weren't added explicitly because the generic entry works, but it made the device appearing as "Generic", and people are confused as if it's no proper HDMI controller. Add them so that the name shows up properly as "ATI HDMI" instead of "Generic". According to Takashi's tests and the lack of complaints, these devices work fine without disabling snooping. Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 8d20dc1a0d1afa161be8ea232e58876b2429afe3 Author: James Ralston Date: Mon Nov 4 09:27:45 2013 -0800 ALSA: hda - Add Device IDs for Intel Wildcat Point-LP PCH commit 4eeca499be4ff4216b745e35ae8c8bffa6445eac upstream. This patch adds the HD Audio Device IDs for the Intel Wildcat Point-LP PCH. Signed-off-by: James Ralston Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 50ce68250ef68fe6cd54ad8127a63c91646b37cc Author: Mengdong Lin Date: Mon Nov 4 01:13:13 2013 -0500 ALSA: hda - rename function not_share_unassigned_cvt() commit 300016b960661b4df63690177b22ba5426ff5706 upstream. The function name not_share_unassigned_cvt() is opposite to what it does. This patch renames it to intel_not_share_assigned_cvt(), and addes comments to explain why some Intel display codecs need this workaround. Signed-off-by: Mengdong Lin Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 9ad9282061db8217a7859668e5620a05c4bb728b Author: Mengdong Lin Date: Thu Oct 31 18:31:51 2013 -0400 ALSA: hda - not choose assigned converters for unused pins of Valleyview commit 023838542dc8a4eac9650f98942671078a4ce73d upstream. For Valleyview display codec, if an unused pin chooses an assgined converter selected by a used pin, playback on the unused pin can also give sound to the output device of the used pin. It's because data flows from the same convertor to the display port of the used pin. This issue is same as Haswell. So this patch avoids using assinged convertors for unused pins. The related function haswell_config_cvts() is renamed for code reuse. Signed-off-by: Mengdong Lin Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 94a6ebf42ef158a5a7812c7bc2bc9d68adcfc68f Author: Takashi Iwai Date: Mon Oct 21 16:31:45 2013 +0200 ALSA: hda - Fix typos in patch_hdmi.c commit b55447a7301b12d509df4b2909ed38d125ad83d4 upstream. ... which was introduced by the previous commit a4e9a38b, causing build errors without CONFIG_PROC_FS. Reported-by: Fengguang Wu Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 24c0e78005d2cfdc675397aae1066a05bbe5d263 Author: Mengdong Lin Date: Sun Oct 20 23:03:31 2013 -0400 ALSA: hda - add codec ID for Valleyview2 display codec commit cc1a95d9f6423ced191b6f264e9657d98844ea0d upstream. This patch adds codec ID (0x80862882) and module alias for Valleyview2 display codec. Signed-off-by: Mengdong Lin Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 0bb77031ef98e6b483e2420210d95fc7f447394d Author: Takashi Iwai Date: Thu Oct 17 18:21:12 2013 +0200 ALSA: hda - Move mutex from hda_eld to per_pin in HDMI codec driver commit a4e9a38b40a0e2f7dad1a0b355896d23fbdd16e0 upstream. Since the lock is used primarily in patch_hdmi.c, it's better to move it in the local struct instead of exporting in hda_eld. The only functions requiring the lock in hda_eld.c are proc accessors. So in this patch, the proc entry and its creation/deletion/accessors are moved into patch_hdmi.c, together with the mutex lock to pin_spec struct. The former proc info functions are exported so that they can be called from patch_hdmi.c. Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 742096f90e8ee174fb4fafe8bb721705ba2cf98a Author: Takashi Iwai Date: Thu Oct 17 18:03:24 2013 +0200 ALSA: hda - Fix possible races in HDMI driver commit cbbaa603a03cc46681e24d6b2804b62fde95a2af upstream. Some per_pin fields and ELD contents might be changed dynamically in multiple ways where the concurrent accesses are still opened in the current code. This patch fixes such possible races by using eld->lock in appropriate places. Reported-by: Anssi Hannula Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 822d77896bafc1f9dd06f42ad6200a08930f3155 Author: Anssi Hannula Date: Sat Oct 5 02:25:44 2013 +0300 ALSA: hda - hdmi: Tweak debug messages to be more useful commit 980b24958f0c615fd003d37f0fce4ab1ecd01784 upstream. Allow channel map debugging for both automatic and manual channel maps, and print CA always when updating infoframe. Signed-off-by: Anssi Hannula Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 082a24d32f77db8aa160382827ee37de0ddfd896 Author: Anssi Hannula Date: Sat Oct 5 02:25:43 2013 +0300 ALSA: hda - hdmi: Fix available channel maps missing from TLV commit bb731f2100e614a8d7c5965d3663aed893859733 upstream. Currently the available channel maps TLV only contains channel maps that are limited to the traditional 7.1 speakers. Since the other HDMI channel mapping functions have been fixed to properly handle all CEA-861-E specified speakers, allow them to be listed. Signed-off-by: Anssi Hannula Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 7f07dcd349cbec7dbd6ddc10464bf4da8132f6ee Author: Anssi Hannula Date: Sat Oct 5 02:25:42 2013 +0300 ALSA: hda - hdmi: Fix channel maps with less common speakers commit a5b7d510b2220cccbcaeb1b87a6d8c47efeb154c upstream. For some speakers and slots the CEA slot <-> speaker assignment depends on the used CEA Channel Allocation value. Therefore the from_cea_slot() and to_cea_slot() helpers currently only work correctly for the regular 7.1 speakers. Fix them to work with all speakers, taking the re-ordered CA index as input and adapting use sites accordingly. This change allows manual channel mapping to actually work for all CEA allocated speakers. Additionally, this fixes incorrect channel map reporting in automatic channel mapping mode when an affected speaker position is used (e.g. 6.1 map which contains an RC speaker). Signed-off-by: Anssi Hannula Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 83d514f8571a8f709daff8ed488ce04f8ada94cf Author: Anssi Hannula Date: Sat Oct 5 02:25:41 2013 +0300 ALSA: hda - hdmi: Fix unused slots being enabled in manual and non-PCM mappings commit 11f7c52d90b21a51b0bc6a8b642c6ed150bdc219 upstream. hdmi_manual_setup_channel_mapping() and hdmi_std_setup_channel_mapping try to assign ALSA channels to HDMI channel slots and disable (i.e. silence) other slots. However, they try to disable a slot by using AC_VERB_SET_CHAN_SLOT with parameter ((alsa_ch << 8) | 0xf), while the correct parameter is ((0xf << 8) | hdmi_slot), i.e. the slot should be unassigned, not the ALSA channel. Fix that by actually disabling the unused slots. Note that this bug did not cause any (reported) issues because slots incorrectly having audio are normally ignored by a receiver if the CEA channel allocation used does not map that slot to any speaker. Additionally, the converter channel count configuration limits the number of actually active channels in any case. Signed-off-by: Anssi Hannula Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit b88945f412cf9f7aee57f5537b8758938a2f316a Author: Anssi Hannula Date: Sat Oct 5 02:25:40 2013 +0300 ALSA: hda - hdmi: Fix programmed active channel count commit 1df5a06abbaa876ecc01ea84064cdffb4f52a1a1 upstream. Currently the converter channel count is set to the number of actual input channels. The audio infoframe channel count field is set similarly. However, sometimes the used channel map does not map all input channels to outputs. Notably, 3 channel modes (e.g. 2.1) require a dummy input channel so there are 4 input channels. According to the HDA specification, converter channel count should be programmed according to the number of _active_ channels. On Intel HDMI codecs (but not on NVIDIA), setting the converter channel to a higher value than there are actually mapped channels to HDMI slots will cause no audio to be output at all. Note that the effects of this issue are currently partially masked by other bugs that prevent the driver from actually unmapping channels in certain cases. For example, if a 4 channel stream is first created and prepared, it gets a FL,FR,RL,RR mapping (ALSA->HDMI slot mapping 0->0, 1->1, 2->4, 3->5). If one thereafter assigns a FR,FL,FC mapping to it, the driver will remap 2->3 but fail to unmap 2->4 and 3->5, so there are still 4 active channels and the issue will not trigger in this case. These bugs will be fixed separately. Fix the channel counts in the converter channel count field and in the audio infoframe channel count field to match the actual number of active channels. Signed-off-by: Anssi Hannula Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 86bf1122e6e267182919e18ec5fd9f8a286d4da9 Author: Anssi Hannula Date: Sat Oct 5 02:25:39 2013 +0300 ALSA: hda - hdmi: Fix incorrect default channel mapping for unusual CAs commit 90f28002110d783f49639f0db2ccdc0b58302cbd upstream. hdmi_std_setup_channel_mapping() selects a Channel Allocation according to the sink reported speaker mask, preferring the ALSA standard layouts. If the channel allocation is not one of the ALSA standard layouts, the ALSA channels are mapped directly to HDMI channels in order. However, the function does not take into account that there a holes in the HDMI channel map. Additionally, the function tries to disable a slot by using AC_VERB_SET_CHAN_SLOT with parameter ((alsa_ch << 8) | 0xf), while the correct parameter is ((0xf << 8) | hdmi_slot), i.e. the slot should be unassigned, not the ALSA channel. Fix both of the issues for non-ALSA-default layouts. Tested on Intel HDMI with a speaker mask of FL | FR | FC | RC, which causes CA 0x06 to be selected for 4-channel audio, which causes incorrect output (sound destined to RC goes to FC and FC goes nowhere) without the patch. Signed-off-by: Anssi Hannula Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit b378f0653eb0674d94a0d6c526a663e57a3d7cac Author: Gerald Schaefer Date: Tue Jan 28 18:40:12 2014 +0100 s390/appldata: restore missing init_virt_timer() commit b7c5b1aa2836c933ab03f90391619ebdc9112e46 upstream. Commit 27f6b416 "s390/vtimer: rework virtual timer interface" removed the call to init_virt_timer() by mistake, which is added again by this patch. Signed-off-by: Gerald Schaefer Signed-off-by: Martin Schwidefsky Signed-off-by: Jiri Slaby commit ccb738e88b60ec21a96f8f5e11a1857236deb518 Author: Martin Schwidefsky Date: Fri Nov 22 12:04:18 2013 +0100 s390,time: revert direct ktime path for s390 clockevent device commit 8adbf78ec4839c1dc4ff20c9a1f332a7bc99e6e6 upstream. Git commit 4f37a68cdaf6dea833cfdded2a3e0c47c0f006da "s390: Use direct ktime path for s390 clockevent device" makes use of the CLOCK_EVT_FEAT_KTIME clockevent option to avoid the delta calculation with ktime_get() in clockevents_program_event and the get_tod_clock() in s390_next_event. This is based on the assumption that the difference between the internal ktime and the hardware clock is reflected in the wall_to_monotonic delta. But this is not true, the ntp corrections are applied via changes to the tk->mult multiplier and this is not reflected in wall_to_monotonic. In theory this could be solved by using the raw monotonic clock but it is simpler to switch back to the standard clock delta calculation. Signed-off-by: Martin Schwidefsky Signed-off-by: Jiri Slaby commit e1a6db9c9503479d7c28c2662b3895b68a7e96ed Author: Martin Schwidefsky Date: Fri Nov 22 10:04:53 2013 +0100 s390/time,vdso: convert to the new update_vsyscall interface commit 79c74ecbebf76732f91b82a62ce7fc8a88326962 upstream. Switch to the improved update_vsyscall interface that provides sub-nanosecond precision for gettimeofday and clock_gettime. Signed-off-by: Martin Schwidefsky Signed-off-by: Jiri Slaby commit c1b73028e93c7a9217ad75ed75a7fe167606054d Author: Hendrik Brueckner Date: Tue Nov 12 15:03:37 2013 +0100 s390/3270: fix missing device_destroy() call commit d1e61fe49fd450be15d402ac353784f5ba8a624e upstream. Unloading the fs3270 kernel module does not remove the created "3270/tub" device. Reloading the module then causes a sysfs warning: "sysfs: cannot create duplicate filename '/devices/virtual/3270/3270!tub'". Call device_destroy() in the module exit function to solve this issue. Signed-off-by: Hendrik Brueckner Signed-off-by: Martin Schwidefsky Signed-off-by: Jiri Slaby commit 5afb0316f677daa3603c79b648800f9af012c200 Author: Felipe Contreras Date: Thu Oct 3 12:13:03 2013 -0500 ACPI: update win8 OSI blacklist commit b4cb9244a544a1623305eb58267a90418268d31e upstream. More people have reported they need this for their machines to work correctly. References: https://bugzilla.kernel.org/show_bug.cgi?id=60682 Reported-by: Stefan Hellermann Reported-by: Benedikt Sauer Reported-by: Erno Kuusela Reported-by: Jonathan Doman Reported-by: Christoph Klaffl Reported-by: Jan Hendrik Nielsen Signed-off-by: Felipe Contreras Signed-off-by: Rafael J. Wysocki Signed-off-by: Jiri Slaby