user/sven/linux.git, branch v3.12.15

Linux 3.12.15

2014-03-24T08:45:08Z

PNP / ACPI: proper handling of ACPI IO/Memory resource parsing failures

2014-03-24T08:45:07Z

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

arm64: mm: Add double logical invert to pte accessors

2014-03-24T08:45:07Z

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

bio-integrity: Fix bio_integrity_verify segment start bug

2014-03-24T08:45:06Z

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

MIPS: include linux/types.h

2014-03-24T08:45:06Z

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

ALSA: oxygen: modify adjust_dg_dac_routing function

2014-03-24T08:45:05Z

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

x86, fpu: Check tsk_used_math() in kernel_fpu_end() for eager FPU

2014-03-24T08:45:05Z

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

SCSI: storvsc: NULL pointer dereference fix

2014-03-24T08:45:04Z

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

SCSI: qla2xxx: Fix multiqueue MSI-X registration.

2014-03-24T08:45:04Z

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

SCSI: qla2xxx: Poll during initialization for ISP25xx and ISP83xx

2014-03-24T08:45:04Z

commit b77ed25c9f8402e8b3e49e220edb4ef09ecfbb53 upstream. Signed-off-by: Giridhar Malavali Signed-off-by: Saurav Kashyap Signed-off-by: James Bottomley Signed-off-by: Jiri Slaby