commit c0cbbdebe91a944d653ca75670b77bbf57498150 Author: Greg Kroah-Hartman Date: Wed Jul 9 11:18:37 2014 -0700 Linux 3.14.12 commit bc4dd93ddeb21f4ac2f98a3b9eda02280f14b2a2 Author: Hugh Dickins Date: Mon Jun 23 13:22:07 2014 -0700 mm: fix crashes from mbind() merging vmas 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 commit 93ab3fb918cb11f18f54587dc10dd5712e8ff8ad Author: Mikulas Patocka Date: Tue Apr 8 21:52:05 2014 -0400 sym53c8xx_2: Set DID_REQUEUE return code when aborting squeue 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 commit d35426ed1fdd2c16d41ff4b83cfa2206dad57c07 Author: Joonsoo Kim Date: Mon Jun 23 13:22:06 2014 -0700 slab: fix oops when reading /proc/slab_allocators commit 03787301420376ae41fbaf4267f4a6253d152ac5 upstream. Commit b1cb0982bdd6 ("change the management method of free objects of the slab") introduced a bug on slab leak detector ('/proc/slab_allocators'). This detector works like as following decription. 1. traverse all objects on all the slabs. 2. determine whether it is active or not. 3. if active, print who allocate this object. but that commit changed the way how to manage free objects, so the logic determining whether it is active or not is also changed. In before, we regard object in cpu caches as inactive one, but, with this commit, we mistakenly regard object in cpu caches as active one. This intoduces kernel oops if DEBUG_PAGEALLOC is enabled. If DEBUG_PAGEALLOC is enabled, kernel_map_pages() is used to detect who corrupt free memory in the slab. It unmaps page table mapping if object is free and map it if object is active. When slab leak detector check object in cpu caches, it mistakenly think this object active so try to access object memory to retrieve caller of allocation. At this point, page table mapping to this object doesn't exist, so oops occurs. Following is oops message reported from Dave. It blew up when something tried to read /proc/slab_allocators (Just cat it, and you should see the oops below) Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC Modules linked in: [snip...] CPU: 1 PID: 9386 Comm: trinity-c33 Not tainted 3.14.0-rc5+ #131 task: ffff8801aa46e890 ti: ffff880076924000 task.ti: ffff880076924000 RIP: 0010:[] [] handle_slab+0x8a/0x180 RSP: 0018:ffff880076925de0 EFLAGS: 00010002 RAX: 0000000000001000 RBX: 0000000000000000 RCX: 000000005ce85ce7 RDX: ffffea00079be100 RSI: 0000000000001000 RDI: ffff880107458000 RBP: ffff880076925e18 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 000000000000000f R12: ffff8801e6f84000 R13: ffffea00079be100 R14: ffff880107458000 R15: ffff88022bb8d2c0 FS: 00007fb769e45740(0000) GS:ffff88024d040000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff8801e6f84ff8 CR3: 00000000a22db000 CR4: 00000000001407e0 DR0: 0000000002695000 DR1: 0000000002695000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000070602 Call Trace: leaks_show+0xce/0x240 seq_read+0x28e/0x490 proc_reg_read+0x3d/0x80 vfs_read+0x9b/0x160 SyS_read+0x58/0xb0 tracesys+0xd4/0xd9 Code: f5 00 00 00 0f 1f 44 00 00 48 63 c8 44 3b 0c 8a 0f 84 e3 00 00 00 83 c0 01 44 39 c0 72 eb 41 f6 47 1a 01 0f 84 e9 00 00 00 89 f0 <4d> 8b 4c 04 f8 4d 85 c9 0f 84 88 00 00 00 49 8b 7e 08 4d 8d 46 RIP handle_slab+0x8a/0x180 To fix the problem, I introduce an object status buffer on each slab. With this, we can track object status precisely, so slab leak detector would not access active object and no kernel oops would occur. Memory overhead caused by this fix is only imposed to CONFIG_DEBUG_SLAB_LEAK which is mainly used for debugging, so memory overhead isn't big problem. Signed-off-by: Joonsoo Kim Reported-by: Dave Jones Reported-by: Tetsuo Handa Reviewed-by: Vladimir Davydov Cc: Christoph Lameter Cc: Pekka Enberg Cc: David Rientjes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 347f31e9ad98b6bc15c50c72ae385b50bd7149b0 Author: Rik van Riel Date: Tue Apr 29 15:36:15 2014 -0400 mm/numa: Remove BUG_ON() in __handle_mm_fault() commit 107437febd495a50e2cd09c81bbaa84d30e57b07 upstream. Changing PTEs and PMDs to pte_numa & pmd_numa is done with the mmap_sem held for reading, which means a pmd can be instantiated and turned into a numa one while __handle_mm_fault() is examining the value of old_pmd. If that happens, __handle_mm_fault() should just return and let the page fault retry, instead of throwing an oops. This is handled by the test for pmd_trans_huge(*pmd) below. Signed-off-by: Rik van Riel Reviewed-by: Naoya Horiguchi Reported-by: Sunil Pandey Signed-off-by: Peter Zijlstra Cc: Andrew Morton Cc: Johannes Weiner Cc: Kirill A. Shutemov Cc: Linus Torvalds Cc: Mel Gorman Cc: linux-mm@kvack.org Cc: lwoodman@redhat.com Cc: dave.hansen@intel.com Link: http://lkml.kernel.org/r/20140429153615.2d72098e@annuminas.surriel.com Signed-off-by: Ingo Molnar Patrick McLean Signed-off-by: Greg Kroah-Hartman commit c10760de1dfd589d77fded52838e99df1a38a8c4 Author: Zhichuang SUN Date: Wed May 21 14:13:30 2014 +0800 drivers/video/fbdev/fb-puv3.c: Add header files for function unifb_mmap 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 commit 18600e22a3d3f55018179e7fcf9ed8e490d9bf15 Author: Chen Gang Date: Mon Mar 24 20:17:44 2014 +0800 arch/unicore32/mm/alignment.c: include "asm/pgtable.h" to avoid compiling error 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 commit f87b60a38a4f673b20652326f98fddf120d343fa Author: Sander Eikelenboom Date: Fri May 2 15:09:27 2014 +0200 ALSA: usb-audio: Prevent printk ratelimiting from spamming kernel log while DEBUG not defined 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 commit 44591702f7d921c4c8b9973b32015bd1867efe47 Author: Tim Gardner Date: Wed Apr 9 11:30:44 2014 -0600 ALSA: usb-audio: Suppress repetitive debug messages from retire_playback_urb() 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 commit 306f596b877b65fba7a85e074730d3f13e402fd4 Author: Richard Guy Briggs Date: Mon Feb 24 12:31:11 2014 -0500 audit: remove superfluous new- prefix in AUDIT_LOGIN messages commit aa589a13b5d00d3c643ee4114d8cbc3addb4e99f upstream. The new- prefix on ses and auid are un-necessary and break ausearch. Signed-off-by: Richard Guy Briggs Reported-by: Steve Grubb Signed-off-by: Greg Kroah-Hartman commit 199f5458a1271586f5241fe5f5d28b7be3d2845c Author: Anatol Pomozov Date: Tue Apr 15 11:31:33 2014 -0700 aio: block io_destroy() until all context requests are completed commit e02ba72aabfade4c9cd6e3263e9b57bf890ad25c upstream. deletes aio context and all resources related to. It makes sense that no IO operations connected to the context should be running after the context is destroyed. As we removed io_context we have no chance to get requests status or call io_getevents(). man page for io_destroy says that this function may block until all context's requests are completed. Before kernel 3.11 io_destroy() blocked indeed, but since aio refactoring in 3.11 it is not true anymore. Here is a pseudo-code that shows a testcase for a race condition discovered in 3.11: initialize io_context io_submit(read to buffer) io_destroy() // context is destroyed so we can free the resources free(buffers); // if the buffer is allocated by some other user he'll be surprised // to learn that the buffer still filled by an outstanding operation // from the destroyed io_context The fix is straight-forward - add a completion struct and wait on it in io_destroy, complete() should be called when number of in-fligh requests reaches zero. If two or more io_destroy() called for the same context simultaneously then only the first one waits for IO completion, other calls behaviour is undefined. Tested: ran http://pastebin.com/LrPsQ4RL testcase for several hours and do not see the race condition anymore. Signed-off-by: Anatol Pomozov Signed-off-by: Benjamin LaHaise Cc: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 2d29f7576d8a79e4effb79404e76ea911488a44e Author: Imre Deak Date: Mon Jun 2 14:21:10 2014 +0300 drm/i915: fix display power sw state reporting commit b8c000d9bf23e7c1155ef421f595d1cbc25262da upstream. Atm, we refcount both power domains and power wells and intel_display_power_enabled_sw() returns the power domain refcount. What the callers are really interested in though is the sw state of the underlying power wells. Due to this we will report incorrectly that a given power domain is off if its power wells were enabled via another power domain, for example POWER_DOMAIN_INIT which enables all power wells. As a fix return instead the state based on the refcount of all power wells included in the passed in power domain. References: https://bugs.freedesktop.org/show_bug.cgi?id=79505 References: https://bugs.freedesktop.org/show_bug.cgi?id=79038 Reported-by: Chris Wilson Signed-off-by: Imre Deak Reviewed-by: Damien Lespiau Signed-off-by: Daniel Vetter Acked-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 22d58715d7be9aaf334e00b33418156e58f87092 Author: Micky Ching Date: Thu Mar 27 13:35:04 2014 +0800 mmc: rtsx: add R1-no-CRC mmc command type handle commit 5027251eced6e34315a52bd841279df957f627bb upstream. a27fbf2f067b0cd ("mmc: add ignorance case for CMD13 CRC error") produced a cmd.flags unhandled in realtek pci host driver. This will make MMC card fail to initialize, this patch is used to handle the new cmd.flags condition and MMC card can be used. Signed-off-by: Micky Ching Signed-off-by: Ulf Hansson Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman commit 9210bad0ecb522c1b89dd496274637cb92e403d5 Author: Hans de Goede Date: Wed Apr 23 12:20:55 2014 +0200 brcmfmac: Fix brcmf_chip_ai_coredisable not applying reset bits to BCMA_IOCTL commit ffa216bb5eecfce0f01b0b2a95d5c320dde90005 upstream. brcmfmac has been broken on my cubietruck with a BCM43362: brcmfmac: brcmf_chip_recognition: found AXI chip: BCM43362, rev=1 brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d since commit 53036261033: "brcmfmac: update core reset and disable routines". The problem is that since this commit brcmf_chip_ai_resetcore no longer sets BCMA_IOCTL itself before bringing the core out of reset, instead relying on brcmf_chip_ai_coredisable to do so. But brcmf_chip_ai_coredisable is a nop of the chip is already in reset. This patch modifies brcmf_chip_ai_coredisable to always set BCMA_IOCTL even if the core is already in reset. This fixes brcmfmac hanging in firmware loading on my board. Cc: stable@vger.kernel.org # v3.14 Signed-off-by: Hans de Goede Acked-by: Arend van Spriel Signed-off-by: John W. Linville [arend@broadcom.com: rebase patch on linux-3.14.y branch] Signed-off-by: Arend van Spriel Signed-off-by: Greg Kroah-Hartman commit 82b8759a69e9b0b795e897ec312599953a6c3946 Author: Florian Westphal Date: Sat Jun 7 21:17:04 2014 +0200 netfilter: nf_nat: fix oops on netns removal commit 945b2b2d259d1a4364a2799e80e8ff32f8c6ee6f upstream. Quoting Samu Kallio: Basically what's happening is, during netns cleanup, nf_nat_net_exit gets called before ipv4_net_exit. As I understand it, nf_nat_net_exit is supposed to kill any conntrack entries which have NAT context (through nf_ct_iterate_cleanup), but for some reason this doesn't happen (perhaps something else is still holding refs to those entries?). When ipv4_net_exit is called, conntrack entries (including those with NAT context) are cleaned up, but the nat_bysource hashtable is long gone - freed in nf_nat_net_exit. The bug happens when attempting to free a conntrack entry whose NAT hash 'prev' field points to a slot in the freed hash table (head for that bin). We ignore conntracks with null nat bindings. But this is wrong, as these are in bysource hash table as well. Restore nat-cleaning for the netns-is-being-removed case. bug: https://bugzilla.kernel.org/show_bug.cgi?id=65191 Fixes: c2d421e1718 ('netfilter: nf_nat: fix race when unloading protocol modules') Reported-by: Samu Kallio Debugged-by: Samu Kallio Signed-off-by: Florian Westphal Tested-by: Samu Kallio Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 693639e6d5de17cdd5db53f8046a4c6fd275647a Author: Peter Hurley Date: Mon Jun 16 08:10:42 2014 -0400 tty: Correct INPCK handling commit 66528f90669691c85c73bea4f0c9f4a5857c4cab upstream. If INPCK is not set, input parity detection should be disabled. This means parity errors should not be received from the tty driver, and the data received should be treated normally. SUS v3, 11.2.2, General Terminal Interface - Input Modes, states: "If INPCK is set, input parity checking shall be enabled. If INPCK is not set, input parity checking shall be disabled, allowing output parity generation without input parity errors. Note that whether input parity checking is enabled or disabled is independent of whether parity detection is enabled or disabled (see Control Modes). If parity detection is enabled but input parity checking is disabled, the hardware to which the terminal is connected shall recognize the parity bit, but the terminal special file shall not check whether or not this bit is correctly set." Ignore parity errors reported by the tty driver when INPCK is not set, and handle the received data normally. Fixes: Bugzilla #71681, 'Improvement of n_tty_receive_parity_error from n_tty.c' Reported-by: Ivan Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman commit d41660414cbb85cfef0df11c2580890648211355 Author: Peter Hurley Date: Mon Jun 16 08:10:41 2014 -0400 serial: Fix IGNBRK handling commit ef8b9ddcb45fa3b1e11acd72be2398001e807d14 upstream. If IGNBRK is set without either BRKINT or PARMRK set, some uart drivers send a 0x00 byte for BREAK without the TTYBREAK flag to the line discipline, when it should send either nothing or the TTYBREAK flag set. This happens because the read_status_mask masks out the BI condition, which uart_insert_char() then interprets as a normal 0x00 byte. SUS v3 is clear regarding the meaning of IGNBRK; Section 11.2.2, General Terminal Interface - Input Modes, states: "If IGNBRK is set, a break condition detected on input shall be ignored; that is, not put on the input queue and therefore not read by any process." Fix read_status_mask to include the BI bit if IGNBRK is set; the lsr status retains the BI bit if a BREAK is recv'd, which is subsequently ignored in uart_insert_char() when masked with the ignore_status_mask. Affected drivers: 8250 - all serial_txx9 mfd amba-pl010 amba-pl011 atmel_serial bfin_uart dz ip22zilog max310x mxs-auart netx-serial pnx8xxx_uart pxa sb1250-duart sccnxp serial_ks8695 sirfsoc_uart st-asc vr41xx_siu zs sunzilog fsl_lpuart sunsab ucc_uart bcm63xx_uart sunsu efm32-uart pmac_zilog mpsc msm_serial m32r_sio Unaffected drivers: omap-serial rp2 sa1100 imx icom Annotated for fixes: altera_uart mcf Drivers without break detection: 21285 xilinx-uartps altera_jtaguart apbuart arc-uart clps711x max3100 uartlite msm_serial_hs nwpserial lantiq vt8500_serial Unknown: samsung mpc52xx_uart bfin_sport_uart cpm_uart/core Fixes: Bugzilla #71651, '8250_core.c incorrectly handles IGNBRK flag' Reported-by: Ivan Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman commit 9e0126ef80c2c33f6ce8aeca9035e8baa6e7d3d0 Author: Stephen Boyd Date: Fri May 16 16:07:09 2014 -0700 clk: qcom: Fix mmcc-8974's PLL configurations commit 437ae6a1b8f2eedebfbf0f6572e19ca5c58a3f71 upstream. We forgot to add the status bit for the PLLs and we were using the wrong register and masks for configuration, leading to unexpected PLL configurations. Fix this. Fixes: d8b212014e69 (clk: qcom: Add support for MSM8974's multimedia clock controller (MMCC)) Signed-off-by: Stephen Boyd Signed-off-by: Mike Turquette Signed-off-by: Greg Kroah-Hartman commit ad40aceaec1b7ba8bd2716544db4bb55214177b7 Author: Stephen Boyd Date: Fri May 16 16:07:08 2014 -0700 clk: qcom: Fix clk_rcg2_is_enabled() check commit aa014149ba002155a084ec1e9328e95b70167cbb upstream. If the bit is set the clock is off so we should be checking for a clear bit, not a set bit. Invert the logic. Fixes: bcd61c0f535a (clk: qcom: Add support for root clock generators (RCGs)) Signed-off-by: Stephen Boyd Signed-off-by: Mike Turquette Signed-off-by: Greg Kroah-Hartman commit 6408e65dfa751860e2c2b9388400a51da43b4d55 Author: Jack Morgenstein Date: Thu May 29 16:31:00 2014 +0300 mlx4_core: Fix incorrect FLAGS1 bitmap test in mlx4_QUERY_FUNC_CAP commit bc82878baa10c2a6a4a6affaf52c152935112142 upstream. Commit eb17711bc1d6 ("net/mlx4_core: Introduce nic_info new flag in QUERY_FUNC_CAP") did: if (func_cap->flags1 & QUERY_FUNC_CAP_FLAGS1_OFFSET) { which should be: if (func_cap->flags1 & QUERY_FUNC_CAP_FLAGS1_FORCE_VLAN) { Fix that. Fixes: eb17711bc1d6 ("net/mlx4_core: Introduce nic_info new flag in QUERY_FUNC_CAP") Signed-off-by: Jack Morgenstein Signed-off-by: Or Gerlitz Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit caa56204516ab47ec10852cf38bab289711a26df Author: Michal Nazarewicz Date: Wed Jul 2 15:22:35 2014 -0700 mm: page_alloc: fix CMA area initialisation when pageblock > MAX_ORDER commit dc78327c0ea7da5186d8cbc1647bd6088c5c9fa5 upstream. With a kernel configured with ARM64_64K_PAGES && !TRANSPARENT_HUGEPAGE, the following is triggered at early boot: SMP: Total of 8 processors activated. devtmpfs: initialized Unable to handle kernel NULL pointer dereference at virtual address 00000008 pgd = fffffe0000050000 [00000008] *pgd=00000043fba00003, *pmd=00000043fba00003, *pte=00e0000078010407 Internal error: Oops: 96000006 [#1] SMP Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.15.0-rc864k+ #44 task: fffffe03bc040000 ti: fffffe03bc080000 task.ti: fffffe03bc080000 PC is at __list_add+0x10/0xd4 LR is at free_one_page+0x270/0x638 ... Call trace: __list_add+0x10/0xd4 free_one_page+0x26c/0x638 __free_pages_ok.part.52+0x84/0xbc __free_pages+0x74/0xbc init_cma_reserved_pageblock+0xe8/0x104 cma_init_reserved_areas+0x190/0x1e4 do_one_initcall+0xc4/0x154 kernel_init_freeable+0x204/0x2a8 kernel_init+0xc/0xd4 This happens because init_cma_reserved_pageblock() calls __free_one_page() with pageblock_order as page order but it is bigger than MAX_ORDER. This in turn causes accesses past zone->free_list[]. Fix the problem by changing init_cma_reserved_pageblock() such that it splits pageblock into individual MAX_ORDER pages if pageblock is bigger than a MAX_ORDER page. In cases where !CONFIG_HUGETLB_PAGE_SIZE_VARIABLE, which is all architectures expect for ia64, powerpc and tile at the moment, the “pageblock_order > MAX_ORDER” condition will be optimised out since both sides of the operator are constants. In cases where pageblock size is variable, the performance degradation should not be significant anyway since init_cma_reserved_pageblock() is called only at boot time at most MAX_CMA_AREAS times which by default is eight. Signed-off-by: Michal Nazarewicz Reported-by: Mark Salter Tested-by: Mark Salter Tested-by: Christopher Covington Cc: Mel Gorman Cc: David Rientjes Cc: Marek Szyprowski Cc: Catalin Marinas Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e72e686bc5ada94c4832967c4f31219b3d55a9ad Author: Thomas Gleixner Date: Thu Jun 19 21:34:37 2014 +0000 irqchip: spear_shirq: Fix interrupt offset commit 4f4366033945419b0c52118c29d3057d7c558765 upstream. The ras3 block on spear320 claims to have 3 interrupts. In fact it has one and 6 reserved interrupts. Account the 6 reserved to this block so it has 7 interrupts total. That matches the datasheet and the device tree entries. Broken since commit 80515a5a(ARM: SPEAr3xx: shirq: simplify and move the shared irq multiplexor to DT). Testing is overrated.... Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/20140619212712.872379208@linutronix.de Fixes: 80515a5a2e3c ('ARM: SPEAr3xx: shirq: simplify and move the shared irq multiplexor to DT') Acked-by: Viresh Kumar Signed-off-by: Jason Cooper Signed-off-by: Greg Kroah-Hartman commit 349908f43bdc379bffc2e112b84572d2fc11765d Author: NeilBrown Date: Wed Jul 2 12:04:14 2014 +1000 md: flush writes before starting a recovery. commit 133d4527eab8d199a62eee6bd433f0776842df2e upstream. When we write to a degraded array which has a bitmap, we make sure the relevant bit in the bitmap remains set when the write completes (so a 're-add' can quickly rebuilt a temporarily-missing device). If, immediately after such a write starts, we incorporate a spare, commence recovery, and skip over the region where the write is happening (because the 'needs recovery' flag isn't set yet), then that write will not get to the new device. Once the recovery finishes the new device will be trusted, but will have incorrect data, leading to possible corruption. We cannot set the 'needs recovery' flag when we start the write as we do not know easily if the write will be "degraded" or not. That depends on details of the particular raid level and particular write request. This patch fixes a corruption issue of long standing and so it suitable for any -stable kernel. It applied correctly to 3.0 at least and will minor editing to earlier kernels. Reported-by: Bill Tested-by: Bill Link: http://lkml.kernel.org/r/53A518BB.60709@sbcglobal.net Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 1857a6278161211c4247041747a906da505018d3 Author: Steven Rostedt (Red Hat) Date: Tue Jun 24 23:50:09 2014 -0400 tracing: Remove ftrace_stop/start() from reading the trace file commit 099ed151675cd1d2dbeae1dac697975f6a68716d upstream. Disabling reading and writing to the trace file should not be able to disable all function tracing callbacks. There's other users today (like kprobes and perf). Reading a trace file should not stop those from happening. Reviewed-by: Masami Hiramatsu Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 1d58e36ff8741e847d06fdc2fc1a27f313861944 Author: Michal Nazarewicz Date: Fri Jun 13 15:38:05 2014 +0200 tools: ffs-test: fix header values endianess commit f35f71244da6e51db4e1f2c7e318581f498ececf upstream. It appears that no one ever run ffs-test on a big-endian machine, since it used cpu-endianess for fs_count and hs_count fields which should be in little-endian format. Fix by wrapping the numbers in cpu_to_le32. Signed-off-by: Michal Nazarewicz Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 737c7943b87adebbd4abca7a196539511c04071e Author: J. Bruce Fields Date: Thu Jun 19 16:44:48 2014 -0400 nfsd: fix rare symlink decoding bug commit 76f47128f9b33af1e96819746550d789054c9664 upstream. An NFS operation that creates a new symlink includes the symlink data, which is xdr-encoded as a length followed by the data plus 0 to 3 bytes of zero-padding as required to reach a 4-byte boundary. The vfs, on the other hand, wants null-terminated data. The simple way to handle this would be by copying the data into a newly allocated buffer with space for the final null. The current nfsd_symlink code tries to be more clever by skipping that step in the (likely) case where the byte following the string is already 0. But that assumes that the byte following the string is ours to look at. In fact, it might be the first byte of a page that we can't read, or of some object that another task might modify. Worse, the NFSv4 code tries to fix the problem by actually writing to that byte. In the NFSv2/v3 cases this actually appears to be safe: - nfs3svc_decode_symlinkargs explicitly null-terminates the data (after first checking its length and copying it to a new page). - NFSv2 limits symlinks to 1k. The buffer holding the rpc request is always at least a page, and the link data (and previous fields) have maximum lengths that prevent the request from reaching the end of a page. In the NFSv4 case the CREATE op is potentially just one part of a long compound so can end up on the end of a page if you're unlucky. The minimal fix here is to copy and null-terminate in the NFSv4 case. The nfsd_symlink() interface here seems too fragile, though. It should really either do the copy itself every time or just require a null-terminated string. Reported-by: Jeff Layton Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit d76487939ce88c9b19cb1c8dada9c550590cac14 Author: Dan Carpenter Date: Fri Jun 20 20:22:00 2014 +0100 staging: iio/ad7291: fix error code in ad7291_probe() commit b70e19c222a64018d308ebc80333575aff9f4e51 upstream. We should be returning a negative error code instead of success here. This would have been detected by GCC, except that the "ret" variable was initialized with a bogus value to disable GCC's uninitialized variable warnings. I've cleaned that up, as well. Signed-off-by: Dan Carpenter Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit e7bf5a8bbc2fa525e83f1acdd74c5914ed142f47 Author: Adam Thomson Date: Thu Nov 6 12:11:00 2014 +0000 iio: of_iio_channel_get_by_name() returns non-null pointers for error legs commit a2c12493ed7e63a18cef33a71686d12ffcd6600e upstream. Currently in the inkern.c code for IIO framework, the function of_iio_channel_get_by_name() will return a non-NULL pointer when it cannot find a channel using of_iio_channel_get() and when it tries to search for 'io-channel-ranges' property and fails. This is incorrect behaviour as the function which calls this expects a NULL pointer for failure. This patch rectifies the issue. Signed-off-by: Adam Thomson Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 4c8c5a45d44452212a26af9a80f580707f1f77d1 Author: Xiaoming Gao Date: Thu Jun 19 19:14:57 2014 +0800 kvm: fix wrong address when writing Hyper-V tsc page commit e1fa108d24697b78348fd4e5a531029a50d0d36d upstream. When kvm_write_guest writes the tsc_ref structure to the guest, or it will lead the low HV_X64_MSR_TSC_REFERENCE_ADDRESS_SHIFT bits of the TSC page address must be cleared, or the guest can see a non-zero sequence number. Otherwise Windows guests would not be able to get a correct clocksource (QueryPerformanceCounter will always return 0) which causes serious chaos. Signed-off-by: Xiaoming Gao Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit a46438472e31a9766352c97e37caaa2848ddea10 Author: Paolo Bonzini Date: Thu Jun 19 11:40:18 2014 +0200 KVM: x86: preserve the high 32-bits of the PAT register commit 7cb060a91c0efc5ff94f83c6df3ed705e143cdb9 upstream. KVM does not really do much with the PAT, so this went unnoticed for a long time. It is exposed however if you try to do rdmsr on the PAT register. Reported-by: Valentine Sinitsyn Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 16f225f355b19890d4e09b345c3fd85496fa4c66 Author: Nadav Amit Date: Wed Jun 18 17:21:19 2014 +0300 KVM: x86: Increase the number of fixed MTRR regs to 10 commit 682367c494869008eb89ef733f196e99415ae862 upstream. Recent Intel CPUs have 10 variable range MTRRs. Since operating systems sometime make assumptions on CPUs while they ignore capability MSRs, it is better for KVM to be consistent with recent CPUs. Reporting more MTRRs than actually supported has no functional implications. Signed-off-by: Nadav Amit Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 7c9db4927e4713d0fb071619d2997e2f5a209583 Author: Jan Kara Date: Thu Jun 26 12:30:54 2014 -0400 ext4: Fix hole punching for files with indirect blocks commit a93cd4cf86466caa49cfe64607bea7f0bde3f916 upstream. Hole punching code for files with indirect blocks wrongly computed number of blocks which need to be cleared when traversing the indirect block tree. That could result in punching more blocks than actually requested and thus effectively cause a data loss. For example: fallocate -n -p 10240000 4096 will punch the range 10240000 - 12632064 instead of the range 1024000 - 10244096. Fix the calculation. Fixes: 8bad6fc813a3a5300f51369c39d315679fd88c72 Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit cbbe137036cec32f997d9dc945b45412a92bad61 Author: Jan Kara Date: Sun Jun 15 23:46:28 2014 -0400 ext4: Fix buffer double free in ext4_alloc_branch() commit c5c7b8ddfbf8cb3b2291e515a34ab1b8982f5a2d upstream. Error recovery in ext4_alloc_branch() calls ext4_forget() even for buffer corresponding to indirect block it did not allocate. This leads to brelse() being called twice for that buffer (once from ext4_forget() and once from cleanup in ext4_ind_map_blocks()) leading to buffer use count misaccounting. Eventually (but often much later because there are other users of the buffer) we will see messages like: VFS: brelse: Trying to free free buffer Another manifestation of this problem is an error: JBD2 unexpected failure: jbd2_journal_revoke: !buffer_revoked(bh); inconsistent data on disk The fix is easy - don't forget buffer we did not allocate. Also add an explanatory comment because the indexing at ext4_alloc_branch() is somewhat subtle. Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit baa9dbe85a5ce7d415837652a14c2edac0455880 Author: Tejun Heo Date: Thu Jun 19 17:42:57 2014 -0400 blkcg: fix use-after-free in __blkg_release_rcu() by making blkcg_gq refcnt an atomic_t commit a5049a8ae34950249a7ae94c385d7c5c98914412 upstream. Hello, So, this patch should do. Joe, Vivek, can one of you guys please verify that the oops goes away with this patch? Jens, the original thread can be read at http://thread.gmane.org/gmane.linux.kernel/1720729 The fix converts blkg->refcnt from int to atomic_t. It does some overhead but it should be minute compared to everything else which is going on and the involved cacheline bouncing, so I think it's highly unlikely to cause any noticeable difference. Also, the refcnt in question should be converted to a perpcu_ref for blk-mq anyway, so the atomic_t is likely to go away pretty soon anyway. Thanks. ------- 8< ------- __blkg_release_rcu() may be invoked after the associated request_queue is released with a RCU grace period inbetween. As such, the function and callbacks invoked from it must not dereference the associated request_queue. This is clearly indicated in the comment above the function. Unfortunately, while trying to fix a different issue, 2a4fd070ee85 ("blkcg: move bulk of blkcg_gq release operations to the RCU callback") ignored this and added [un]locking of @blkg->q->queue_lock to __blkg_release_rcu(). This of course can cause oops as the request_queue may be long gone by the time this code gets executed. general protection fault: 0000 [#1] SMP CPU: 21 PID: 30 Comm: rcuos/21 Not tainted 3.15.0 #1 Hardware name: Stratus ftServer 6400/G7LAZ, BIOS BIOS Version 6.3:57 12/25/2013 task: ffff880854021de0 ti: ffff88085403c000 task.ti: ffff88085403c000 RIP: 0010:[] [] _raw_spin_lock_irq+0x15/0x60 RSP: 0018:ffff88085403fdf0 EFLAGS: 00010086 RAX: 0000000000020000 RBX: 0000000000000010 RCX: 0000000000000000 RDX: 000060ef80008248 RSI: 0000000000000286 RDI: 6b6b6b6b6b6b6b6b RBP: ffff88085403fdf0 R08: 0000000000000286 R09: 0000000000009f39 R10: 0000000000020001 R11: 0000000000020001 R12: ffff88103c17a130 R13: ffff88103c17a080 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88107fca0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000006e5ab8 CR3: 000000000193d000 CR4: 00000000000407e0 Stack: ffff88085403fe18 ffffffff812cbfc2 ffff88103c17a130 0000000000000000 ffff88103c17a130 ffff88085403fec0 ffffffff810d1d28 ffff880854021de0 ffff880854021de0 ffff88107fcaec58 ffff88085403fe80 ffff88107fcaec30 Call Trace: [] __blkg_release_rcu+0x72/0x150 [] rcu_nocb_kthread+0x1e8/0x300 [] kthread+0xe1/0x100 [] ret_from_fork+0x7c/0xb0 Code: ff 47 04 48 8b 7d 08 be 00 02 00 00 e8 55 48 a4 ff 5d c3 0f 1f 00 66 66 66 66 90 55 48 89 e5 +fa 66 66 90 66 66 90 b8 00 00 02 00 0f c1 07 89 c2 c1 ea 10 66 39 c2 75 02 5d c3 83 e2 fe 0f +b7 RIP [] _raw_spin_lock_irq+0x15/0x60 RSP The request_queue locking was added because blkcg_gq->refcnt is an int protected with the queue lock and __blkg_release_rcu() needs to put the parent. Let's fix it by making blkcg_gq->refcnt an atomic_t and dropping queue locking in the function. Given the general heavy weight of the current request_queue and blkcg operations, this is unlikely to cause any noticeable overhead. Moreover, blkcg_gq->refcnt is likely to be converted to percpu_ref in the near future, so whatever (most likely negligible) overhead it may add is temporary. Signed-off-by: Tejun Heo Reported-by: Joe Lawrence Acked-by: Vivek Goyal Link: http://lkml.kernel.org/g/alpine.DEB.2.02.1406081816540.17948@jlaw-desktop.mno.stratus.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit c9434069518d74c16a9298d20fb927be8ab259f0 Author: Steve French Date: Sun Jun 22 20:38:49 2014 -0500 CIFS: fix mount failure with broken pathnames when smb3 mount with mapchars option commit ce36d9ab3bab06b7b5522f5c8b68fac231b76ffb upstream. When we SMB3 mounted with mapchars (to allow reserved characters : \ / > < * ? via the Unicode Windows to POSIX remap range) empty paths (eg when we open "" to query the root of the SMB3 directory on mount) were not null terminated so we sent garbarge as a path name on empty paths which caused SMB2/SMB2.1/SMB3 mounts to fail when mapchars was specified. mapchars is particularly important since Unix Extensions for SMB3 are not supported (yet) Signed-off-by: Steve French Reviewed-by: David Disseldorp Signed-off-by: Greg Kroah-Hartman commit 2545a404c729dd4e425b7fff2e245677b8b402b6 Author: Björn Baumbach Date: Tue Jun 10 12:03:26 2014 +0200 fs/cifs: fix regression in cifs_create_mf_symlink() commit a1d0b84c308d7fdfb67eb76498116a6c2fdda507 upstream. commit d81b8a40e2ece0a9ab57b1fe1798e291e75bf8fc ("CIFS: Cleanup cifs open codepath") changed disposition to FILE_OPEN. Signed-off-by: Björn Baumbach Signed-off-by: Stefan Metzmacher Reviewed-by: Stefan Metzmacher Cc: Pavel Shilovsky Cc: Steve French Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit ad8615594ecd776c9cc0291a6691d9375630cda1 Author: Rafał Miłecki Date: Thu Jun 12 22:28:22 2014 +0200 b43: fix frequency reported on G-PHY with /new/ firmware commit 2fc68eb122c7ea6cd5be1fe7d6650c0beb2f4f40 upstream. Support for firmware rev 508+ was added years ago, but we never noticed it reports channel in a different way for G-PHY devices. Instead of offset from 2400 MHz it simply passes channel id (AKA hw_value). So far it was (most probably) affecting monitor mode users only, but the following recent commit made it noticeable for quite everybody: commit 3afc2167f60a327a2c1e1e2600ef209a3c2b75b7 Author: Emmanuel Grumbach Date: Tue Mar 4 16:50:13 2014 +0200 cfg80211/mac80211: ignore signal if the frame was heard on wrong channel Reported-by: Aaro Koskinen Signed-off-by: Rafał Miłecki Tested-by: Aaro Koskinen Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 1f2661c088fb1c1bf6a574f16d1666761620e3ff Author: Maxime Ripard Date: Mon Jun 23 22:49:40 2014 +0200 net: allwinner: emac: Add missing free_irq commit b91113282bf44df46aba374a0b8f88a75bfd4b3f upstream. If the mdio probe function fails in emac_open, the interrupt we just requested isn't freed. If emac_open is called again, for example because we try to set up the interface again, the kernel will oops because the interrupt wasn't properly released. Signed-off-by: Maxime Ripard Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 04f19c5801b5e45ba34a559779e284bfbcee62b9 Author: ChiaHao Date: Thu Jun 12 15:32:33 2014 +0100 arm64: Bug fix in stack alignment exception commit 3906c2b53cd23c2ae03e6ce41432c8e7f0a3cbbb upstream. The value of ESR has been stored into x1, and should be directly pass to do_sp_pc_abort function, "MOV x1, x25" is an extra operation and do_sp_pc_abort will get the wrong value of ESR. Signed-off-by: ChiaHao Signed-off-by: Catalin Marinas Cc: Signed-off-by: Greg Kroah-Hartman commit ea49087c4616caa9bceb8ce488c242bb2487bd76 Author: David R. Piegdon Date: Mon Jun 16 23:42:51 2014 +0000 ARM: OMAP2+: Fix parser-bug in platform muxing code commit c021f241f4fab2bb4fc4120a38a828a03dd3f970 upstream. Fix a parser-bug in the omap2 muxing code where muxtable-entries will be wrongly selected if the requested muxname is a *prefix* of their m0-entry and they have a matching mN-entry. Fix by additionally checking that the length of the m0_entry is equal. For example muxing of "dss_data2.dss_data2" on omap32xx will fail because the prefix "dss_data2" will match the mux-entries "dss_data2" as well as "dss_data20", with the suffix "dss_data2" matching m0 (for dss_data2) and m4 (for dss_data20). Thus both are recognized as signal path candidates: Relevant muxentries from mux34xx.c: _OMAP3_MUXENTRY(DSS_DATA20, 90, "dss_data20", NULL, "mcspi3_somi", "dss_data2", "gpio_90", NULL, NULL, "safe_mode"), _OMAP3_MUXENTRY(DSS_DATA2, 72, "dss_data2", NULL, NULL, NULL, "gpio_72", NULL, NULL, "safe_mode"), This will result in a failure to mux the pin at all: _omap_mux_get_by_name: Multiple signal paths (2) for dss_data2.dss_data2 Patch should apply to linus' latest master down to rather old linux-2.6 trees. Signed-off-by: David R. Piegdon Cc: stable@vger.kernel.org [tony@atomide.com: updated description to include full description] Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit f0b43bec2d022381a70f63007b925efe0c3a9f03 Author: Steve Capper Date: Wed Jul 2 11:46:23 2014 +0100 arm64: mm: Make icache synchronisation logic huge page aware commit 923b8f5044da753e4985ab15c1374ced2cdf616c upstream. The __sync_icache_dcache routine will only flush the dcache for the first page of a compound page, potentially leading to stale icache data residing further on in a hugetlb page. This patch addresses this issue by taking into consideration the order of the page when flushing the dcache. Reported-by: Mark Brown Tested-by: Mark Brown Signed-off-by: Steve Capper Acked-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 1f8e5d4325ab2b4b328ca4eabcd2a687103d0565 Author: David Rientjes Date: Mon Jun 23 13:22:04 2014 -0700 mm, pcp: allow restoring percpu_pagelist_fraction default commit 7cd2b0a34ab8e4db971920eef8982f985441adfb upstream. Oleg reports a division by zero error on zero-length write() to the percpu_pagelist_fraction sysctl: divide error: 0000 [#1] SMP DEBUG_PAGEALLOC CPU: 1 PID: 9142 Comm: badarea_io Not tainted 3.15.0-rc2-vm-nfs+ #19 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 task: ffff8800d5aeb6e0 ti: ffff8800d87a2000 task.ti: ffff8800d87a2000 RIP: 0010: percpu_pagelist_fraction_sysctl_handler+0x84/0x120 RSP: 0018:ffff8800d87a3e78 EFLAGS: 00010246 RAX: 0000000000000f89 RBX: ffff88011f7fd000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000010 RBP: ffff8800d87a3e98 R08: ffffffff81d002c8 R09: ffff8800d87a3f50 R10: 000000000000000b R11: 0000000000000246 R12: 0000000000000060 R13: ffffffff81c3c3e0 R14: ffffffff81cfddf8 R15: ffff8801193b0800 FS: 00007f614f1e9740(0000) GS:ffff88011f440000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007f614f1fa000 CR3: 00000000d9291000 CR4: 00000000000006e0 Call Trace: proc_sys_call_handler+0xb3/0xc0 proc_sys_write+0x14/0x20 vfs_write+0xba/0x1e0 SyS_write+0x46/0xb0 tracesys+0xe1/0xe6 However, if the percpu_pagelist_fraction sysctl is set by the user, it is also impossible to restore it to the kernel default since the user cannot write 0 to the sysctl. This patch allows the user to write 0 to restore the default behavior. It still requires a fraction equal to or larger than 8, however, as stated by the documentation for sanity. If a value in the range [1, 7] is written, the sysctl will return EINVAL. This successfully solves the divide by zero issue at the same time. Signed-off-by: David Rientjes Reported-by: Oleg Drokin Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 1725aa78848dd382a9705146131d0b10164650ba Author: Naoya Horiguchi Date: Mon Jun 23 13:22:03 2014 -0700 hugetlb: fix copy_hugetlb_page_range() to handle migration/hwpoisoned entry 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 commit bc3e3ff65a157cc6ef43e2279cfac6cf7cdcbbbe Author: Emmanuel Grumbach Date: Thu May 8 12:15:22 2014 +0300 iwlwifi: pcie: try to get ownership several times commit 501fd9895c1d7d8161ed56698ae2fccb10ef14f5 upstream. Some races with the hardware can happen when we take ownership of the device. Don't give up after the first try. Reviewed-by: Johannes Berg Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit 94d21115127a2c593e04e5199caaf9bf22aa5eb3 Author: Felix Fietkau Date: Tue May 27 22:33:57 2014 +0200 mac80211: fix a memory leak on sta rate selection table commit 53d045258ee2e38b1e882617cb0799a04d05f5fa upstream. If the rate control algorithm uses a selection table, it is leaked when the station is destroyed - fix that. Signed-off-by: Felix Fietkau Reported-by: Christophe Prévotaux Fixes: 0d528d85c519 ("mac80211: improve the rate control API") [add commit log entry, remove pointless NULL check] Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit c7e592387547f09a0e25a698f9295edec03971d8 Author: Arik Nemtsov Date: Mon May 26 14:40:51 2014 +0300 mac80211: don't check netdev state for debugfs read/write commit 923eaf367206e01f22c97aee22300e332d071916 upstream. Doing so will lead to an oops for a p2p-dev interface, since it has no netdev. Signed-off-by: Arik Nemtsov Signed-off-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 48e805c8a9abd72f9990c8a1778e28a42156a82e Author: Krzysztof Hałasa Date: Mon May 26 14:14:46 2014 +0200 mac80211: fix IBSS join by initializing last_scan_completed commit c7d37a66e345df2fdf1aa7b2c9a6d3d53846ca5b upstream. Without this fix, freshly rebooted Linux creates a new IBSS instead of joining an existing one. Only when jiffies counter overflows after 5 minutes the IBSS can be successfully joined. Signed-off-by: Krzysztof Hałasa [edit commit message slightly] Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit f4e368a53c65f8acd462b2b038c18a21d30eaeb8 Author: Doug Smythies Date: Tue Jun 17 13:36:10 2014 -0700 intel_pstate: Correct rounding in busy calculation commit 51d211e9c334b9eca3505f4052afa660c3e0606b upstream. There was a mistake in the actual rounding portion this previous patch: f0fe3cd7e12d (intel_pstate: Correct rounding in busy calculation) such that the rounding was asymetric and incorrect. Severity: Not very serious, but can increase target pstate by one extra value. For real world work flows the issue should self correct (but I have no proof). It is the equivalent of different PID gains for positive and negative numbers. Examples: -3.000000 used to round to -4, rounds to -3 with this patch. -3.503906 used to round to -5, rounds to -4 with this patch. Fixes: f0fe3cd7e12d (intel_pstate: Correct rounding in busy calculation) Signed-off-by: Doug Smythies Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 15a446b98f735f427927a251e82fed0a5a59c9ee Author: Fabio Baltieri Date: Sun Jun 8 22:06:24 2014 +0100 hwmon: (ina2xx) Cast to s16 on shunt and current regs commit c0214f98943b1fe43f7be61b7782b0c8f0836f28 upstream. All devices supported by ina2xx are bidirectional and report the measured shunt voltage and power values as a signed 16 bit, but the current driver implementation caches all registers as u16, leading to an incorrect sign extension when reporting to userspace in ina2xx_get_value(). This patch fixes the problem by casting the signed registers to s16. Tested on an INA219. Signed-off-by: Fabio Baltieri Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit caa1bc98057da9435a67aa6e508469b4b0238615 Author: Ilya Dryomov Date: Tue Jun 10 13:53:29 2014 +0400 rbd: handle parent_overlap on writes correctly commit 9638556a276125553549fdfe349c464481ec2f39 upstream. The following check in rbd_img_obj_request_submit() rbd_dev->parent_overlap <= obj_request->img_offset allows the fall through to the non-layered write case even if both parent_overlap and obj_request->img_offset belong to the same RADOS object. This leads to data corruption, because the area to the left of parent_overlap ends up unconditionally zero-filled instead of being populated with parent data. Suppose we want to write 1M to offset 6M of image bar, which is a clone of foo@snap; object_size is 4M, parent_overlap is 5M: rbd_data..0000000000000001 ---------------------|----------------------|------------ | should be copyup'ed | should be zeroed out | write ... ---------------------|----------------------|------------ 4M 5M 6M parent_overlap obj_request->img_offset 4..5M should be copyup'ed from foo, yet it is zero-filled, just like 5..6M is. Given that the only striping mode kernel client currently supports is chunking (i.e. stripe_unit == object_size, stripe_count == 1), round parent_overlap up to the next object boundary for the purposes of the overlap check. Signed-off-by: Ilya Dryomov Reviewed-by: Josh Durgin Signed-off-by: Greg Kroah-Hartman commit 33e2582114901a0ad084a8d6f1a20e28a33243de Author: Alex Elder Date: Sat Apr 26 14:21:44 2014 +0400 rbd: use reference counts for image requests commit 0f2d5be792b0466b06797f637cfbb0f64dbb408c upstream. Each image request contains a reference count, but to date it has not actually been used. (I think this was just an oversight.) A recent report involving rbd failing an assertion shed light on why and where we need to use these reference counts. Every OSD request associated with an object request uses rbd_osd_req_callback() as its callback function. That function will call a helper function (dependent on the type of OSD request) that will set the object request's "done" flag if the object request if appropriate. If that "done" flag is set, the object request is passed to rbd_obj_request_complete(). In rbd_obj_request_complete(), requests are processed in sequential order. So if an object request completes before one of its predecessors in the image request, the completion is deferred. Otherwise, if it's a completing object's "turn" to be completed, it is passed to rbd_img_obj_end_request(), which records the result of the operation, accumulates transferred bytes, and so on. Next, the successor to this request is checked and if it is marked "done", (deferred) completion processing is performed on that request, and so on. If the last object request in an image request is completed, rbd_img_request_complete() is called, which (typically) destroys the image request. There is a race here, however. The instant an object request is marked "done" it can be provided (by a thread handling completion of one of its predecessor operations) to rbd_img_obj_end_request(), which (for the last request) can then lead to the image request getting torn down. And this can happen *before* that object has itself entered rbd_img_obj_end_request(). As a result, once it *does* enter that function, the image request (and even the object request itself) may have been freed and become invalid. All that's necessary to avoid this is to properly count references to the image requests. We tear down an image request's object requests all at once--only when the entire image request has completed. So there's no need for an image request to count references for its object requests. However, we don't want an image request to go away until the last of its object requests has passed through rbd_img_obj_callback(). In other words, we don't want rbd_img_request_complete() to necessarily result in the image request being destroyed, because it may get called before we've finished processing on all of its object requests. So the fix is to add a reference to an image request for each of its object requests. The reference can be viewed as representing an object request that has not yet finished its call to rbd_img_obj_callback(). That is emphasized by getting the reference right after assigning that as the image object's callback function. The corresponding release of that reference is done at the end of rbd_img_obj_callback(), which every image object request passes through exactly once. Signed-off-by: Alex Elder Reviewed-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit dd7ba80f4a3933c025e6adcf5f5d730181d91ab0 Author: Lukas Czerner Date: Wed Jun 11 12:28:43 2014 -0400 dm thin: update discard_granularity to reflect the thin-pool blocksize commit 09869de57ed2728ae3c619803932a86cb0e2c4f8 upstream. DM thinp already checks whether the discard_granularity of the data device is a factor of the thin-pool block size. But when using the dm-thin-pool's discard passdown support, DM thinp was not selecting the max of the underlying data device's discard_granularity and the thin-pool's block size. Update set_discard_limits() to set discard_granularity to the max of these values. This enables blkdev_issue_discard() to properly align the discards that are sent to the DM thin device on a full block boundary. As such each discard will now cover an entire DM thin-pool block and the block will be reclaimed. Reported-by: Zdenek Kabelac Signed-off-by: Lukas Czerner Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit e4b08895ac3f0b5c5eae0f33c76a93a617cdfb63 Author: Marcin Kraglak Date: Fri Jun 13 14:08:22 2014 +0200 Bluetooth: Allow change security level on ATT_CID in slave role commit 92d1372e1a9fec00e146b74e8b9ad7a385b9b37f upstream. Kernel supports SMP Security Request so don't block increasing security when we are slave. Signed-off-by: Marcin Kraglak Acked-by: Johan Hedberg Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 0d45819c973f83b1b4ef9bd92ffffe6083a7c526 Author: Johan Hedberg Date: Fri Jun 13 10:22:28 2014 +0300 Bluetooth: Fix locking of hdev when calling into SMP code commit c73f94b8c093a615ce80eabbde0ac6eb9abfe31a upstream. The SMP code expects hdev to be unlocked since e.g. crypto functions will try to (re)lock it. Therefore, we need to release the lock before calling into smp.c from mgmt.c. Without this we risk a deadlock whenever the smp_user_confirm_reply() function is called. Signed-off-by: Johan Hedberg Tested-by: Lukasz Rymanowski Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit dc3048374bf4a8becb7d8b2c962c02166d28c6f0 Author: Johan Hedberg Date: Tue Jun 10 14:05:57 2014 +0300 Bluetooth: Fix indicating discovery state when canceling inquiry commit 50143a433b70e3145bcf8a4a4e54f0c11bdee32b upstream. When inquiry is canceled through the HCI_Cancel_Inquiry command there is no Inquiry Complete event generated. Instead, all we get is the command complete for the HCI_Inquiry_Cancel command. This means that we must call the hci_discovery_set_state() function from the respective command complete handler in order to ensure that user space knows the correct discovery state. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 43db39a6db7aa14302eea088abf1d1d88e60d608 Author: Johan Hedberg Date: Tue Jun 10 09:54:24 2014 +0300 Bluetooth: Fix check for connection encryption commit e694788d73efe139b24f78b036deb97fe57fa8cb upstream. The conn->link_key variable tracks the type of link key in use. It is set whenever we respond to a link key request as well as when we get a link key notification event. These two events do not however always guarantee that encryption is enabled: getting a link key request and responding to it may only mean that the remote side has requested authentication but not encryption. On the other hand, the encrypt change event is a certain guarantee that encryption is enabled. The real encryption state is already tracked in the conn->link_mode variable through the HCI_LM_ENCRYPT bit. This patch fixes a check for encryption in the hci_conn_auth function to use the proper conn->link_mode value and thereby eliminates the chance of a false positive result. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 9a5fcacabde0fe11456f4a1e88072c01846cea25 Author: Johan Hedberg Date: Mon Jun 9 13:58:14 2014 +0300 Bluetooth: Fix SSP acceptor just-works confirmation without MITM commit ba15a58b179ed76a7e887177f2b06de12c58ec8f upstream. From the Bluetooth Core Specification 4.1 page 1958: "if both devices have set the Authentication_Requirements parameter to one of the MITM Protection Not Required options, authentication stage 1 shall function as if both devices set their IO capabilities to DisplayOnly (e.g., Numeric comparison with automatic confirmation on both devices)" So far our implementation has done user confirmation for all just-works cases regardless of the MITM requirements, however following the specification to the word means that we should not be doing confirmation when neither side has the MITM flag set. Signed-off-by: Johan Hedberg Tested-by: Szymon Janc Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 1b591538c49cf9bb29a3325d0990ccb3ac84ed8e Author: Thomas Hellstrom Date: Wed Jul 2 15:47:04 2014 +0200 drm/vmwgfx: Fix incorrect write to read-only register v2: commit 4e578080ed3262ed2c3985868539bc66218d25c0 upstream. Commit "drm/vmwgfx: correct fb_fix_screeninfo.line_length", while fixing a vmwgfx fbdev bug, also writes the pitch to a supposedly read-only register: SVGA_REG_BYTES_PER_LINE, while it should be (and also in fact is) written to SVGA_REG_PITCHLOCK. This patch is Cc'd stable because of the unknown effects writing to this register might have, particularly on older device versions. v2: Updated log message. Cc: Christopher Friedt Tested-by: Christopher Friedt Signed-off-by: Thomas Hellstrom Reviewed-by: Jakob Bornecrantz Signed-off-by: Greg Kroah-Hartman commit 1d7b7dfccfe9cd50f441d193b7ca9f811706ca70 Author: Jani Nikula Date: Mon Jun 9 18:24:34 2014 +0300 drm/i915: set backlight duty cycle after backlight enable for gen4 commit 2e7eeeb59a92d09144fdb7d2dc1af77a10a7945b upstream. For reasons I can't claim to fully understand gen4 seems to require backlight duty cycle setting after the backlight has been enabled, or else black screen follows. I don't have documentation for the correct sequence on gen4 either. Confirmed on Dell Latitude D630 and MacBook4,1. This fixes a regression introduced by commit b35684b8fa94e04f55fd38bf672b737741d2f9e2 Author: Jani Nikula Date: Thu Nov 14 12:13:41 2013 +0200 drm/i915: do full backlight setup at enable time Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=75791 Reported-and-tested-by: mcy@lm7.fr Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79423 Reported-and-tested-by: Marc Milgram Acked-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 87536bfea3d962fd0f2dcba1e5fc029d5c2b27d7 Author: Ville Syrjälä Date: Mon Jun 9 16:20:46 2014 +0300 drm/i915: Avoid div-by-zero when pixel_multiplier is zero commit 2b85886a5457f5c5dbcd32edbd4e6bba0f4e8678 upstream. On certain platforms pixel_multiplier is read out in .get_pipe_config(), but it also gets used to calculate the pixel clock in intel_sdvo_get_config(). If the pipe is disable but some SDVO outputs are active, we may end up dividing by zero in intel_sdvo_get_config(). To avoid the problem simply check for zero pixel_multiplier and skip the division. Another attempt at fixing this involved populating pixel_multiplier to 1 even for disabled pipes, but that triggered a WARN because SDVO_CMD_GET_CLOCK_RATE_MULT command failed and thus encoder_pixel_multiplier was left at zero and didn't match pipe_config->pixel_multiplier. The "divide by pixel_multiplier" operation got introduced here: commit 18442d08786472c63a0a80c27f92b033dffc26de Author: Ville Syrjälä Date: Fri Sep 13 16:00:08 2013 +0300 drm/i915: Fix port_clock and adjusted_mode.clock readout all over and it has caused a regression on certain machines since they would hit the div-by-zero during resume. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76520 Tested-by: Tim Richardson Reviewed-by: Daniel Vetter Signed-off-by: Ville Syrjälä Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 671ba13d0252680922f95374220e48a0e4324f8b Author: Ilia Mirkin Date: Sat Jun 7 15:39:45 2014 -0400 drm/gk208/gr: add missing registers to grctx init commit 255b329ca7f0e9b5fa6da3a68bb713684fe10305 upstream. This fixes hangs on GK208 which happen instantaneously on trying to use a geometry shader. Signed-off-by: Ilia Mirkin Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 01ffce838a7d34abd6cf7b4339fc229e1eed74a6 Author: Mario Kleiner Date: Wed Mar 19 08:12:51 2014 +0100 drm/nv50-/mc: fix kms pageflip events by reordering irq handling order. commit dcfb1009df3b4ad8d2e0779dd45b438629d6858a upstream. Whenever a single nouveau_mc_intr() main gpu irq-handler invocation was responsible for calling both, the vblank-irq handler (display engine irq) and kms-pageflip completion handler (from fifo irq), the order of invocation was wrong. nouveau_finish_flip() was called before drm_handle_vblank() for the vblank of pageflip completion, so the emitted pageflip event contained stale vblank count and timestamp from previous vblank. This caused failure in userspace to timestamp properly. Reorder order of invocation of engine irq handlers: Put NVDEV_ENGINE_DISP always on top, and thereby before NVDEV_ENGINE_FIFO, so that drm_handle_vblank() gets called to update vblank timestamps and count before potential pageflip events make use of that information. This works on nv-50 and later, where kms-pageflip completion triggers an irq either after a separate vblank irq, or both pageflip and vblank trigger one common irq invocation, but never before vblank irqs. v2 (Ben): - removed mods for nv04-nv40, it doesn't help there anyway - this is considered a hack, and a better solution should be found Signed-off-by: Mario Kleiner Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit dccabf3a51f63e41aa6c6625f9acd2201d03a6b9 Author: Alex Deucher Date: Wed Jul 2 14:10:19 2014 -0400 drm/radeon/cik: fix typo in EOP packet commit b397207b7475afa9df2f94541f978100ff1ea47e upstream. Volatile bit was in the wrong location. This bit is not used at the moment. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 333cc3bb9c362e329e2f3f3ffc56288f52fe5b48 Author: Alex Deucher Date: Tue Jul 1 12:11:31 2014 -0400 drm/radeon/dpm: fix vddci setup typo on cayman commit b0880e87c1fd038b84498944f52e52c3e86ebe59 upstream. We were using the vddc mask rather than the vddci mask. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=79071 May also fix: https://bugs.freedesktop.org/show_bug.cgi?id=69723 Noticed by: Dieter Nützel Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 1dec81d2ff5fe89b40ba7f075d41056d9d7d3cce Author: Alex Deucher Date: Tue Jul 1 12:07:33 2014 -0400 drm/radeon/dpm: fix typo in vddci setup for eg/btc commit e07929810f0a19ddd756558290c7d72827cbfcd9 upstream. We were using the vddc mask rather than the vddci mask. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=79071 Possibly also fixes: https://bugzilla.kernel.org/show_bug.cgi?id=68571 Noticed-by: Jonathan Howard Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit f7e9f1397eb3ebada6ff54b263991028970c07a4 Author: Marek Olšák Date: Tue May 27 02:56:36 2014 +0200 drm/radeon: don't allow RADEON_GEM_DOMAIN_CPU for command submission commit ec65da385d46f63740c1c9230b891a6dcbd64c71 upstream. It hangs the hardware. Signed-off-by: Marek Olšák Reviewed-by: Christian König Signed-off-by: Greg Kroah-Hartman commit 42004014feb3e44d491083f26f570e99a12523d8 Author: Alex Deucher Date: Tue May 27 16:40:51 2014 -0400 drm/radeon/atom: fix dithering on certain panels commit 642528355c694f5ed68f6bff9ff520326a249f99 upstream. We need to specify the encoder mode as LVDS for eDP when using the Crtc_Source atom table in order to properly set up the FMT hardware. bug: https://bugs.freedesktop.org/show_bug.cgi?id=73911 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 9c824b49e49e570933dd110a0fd8fe2d2928151c Author: Alex Deucher Date: Tue May 27 13:48:05 2014 -0400 drm/radeon/dp: fix lane/clock setup for dp 1.2 capable devices commit 3b6d9fd23e015b5397c438fd3cd74147d2c805b6 upstream. Only DCE5+ asics support DP 1.2. Noticed by ArtForz on IRC. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit e232e66d3dac705538007f92c36f990ffdde48b2 Author: Alex Deucher Date: Tue May 27 13:11:36 2014 -0400 drm/radeon: fix typo in radeon_connector_is_dp12_capable() commit af5d36539dfe043f1cf0f8b7334d6bb12cd14e75 upstream. We were checking the ext clock rather than the display clock. Noticed by ArtForz on IRC. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 8b9cd5bd86c72f327fa4b4f9bbd7715b12bafdf5 Author: Alex Deucher Date: Mon Apr 21 21:45:09 2014 -0400 drm/radeon: only apply hdmi bpc pll flags when encoder mode is hdmi commit 7d5ab3009a8ca777174f6f469277b3922d56fd4b upstream. May fix display issues with non-HDMI displays. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 06c9285bd091c31b24cab368dbc85469c0ee4dae Author: Mario Kleiner Date: Wed Jun 11 09:51:23 2014 +0200 drm/nouveau/kms: reference vblank for crtc during pageflip. commit ba124a41058b300a5464206d2d33803cc3dc82ec upstream. Need to drm_vblank_get/put() the crtc involved in a pending pageflip, or we might not get vblank irqs and updates of vblank counts and timestamps for pageflip events and flip completion. Signed-off-by: Mario Kleiner Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 4091d550aa42321436e3e995baf0b410dd30aaaa Author: Mario Kleiner Date: Wed May 28 05:22:18 2014 +0200 drm/nouveau/disp/nv04-nv40: abort scanoutpos query on vga analog. commit e291af3f2259e9e105dfd72416fd5796513791a4 upstream. nv04_disp_scanoutpos() must abort to trigger simple timestamping fallback if vtotal/htotal regs return zero. This happens if the output isn't a digital output, but a vga analog output, as the regs don't get initialized in that case. Fixes timestamping failure on nv-40 and earlier with vga output. Signed-off-by: Mario Kleiner Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 2f47f0fabeb6a00537de011cd4d3aacdf3e8cadc Author: Mario Kleiner Date: Tue May 13 00:42:08 2014 +0200 drm/nouveau/kms/nv04-nv40: fix pageflip events via special case. commit af4870e406126b7ac0ae7c7ce5751f25ebe60f28 upstream. Cards with nv04 display engine can't reliably use vblank counts and timestamps computed via drm_handle_vblank(), as the function gets invoked after sending the pageflip events. Fix this by defaulting to the old crtcid = -1 fallback path on <= NV-50 cards, and only using the precise path on NV-50 and later. Signed-off-by: Mario Kleiner Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 2ef209f2c98db4975aed7a2aa560040b6e263099 Author: Alex Deucher Date: Mon May 19 14:04:43 2014 -0400 vgaswitcheroo: switch the mux to the igp on power down when runpm is enabled commit f2bc561610962693be61425cf913778586d8f9c1 upstream. Avoids blank screens on muxed systems when runpm is active. bug: https://bugs.freedesktop.org/show_bug.cgi?id=75917 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 8b1666574453b5758688c81ae52bb77ec789545f Author: Thomas Petazzoni Date: Thu May 22 14:56:52 2014 +0200 mtd: pxa3xx_nand: make the driver work on big-endian systems commit b7e460624f0f3c31150f3b09e75b0d009e22ba5f upstream. The pxa3xx_nand driver currently uses __raw_writel() and __raw_readl() to access I/O registers. However, those functions do not do any endianness swapping, which means that they won't work when the CPU runs in big-endian but the I/O registers are little endian, which is the common situation for ARM systems running big endian. Since __raw_writel() and __raw_readl() do not include any memory barriers and the pxa3xx_nand driver can only be compiled for ARM platforms, the closest I/o accessors functions that do endianess swapping are writel_relaxed() and readl_relaxed(). This patch has been verified to work on Armada XP GP: without the patch, the NAND is not detected when the kernel runs big endian while it is properly detected when the kernel runs little endian. With the patch applied, the NAND is properly detected in both situations (little and big endian). Signed-off-by: Thomas Petazzoni Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman commit d2c672058a57e1640205a2afe04fecff75161e56 Author: pekon gupta Date: Thu Mar 20 18:49:58 2014 +0530 mtd: nand: omap: fix BCHx ecc.correct to return detected bit-flips in erased-page commit f306e8c3b667632952f1a4a74ffb910bbc06255f upstream. fixes: commit 62116e5171e00f85a8d53f76e45b84423c89ff34 mtd: nand: omap2: Support for hardware BCH error correction. In omap_elm_correct_data(), if bitflip_count in an erased-page is within the correctable limit (< ecc.strength), then it is not indicated back to the caller ecc->read_page(). This mis-guides upper layers like MTD and UBIFS layer to assume erased-page as perfectly clean and use it for writing even if actual bitflip_count was dangerously high (bitflip_count > mtd->bitflip_threshold). This patch fixes this above issue, by returning 'stats' to caller ecc->read_page() under all scenarios. Reported-by: Brian Norris Signed-off-by: Pekon Gupta Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman commit fb4b756348079c378874d232f0f3664be6551aeb Author: Pekon Gupta Date: Tue May 6 09:41:32 2014 +0530 mtd: eLBC NAND: fix subpage write support commit f034d87def51f026b735d1e2877e9387011b2ba3 upstream. As subpage write is enabled by default for all drivers, nand_write_subpage_hwecc causes a crash if the driver did not register ecc->hwctl or ecc->calculate. This behavior was introduced in commit 837a6ba4f3b6d23026674e6af6b6849a4634fff9 "mtd: nand: subpage write support for hardware based ECC schemes". This fixes a crash by emulating subpage write support by padding sub-page data with 0xff on either sides to make it full page compatible. Reported-by: Helmut Schaa Tested-by: Helmut Schaa Signed-off-by: Pekon Gupta Reviewed-by: Scott Wood Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman commit cbb5c309f56157e7010c40915b294151e83bd118 Author: Stanislaw Gruszka Date: Mon Jun 16 18:45:15 2014 +0200 rt2x00: fix rfkill regression on rt2500pci commit 616a8394b5df8c88f4dd416f4527439a4e365034 upstream. As reported by Niels, starting rfkill polling during device probe (commit e2bc7c5, generally sane change) broke rfkill on rt2500pci device. I considered that bug as some initalization issue, which should be fixed on rt2500pci specific code. But after several attempts (see bug report for details) we fail to find working solution. Hence I decided to revert to old behaviour on rt2500pci to fix regression. Additionally patch also unregister rfkill on device remove instead of ifconfig down, what was another issue introduced by bad commit. Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=73821 Fixes: e2bc7c5f3cb8 ("rt2x00: Fix rfkill_polling register function.") Bisected-by: Niels Reported-and-tested-by: Niels Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 793985a2390311c7a321254c220a25a9e57aa610 Author: Stanislaw Gruszka Date: Tue Jun 10 12:51:06 2014 +0200 rt2x00: disable TKIP on USB commit 8edcb0ba0d56f5914eef11eda6db8bfe74eb9ca8 upstream. On USB we can not get atomically TKIP key. We have to disable support for TKIP acceleration on USB hardware to avoid bug as showed bellow. [ 860.827243] BUG: scheduling while atomic: hostapd/3397/0x00000002 [ 860.827280] Call Trace: [ 860.827282] [] dump_stack+0x4d/0x66 [ 860.827284] [] __schedule_bug+0x47/0x55 [ 860.827285] [] __schedule+0x733/0x7b0 [ 860.827287] [] schedule+0x29/0x70 [ 860.827289] [] schedule_timeout+0x15a/0x2b0 [ 860.827291] [] ? ftrace_raw_event_tick_stop+0xc0/0xc0 [ 860.827294] [] ? __module_text_address+0x12/0x70 [ 860.827296] [] wait_for_completion_timeout+0xb3/0x140 [ 860.827298] [] ? wake_up_state+0x20/0x20 [ 860.827301] [] usb_start_wait_urb+0x7d/0x150 [ 860.827303] [] usb_control_msg+0xc5/0x110 [ 860.827305] [] rt2x00usb_vendor_request+0xc6/0x160 [rt2x00usb] [ 860.827307] [] rt2x00usb_vendor_req_buff_lock+0x75/0x150 [rt2x00usb] [ 860.827309] [] rt2x00usb_vendor_request_buff+0xa3/0xe0 [rt2x00usb] [ 860.827311] [] rt2x00usb_register_multiread+0x33/0x40 [rt2800usb] [ 860.827314] [] rt2800_get_tkip_seq+0x39/0x50 [rt2800lib] [ 860.827321] [] ieee80211_get_key+0x218/0x2a0 [mac80211] [ 860.827322] [] ? __nlmsg_put+0x6c/0x80 [ 860.827329] [] nl80211_get_key+0x22e/0x360 [cfg80211] Reported-and-tested-by: Peter Wu Reported-and-tested-by: Pontus Fuchs Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit d4d3b27333ded534e1cab26a33b7e4f1163e8ff9 Author: Michal Nazarewicz Date: Tue Jun 17 17:47:41 2014 +0200 usb: gadget: f_fs: fix NULL pointer dereference when there are no strings commit f0688c8b81d2ea239c3fb0b848f623b579238d99 upstream. If the descriptors do not need any strings and user space sends empty set of strings, the ffs->stringtabs field remains NULL. Thus *ffs->stringtabs in functionfs_bind leads to a NULL pointer dereferenece. The bug was introduced by commit [fd7c9a007f: “use usb_string_ids_n()”]. While at it, remove double initialisation of lang local variable in that function. ffs->strings_count does not need to be checked in any way since in the above scenario it will remain zero and usb_string_ids_n() is a no-operation when colled with 0 argument. Signed-off-by: Michal Nazarewicz Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 28c5980b5494b8163d6cba5a5007b6ec7e63de66 Author: Michal Nazarewicz Date: Fri Jun 13 15:38:04 2014 +0200 usb: gadget: f_fs: resurect usb_functionfs_descs_head structure commit 09122141785348bf9539762a5f5dbbae3761c783 upstream. Even though usb_functionfs_descs_head structure is now deprecated, it has been used by some user space tools. Its removel in commit [ac8dde1: “Add flags to descriptors block”] was an oversight leading to build breakage for such tools. Bring it back so that old user space tools can still be build without problems on newer kernel versions. Reported-by: Lad, Prabhakar Reported-by: Krzysztof Opasiak Signed-off-by: Michal Nazarewicz Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit de49c5f1702ce48835fcf9e13e11314ec9f1be28 Author: Johan Hovold Date: Thu Jun 5 16:05:52 2014 +0200 USB: ftdi_sio: fix null deref at port probe commit aea1ae8760314e072bf1b773521e9de5d5dda10d upstream. Fix NULL-pointer dereference when probing an interface with no endpoints. These devices have two bulk endpoints per interface, but this avoids crashing the kernel if a user forces a non-FTDI device to be probed. Note that the iterator variable was made unsigned in order to avoid a maybe-uninitialized compiler warning for ep_desc after the loop. Fixes: 895f28badce9 ("USB: ftdi_sio: fix hi-speed device packet size calculation") Reported-by: Mike Remski Tested-by: Mike Remski Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 0d845a46caab134b9ffc05e86d1acacdde353c34 Author: Peter Chen Date: Wed Jul 2 12:16:31 2014 +0800 usb: chipidea: udc: delete td from req's td list at ep_dequeue commit e4adcff09ca39ecbcc4851d40d0f0a5458e7b77a upstream. We need to delete un-finished td from current request's td list at ep_dequeue API, otherwise, this non-user td will be remained at td list before this request is freed. So if we do ep_queue-> ep_dequeue->ep_queue sequence, when the complete interrupt for the second ep_queue comes, we search td list for this request, the first td (added by the first ep_queue) will be handled, and its status is still active, so we will consider the this transfer still not be completed, but in fact, it has completed. It causes the peripheral side considers it never receives current data for this transfer. We met this problem when do "Error Recovery Test - Device Configured" test item for USBCV2 MSC test, the host has never received ACK for the IN token for CSW due to peripheral considers it does not get this CBW, the USBCV test log like belows: -------------------------------------------------------------------------- INFO Issuing BOT MSC Reset, reset should always succeed INFO Retrieving status on CBW endpoint INFO CBW endpoint status = 0x0 INFO Retrieving status on CSW endpoint INFO CSW endpoint status = 0x0 INFO Issuing required command (Test Unit Ready) to verify device has recovered INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW Bulk Request timed out! ERROR Failed CSW phase : should have been success or stall FAIL (5.3.4) The CSW status value must be 0x00, 0x01, or 0x02. ERROR BOTCommonMSCRequest failed: error=80004000 Cc: Andrzej Pietrasiewicz Signed-off-by: Peter Chen Signed-off-by: Greg Kroah-Hartman commit 6ea07d9b040bd42f4398e413a09d8f5795756886 Author: Ezequiel Garcia Date: Mon Jun 23 15:34:22 2014 -0300 usb: musb: Fix panic upon musb_am335x module removal commit 7adb5c876e9c0677078a1e1094c6eafd29c30b74 upstream. At probe time, the musb_am335x driver register its childs by calling of_platform_populate(), which registers all childs in the devicetree hierarchy recursively. On the other side, the driver's remove() function uses of_device_unregister() to remove each child of musb_am335x's. However, when musb_dsps is loaded, its devices are attached to the musb_am335x device as musb_am335x childs. Hence, musb_am335x remove() will attempt to unregister the devices registered by musb_dsps, which produces a kernel panic. In other words, the childs in the "struct device" hierarchy are not the same as the childs in the "devicetree" hierarchy. Ideally, we should enforce the removal of the devices registered by musb_am335x *only*, instead of all its child devices. However, because of the recursive nature of of_platform_populate, this doesn't seem possible. Therefore, as the only solution at hand, this commit disables musb_am335x driver removal capability, preventing it from being ever removed. This was originally suggested by Sebastian Siewior: https://www.mail-archive.com/linux-omap@vger.kernel.org/msg104946.html And for reference, here's the panic upon module removal: musb-hdrc musb-hdrc.0.auto: remove, state 4 usb usb1: USB disconnect, device number 1 musb-hdrc musb-hdrc.0.auto: USB bus 1 deregistered Unable to handle kernel NULL pointer dereference at virtual address 0000008c pgd = de11c000 [0000008c] *pgd=9e174831, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] ARM Modules linked in: musb_am335x(-) musb_dsps musb_hdrc usbcore usb_common CPU: 0 PID: 623 Comm: modprobe Not tainted 3.15.0-rc4-00001-g24efd13 #69 task: de1b7500 ti: de122000 task.ti: de122000 PC is at am335x_shutdown+0x10/0x28 LR is at am335x_shutdown+0xc/0x28 pc : [] lr : [] psr: a0000013 sp : de123df8 ip : 00000004 fp : 00028f00 r10: 00000000 r9 : de122000 r8 : c000e6c4 r7 : de0e3c10 r6 : de0e3800 r5 : de624010 r4 : de1ec750 r3 : de0e3810 r2 : 00000000 r1 : 00000001 r0 : 00000000 Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 9e11c019 DAC: 00000015 Process modprobe (pid: 623, stack limit = 0xde122240) Stack: (0xde123df8 to 0xde124000) 3de0: de0e3810 bf054488 3e00: bf05444c de624010 60000013 bf043650 000012fc de624010 de0e3810 bf043a20 3e20: de0e3810 bf04b240 c0635b88 c02ca37c c02ca364 c02c8db0 de1b7500 de0e3844 3e40: de0e3810 c02c8e28 c0635b88 de02824c de0e3810 c02c884c de0e3800 de0e3810 3e60: de0e3818 c02c5b20 bf05417c de0e3800 de0e3800 c0635b88 de0f2410 c02ca838 3e80: bf05417c de0e3800 bf055438 c02ca8cc de0e3c10 bf054194 de0e3c10 c02ca37c 3ea0: c02ca364 c02c8db0 de1b7500 de0e3c44 de0e3c10 c02c8e28 c0635b88 de02824c 3ec0: de0e3c10 c02c884c de0e3c10 de0e3c10 de0e3c18 c02c5b20 de0e3c10 de0e3c10 3ee0: 00000000 bf059000 a0000013 c02c5bc0 00000000 bf05900c de0e3c10 c02c5c48 3f00: de0dd0c0 de1ec970 de0f2410 bf05929c de0f2444 bf05902c de0f2410 c02ca37c 3f20: c02ca364 c02c8db0 bf05929c de0f2410 bf05929c c02c94c8 bf05929c 00000000 3f40: 00000800 c02c8ab4 bf0592e0 c007fc40 c00dd820 6273756d 336d615f 00783533 3f60: c064a0ac de1b7500 de122000 de1b7500 c000e590 00000001 c000e6c4 c0060160 3f80: 00028e70 00028e70 00028ea4 00000081 60000010 00028e70 00028e70 00028ea4 3fa0: 00000081 c000e500 00028e70 00028e70 00028ea4 00000800 becb59f8 00027608 3fc0: 00028e70 00028e70 00028ea4 00000081 00000001 00000001 00000000 00028f00 3fe0: b6e6b6f0 becb59d4 000160e8 b6e6b6fc 60000010 00028ea4 00000000 00000000 [] (am335x_shutdown) from [] (dsps_musb_exit+0x3c/0x4c [musb_dsps]) [] (dsps_musb_exit [musb_dsps]) from [] (musb_shutdown+0x80/0x90 [musb_hdrc]) [] (musb_shutdown [musb_hdrc]) from [] (musb_remove+0x24/0x68 [musb_hdrc]) [] (musb_remove [musb_hdrc]) from [] (platform_drv_remove+0x18/0x1c) [] (platform_drv_remove) from [] (__device_release_driver+0x70/0xc8) [] (__device_release_driver) from [] (device_release_driver+0x20/0x2c) [] (device_release_driver) from [] (bus_remove_device+0xdc/0x10c) [] (bus_remove_device) from [] (device_del+0x104/0x198) [] (device_del) from [] (platform_device_del+0x14/0x9c) [] (platform_device_del) from [] (platform_device_unregister+0xc/0x20) [] (platform_device_unregister) from [] (dsps_remove+0x18/0x38 [musb_dsps]) [] (dsps_remove [musb_dsps]) from [] (platform_drv_remove+0x18/0x1c) [] (platform_drv_remove) from [] (__device_release_driver+0x70/0xc8) [] (__device_release_driver) from [] (device_release_driver+0x20/0x2c) [] (device_release_driver) from [] (bus_remove_device+0xdc/0x10c) [] (bus_remove_device) from [] (device_del+0x104/0x198) [] (device_del) from [] (device_unregister+0xc/0x20) [] (device_unregister) from [] (of_remove_populated_child+0xc/0x14 [musb_am335x]) [] (of_remove_populated_child [musb_am335x]) from [] (device_for_each_child+0x44/0x70) [] (device_for_each_child) from [] (am335x_child_remove+0x18/0x30 [musb_am335x]) [] (am335x_child_remove [musb_am335x]) from [] (platform_drv_remove+0x18/0x1c) [] (platform_drv_remove) from [] (__device_release_driver+0x70/0xc8) [] (__device_release_driver) from [] (driver_detach+0xb4/0xb8) [] (driver_detach) from [] (bus_remove_driver+0x4c/0xa0) [] (bus_remove_driver) from [] (SyS_delete_module+0x128/0x1cc) [] (SyS_delete_module) from [] (ret_fast_syscall+0x0/0x48) Fixes: 97238b35d5bb ("usb: musb: dsps: use proper child nodes") Acked-by: George Cherian Signed-off-by: Ezequiel Garcia Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit a5d6bd2499fb860e7eaa537973fddcc9d8157491 Author: Thomas Gleixner Date: Fri Jun 20 23:41:24 2014 +0200 usb: musb: Ensure that cppi41 timer gets armed on premature DMA TX irq commit c58d80f523ffc15ef4d062fc7aeb03793fe39701 upstream. Some TI chips raise the DMA complete interrupt before the actual transfer has been completed. The code tries to busy wait for a few microseconds and if that fails it arms an hrtimer to recheck. So far so good, but that has the following issue: CPU 0 CPU1 start_next_transfer(RQ1); DMA interrupt if (premature_irq(RQ1)) if (!hrtimer_active(timer)) hrtimer_start(timer); hrtimer expires timer->state = CALLBACK_RUNNING; timer->fn() cppi41_recheck_tx_req() complete_request(RQ1); if (requests_pending()) start_next_transfer(RQ2); DMA interrupt if (premature_irq(RQ2)) if (!hrtimer_active(timer)) hrtimer_start(timer); timer->state = INACTIVE; The premature interrupt of request2 on CPU1 does not arm the timer and therefor the request completion never happens because it checks for !hrtimer_active(). hrtimer_active() evaluates: timer->state != HRTIMER_STATE_INACTIVE which of course evaluates to true in the above case as timer->state is CALLBACK_RUNNING. That's clearly documented: * A timer is active, when it is enqueued into the rbtree or the * callback function is running or it's in the state of being migrated * to another cpu. But that's not what the code wants to check. The code wants to check whether the timer is queued, i.e. whether its armed and waiting for expiry. We have a helper function for this: hrtimer_is_queued(). This evaluates: timer->state & HRTIMER_STATE_QUEUED So in the above case this evaluates to false and therefor forces the DMA interrupt on CPU1 to call hrtimer_start(). Use hrtimer_is_queued() instead of hrtimer_active() and evrything is good. Reported-by: Torben Hohn Signed-off-by: Thomas Gleixner Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 7795e81c2a934effe205973a31eaacdc8aae40f7 Author: Linus Walleij Date: Tue Jun 10 10:54:16 2014 +0200 usb: musb: ux500: don't propagate the OF node commit 82363cf2eeafeea6ba88849f5e2febdc8a05943f upstream. There is a regression in the upcoming v3.16-rc1, that is caused by a problem that has been around for a while but now finally hangs the system. The bootcrawl looks like this: pinctrl-nomadik soc:pinctrl: pin GPIO256_AF28 already requested by a03e0000.usb_per5; cannot claim for musb-hdrc.0.auto pinctrl-nomadik soc:pinctrl: pin-256 (musb-hdrc.0.auto) status -22 pinctrl-nomadik soc:pinctrl: could not request pin 256 (GPIO256_AF28) from group usb_a_1 on device pinctrl-nomadik musb-hdrc musb-hdrc.0.auto: Error applying setting, reverse things back HS USB OTG: no transceiver configured musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 platform musb-hdrc.0.auto: Driver musb-hdrc requests probe deferral (...) The ux500 MUSB driver propagates the OF node to the dynamically created musb-hdrc device, which is incorrect as it makes the OF core believe there are two devices spun from the very same DT node, which confuses other parts of the device core, notably the pin control subsystem, which will try to apply all the pin control settings also to the HDRC device as it gets instantiated. (The OMAP2430 for example, does not set the of_node member.) Cc: Arnd Bergmann Acked-by: Lee Jones Signed-off-by: Linus Walleij Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit e8a9ee4264c3b06a1cfb5dedacb538d6be95ba74 Author: Bjørn Mork Date: Fri Jun 6 17:25:56 2014 +0200 usb: option: add/modify Olivetti Olicard modems commit b0ebef36e93703e59003ad6a1a20227e47714417 upstream. Adding a couple of Olivetti modems and blacklisting the net function on a couple which are already supported. Reported-by: Lars Melin Signed-off-by: Bjørn Mork Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit bba6435b4ed96f13f3786536fb66a567e0bb669f Author: Oliver Neukum Date: Tue May 20 16:27:40 2014 +0200 USB: option: add device ID for SpeedUp SU9800 usb 3g modem commit 1cab4c68e339086cdaff7535848e878e8f261fca upstream. Reported by Alif Mubarak Ahmad: This device vendor and product id is 1c9e:9800 It is working as serial interface with generic usbserial driver. I thought it is more suitable to use usbserial option driver, which has better capability distinguishing between modem serial interface and micro sd storage interface. [ johan: style changes ] Signed-off-by: Oliver Neukum Tested-by: Alif Mubarak Ahmad Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 7c2455026974c841a85ba2ae5c0d48e845871735 Author: Wang, Yu Date: Tue Jun 24 17:14:44 2014 +0300 xhci: Fix runtime suspended xhci from blocking system suspend. commit d6236f6d1d885aa19d1cd7317346fe795227a3cc upstream. The system suspend flow as following: 1, Freeze all user processes and kenrel threads. 2, Try to suspend all devices. 2.1, If pci device is in RPM suspended state, then pci driver will try to resume it to RPM active state in the prepare stage. 2.2, xhci_resume function calls usb_hcd_resume_root_hub to queue two workqueue items to resume usb2&usb3 roothub devices. 2.3, Call suspend callbacks of devices. 2.3.1, All suspend callbacks of all hcd's children, including roothub devices are called. 2.3.2, Finally, hcd_pci_suspend callback is called. Due to workqueue threads were already frozen in step 1, the workqueue items can't be scheduled, and the roothub devices can't be resumed in this flow. The HCD_FLAG_WAKEUP_PENDING flag which is set in usb_hcd_resume_root_hub won't be cleared. Finally, hcd_pci_suspend will return -EBUSY, and system suspend fails. The reason why this issue doesn't show up very often is due to that choose_wakeup will be called in step 2.3.1. In step 2.3.1, if udev->do_remote_wakeup is not equal to device_may_wakeup(&udev->dev), then udev will resume to RPM active for changing the wakeup settings. This has been a lucky hit which hides this issue. For some special xHCI controllers which have no USB2 port, then roothub will not match hub driver due to probe failed. Then its do_remote_wakeup will be set to zero, and we won't be as lucky. xhci driver doesn't need to resume roothub devices everytime like in the above case. It's only needed when there are pending event TRBs. This patch should be back-ported to kernels as old as 3.2, that contains the commit f69e3120df82391a0ee8118e0a156239a06b2afb "USB: XHCI: resume root hubs when the controller resumes" Signed-off-by: Wang, Yu Acked-by: Alan Stern [use readl() instead of removed xhci_readl(), reword commit message -Mathias] Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 8f4f6a9e1124eca6a4b192c8cb1db56e83da4379 Author: Mathias Nyman Date: Tue Jun 24 17:14:41 2014 +0300 xhci: correct burst count field for isoc transfers on 1.0 xhci hosts commit 3213b151387df0b95f4eada104f68eb1c1409cb3 upstream. The transfer burst count (TBC) field in xhci 1.0 hosts should be set to the number of bursts needed to transfer all packets in a isoc TD. Supported values are 0-2 (1 to 3 bursts per service interval). Formula for TBC calculation is given in xhci spec section 4.11.2.3: TBC = roundup( Transfer Descriptor Packet Count / Max Burst Size +1 ) - 1 This patch should be applied to stable kernels since 3.0 that contain the commit 5cd43e33b9519143f06f507dd7cbee6b7a621885 "xhci 1.0: Set transfer burst count field." Suggested-by: ShiChun Ma Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit a82d63ba320abc0e13b8354227918db3785c968c Author: Mathias Nyman Date: Tue Jun 24 17:14:40 2014 +0300 xhci: Use correct SLOT ID when handling a reset device command commit 6fcfb0d682a8212d321a6131adc94daf0905992a upstream. Command completion events normally include command completion status, SLOT_ID, and a pointer to the original command. Reset device command completion SLOT_ID may be zero according to xhci specs 4.6.11. VIA controllers set the SLOT_ID to zero, triggering a WARN_ON in the command completion handler. Use the SLOT ID found from the original command instead. This patch should be applied to stable kernels since 3.13 that contain the commit 20e7acb13ff48fbc884d5918c3697c27de63922a "xhci: use completion event's slot id rather than dig it out of command" Reported-by: Saran Neti Tested-by: Saran Neti Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 5b827636a4492d98c6cb66f68c567cd45f683264 Author: Paolo Bonzini Date: Wed Jun 4 13:34:58 2014 +0200 virtio-scsi: fix various bad behavior on aborted requests commit 8faeb529b2dabb9df691d614dda18910a43d05c9 upstream. Even though the virtio-scsi spec guarantees that all requests related to the TMF will have been completed by the time the TMF itself completes, the request queue's callback might not have run yet. This causes requests to be completed more than once, and as a result triggers a variety of BUGs or oopses. Signed-off-by: Paolo Bonzini Reviewed-by: Venkatesh Srinivas Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit 2f0ca22f63025abeb922392b927b68d8831b251e Author: Ulrich Obergfell Date: Wed Jun 4 13:34:57 2014 +0200 scsi_error: fix invalid setting of host byte commit 8922a908908ff947f1f211e07e2e97f1169ad3cb upstream. After scsi_try_to_abort_cmd returns, the eh_abort_handler may have already found that the command has completed in the device, causing the host_byte to be nonzero (e.g. it could be DID_ABORT). When this happens, ORing DID_TIME_OUT into the host byte will corrupt the result field and initiate an unwanted command retry. Fix this by using set_host_byte instead, following the model of commit 2082ebc45af9c9c648383b8cde0dc1948eadbf31. Signed-off-by: Ulrich Obergfell [Fix all instances according to review comments. - Paolo] Signed-off-by: Paolo Bonzini Signed-off-by: Christoph Hellwig Reviewed-by: Ewan D. Milne Reviewed-by: Hannes Reinecke Signed-off-by: Greg Kroah-Hartman commit b63cf1accc078931f5f9bb2c8ac23365db388ee0 Author: Paolo Bonzini Date: Wed Jun 4 13:34:56 2014 +0200 virtio-scsi: avoid cancelling uninitialized work items commit cdda0e5acbb78f7b777049f8c27899e5c5bb368f upstream. Calling the workqueue interface on uninitialized work items isn't a good idea even if they're zeroed. It's not failing catastrophically only through happy accidents. Signed-off-by: Paolo Bonzini Reviewed-by: Stefan Hajnoczi Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit 9d2da49acf75f2c43847500f279fd68d802aabd4 Author: Brian King Date: Fri May 23 10:52:11 2014 -0500 ibmvscsi: Add memory barriers for send / receive commit 7114aae02742d6b5c5a0d39a41deb61d415d3717 upstream. Add a memory barrier prior to sending a new command to the VIOS to ensure the VIOS does not receive stale data in the command buffer. Also add a memory barrier when processing the CRQ for completed commands. Signed-off-by: Brian King Acked-by: Nathan Fontenot Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit 74dcc3a7d57ffab9ab0f7dd7f064f83868e61895 Author: Brian King Date: Fri May 23 10:52:10 2014 -0500 ibmvscsi: Abort init sequence during error recovery commit 9ee755974bea2f9880e517ec985dc9dede1b3a36 upstream. If a CRQ reset is triggered for some reason while in the middle of performing VSCSI adapter initialization, we don't want to call the done function for the initialization MAD commands as this will only result in two threads attempting initialization at the same time, resulting in failures. Signed-off-by: Brian King Acked-by: Nathan Fontenot Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman