linux, branch v3.10.48

Linux 3.10.48

2014-07-09T18:14:10Z

mm: fix crashes from mbind() merging vmas

2014-07-09T18:14:03Z

commit d05f0cdcbe6388723f1900c549b4850360545201 upstream. In v2.6.34 commit 9d8cebd4bcd7 ("mm: fix mbind vma merge problem") introduced vma merging to mbind(), but it should have also changed the convention of passing start vma from queue_pages_range() (formerly check_range()) to new_vma_page(): vma merging may have already freed that structure, resulting in BUG at mm/mempolicy.c:1738 and probably worse crashes. Fixes: 9d8cebd4bcd7 ("mm: fix mbind vma merge problem") Reported-by: Naoya Horiguchi Tested-by: Naoya Horiguchi Signed-off-by: Hugh Dickins Acked-by: Christoph Lameter Cc: KOSAKI Motohiro Cc: Minchan Kim Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

hugetlb: fix copy_hugetlb_page_range() to handle migration/hwpoisoned entry

2014-07-09T18:14:03Z

commit 4a705fef986231a3e7a6b1a6d3c37025f021f49f upstream. There's a race between fork() and hugepage migration, as a result we try to "dereference" a swap entry as a normal pte, causing kernel panic. The cause of the problem is that copy_hugetlb_page_range() can't handle "swap entry" family (migration entry and hwpoisoned entry) so let's fix it. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Naoya Horiguchi Acked-by: Hugh Dickins Cc: Christoph Lameter Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

sym53c8xx_2: Set DID_REQUEUE return code when aborting squeue

2014-07-09T18:14:03Z

commit fd1232b214af43a973443aec6a2808f16ee5bf70 upstream. This patch fixes I/O errors with the sym53c8xx_2 driver when the disk returns QUEUE FULL status. When the controller encounters an error (including QUEUE FULL or BUSY status), it aborts all not yet submitted requests in the function sym_dequeue_from_squeue. This function aborts them with DID_SOFT_ERROR. If the disk has full tag queue, the request that caused the overflow is aborted with QUEUE FULL status (and the scsi midlayer properly retries it until it is accepted by the disk), but the sym53c8xx_2 driver aborts the following requests with DID_SOFT_ERROR --- for them, the midlayer does just a few retries and then signals the error up to sd. The result is that disk returning QUEUE FULL causes request failures. The error was reproduced on 53c895 with COMPAQ BD03685A24 disk (rebranded ST336607LC) with command queue 48 or 64 tags. The disk has 64 tags, but under some access patterns it return QUEUE FULL when there are less than 64 pending tags. The SCSI specification allows returning QUEUE FULL anytime and it is up to the host to retry. Signed-off-by: Mikulas Patocka Cc: Matthew Wilcox Cc: James Bottomley Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

drivers/video/fbdev/fb-puv3.c: Add header files for function unifb_mmap

2014-07-09T18:14:03Z

commit fbc6c4a13bbfb420eedfdb26a0a859f9c07e8a7b upstream. Function unifb_mmap calls functions which are defined in linux/mm.h and asm/pgtable.h The related error (for unicore32 with unicore32_defconfig): CC drivers/video/fbdev/fb-puv3.o drivers/video/fbdev/fb-puv3.c: In function 'unifb_mmap': drivers/video/fbdev/fb-puv3.c:646: error: implicit declaration of function 'vm_iomap_memory' drivers/video/fbdev/fb-puv3.c:646: error: implicit declaration of function 'pgprot_noncached' Signed-off-by: Zhichuang Sun Cc: Jean-Christophe Plagniol-Villard Cc: Tomi Valkeinen Cc: Jingoo Han Cc: Daniel Vetter Cc: Joe Perches Cc: Laurent Pinchart Cc: linux-fbdev@vger.kernel.org Acked-by: Xuetao Guan Signed-off-by: Tomi Valkeinen Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

arch/unicore32/mm/alignment.c: include "asm/pgtable.h" to avoid compiling error

2014-07-09T18:14:02Z

commit 1ff38c56cbd095c4c0dfa581a859ba3557830f78 upstream. Need include "asm/pgtable.h" to include "asm-generic/pgtable-nopmd.h", so can let 'pmd_t' defined. The related error with allmodconfig: CC arch/unicore32/mm/alignment.o In file included from arch/unicore32/mm/alignment.c:24: arch/unicore32/include/asm/tlbflush.h:135: error: expected .). before .*. token arch/unicore32/include/asm/tlbflush.h:154: error: expected .). before .*. token In file included from arch/unicore32/mm/alignment.c:27: arch/unicore32/mm/mm.h:15: error: expected .=., .,., .;., .sm. or ._attribute__. before .*. token arch/unicore32/mm/mm.h:20: error: expected .=., .,., .;., .sm. or ._attribute__. before .*. token arch/unicore32/mm/mm.h:25: error: expected .=., .,., .;., .sm. or ._attribute__. before .*. token make[1]: *** [arch/unicore32/mm/alignment.o] Error 1 make: *** [arch/unicore32/mm] Error 2 Signed-off-by: Chen Gang Acked-by: Xuetao Guan Signed-off-by: Xuetao Guan Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

ALSA: usb-audio: Prevent printk ratelimiting from spamming kernel log while DEBUG not defined

2014-07-09T18:14:02Z

commit b7a7723513dc89f83d6df13206df55d4dc26e825 upstream. This (widely used) construction: if(printk_ratelimit()) dev_dbg() Causes the ratelimiting to spam the kernel log with the "callbacks suppressed" message below, even while the dev_dbg it is supposed to rate limit wouldn't print anything because DEBUG is not defined for this device. [ 533.803964] retire_playback_urb: 852 callbacks suppressed [ 538.807930] retire_playback_urb: 852 callbacks suppressed [ 543.811897] retire_playback_urb: 852 callbacks suppressed [ 548.815745] retire_playback_urb: 852 callbacks suppressed [ 553.819826] retire_playback_urb: 852 callbacks suppressed So use dev_dbg_ratelimited() instead of this construction. Signed-off-by: Sander Eikelenboom Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: usb-audio: Suppress repetitive debug messages from retire_playback_urb()

2014-07-09T18:14:02Z

commit a5065eb6da55b226661456e6a7435f605df98111 upstream. BugLink: http://bugs.launchpad.net/bugs/1305133 Malfunctioning or slow devices can cause a flood of dmesg SPAM. I've ignored checkpatch.pl complaints about the use of printk_ratelimit() in favour of prior art in sound/usb/pcm.c. WARNING: Prefer printk_ratelimited or pr__ratelimited to printk_ratelimit + if (printk_ratelimit() && Cc: Jaroslav Kysela Cc: Takashi Iwai Cc: Eldad Zack Cc: Daniel Mack Cc: Clemens Ladisch Signed-off-by: Tim Gardner Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

serial: 8250_dw: Fix LCR workaround regression

2014-07-09T18:14:02Z

commit 6979f8d28049879e6147767d93ba6732c8bd94f4 upstream. Commit c49436b657d0 (serial: 8250_dw: Improve unwritable LCR workaround) caused a regression. It added a check that the LCR was written properly to detect and workaround the busy quirk, but the behaviour of bit 5 (UART_LCR_SPAR) differs between IP versions 3.00a and 3.14c per the docs. On older versions this caused the check to fail and it would repeatedly force idle and rewrite the LCR register, causing delays and preventing any input from serial being received. This is fixed by masking out UART_LCR_SPAR before making the comparison. Signed-off-by: James Hogan Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: Tim Kryger Cc: Ezequiel Garcia Cc: Matt Porter Cc: Markus Mayer Tested-by: Tim Kryger Tested-by: Ezequiel Garcia Tested-by: Heikki Krogerus Cc: Wang Nan Signed-off-by: Greg Kroah-Hartman

serial: 8250_dw: Improve unwritable LCR workaround

2014-07-09T18:14:02Z

commit c49436b657d0a56a6ad90d14a7c3041add7cf64d upstream. When configured with UART_16550_COMPATIBLE=NO or in versions prior to the introduction of this option, the Designware UART will ignore writes to the LCR if the UART is busy. The current workaround saves a copy of the last written LCR and re-writes it in the ISR for a special interrupt that is raised when a write was ignored. Unfortunately, interrupts are typically disabled prior to performing a sequence of register writes that include the LCR so the point at which the retry occurs is too late. An example is serial8250_do_set_termios() where an ignored LCR write results in the baud divisor not being set and instead a garbage character is sent out the transmitter. Furthermore, since serial_port_out() offers no way to indicate failure, a serious effort must be made to ensure that the LCR is actually updated before returning back to the caller. This is difficult, however, as a UART that was busy during the first attempt is likely to still be busy when a subsequent attempt is made unless some extra action is taken. This updated workaround reads back the LCR after each write to confirm that the new value was accepted by the hardware. Should the hardware ignore a write, the TX/RX FIFOs are cleared and the receive buffer read before attempting to rewrite the LCR out of the hope that doing so will force the UART into an idle state. While this may seem unnecessarily aggressive, writes to the LCR are used to change the baud rate, parity, stop bit, or data length so the data that may be lost is likely not important. Admittedly, this is far from ideal but it seems to be the best that can be done given the hardware limitations. Lastly, the revised workaround doesn't touch the LCR in the ISR, so it avoids the possibility of a "serial8250: too much work for irq" lock up. This problem is rare in real situations but can be reproduced easily by wiring up two UARTs and running the following commands. # stty -F /dev/ttyS1 echo # stty -F /dev/ttyS2 echo # cat /dev/ttyS1 & [1] 375 # echo asdf > /dev/ttyS1 asdf [ 27.700000] serial8250: too much work for irq96 [ 27.700000] serial8250: too much work for irq96 [ 27.710000] serial8250: too much work for irq96 [ 27.710000] serial8250: too much work for irq96 [ 27.720000] serial8250: too much work for irq96 [ 27.720000] serial8250: too much work for irq96 [ 27.730000] serial8250: too much work for irq96 [ 27.730000] serial8250: too much work for irq96 [ 27.740000] serial8250: too much work for irq96 Signed-off-by: Tim Kryger Reviewed-by: Matt Porter Reviewed-by: Markus Mayer Reviewed-by: Heikki Krogerus [wangnan: backport to 3.10.43: - adjust context - remove unneeded local var] Signed-off-by: Wang Nan Signed-off-by: Greg Kroah-Hartman