commit 89e419960fb6a260f6a112821507d516117d5aa1 Author: Greg Kroah-Hartman Date: Mon Aug 3 09:30:08 2015 -0700 Linux 4.1.4 commit eee18465135ca687330666ce1886603c3c265ae5 Author: Kirill A. Shutemov Date: Mon Jul 20 14:29:58 2015 -0700 x86/mpx: Do not set ->vm_ops on MPX VMAs commit a89652769470d12cd484ee3d3f7bde0742be8d96 upstream. MPX setups private anonymous mapping, but uses vma->vm_ops too. This can confuse core VM, as it relies on vm->vm_ops to distinguish file VMAs from anonymous. As result we will get SIGBUS, because handle_pte_fault() thinks it's file VMA without vm_ops->fault and it doesn't know how to handle the situation properly. Let's fix that by not setting ->vm_ops. We don't really need ->vm_ops here: MPX VMA can be detected with VM_MPX flag. And vma_merge() will not merge MPX VMA with non-MPX VMA, because ->vm_flags won't match. The only thing left is name of VMA. I'm not sure if it's part of ABI, or we can just drop it. The patch keep it by providing arch_vma_name() on x86. Signed-off-by: Kirill A. Shutemov Signed-off-by: Dave Hansen Cc: Andy Lutomirski Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: dave@sr71.net Link: http://lkml.kernel.org/r/20150720212958.305CC3E9@viggo.jf.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit c86df9fa76f914d84e02caf2aaf11a22ca1820c2 Author: Kirill A. Shutemov Date: Mon Jul 6 23:18:37 2015 +0300 mm: avoid setting up anonymous pages into file mapping commit 6b7339f4c31ad69c8e9c0b2859276e22cf72176d upstream. Reading page fault handler code I've noticed that under right circumstances kernel would map anonymous pages into file mappings: if the VMA doesn't have vm_ops->fault() and the VMA wasn't fully populated on ->mmap(), kernel would handle page fault to not populated pte with do_anonymous_page(). Let's change page fault handler to use do_anonymous_page() only on anonymous VMA (->vm_ops == NULL) and make sure that the VMA is not shared. For file mappings without vm_ops->fault() or shred VMA without vm_ops, page fault on pte_none() entry would lead to SIGBUS. Signed-off-by: Kirill A. Shutemov Acked-by: Oleg Nesterov Cc: Andrew Morton Cc: Willy Tarreau Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bf94e2202c008de5ebb87e6f5887aba5b9aa8152 Author: Linus Torvalds Date: Thu Jul 9 11:20:01 2015 -0700 Fix firmware loader uevent buffer NULL pointer dereference commit 6f957724b94cb19f5c1c97efd01dd4df8ced323c upstream. The firmware class uevent function accessed the "fw_priv->buf" buffer without the proper locking and testing for NULL. This is an old bug (looks like it goes back to 2012 and commit 1244691c73b2: "firmware loader: introduce firmware_buf"), but for some reason it's triggering only now in 4.2-rc1. Shuah Khan is trying to bisect what it is that causes this to trigger more easily, but in the meantime let's just fix the bug since others are hitting it too (at least Ingo reports having seen it as well). Reported-and-tested-by: Shuah Khan Acked-by: Ming Lei Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 206f4fba0c512a45a7cc547ca7388a4e2d7c9c03 Author: Joe Perches Date: Thu Mar 26 20:47:10 2015 -0700 hpfs: hpfs_error: Remove static buffer, use vsprintf extension %pV instead commit a28e4b2b18ccb90df402da3f21e1a83c9d4f8ec1 upstream. Removing unnecessary static buffers is good. Use the vsprintf %pV extension instead. Signed-off-by: Joe Perches Signed-off-by: Mikulas Patocka Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 53c34bd0491cadbe4cbc211327f608ebc8ba4eaa Author: Sanidhya Kashyap Date: Sat Mar 21 12:57:50 2015 -0400 hpfs: kstrdup() out of memory handling commit ce657611baf902f14ae559ce4e0787ead6712067 upstream. There is a possibility of nothing being allocated to the new_opts in case of memory pressure, therefore return ENOMEM for such case. Signed-off-by: Sanidhya Kashyap Signed-off-by: Mikulas Patocka Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit abf09a2bc0b62809acf20486190071696f5f1d7b Author: Szabolcs Nagy Date: Wed Jul 1 23:08:10 2015 +0100 ARM: 8397/1: fix vdsomunge not to depend on glibc specific error.h commit 13ee9fdba96577eb1583dcd7b15767ef623fae12 upstream. If the host toolchain is not glibc based then the arm kernel build fails with arch/arm/vdso/vdsomunge.c:53:19: fatal error: error.h: No such file or directory error.h is a glibc only header (ie not available in musl, newlib and bsd libcs). Changed the error reporting to standard conforming code to avoid depending on specific C implementations. Signed-off-by: Szabolcs Nagy Acked-by: Will Deacon Fixes: 8512287a8165 ("ARM: 8330/1: add VDSO user-space code") Signed-off-by: Nathan Lynch Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit ec5ea3004ddc46c09c6805119cedb7b8f516b997 Author: Stephen Boyd Date: Fri Jun 19 21:37:56 2015 +0100 ARM: 8393/1: smp: Fix suspicious RCU usage with ipi tracepoints commit 398f74569cebbf06bc6b069442bcd0e9616ca465 upstream. John Stultz reports an RCU splat on boot with ARM ipi trace events enabled. =============================== [ INFO: suspicious RCU usage. ] 4.1.0-rc7-00033-gb5bed2f #153 Not tainted ------------------------------- include/trace/events/ipi.h:68 suspicious rcu_dereference_check() usage! other info that might help us debug this: RCU used illegally from idle CPU! rcu_scheduler_active = 1, debug_locks = 0 RCU used illegally from extended quiescent state! no locks held by swapper/0/0. stack backtrace: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.0-rc7-00033-gb5bed2f #153 Hardware name: Qualcomm (Flattened Device Tree) [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0x70/0xbc) [] (dump_stack) from [] (handle_IPI+0x428/0x604) [] (handle_IPI) from [] (gic_handle_irq+0x54/0x5c) [] (gic_handle_irq) from [] (__irq_svc+0x44/0x7c) Exception stack(0xc09f3f48 to 0xc09f3f90) 3f40: 00000001 00000001 00000000 c09f73b8 c09f4528 c0a5de9c 3f60: c076b4f0 00000000 00000000 c09ef108 c0a5cec1 00000001 00000000 c09f3f90 3f80: c026bf60 c0210ab8 20000113 ffffffff [] (__irq_svc) from [] (arch_cpu_idle+0x20/0x3c) [] (arch_cpu_idle) from [] (cpu_startup_entry+0x2c0/0x5dc) [] (cpu_startup_entry) from [] (start_kernel+0x358/0x3c4) [] (start_kernel) from [<8020807c>] (0x8020807c) At this point in the IPI handling path we haven't called irq_enter() yet, so RCU doesn't know that we're about to exit idle and properly warns that we're using RCU from an idle CPU. Use trace_ipi_entry_rcuidle() instead of trace_ipi_entry() so that RCU is informed about our exit from idle. Fixes: 365ec7b17327 ("ARM: add IPI tracepoints") Reported-by: John Stultz Tested-by: John Stultz Acked-by: Steven Rostedt Reviewed-by: Paul E. McKenney Signed-off-by: Stephen Boyd Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit a0238976f43770541b4f899415f0e75800df2d4a Author: Srikar Dronamraju Date: Wed Jun 24 16:40:04 2015 +0530 perf bench numa: Fix to show proper convergence stats commit 2b42b09b88c831ba4da2d669581dde371c38c2af upstream. With commit: e1e455f4f4d3 (perf tools: Work around lack of sched_getcpu in glibc < 2.6), perf_bench numa mem with -c or -m option is not able to correctly calculate convergence. With the above commit, sched_getcpu always seems to return -1. The intention of commit e1e455f was to add a sched_getcpu in glibc < 2.6. Hence keep the sched_getcpu definition under an ifdef. This regression happened occurred between v4.0 and v4.1 Signed-off-by: Srikar Dronamraju Acked-by: Ingo Molnar Cc: Jiri Olsa Cc: Masami Hiramatsu Cc: Namhyung Kim Cc: Vinson Lee Fixes: e1e455f4f4d3 ("perf tools: Work around lack of sched_getcpu in glibc < 2.6") Link: http://lkml.kernel.org/r/20150624111004.GA5220@linux.vnet.ibm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 6b344aadf96db338f644f5d205596b82e6248d07 Author: Christoffer Dall Date: Wed Jul 1 14:08:31 2015 +0200 arm64: Don't report clear pmds and puds as huge commit fd28f5d439fca77348c129d5b73043a56f8a0296 upstream. The current pmd_huge() and pud_huge() functions simply check if the table bit is not set and reports the entries as huge in that case. This is counter-intuitive as a clear pmd/pud cannot also be a huge pmd/pud, and it is inconsistent with at least arm and x86. To prevent others from making the same mistake as me in looking at code that calls these functions and to fix an issue with KVM on arm64 that causes memory corruption due to incorrect page reference counting resulting from this mistake, let's change the behavior. Signed-off-by: Christoffer Dall Reviewed-by: Steve Capper Acked-by: Marc Zyngier Fixes: 084bd29810a5 ("ARM64: mm: HugeTLB support.") Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 1aca08fe1fba6dd5e895a379519c57a5918d5281 Author: Xi Wang Date: Thu Jun 25 18:39:15 2015 -0700 arm64: bpf: fix endianness conversion bugs commit d63903bbc30c7ccad040851dfdb4da12d9a17bcf upstream. Upper bits should be zeroed in endianness conversion: - even when there's no need to change endianness (i.e., BPF_FROM_BE on big endian or BPF_FROM_LE on little endian); - after rev16. This patch fixes such bugs by emitting extra instructions to clear upper bits. Cc: Zi Shen Lim Acked-by: Alexei Starovoitov Fixes: e54bcde3d69d ("arm64: eBPF JIT compiler") Signed-off-by: Xi Wang Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 83893dd22e36d0da4b27ed7d8930669d84044d23 Author: Xi Wang Date: Thu Jun 25 05:47:39 2015 -0700 arm64: bpf: fix out-of-bounds read in bpf2a64_offset() commit 8eee539ddea09bccae2426f09b0ba6a18b72b691 upstream. Problems occur when bpf_to or bpf_from has value prog->len - 1 (e.g., "Very long jump backwards" in test_bpf where the last instruction is a jump): since ctx->offset has length prog->len, ctx->offset[bpf_to + 1] or ctx->offset[bpf_from + 1] will cause an out-of-bounds read, leading to a bogus jump offset and kernel panic. This patch moves updating ctx->offset to after calling build_insn(), and changes indexing to use bpf_to and bpf_from without + 1. Fixes: e54bcde3d69d ("arm64: eBPF JIT compiler") Cc: Zi Shen Lim Cc: Will Deacon Acked-by: Alexei Starovoitov Signed-off-by: Xi Wang Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 2dd7172e36d015013859e5afd3abaeffa92e9397 Author: Stephen Boyd Date: Wed Jun 24 13:14:18 2015 -0700 ARM64: smp: Fix suspicious RCU usage with ipi tracepoints commit be081d9bf3e163a9ed1ca2f0f14f08424c7f9016 upstream. John Stultz reported an RCU splat on ARM with ipi trace events enabled. It looks like the same problem exists on ARM64. At this point in the IPI handling path we haven't called irq_enter() yet, so RCU doesn't know that we're about to exit idle and properly warns that we're using RCU from an idle CPU. Use trace_ipi_entry_rcuidle() instead of trace_ipi_entry() so that RCU is informed about our exit from idle. Cc: John Stultz Cc: Nicolas Pitre Acked-by: Steven Rostedt Reviewed-by: Paul E. McKenney Fixes: 45ed695ac10a ("ARM64: add IPI tracepoints") Signed-off-by: Stephen Boyd Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 409e901e4d22f51cbe19a9ec1f943fbbdcc35853 Author: Al Viro Date: Sat Jul 4 16:11:05 2015 -0400 p9_client_write(): avoid double p9_free_req() commit 67e808fbb0404a12d9b9830a44bbb48d447d8bc9 upstream. Braino in "9p: switch p9_client_write() to passing it struct iov_iter *"; if response is impossible to parse and we discard the request, get the out of the loop right there. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 7e7ef0282a07dc7fc267c6e753f1a2e0919f7e01 Author: Aaro Koskinen Date: Wed Jul 1 13:38:52 2015 +0300 EDAC, octeon: Fix broken build due to model helper renames commit 75a15a7864c9e281c74a1670b10b69d1d7ff1c82 upstream. Commit debe6a623d3c ("MIPS: OCTEON: Update octeon-model.h code for new SoCs.") renamed some SoC model helper functions, but forgot to update the EDAC drivers resulting in build failures. Fix that. Signed-off-by: Aaro Koskinen Acked-by: David Daney Cc: Mauro Carvalho Chehab Cc: Ralf Baechle Cc: linux-edac Cc: linux-mips@linux-mips.org Link: http://lkml.kernel.org/r/1435747132-10954-1-git-send-email-aaro.koskinen@nokia.com Signed-off-by: Borislav Petkov Signed-off-by: Greg Kroah-Hartman commit 634c7dc4993bfa57e66d82ca1394c472cc16e57a Author: Russell King Date: Mon Jun 22 18:39:43 2015 +0100 ARM: dove: fix legacy dove IRQ numbers commit 5d6bed2a9c8bc161bff4cc7cede00f2e0e27a7e7 upstream. v3.18 changed handle_IRQ() to call __handle_domain_irq(), which now rejects attempts to deliver IRQ0. Since IRQ 0 is used as the timer interrupt (just like the PIT on x86), this causes boot to fail as the bogomips calibration never completes. Fix this by shuffling all interrupts up by one. Fixes: a71b092a9c68 ("ARM: Convert handle_IRQ to use __handle_domain_irq") Signed-off-by: Russell King Signed-off-by: Gregory CLEMENT Signed-off-by: Greg Kroah-Hartman commit fb74882f63287d2a19edbc3a7a425ff21de771b7 Author: Chris Wilson Date: Sun Jun 28 14:18:16 2015 +0100 agp/intel: Fix typo in needs_ilk_vtd_wa() commit 8b572a4200828b4e75cc22ed2f494b58d5372d65 upstream. In needs_ilk_vtd_wa(), we pass in the GPU device but compared it against the ids for the mobile GPU and the mobile host bridge. That latter is impossible and so likely was just a typo for the desktop GPU device id (which is also buggy). Fixes commit da88a5f7f7d434e2cde1b3e19d952e6d84533662 Author: Chris Wilson Date: Wed Feb 13 09:31:53 2013 +0000 drm/i915: Disable WC PTE updates to w/a buggy IOMMU on ILK Reported-by: Ting-Wei Lan Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91127 References: https://bugzilla.freedesktop.org/show_bug.cgi?id=60391 Signed-off-by: Chris Wilson Cc: Daniel Vetter Reviewed-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit a6a8032fb8622cf5ba914fbb5e8555f411d327d7 Author: Ilya Dryomov Date: Wed Jun 24 17:24:33 2015 +0300 rbd: use GFP_NOIO in rbd_obj_request_create() commit 5a60e87603c4c533492c515b7f62578189b03c9c upstream. rbd_obj_request_create() is called on the main I/O path, so we need to use GFP_NOIO to make sure allocation doesn't blow back on us. Not all callers need this, but I'm still hardcoding the flag inside rather than making it a parameter because a) this is going to stable, and b) those callers shouldn't really use rbd_obj_request_create() and will be fixed in the future. More memory allocation fixes will follow. Signed-off-by: Ilya Dryomov Reviewed-by: Alex Elder Signed-off-by: Greg Kroah-Hartman commit 4932ba1eb094b3e7ef56ca9d11751543dce6c1e1 Author: Al Viro Date: Sun Jul 12 10:34:29 2015 -0400 9p: don't leave a half-initialized inode sitting around commit 0a73d0a204a4a04a1e110539c5a524ae51f91d6d upstream. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 9974db06b353ada77b1c11c13a34ffd00227235a Author: Al Viro Date: Sat Jul 4 16:04:19 2015 -0400 9p: forgetting to cancel request on interrupted zero-copy RPC commit a84b69cb6e0a41e86bc593904faa6def3b957343 upstream. If we'd already sent a request and decide to abort it, we *must* issue TFLUSH properly and not just blindly reuse the tag, or we'll get seriously screwed when response eventually arrives and we confuse it for response to later request that had reused the same tag. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 213f7d2bbfe91396a5c18ccc4057bcee6674f455 Author: Trond Myklebust Date: Mon Jun 1 15:10:25 2015 -0400 SUNRPC: Fix a memory leak in the backchannel code commit 88de6af24f2b48b06c514d3c3d0a8f22fafe30bd upstream. req->rq_private_buf isn't initialised when xprt_setup_backchannel calls xprt_free_allocation. Fixes: fb7a0b9addbdb ("nfs41: New backchannel helper routines") Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 746af0098bf877cac19f821997cfb21a530e343d Author: Jeff Layton Date: Wed Jun 24 12:10:24 2015 -0400 nfs: always update creds in mirror, even when we have an already connected ds commit 0c8315dd56577445dd1afe6b9cfa06b7efdf2f82 upstream. A ds can be associated with more than one mirror, but we currently skip setting a mirror's credentials if we find that it's already set up with a connected client. The upshot is that we can end up sending DS writes with MDS credentials instead of properly setting them up. Fix nfs4_ff_layout_prepare_ds to always verify that the mirror's credentials are set up, even when we have a DS that's already connected. Reported-by: Tom Haynes Signed-off-by: Jeff Layton Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 1488271989894c89ddac1fa6764edb89421c2160 Author: Jeff Layton Date: Wed Jun 24 12:10:23 2015 -0400 nfs: fix potential credential leak in ff_layout_update_mirror_cred commit a24221dca1868101c9b4b5adde4a6a5b1a3a64a7 upstream. If we have two tasks racing to update a mirror's credentials, then they can end up leaking one (or more) sets of credentials. The first task will set mirror->cred and then the second task will just overwrite it. Use a cmpxchg to ensure that the creds are only set once. If we get to the point where we would set mirror->cred and find that they're already set, then we just release the creds that were just found. Signed-off-by: Jeff Layton Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit a400ef50e78554c779742d45c6f7bfa4fa39d990 Author: Trond Myklebust Date: Wed Jun 17 19:56:22 2015 -0400 NFS: Ensure we set NFS_CONTEXT_RESEND_WRITES when requeuing writes commit c70701131f7a8edea91fc49d11796d342cff7c62 upstream. If a write attempt fails, and the write is queued up for resending to the server, as opposed to being dropped, then we need to set the appropriate flag so that nfs_file_fsync() does the right thing. Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 380db129455056b9edb8b8643023d5edbcb91595 Author: Jeff Layton Date: Tue Jun 9 19:43:56 2015 -0400 nfs: increase size of EXCHANGE_ID name string buffer commit 764ad8ba8cd4c6f836fca9378f8c5121aece0842 upstream. The current buffer is much too small if you have a relatively long hostname. Bring it up to the size of the one that SETCLIENTID has. Reported-by: Michael Skralivetsky Signed-off-by: Jeff Layton Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 9b0702a4f1925ad80e04b1f78012116446e53222 Author: Olga Kornievskaia Date: Fri May 15 11:45:31 2015 -0400 fixing infinite OPEN loop in 4.0 stateid recovery commit e8d975e73e5fa05f983fbf2723120edcf68e0b38 upstream. Problem: When an operation like WRITE receives a BAD_STATEID, even though recovery code clears the RECLAIM_NOGRACE recovery flag before recovering the open state, because of clearing delegation state for the associated inode, nfs_inode_find_state_and_recover() gets called and it makes the same state with RECLAIM_NOGRACE flag again. As a results, when we restart looking over the open states, we end up in the infinite loop instead of breaking out in the next test of state flags. Solution: unset the RECLAIM_NOGRACE set because of calling of nfs_inode_find_state_and_recover() after returning from calling recover_open() function. Signed-off-by: Olga Kornievskaia Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 4e4c360e0ec888eb2373185e0c204b1f4896046d Author: Chuck Lever Date: Tue May 26 11:53:52 2015 -0400 NFS: Fix size of NFSACL SETACL operations commit d683cc49daf7c5afca8cd9654aaa1bf63cdf2ad9 upstream. When encoding the NFSACL SETACL operation, reserve just the estimated size of the ACL rather than a fixed maximum. This eliminates needless zero padding on the wire that the server ignores. Fixes: ee5dc7732bd5 ('NFS: Fix "kernel BUG at fs/nfs/nfs3xdr.c:1338!"') Signed-off-by: Chuck Lever Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 48ac6c92fabea8eaf75d1f25255a502b1c354f48 Author: Trond Myklebust Date: Fri Jun 26 15:37:58 2015 -0400 pNFS/flexfiles: Fix the reset of struct pgio_header when resending commit d620876990f02788d5a663075df007ffb91bdfad upstream. hdr->good_bytes needs to be set to the length of the request, not zero. Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 759367b8eaa40930166671679a00f5ec97e2c5fa Author: Trond Myklebust Date: Wed Jun 17 19:41:51 2015 -0400 pNFS: Fix a memory leak when attempted pnfs fails commit 1ca018d28d96d07788474abf66a5f3e9594841f5 upstream. pnfs_do_write() expects the call to pnfs_write_through_mds() to free the pgio header and to release the layout segment before exiting. The problem is that nfs_pgio_data_destroy() doesn't actually do this; it only frees the memory allocated by nfs_generic_pgio(). Ditto for pnfs_do_read()... Fix in both cases is to add a call to hdr->release(hdr). Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit e420c99545b699d262cf507244eef0959380e46b Author: Hai Li Date: Thu Jun 25 18:35:33 2015 -0400 clk: qcom: Use parent rate when set rate to pixel RCG clock commit 6d451367bfa16fc103604bacd258f534c65d1540 upstream. Since the parent rate has been recalculated, pixel RCG clock should rely on it to find the correct M/N values during set_rate, instead of calling __clk_round_rate() to its parent again. Signed-off-by: Hai Li Tested-by: Archit Taneja Fixes: 99cbd064b059 ("clk: qcom: Support display RCG clocks") [sboyd@codeaurora.org: Silenced unused parent variable warning] Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 9baf2fc882dfe349c227f4d82dd475973dfc8ccd Author: Krzysztof Kozlowski Date: Wed May 13 15:54:40 2015 +0900 clk: ti: dra7-atl-clock: Fix possible ERR_PTR dereference commit e0cdcda508f110b7ec190dc7c5eb2869ba73a535 upstream. of_clk_get_from_provider() returns ERR_PTR on failure. The dra7-atl-clock driver was not checking its return value and immediately used it in __clk_get_hw(). __clk_get_hw() dereferences supplied clock, if it is not NULL, so in that case it would dereference an ERR_PTR. Fixes: 9ac33b0ce81f ("CLK: TI: Driver for DRA7 ATL (Audio Tracking Logic)") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit c4087d1c9897eade8ea4122956d4357f5d6a2043 Author: Stefan Wahren Date: Wed Apr 29 16:36:43 2015 +0000 clk: Fix JSON output in debugfs commit 7cb81136d2efe0f5ed9d965857f4756a15e6c338 upstream. key/value pairs in a JSON object must be separated by a comma. After adding the properties "accuracy" and "phase" the JSON output of /sys/kernel/debug/clk/clk_dump is invalid. So add the missing commas to fix it. Fixes: 5279fc402ae5 ("clk: add clk accuracy retrieval support") Signed-off-by: Stefan Wahren [sboyd@codeaurora.org: Added comment in function] Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 8409afae50e61b3f8297483cf8b8abf52f951909 Author: Geert Uytterhoeven Date: Thu May 7 01:08:08 2015 -0700 gpiolib: Add missing dummies for the unified device properties interface commit 496e7ce2a46562938edcb74f65b26068ee8895f6 upstream. If GPIOLIB=n: drivers/leds/leds-gpio.c: In function ‘gpio_leds_create’: drivers/leds/leds-gpio.c:187: error: implicit declaration of function ‘devm_get_gpiod_from_child’ drivers/leds/leds-gpio.c:187: warning: assignment makes pointer from integer without a cast Add dummies for fwnode_get_named_gpiod() and devm_get_gpiod_from_child() for the !GPIOLIB case to fix this. Signed-off-by: Geert Uytterhoeven Fixes: 40b7318319281b1b ("gpio: Support for unified device properties interface") Acked-by: Alexandre Courbot Acked-by: Linus Walleij Signed-off-by: Bryan Wu Signed-off-by: Greg Kroah-Hartman commit 54472f76f659f91ddad03a79723a8a229bb12fff Author: Uwe Kleine-König Date: Wed Apr 29 20:38:46 2015 +0200 watchdog: omap: assert the counter being stopped before reprogramming commit 530c11d432727c697629ad5f9d00ee8e2864d453 upstream. The omap watchdog has the annoying behaviour that writes to most registers don't have any effect when the watchdog is already running. Quoting the AM335x reference manual: To modify the timer counter value (the WDT_WCRR register), prescaler ratio (the WDT_WCLR[4:2] PTV bit field), delay configuration value (the WDT_WDLY[31:0] DLY_VALUE bit field), or the load value (the WDT_WLDR[31:0] TIMER_LOAD bit field), the watchdog timer must be disabled by using the start/stop sequence (the WDT_WSPR register). Currently the timer is stopped in the .probe callback but still there are possibilities that yield to a situation where omap_wdt_start is entered with the timer running (e.g. when /dev/watchdog is closed without stopping and then reopened). In such a case programming the timeout silently fails! To circumvent this stop the timer before reprogramming. Assuming one of the first things the watchdog user does is setting the timeout explicitly nothing too bad should happen because this explicit setting works fine. Fixes: 7768a13c252a ("[PATCH] OMAP: Add Watchdog driver support") Signed-off-by: Uwe Kleine-König Reviewed-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Greg Kroah-Hartman commit 34f94b18c76f5912815cb1612f40deb7fcb4d0f6 Author: Konstantin Khlebnikov Date: Wed Apr 8 19:59:20 2015 +0300 of: return NUMA_NO_NODE from fallback of_node_to_nid() commit c8fff7bc5bba6bd59cad40441c189c4efe7190f6 upstream. Node 0 might be offline as well as any other numa node, in this case kernel cannot handle memory allocation and crashes. Signed-off-by: Konstantin Khlebnikov Fixes: 0c3f061c195c ("of: implement of_node_to_nid as a weak function") Signed-off-by: Grant Likely Signed-off-by: Greg Kroah-Hartman commit 4473d8ccadce054ba37c02f1cf131ae007a5e32e Author: Miklos Szeredi Date: Mon Jun 22 13:53:48 2015 +0200 ovl: lookup whiteouts outside iterate_dir() commit cdb672795876d7bc1870aed9a2d7cb59f43d1d96 upstream. If jffs2 can deadlock on overlayfs readdir because it takes the same lock on ->iterate() as in ->lookup(). Fix by moving whiteout checking outside iterate_dir(). Optimized by collecting potential whiteouts (DT_CHR) in a temporary list and if non-empty iterating throug these and checking for a 0/0 chardev. Signed-off-by: Miklos Szeredi Fixes: 49c21e1cacd7 ("ovl: check whiteout while reading directory") Reported-by: Roman Yeryomin Signed-off-by: Greg Kroah-Hartman commit 4e5c0806a19975c7d9ab9171af53d4e8125342aa Author: Pali Rohár Date: Tue Jun 23 10:11:19 2015 +0200 dell-laptop: Fix allocating & freeing SMI buffer page commit b8830a4e71b15d0364ac8e6c55301eea73f211da upstream. This commit fix kernel crash when probing for rfkill devices in dell-laptop driver failed. Function free_page() was incorrectly used on struct page * instead of virtual address of SMI buffer. This commit also simplify allocating page for SMI buffer by using __get_free_page() function instead of sequential call of functions alloc_page() and page_address(). Signed-off-by: Pali Rohár Acked-by: Michal Hocko Signed-off-by: Darren Hart Signed-off-by: Greg Kroah-Hartman commit a35b0d6cc0ec26fb607f6cf7bc7be5756c5de63e Author: Jingoo Han Date: Thu Jun 18 00:12:27 2015 +0900 of/address: use atomic allocation in pci_register_io_range() commit 294240ffe784e951dc2ef070da04fa31ef6db3a0 upstream. When kzalloc() is called under spin_lock(), GFP_ATOMIC should be used to avoid sleeping allocation. The call tree is: of_pci_range_to_resource() --> pci_register_io_range() <-- takes spin_lock(&io_range_lock); --> kzalloc() Signed-off-by: Jingoo Han Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman commit 0b99ffc6ea42e16fa4c5b01a414ac0f26766a5f4 Author: Arnd Bergmann Date: Sat Jun 13 15:23:33 2015 +0200 ideapad: fix software rfkill setting commit 4b200b4604bec3388426159f1656109d19fadf6e upstream. This fixes a several year old regression that I found while trying to get the Yoga 3 11 to work. The ideapad_rfk_set function is meant to send a command to the embedded controller through ACPI, but as of c1f73658ed, it sends the index of the rfkill device instead of the command, and ignores the opcode field. This changes it back to the original behavior, which indeed flips the rfkill state as seen in the debugfs interface. Signed-off-by: Arnd Bergmann Fixes: c1f73658ed ("ideapad: pass ideapad_priv as argument (part 2)") Signed-off-by: Darren Hart Signed-off-by: Greg Kroah-Hartman commit 65f5cac612390fdf05f21df8633f7ed11f778f22 Author: Dmitry Tunin Date: Sun Jan 18 15:44:40 2015 +0300 ideapad_laptop: Lenovo G50-30 fix rfkill reports wireless blocked commit 4fa9dabcffc8e16601307d3d56b58c68d9716ba4 upstream. Lenovo G30-50 does not have a hardware wireless switch and wireless is always blocked. BugLink: https://bugs.launchpad.net/bugs/1397021 Signed-off-by: Dmitry Tunin Signed-off-by: Philippe Coval [dvhart@linux.intel.com: Reordered dmi id per Phillippe's later version] Signed-off-by: Darren Hart Signed-off-by: Greg Kroah-Hartman commit 4f0b316fff5b5b90ab8f5f9292b464f0c26d19e3 Author: Damian Eppel Date: Fri Jun 26 15:23:04 2015 +0200 clocksource: exynos_mct: Avoid blocking calls in the cpu hotplug notifier commit 56a94f13919c0db5958611b388e1581b4852f3c9 upstream. Whilst testing cpu hotplug events on kernel configured with DEBUG_PREEMPT and DEBUG_ATOMIC_SLEEP we get following BUG message, caused by calling request_irq() and free_irq() in the context of hotplug notification (which is in this case atomic context). [ 40.785859] CPU1: Software reset [ 40.786660] BUG: sleeping function called from invalid context at mm/slub.c:1241 [ 40.786668] in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/1 [ 40.786678] Preemption disabled at:[< (null)>] (null) [ 40.786681] [ 40.786692] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.19.0-rc4-00024-g7dca860 #36 [ 40.786698] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 40.786728] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 40.786747] [] (show_stack) from [] (dump_stack+0x70/0xbc) [ 40.786767] [] (dump_stack) from [] (kmem_cache_alloc+0xd8/0x170) [ 40.786785] [] (kmem_cache_alloc) from [] (request_threaded_irq+0x64/0x128) [ 40.786804] [] (request_threaded_irq) from [] (exynos4_local_timer_setup+0xc0/0x13c) [ 40.786820] [] (exynos4_local_timer_setup) from [] (exynos4_mct_cpu_notify+0x30/0xa8) [ 40.786838] [] (exynos4_mct_cpu_notify) from [] (notifier_call_chain+0x44/0x84) [ 40.786857] [] (notifier_call_chain) from [] (__cpu_notify+0x28/0x44) [ 40.786873] [] (__cpu_notify) from [] (secondary_start_kernel+0xec/0x150) [ 40.786886] [] (secondary_start_kernel) from [<40008764>] (0x40008764) Interrupts cannot be requested/freed in the CPU_STARTING/CPU_DYING notifications which run on the hotplugged cpu with interrupts and preemption disabled. To avoid the issue, request the interrupts for all possible cpus in the boot code. The interrupts are marked NO_AUTOENABLE to avoid a racy request_irq/disable_irq() sequence. The flag prevents the request_irq() code from enabling the interrupt immediately. The interrupt is then enabled in the CPU_STARTING notifier of the hotplugged cpu and again disabled with disable_irq_nosync() in the CPU_DYING notifier. [ tglx: Massaged changelog to match the patch ] Fixes: 7114cd749a12 ("clocksource: exynos_mct: use (request/free)_irq calls for local timer registration") Reported-by: Krzysztof Kozlowski Reviewed-by: Krzysztof Kozlowski Tested-by: Krzysztof Kozlowski Tested-by: Marcin Jabrzyk Signed-off-by: Damian Eppel Cc: m.szyprowski@samsung.com Cc: kyungmin.park@samsung.com Cc: daniel.lezcano@linaro.org Cc: kgene@kernel.org Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/1435324984-7328-1-git-send-email-d.eppel@samsung.com Signed-off-by: Thomas Gleixner Cc: Signed-off-by: Greg Kroah-Hartman commit 8b7c99ee18a5a872406ffcffdc60fd4a7744770a Author: Alexander Duyck Date: Sat May 2 00:52:00 2015 -0700 e1000e: Cleanup handling of VLAN_HLEN as a part of max frame size commit 8084b86dcfbc4b4822868c1dbdb429b5c08154e2 upstream. When the VLAN_HLEN was added to the calculation for the maximum frame size there seems to have been a number of issues added to the driver. The first issue is that in some cases the maximum frame size for a device never really reached the actual maximum frame size as the VLAN header length was not included the calculation for that value. As a result some parts only supported a maximum frame size of either 1496 in the case of parts that didn't support jumbo frames, and 8996 in the case of the parts that do. The second issue is the fact that there were several checks that weren't updated so as a result setting an MTU of 1500 was treated as enabling jumbo frames as the calculated value was 1522 instead of 1518. I have addressed those by replacing ETH_FRAME_LEN with VLAN_ETH_FRAME_LEN where appropriate. The final issue was the fact that lowering the MTU below 1500 would cause the driver to allocate 2K buffers for the rings. This is an old issue that was fixed several years ago in igb/ixgbe and I am addressing now by just replacing == with a <= so that we always just round up to 1522 for anything that isn't a jumbo frame. Fixes: c751a3d58cf2d ("e1000e: Correctly include VLAN_HLEN when changing interface MTU") Signed-off-by: Alexander Duyck Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman commit 063c47a030bf17eac2d9010f0a899be5f7f4db87 Author: Michal Kazior Date: Fri May 22 10:22:40 2015 +0200 mac80211: prevent possible crypto tx tailroom corruption commit ab499db80fcf07c18e4053f91a619500f663e90e upstream. There was a possible race between ieee80211_reconfig() and ieee80211_delayed_tailroom_dec(). This could result in inability to transmit data if driver crashed during roaming or rekeying and subsequent skbs with insufficient tailroom appeared. This race was probably never seen in the wild because a device driver would have to crash AND recover within 0.5s which is very unlikely. I was able to prove this race exists after changing the delay to 10s locally and crashing ath10k via debugfs immediately after GTK rekeying. In case of ath10k the counter went below 0. This was harmless but other drivers which actually require tailroom (e.g. for WEP ICV or MMIC) could end up with the counter at 0 instead of >0 and introduce insufficient skb tailroom failures because mac80211 would not resize skbs appropriately anymore. Fixes: 8d1f7ecd2af5 ("mac80211: defer tailroom counter manipulation when roaming") Signed-off-by: Michal Kazior Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 7b53ca5c69fd9054c0fc3af97717176a8dacdb4f Author: Michal Kazior Date: Fri May 22 10:57:22 2015 +0200 cfg80211: ignore netif running state when changing iftype commit 6cbfb1bb66e4e85da5db78e8ff429a85bd84ce64 upstream. It was possible for mac80211 to be coerced into an unexpected flow causing sdata union to become corrupted. Station pointer was put into sdata->u.vlan.sta memory location while it was really master AP's sdata->u.ap.next_beacon. This led to station entry being later freed as next_beacon before __sta_info_flush() in ieee80211_stop_ap() and a subsequent invalid pointer dereference crash. The problem was that ieee80211_ptr->use_4addr wasn't cleared on interface type changes. This could be reproduced with the following steps: # host A and host B have just booted; no # wpa_s/hostapd running; all vifs are down host A> iw wlan0 set type station host A> iw wlan0 set 4addr on host A> printf 'interface=wlan0\nssid=4addrcrash\nchannel=1\nwds_sta=1' > /tmp/hconf host A> hostapd -B /tmp/conf host B> iw wlan0 set 4addr on host B> ifconfig wlan0 up host B> iw wlan0 connect -w hostAssid host A> pkill hostapd # host A crashed: [ 127.928192] BUG: unable to handle kernel NULL pointer dereference at 00000000000006c8 [ 127.929014] IP: [] __sta_info_flush+0xac/0x158 ... [ 127.934578] [] ieee80211_stop_ap+0x139/0x26c [ 127.934578] [] ? dump_trace+0x279/0x28a [ 127.934578] [] __cfg80211_stop_ap+0x84/0x191 [ 127.934578] [] cfg80211_stop_ap+0x3f/0x58 [ 127.934578] [] nl80211_stop_ap+0x1b/0x1d [ 127.934578] [] genl_family_rcv_msg+0x259/0x2b5 Note: This isn't a revert of f8cdddb8d61d ("cfg80211: check iface combinations only when iface is running") as far as functionality is considered because b6a550156bc ("cfg80211/mac80211: move more combination checks to mac80211") moved the logic somewhere else already. Fixes: f8cdddb8d61d ("cfg80211: check iface combinations only when iface is running") Signed-off-by: Michal Kazior Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit a35fe5b6b3657f510fb48016c6454603ffb93f7b Author: Eliad Peller Date: Sun Apr 19 11:41:04 2015 +0300 iwlwifi: mvm: fix ROC reference accounting commit c779273b37bec14c33feeab11c4d457a24bc64e0 upstream. commit b112889c5af8124 ("iwlwifi: mvm: add Aux ROC request/response flow") added aux ROC flow in addition to the existing ROC flow. While doing it, it moved the ROC reference release to a common work item, which is being called for both the ROC and aux ROC flows. This resulted in invalid reference accounting, as no reference was taken in case of aux ROC, while a reference was released on completion. Fix it by adding a reference for the aux ROC as well, and release only the relevant references on completion (according to the set bits). While at it, convert cancel_work_sync() to flush_work(), in order to make sure the references are being cleaned properly. Fixes: b112889c5af8 ("iwlwifi: mvm: add Aux ROC request/response flow") Signed-off-by: Eliad Peller Reviewed-by: Johannes Berg Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit 80879086fee9a4bb608689d3e0dc2ddb184aa48b Author: Chun-Yeow Yeoh Date: Tue Jun 9 13:35:33 2015 +0800 mac80211: fix the beacon csa counter for mesh and ibss commit 8df734e865b74d9f273216482a45a38269dc767a upstream. The csa counter has moved from sdata to beacon/presp but it is not updated accordingly for mesh and ibss. Fix this. Fixes: af296bdb8da4 ("mac80211: move csa counters from sdata to beacon/presp") Signed-off-by: Chun-Yeow Yeoh Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit ae41bfc68161ea5d280091ccb9593e9f68d5db44 Author: Vasily Averin Date: Thu Jun 25 15:01:44 2015 -0700 security_syslog() should be called once only commit d194e5d666225b04c7754471df0948f645b6ab3a upstream. The final version of commit 637241a900cb ("kmsg: honor dmesg_restrict sysctl on /dev/kmsg") lost few hooks, as result security_syslog() are processed incorrectly: - open of /dev/kmsg checks syslog access permissions by using check_syslog_permissions() where security_syslog() is not called if dmesg_restrict is set. - syslog syscall and /proc/kmsg calls do_syslog() where security_syslog can be executed twice (inside check_syslog_permissions() and then directly in do_syslog()) With this patch security_syslog() is called once only in all syslog-related operations regardless of dmesg_restrict value. Fixes: 637241a900cb ("kmsg: honor dmesg_restrict sysctl on /dev/kmsg") Signed-off-by: Vasily Averin Cc: Kees Cook Cc: Josh Boyer Cc: Eric Paris Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f843b096c026fba1c2c584a5b9644bb2974bbff7 Author: Chris Metcalf Date: Thu Jun 25 15:02:08 2015 -0700 __bitmap_parselist: fix bug in empty string handling commit 2528a8b8f457d7432552d0e2b6f0f4046bb702f4 upstream. bitmap_parselist("", &mask, nmaskbits) will erroneously set bit zero in the mask. The same bug is visible in cpumask_parselist() since it is layered on top of the bitmask code, e.g. if you boot with "isolcpus=", you will actually end up with cpu zero isolated. The bug was introduced in commit 4b060420a596 ("bitmap, irq: add smp_affinity_list interface to /proc/irq") when bitmap_parselist() was generalized to support userspace as well as kernelspace. Fixes: 4b060420a596 ("bitmap, irq: add smp_affinity_list interface to /proc/irq") Signed-off-by: Chris Metcalf Cc: Rasmus Villemoes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9116f601d95504745db41d077ba7ee8606f73996 Author: Daniel Borkmann Date: Thu Jun 25 15:01:05 2015 -0700 compiler-intel: fix wrong compiler barrier() macro commit b86a50c3b5414eafdbee7f34af4a201a4a7817c2 upstream. Cleanup commit 73679e508201 ("compiler-intel.h: Remove duplicate definition") removed the double definition of __memory_barrier() intrinsics. However, in doing so, it also removed the preceding #undef barrier by accident, meaning, the actual barrier() macro from compiler-gcc.h with inline asm is still in place as __GNUC__ is provided. Subsequently, barrier() can never be defined as __memory_barrier() from compiler.h since it already has a definition in place and if we trust the comment in compiler-intel.h, ecc doesn't support gcc specific asm statements. I don't have an ecc at hand (unsure if that's still used in the field?) and only found this by accident during code review, a revert of that cleanup would be simplest option. Fixes: 73679e508201 ("compiler-intel.h: Remove duplicate definition") Signed-off-by: Daniel Borkmann Reviewed-by: Pranith Kumar Cc: Pranith Kumar Cc: H. Peter Anvin Cc: mancha security Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 534cc62858a02a6fd4664b5f2802f75732c5ba16 Author: Jean Delvare Date: Thu Jun 25 09:06:55 2015 +0200 firmware: dmi_scan: Only honor end-of-table for 64-bit tables commit 17cd5bd5391e6e7b363d66335e1bc6760ae969b9 upstream. A 32-bit entry point to a DMI table says how many structures the table contains. The SMBIOS specification explicitly says that end-of-table markers should be ignored if they are not actually at the end of the DMI table. So only honor the end-of-table marker for tables accessed through 64-bit entry points, as they do not specify a structure count. Fixes: fc43026278 ("dmi: add support for SMBIOS 3.0 64-bit entry point") Signed-off-by: Jean Delvare Acked-by: Ard Biesheuvel Cc: Leif Lindholm Cc: Matt Fleming Signed-off-by: Greg Kroah-Hartman commit 01fed2338abfbfd9719bc9ae0f2673c145f24955 Author: Takashi Iwai Date: Thu Jun 25 00:35:16 2015 +0200 PM / sleep: Increase default DPM watchdog timeout to 60 commit fff3b16d2754a061a3549c4307a186423a0128fd upstream. Many harddisks (mostly WD ones) have firmware problems and take too long, more than 10 seconds, to resume from suspend. And this often exceeds the default DPM watchdog timeout (12 seconds), resulting in a kernel panic out of sudden. Since most distros just take the default as is, we should give a bit more safer value. This patch increases the default value from 12 seconds to one minute, which has been confirmed to be long enough for such problematic disks. Link: https://bugzilla.kernel.org/show_bug.cgi?id=91921 Fixes: 70fea60d888d (PM / Sleep: Detect device suspend/resume lockup and log event) Signed-off-by: Takashi Iwai Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit c791ad1e41a2b1c8df71590d08dbe4b1a1c3b1d5 Author: Naoya Horiguchi Date: Wed Jun 24 16:56:59 2015 -0700 mm/hugetlb: introduce minimum hugepage order commit 641844f5616d7c6597309f560838f996466d7aac upstream. Currently the initial value of order in dissolve_free_huge_page is 64 or 32, which leads to the following warning in static checker: mm/hugetlb.c:1203 dissolve_free_huge_pages() warn: potential right shift more than type allows '9,18,64' This is a potential risk of infinite loop, because 1 << order (== 0) is used in for-loop like this: for (pfn =3D start_pfn; pfn < end_pfn; pfn +=3D 1 << order) ... So this patch fixes it by using global minimum_order calculated at boot time. text data bss dec hex filename 28313 469 84236 113018 1b97a mm/hugetlb.o 28256 473 84236 112965 1b945 mm/hugetlb.o (patched) Fixes: c8721bbbdd36 ("mm: memory-hotplug: enable memory hotplug to handle hugepage") Reported-by: Dan Carpenter Signed-off-by: Naoya Horiguchi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0bcd77743dd60a8a64a9a39e25007968f8cc1c37 Author: Arnd Bergmann Date: Tue May 26 14:45:29 2015 -0700 tty: remove platform_sysrq_reset_seq commit ffb6e0c9a0572f8e5f8e9337a1b40ac2ec1493a1 upstream. The platform_sysrq_reset_seq code was intended as a way for an embedded platform to provide its own sysrq sequence at compile time. After over two years, nobody has started using it in an upstream kernel, and the platforms that were interested in it have moved on to devicetree, which can be used to configure the sequence without requiring kernel changes. The method is also incompatible with the way that most architectures build support for multiple platforms into a single kernel. Now the code is producing warnings when built with gcc-5.1: drivers/tty/sysrq.c: In function 'sysrq_init': drivers/tty/sysrq.c:959:33: warning: array subscript is above array bounds [-Warray-bounds] key = platform_sysrq_reset_seq[i]; We could fix this, but it seems unlikely that it will ever be used, so let's just remove the code instead. We still have the option to pass the sequence either in DT, using the kernel command line, or using the /sys/module/sysrq/parameters/reset_seq file. Fixes: 154b7a489a ("Input: sysrq - allow specifying alternate reset sequence") Signed-off-by: Arnd Bergmann Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit f354666d1be19af7ae671105c693bdb4633eef6b Author: Colin Ian King Date: Fri Jun 5 15:47:27 2015 +0100 RDMA/ocrdma: fix double free on pd commit 4dc544427991e3cef38ce3ae124b7e6557063bd3 upstream. A reorganisation of the PD allocation and deallocation in commit 9ba1377daa ("RDMA/ocrdma: Move PD resource management to driver.") introduced a double free on pd, as detected by static analysis by smatch: drivers/infiniband/hw/ocrdma/ocrdma_verbs.c:682 ocrdma_alloc_pd() error: double free of 'pd'^ The original call to ocrdma_mbx_dealloc_pd() (which does not kfree pd) was replaced with a call to _ocrdma_dealloc_pd() (which does kfree pd). The kfree following this call causes the double free, so just remove it to fix the problem. Fixes: 9ba1377daa ("RDMA/ocrdma: Move PD resource management to driver.") Signed-off-by: Colin Ian King Acked-By: Devesh Sharma Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 32419b851e1fbad53a3908cc3bea923dfb6a1416 Author: Geert Uytterhoeven Date: Fri May 8 10:47:43 2015 +0200 PM / clk: Fix clock error check in __pm_clk_add() commit 3fc3a0be0dab352e065d1dad7d3f81953ed0d4bc upstream. In the final iteration of commit 245bd6f6af8a62a2 ("PM / clock_ops: Add pm_clk_add_clk()"), a refcount increment was added by Grygorii Strashko. However, the accompanying IS_ERR() check operates on the wrong clock pointer, which is always zero at this point, i.e. not an error. This may lead to a NULL pointer dereference later, when __clk_get() tries to dereference an error pointer. Check the passed clock pointer instead to fix this. Signed-off-by: Geert Uytterhoeven Fixes: 245bd6f6af8a62a2 ("PM / clock_ops: Add pm_clk_add_clk()") Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 55df32920758f51d584f5a60a8b82919019c9c4d Author: Ulf Hansson Date: Fri Jun 5 11:40:08 2015 +0200 mmc: sdhci: Restore behavior while creating OCR mask commit 5fd26c7ecb32082745b0bd33c8e35badd1cb5a91 upstream. Commit 3a48edc4bd68 ("mmc: sdhci: Use mmc core regulator infrastucture") changed the behavior for how to assign the ocr_avail mask for the mmc host. More precisely it started to mask the bits instead of assigning them. Restore the behavior, but also make it clear that an OCR mask created from an external regulator overrides the other ones. The OCR mask is determined by one of the following with this priority: 1. Supported ranges of external regulator if one supplies VDD 2. Host OCR mask if set by the driver (based on DT properties) 3. The capabilities reported by the controller itself Fixes: 3a48edc4bd68 ("mmc: sdhci: Use mmc core regulator infrastucture") Cc: Tim Kryger Reported-by: Yangbo Lu Signed-off-by: Ulf Hansson Reviewed-by: Tim Kryger Signed-off-by: Greg Kroah-Hartman commit f213f0f73da0b349931fa3efaf2af79b03efde99 Author: Ding Wang Date: Mon May 18 20:14:15 2015 +0800 mmc: card: Fixup request missing in mmc_blk_issue_rw_rq commit 29535f7b797df35cc9b6b3bca635591cdd3dd2a8 upstream. The current handler of MMC_BLK_CMD_ERR in mmc_blk_issue_rw_rq function may cause new coming request permanent missing when the ongoing request (previoulsy started) complete end. The problem scenario is as follows: (1) Request A is ongoing; (2) Request B arrived, and finally mmc_blk_issue_rw_rq() is called; (3) Request A encounters the MMC_BLK_CMD_ERR error; (4) In the error handling of MMC_BLK_CMD_ERR, suppose mmc_blk_cmd_err() end request A completed and return zero. Continue the error handling, suppose mmc_blk_reset() reset device success; (5) Continue the execution, while loop completed because variable ret is zero now; (6) Finally, mmc_blk_issue_rw_rq() return without processing request B. The process related to the missing request may wait that IO request complete forever, possibly crashing the application or hanging the system. Fix this issue by starting new request when reset success. Signed-off-by: Ding Wang Fixes: 67716327eec7 ("mmc: block: add eMMC hardware reset support") Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 06ab12e64f674aedd402505e2ad89b1765cc86e0 Author: Arnd Bergmann Date: Tue May 19 22:26:04 2015 +0200 serial: samsung: only use earlycon for console commit 357d56151976a78d90dc3dfac01777de0ef05212 upstream. A configuration that enables earlycon but not the core console code causes a link error: drivers/built-in.o: In function `setup_earlycon': drivers/tty/serial/earlycon.c:70: undefined reference to `uart_parse_earlycon' That error can be triggered by the newly added samsung earlycon support, which is missing a 'select' statement. As suggested by Peter Hurley, solves the problem by moving the 'select SERIAL_EARLYCON' statement to the samsung console driver option, as it is done by all other console drivers. Signed-off-by: Arnd Bergmann Fixes: b94ba0328d3b3 ("serial: samsung: Add support for early console") Signed-off-by: Greg Kroah-Hartman commit 1d7a398b461183e920bc591af399580f9623c849 Author: Jiang Liu Date: Wed Jul 8 15:26:39 2015 +0800 ACPI / PCI: Fix regressions caused by resource_size_t overflow with 32-bit kernel commit 1fb01ca93a1348a1469b8777326cd7632483de77 upstream. Zoltan Boszormenyi reported this regression: "There's a Realtek RTL8111/8168/8411 (PCI ID 10ec:8168, Subsystem ID 1565:230e) network chip on the mainboard. After the r8169 driver loaded the IRQs in the machine went berserk. Keyboard keypressed arrived with considerable latency and duplicated, so no real work was possible. The machine responded to the power button but didn't actually power down. It just stuck at the powering down message. I had to press the power button for 4 seconds to power it down. The computer is a POS machine with a big battery inside. Because of this, either ACPI or the Realtek chip kept the bad state and after rebooting, the network chip didn't even show up in lspci. Not even the PXE ROM announced itself during boot. I had to disconnect the battery to beat some sense back to the computer. The regression happens with 4.0.5, 4.1.0-rc8 and 4.1.0-final. 3.18.16 was good." The regression is caused by commit 593669c2ac0f (x86/PCI/ACPI: Use common ACPI resource interfaces to simplify implementation). Since commit 593669c2ac0f, x86 PCI ACPI host bridge driver validates ACPI resources by first converting an ACPI resource to a 'struct resource' structure and then applying checks against the converted resource structure. The 'start' and 'end' fields in 'struct resource' are defined to be type of resource_size_t, which may be 32 bits or 64 bits depending on CONFIG_PHYS_ADDR_T_64BIT. This may cause incorrect resource validation results with 32-bit kernels because 64-bit ACPI resource descriptors may get truncated when converting to 32-bit 'start' and 'end' fields in 'struct resource'. It eventually affects PCI resource allocation subsystem and makes some PCI devices and the system behave abnormally due to incorrect resource assignment. So enhance the ACPI resource parsing interfaces to ignore ACPI resource descriptors with address/offset above 4G when running in 32-bit mode. With the fix applied, the behavior of the machine was restored to how 3.18.16 worked, i.e. the memory range that is over 4GB is ignored again, and lspci -vvxxx shows that everything is at the same memory window as they were with 3.18.16. Reported-and-tested-by: Boszormenyi Zoltan Fixes: 593669c2ac0f (x86/PCI/ACPI: Use common ACPI resource interfaces to simplify implementation) Signed-off-by: Jiang Liu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 24b2b68ee25b25737af7c3b37a63f516d57e8d23 Author: Lv Zheng Date: Wed Jul 1 14:43:34 2015 +0800 ACPICA: Tables: Enable default 64-bit FADT addresses favor commit 0ea61381788a37d864f9841b0fe97d40f7058f3b upstream. ACPICA commit 4da56eeae0749dfe8491285c1e1fad48f6efafd8 The following commit temporarily disables correct 64-bit FADT addresses favor during the period the root cause of the bug is not fixed: Commit: 85dbd5801f62b66e2aa7826aaefcaebead44c8a6 ACPICA: Tables: Restore old behavor to favor 32-bit FADT addresses. With enough protections, this patch re-enables 64-bit FADT addresses by default. If regressions are reported against such change, this patch should be bisected and reverted. Note that 64-bit FACS favor and 64-bit firmware waking vector favor are excluded by this commit in order not to break OSPMs. Lv Zheng. Link: https://bugzilla.kernel.org/show_bug.cgi?id=74021 Link: https://github.com/acpica/acpica/commit/4da56eea Reported-and-tested-by: Oswald Buddenhagen Signed-off-by: Lv Zheng Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit c0f2312598c9adaf4ab819f4d61a1ceaa8705d36 Author: Lv Zheng Date: Wed Jul 1 14:43:26 2015 +0800 ACPICA: Tables: Fix an issue that FACS initialization is performed twice commit c04be18448355441a0c424362df65b6422e27bda upstream. ACPICA commit 90f5332a15e9d9ba83831ca700b2b9f708274658 This patch adds a new FACS initialization flag for acpi_tb_initialize(). acpi_enable_subsystem() might be invoked several times in OS bootup process, and we don't want FACS initialization to be invoked twice. Lv Zheng. Link: https://github.com/acpica/acpica/commit/90f5332a Signed-off-by: Lv Zheng Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit b1bce17e823a3f0c5abb8c6becb2ba314fba8588 Author: Lv Zheng Date: Wed Jul 1 14:43:11 2015 +0800 ACPICA: Tables: Enable both 32-bit and 64-bit FACS commit c04e1fb4396d27f18296db0f914760fa7fe8223a upstream. ACPICA commit f7b86f35416e3d1f71c3d816ff5075ddd33ed486 The following commit is reported to have broken s2ram on some platforms: Commit: 0249ed2444d65d65fc3f3f64f398f1ad0b7e54cd ACPICA: Add option to favor 32-bit FADT addresses. The platform reports 2 FACS tables (which is not allowed by ACPI specification) and the new 32-bit address favor rule forces OSPMs to use the FACS table reported via FADT's X_FIRMWARE_CTRL field. The root cause of the reported bug might be one of the followings: 1. BIOS may favor the 64-bit firmware waking vector address when the version of the FACS is greater than 0 and Linux currently only supports resuming from the real mode, so the 64-bit firmware waking vector has never been set and might be invalid to BIOS while the commit enables higher version FACS. 2. BIOS may favor the FACS reported via the "FIRMWARE_CTRL" field in the FADT while the commit doesn't set the firmware waking vector address of the FACS reported by "FIRMWARE_CTRL", it only sets the firware waking vector address of the FACS reported by "X_FIRMWARE_CTRL". This patch excludes the cases that can trigger the bugs caused by the root cause 2. There is no handshaking mechanism can be used by OSPM to tell BIOS which FACS is currently used. Thus the FACS reported by "FIRMWARE_CTRL" may still be used by BIOS and the 0 value of the 32-bit firmware waking vector might trigger such failure. This patch tries to favor 32bit FACS address in another way where both the FACS reported by "FIRMWARE_CTRL" and the FACS reported by "X_FIRMWARE_CTRL" are loaded so that further commit can set firmware waking vector in the both tables to ensure we can exclude the cases that trigger the bugs caused by the root cause 2. The exclusion is split into 2 commits as this commit is also useful for dumping more ACPI tables, it won't get reverted when such exclusion is no longer necessary. Lv Zheng. Link: https://bugzilla.kernel.org/show_bug.cgi?id=74021 Link: https://github.com/acpica/acpica/commit/f7b86f35 Reported-and-tested-by: Oswald Buddenhagen Signed-off-by: Lv Zheng Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit af3cc7722632f36dd8e05c63d1d261d8fc543487 Author: Rafael J. Wysocki Date: Tue Jul 7 00:31:47 2015 +0200 ACPI / LPSS: Fix up acpi_lpss_create_device() commit d3e13ff3c1aa2403d9a5f371baac088daeb8f56d upstream. Fix a return value (which should be a negative error code) and a memory leak (the list allocated by acpi_dev_get_resources() needs to be freed on ioremap() errors too) in acpi_lpss_create_device() introduced by commit 4483d59e29fe 'ACPI / LPSS: check the result of ioremap()'. Fixes: 4483d59e29fe 'ACPI / LPSS: check the result of ioremap()' Reported-by: Dan Carpenter Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 3dfbf8770ae059d73ee34e7c49c0f628863be932 Author: Rafael J. Wysocki Date: Sat Jul 4 03:09:03 2015 +0200 ACPI / PNP: Reserve ACPI resources at the fs_initcall_sync stage commit 0294112ee3135fbd15eaa70015af8283642dd970 upstream. This effectively reverts the following three commits: 7bc10388ccdd ACPI / resources: free memory on error in add_region_before() 0f1b414d1907 ACPI / PNP: Avoid conflicting resource reservations b9a5e5e18fbf ACPI / init: Fix the ordering of acpi_reserve_resources() (commit b9a5e5e18fbf introduced regressions some of which, but not all, were addressed by commit 0f1b414d1907 and commit 7bc10388ccdd was a fixup on top of the latter) and causes ACPI fixed hardware resources to be reserved at the fs_initcall_sync stage of system initialization. The story is as follows. First, a boot regression was reported due to an apparent resource reservation ordering change after a commit that shouldn't lead to such changes. Investigation led to the conclusion that the problem happened because acpi_reserve_resources() was executed at the device_initcall() stage of system initialization which wasn't strictly ordered with respect to driver initialization (and with respect to the initialization of the pcieport driver in particular), so a random change causing the device initcalls to be run in a different order might break things. The response to that was to attempt to run acpi_reserve_resources() as soon as we knew that ACPI would be in use (commit b9a5e5e18fbf). However, that turned out to be too early, because it caused resource reservations made by the PNP system driver to fail on at least one system and that failure was addressed by commit 0f1b414d1907. That fix still turned out to be insufficient, though, because calling acpi_reserve_resources() before the fs_initcall stage of system initialization caused a boot regression to happen on the eCAFE EC-800-H20G/S netbook. That meant that we only could call acpi_reserve_resources() at the fs_initcall initialization stage or later, but then we might just as well call it after the PNP initalization in which case commit 0f1b414d1907 wouldn't be necessary any more. For this reason, the changes made by commit 0f1b414d1907 are reverted (along with a memory leak fixup on top of that commit), the changes made by commit b9a5e5e18fbf that went too far are reverted too and acpi_reserve_resources() is changed into fs_initcall_sync, which will cause it to be executed after the PNP subsystem initialization (which is an fs_initcall) and before device initcalls (including the pcieport driver initialization) which should avoid the initial issue. Link: https://bugzilla.kernel.org/show_bug.cgi?id=100581 Link: http://marc.info/?t=143092384600002&r=1&w=2 Link: https://bugzilla.kernel.org/show_bug.cgi?id=99831 Link: http://marc.info/?t=143389402600001&r=1&w=2 Fixes: b9a5e5e18fbf "ACPI / init: Fix the ordering of acpi_reserve_resources()" Reported-by: Roland Dreier Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 2dfdaa269d01df3861f6967fd3d08d1ad732794b Author: Dan Carpenter Date: Wed Jun 24 17:30:15 2015 +0300 ACPI / resources: free memory on error in add_region_before() commit 7bc10388ccdd79b3d20463151a1f8e7a590a775b upstream. There is a small memory leak on error. Fixes: 0f1b414d1907 (ACPI / PNP: Avoid conflicting resource reservations) Signed-off-by: Dan Carpenter Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 94fc30841d7d5f59957db6231100c5c07e7c0eab Author: Ilya Dryomov Date: Mon Jun 29 19:30:23 2015 +0300 crush: fix a bug in tree bucket decode commit 82cd003a77173c91b9acad8033fb7931dac8d751 upstream. struct crush_bucket_tree::num_nodes is u8, so ceph_decode_8_safe() should be used. -Wconversion catches this, but I guess it went unnoticed in all the noise it spews. The actual problem (at least for common crushmaps) isn't the u32 -> u8 truncation though - it's the advancement by 4 bytes instead of 1 in the crushmap buffer. Fixes: http://tracker.ceph.com/issues/2759 Signed-off-by: Ilya Dryomov Reviewed-by: Josh Durgin Signed-off-by: Greg Kroah-Hartman commit 650b07ba3c2382113a52f23581e861629476cca5 Author: Miklos Szeredi Date: Wed Jul 1 16:25:55 2015 +0200 fuse: initialize fc->release before calling it commit 0ad0b3255a08020eaf50e34ef0d6df5bdf5e09ed upstream. fc->release is called from fuse_conn_put() which was used in the error cleanup before fc->release was initialized. [Jeremiah Mahler : assign fc->release after calling fuse_conn_init(fc) instead of before.] Signed-off-by: Miklos Szeredi Fixes: a325f9b92273 ("fuse: update fuse_conn_init() and separate out fuse_conn_kill()") Signed-off-by: Greg Kroah-Hartman commit 872d2790a36047dd0f032666550951b4fb865fb4 Author: Stephen Smalley Date: Fri Jul 10 09:40:59 2015 -0400 selinux: fix mprotect PROT_EXEC regression caused by mm change commit 892e8cac99a71f6254f84fc662068d912e1943bf upstream. commit 66fc13039422ba7df2d01a8ee0873e4ef965b50b ("mm: shmem_zero_setup skip security check and lockdep conflict with XFS") caused a regression for SELinux by disabling any SELinux checking of mprotect PROT_EXEC on shared anonymous mappings. However, even before that regression, the checking on such mprotect PROT_EXEC calls was inconsistent with the checking on a mmap PROT_EXEC call for a shared anonymous mapping. On a mmap, the security hook is passed a NULL file and knows it is dealing with an anonymous mapping and therefore applies an execmem check and no file checks. On a mprotect, the security hook is passed a vma with a non-NULL vm_file (as this was set from the internally-created shmem file during mmap) and therefore applies the file-based execute check and no execmem check. Since the aforementioned commit now marks the shmem zero inode with the S_PRIVATE flag, the file checks are disabled and we have no checking at all on mprotect PROT_EXEC. Add a test to the mprotect hook logic for such private inodes, and apply an execmem check in that case. This makes the mmap and mprotect checking consistent for shared anonymous mappings, as well as for /dev/zero and ashmem. Signed-off-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 9d680e03989324f000596be4862728a7c30f22c1 Author: Paul Moore Date: Thu Jul 9 14:20:36 2015 -0400 selinux: don't waste ebitmap space when importing NetLabel categories commit 3324603524925c7727207027d1c15e597412d15e upstream. At present we don't create efficient ebitmaps when importing NetLabel category bitmaps. This can present a problem when comparing ebitmaps since ebitmap_cmp() is very strict about these things and considers these wasteful ebitmaps not equal when compared to their more efficient counterparts, even if their values are the same. This isn't likely to cause problems on 64-bit systems due to a bit of luck on how NetLabel/CIPSO works and the default ebitmap size, but it can be a problem on 32-bit systems. This patch fixes this problem by being a bit more intelligent when importing NetLabel category bitmaps by skipping over empty sections which should result in a nice, efficient ebitmap. Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit df7c9ca8f5925d9b839864437b7090a865d560e4 Author: Filipe Manana Date: Tue Jul 14 16:09:39 2015 +0100 Btrfs: fix file corruption after cloning inline extents commit ed958762644b404654a6f5d23e869f496fe127c6 upstream. Using the clone ioctl (or extent_same ioctl, which calls the same extent cloning function as well) we end up allowing copy an inline extent from the source file into a non-zero offset of the destination file. This is something not expected and that the btrfs code is not prepared to deal with - all inline extents must be at a file offset equals to 0. For example, the following excerpt of a test case for fstests triggers a crash/BUG_ON() on a write operation after an inline extent is cloned into a non-zero offset: _scratch_mkfs >>$seqres.full 2>&1 _scratch_mount # Create our test files. File foo has the same 2K of data at offset 4K # as file bar has at its offset 0. $XFS_IO_PROG -f -s -c "pwrite -S 0xaa 0 4K" \ -c "pwrite -S 0xbb 4k 2K" \ -c "pwrite -S 0xcc 8K 4K" \ $SCRATCH_MNT/foo | _filter_xfs_io # File bar consists of a single inline extent (2K size). $XFS_IO_PROG -f -s -c "pwrite -S 0xbb 0 2K" \ $SCRATCH_MNT/bar | _filter_xfs_io # Now call the clone ioctl to clone the extent of file bar into file # foo at its offset 4K. This made file foo have an inline extent at # offset 4K, something which the btrfs code can not deal with in future # IO operations because all inline extents are supposed to start at an # offset of 0, resulting in all sorts of chaos. # So here we validate that clone ioctl returns an EOPNOTSUPP, which is # what it returns for other cases dealing with inlined extents. $CLONER_PROG -s 0 -d $((4 * 1024)) -l $((2 * 1024)) \ $SCRATCH_MNT/bar $SCRATCH_MNT/foo # Because of the inline extent at offset 4K, the following write made # the kernel crash with a BUG_ON(). $XFS_IO_PROG -c "pwrite -S 0xdd 6K 2K" $SCRATCH_MNT/foo | _filter_xfs_io status=0 exit The stack trace of the BUG_ON() triggered by the last write is: [152154.035903] ------------[ cut here ]------------ [152154.036424] kernel BUG at mm/page-writeback.c:2286! [152154.036424] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC [152154.036424] Modules linked in: btrfs dm_flakey dm_mod crc32c_generic xor raid6_pq nfsd auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache sunrpc loop fuse parport_pc acpi_cpu$ [152154.036424] CPU: 2 PID: 17873 Comm: xfs_io Tainted: G W 4.1.0-rc6-btrfs-next-11+ #2 [152154.036424] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.1-0-g4adadbd-20150316_085822-nilsson.home.kraxel.org 04/01/2014 [152154.036424] task: ffff880429f70990 ti: ffff880429efc000 task.ti: ffff880429efc000 [152154.036424] RIP: 0010:[] [] clear_page_dirty_for_io+0x1e/0x90 [152154.036424] RSP: 0018:ffff880429effc68 EFLAGS: 00010246 [152154.036424] RAX: 0200000000000806 RBX: ffffea0006a6d8f0 RCX: 0000000000000001 [152154.036424] RDX: 0000000000000000 RSI: ffffffff81155d1b RDI: ffffea0006a6d8f0 [152154.036424] RBP: ffff880429effc78 R08: ffff8801ce389fe0 R09: 0000000000000001 [152154.036424] R10: 0000000000002000 R11: ffffffffffffffff R12: ffff8800200dce68 [152154.036424] R13: 0000000000000000 R14: ffff8800200dcc88 R15: ffff8803d5736d80 [152154.036424] FS: 00007fbf119f6700(0000) GS:ffff88043d280000(0000) knlGS:0000000000000000 [152154.036424] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [152154.036424] CR2: 0000000001bdc000 CR3: 00000003aa555000 CR4: 00000000000006e0 [152154.036424] Stack: [152154.036424] ffff8803d5736d80 0000000000000001 ffff880429effcd8 ffffffffa04e97c1 [152154.036424] ffff880429effd68 ffff880429effd60 0000000000000001 ffff8800200dc9c8 [152154.036424] 0000000000000001 ffff8800200dcc88 0000000000000000 0000000000001000 [152154.036424] Call Trace: [152154.036424] [] lock_and_cleanup_extent_if_need+0x147/0x18d [btrfs] [152154.036424] [] __btrfs_buffered_write+0x245/0x4c8 [btrfs] [152154.036424] [] ? btrfs_file_write_iter+0x150/0x3e0 [btrfs] [152154.036424] [] ? btrfs_file_write_iter+0x15f/0x3e0 [btrfs] [152154.036424] [] btrfs_file_write_iter+0x2cc/0x3e0 [btrfs] [152154.036424] [] __vfs_write+0x7c/0xa5 [152154.036424] [] vfs_write+0xa0/0xe4 [152154.036424] [] SyS_pwrite64+0x64/0x82 [152154.036424] [] system_call_fastpath+0x12/0x6f [152154.036424] Code: 48 89 c7 e8 0f ff ff ff 5b 41 5c 5d c3 0f 1f 44 00 00 55 48 89 e5 41 54 53 48 89 fb e8 ae ef 00 00 49 89 c4 48 8b 03 a8 01 75 02 <0f> 0b 4d 85 e4 74 59 49 8b 3c 2$ [152154.036424] RIP [] clear_page_dirty_for_io+0x1e/0x90 [152154.036424] RSP [152154.242621] ---[ end trace e3d3376b23a57041 ]--- Fix this by returning the error EOPNOTSUPP if an attempt to copy an inline extent into a non-zero offset happens, just like what is done for other scenarios that would require copying/splitting inline extents, which were introduced by the following commits: 00fdf13a2e9f ("Btrfs: fix a crash of clone with inline extents's split") 3f9e3df8da3c ("btrfs: replace error code from btrfs_drop_extents") Signed-off-by: Filipe Manana Signed-off-by: Greg Kroah-Hartman commit 98f7bfe6a25a7b822efc7fcc72b7b494fefd438f Author: Filipe Manana Date: Fri Jul 3 20:30:34 2015 +0100 Btrfs: fix list transaction->pending_ordered corruption commit d3efe08400317888f559bbedf0e42cd31575d0ef upstream. When we call btrfs_commit_transaction(), we splice the list "ordered" of our transaction handle into the transaction's "pending_ordered" list, but we don't re-initialize the "ordered" list of our transaction handle, this means it still points to the same elements it used to before the splice. Then we check if the current transaction's state is >= TRANS_STATE_COMMIT_START and if it is we end up calling btrfs_end_transaction() which simply splices again the "ordered" list of our handle into the transaction's "pending_ordered" list, leaving multiple pointers to the same ordered extents which results in list corruption when we are iterating, removing and freeing ordered extents at btrfs_wait_pending_ordered(), resulting in access to dangling pointers / use-after-free issues. Similarly, btrfs_end_transaction() can end up in some cases calling btrfs_commit_transaction(), and both did a list splice of the transaction handle's "ordered" list into the transaction's "pending_ordered" without re-initializing the handle's "ordered" list, resulting in exactly the same problem. This produces the following warning on a kernel with linked list debugging enabled: [109749.265416] ------------[ cut here ]------------ [109749.266410] WARNING: CPU: 7 PID: 324 at lib/list_debug.c:59 __list_del_entry+0x5a/0x98() [109749.267969] list_del corruption. prev->next should be ffff8800ba087e20, but was fffffff8c1f7c35d (...) [109749.287505] Call Trace: [109749.288135] [] dump_stack+0x4f/0x7b [109749.298080] [] ? console_unlock+0x356/0x3a2 [109749.331605] [] warn_slowpath_common+0xa1/0xbb [109749.334849] [] ? __list_del_entry+0x5a/0x98 [109749.337093] [] warn_slowpath_fmt+0x46/0x48 [109749.337847] [] __list_del_entry+0x5a/0x98 [109749.338678] [] btrfs_wait_pending_ordered+0x46/0xdb [btrfs] [109749.340145] [] ? __btrfs_run_delayed_items+0x149/0x163 [btrfs] [109749.348313] [] btrfs_commit_transaction+0x36b/0xa10 [btrfs] [109749.349745] [] ? trace_hardirqs_on+0xd/0xf [109749.350819] [] btrfs_sync_file+0x36f/0x3fc [btrfs] [109749.351976] [] vfs_fsync_range+0x8f/0x9e [109749.360341] [] vfs_fsync+0x1c/0x1e [109749.368828] [] do_fsync+0x34/0x4e [109749.369790] [] SyS_fsync+0x10/0x14 [109749.370925] [] system_call_fastpath+0x12/0x6f [109749.382274] ---[ end trace 48e0d07f7c03d95a ]--- On a non-debug kernel this leads to invalid memory accesses, causing a crash. Fix this by using list_splice_init() instead of list_splice() in btrfs_commit_transaction() and btrfs_end_transaction(). Fixes: 50d9aa99bd35 ("Btrfs: make sure logged extents complete in the current transaction V3" Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 992a3fbb5f5d77b23e4d7a785e4ad22b4acf82cd Author: Filipe Manana Date: Fri Jul 3 08:36:11 2015 +0100 Btrfs: fix memory leak in the extent_same ioctl commit 497b4050e0eacd4c746dd396d14916b1e669849d upstream. We were allocating memory with memdup_user() but we were never releasing that memory. This affected pretty much every call to the ioctl, whether it deduplicated extents or not. This issue was reported on IRC by Julian Taylor and on the mailing list by Marcel Ritter, credit goes to them for finding the issue. Reported-by: Julian Taylor Reported-by: Marcel Ritter Signed-off-by: Filipe Manana Reviewed-by: Mark Fasheh Signed-off-by: Greg Kroah-Hartman commit 544f8fbe0af1ab753531cfc4efedf39d64a2a656 Author: Filipe Manana Date: Wed Jun 17 12:49:23 2015 +0100 Btrfs: fix fsync data loss after append write commit e4545de5b035c7debb73d260c78377dbb69cbfb5 upstream. If we do an append write to a file (which increases its inode's i_size) that does not have the flag BTRFS_INODE_NEEDS_FULL_SYNC set in its inode, and the previous transaction added a new hard link to the file, which sets the flag BTRFS_INODE_COPY_EVERYTHING in the file's inode, and then fsync the file, the inode's new i_size isn't logged. This has the consequence that after the fsync log is replayed, the file size remains what it was before the append write operation, which means users/applications will not be able to read the data that was successsfully fsync'ed before. This happens because neither the inode item nor the delayed inode get their i_size updated when the append write is made - doing so would require starting a transaction in the buffered write path, something that we do not do intentionally for performance reasons. Fix this by making sure that when the flag BTRFS_INODE_COPY_EVERYTHING is set the inode is logged with its current i_size (log the in-memory inode into the log tree). This issue is not a recent regression and is easy to reproduce with the following test case for fstests: seq=`basename $0` seqres=$RESULT_DIR/$seq echo "QA output created by $seq" here=`pwd` tmp=/tmp/$$ status=1 # failure is the default! _cleanup() { _cleanup_flakey rm -f $tmp.* } trap "_cleanup; exit \$status" 0 1 2 3 15 # get standard environment, filters and checks . ./common/rc . ./common/filter . ./common/dmflakey # real QA test starts here _supported_fs generic _supported_os Linux _need_to_be_root _require_scratch _require_dm_flakey _require_metadata_journaling $SCRATCH_DEV _crash_and_mount() { # Simulate a crash/power loss. _load_flakey_table $FLAKEY_DROP_WRITES _unmount_flakey # Allow writes again and mount. This makes the fs replay its fsync log. _load_flakey_table $FLAKEY_ALLOW_WRITES _mount_flakey } rm -f $seqres.full _scratch_mkfs >> $seqres.full 2>&1 _init_flakey _mount_flakey # Create the test file with some initial data and then fsync it. # The fsync here is only needed to trigger the issue in btrfs, as it causes the # the flag BTRFS_INODE_NEEDS_FULL_SYNC to be removed from the btrfs inode. $XFS_IO_PROG -f -c "pwrite -S 0xaa 0 32k" \ -c "fsync" \ $SCRATCH_MNT/foo | _filter_xfs_io sync # Add a hard link to our file. # On btrfs this sets the flag BTRFS_INODE_COPY_EVERYTHING on the btrfs inode, # which is a necessary condition to trigger the issue. ln $SCRATCH_MNT/foo $SCRATCH_MNT/bar # Sync the filesystem to force a commit of the current btrfs transaction, this # is a necessary condition to trigger the bug on btrfs. sync # Now append more data to our file, increasing its size, and fsync the file. # In btrfs because the inode flag BTRFS_INODE_COPY_EVERYTHING was set and the # write path did not update the inode item in the btree nor the delayed inode # item (in memory struture) in the current transaction (created by the fsync # handler), the fsync did not record the inode's new i_size in the fsync # log/journal. This made the data unavailable after the fsync log/journal is # replayed. $XFS_IO_PROG -c "pwrite -S 0xbb 32K 32K" \ -c "fsync" \ $SCRATCH_MNT/foo | _filter_xfs_io echo "File content after fsync and before crash:" od -t x1 $SCRATCH_MNT/foo _crash_and_mount echo "File content after crash and log replay:" od -t x1 $SCRATCH_MNT/foo status=0 exit The expected file output before and after the crash/power failure expects the appended data to be available, which is: 0000000 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa * 0100000 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb * 0200000 Signed-off-by: Filipe Manana Reviewed-by: Liu Bo Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 9547e86be4af61fb535d1487d6a0a607bb67f392 Author: Filipe Manana Date: Sat Jun 13 06:52:57 2015 +0100 Btrfs: fix race between caching kthread and returning inode to inode cache commit ae9d8f17118551bedd797406a6768b87c2146234 upstream. While the inode cache caching kthread is calling btrfs_unpin_free_ino(), we could have a concurrent call to btrfs_return_ino() that adds a new entry to the root's free space cache of pinned inodes. This concurrent call does not acquire the fs_info->commit_root_sem before adding a new entry if the caching state is BTRFS_CACHE_FINISHED, which is a problem because the caching kthread calls btrfs_unpin_free_ino() after setting the caching state to BTRFS_CACHE_FINISHED and therefore races with the task calling btrfs_return_ino(), which is adding a new entry, while the former (caching kthread) is navigating the cache's rbtree, removing and freeing nodes from the cache's rbtree without acquiring the spinlock that protects the rbtree. This race resulted in memory corruption due to double free of struct btrfs_free_space objects because both tasks can end up doing freeing the same objects. Note that adding a new entry can result in merging it with other entries in the cache, in which case those entries are freed. This is particularly important as btrfs_free_space structures are also used for the block group free space caches. This memory corruption can be detected by a debugging kernel, which reports it with the following trace: [132408.501148] slab error in verify_redzone_free(): cache `btrfs_free_space': double free detected [132408.505075] CPU: 15 PID: 12248 Comm: btrfs-ino-cache Tainted: G W 4.1.0-rc5-btrfs-next-10+ #1 [132408.505075] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.1-0-g4adadbd-20150316_085822-nilsson.home.kraxel.org 04/01/2014 [132408.505075] ffff880023e7d320 ffff880163d73cd8 ffffffff8145eec7 ffffffff81095dce [132408.505075] ffff880009735d40 ffff880163d73ce8 ffffffff81154e1e ffff880163d73d68 [132408.505075] ffffffff81155733 ffffffffa054a95a ffff8801b6099f00 ffffffffa0505b5f [132408.505075] Call Trace: [132408.505075] [] dump_stack+0x4f/0x7b [132408.505075] [] ? console_unlock+0x356/0x3a2 [132408.505075] [] __slab_error.isra.28+0x25/0x36 [132408.505075] [] __cache_free+0xe2/0x4b6 [132408.505075] [] ? __btrfs_add_free_space+0x2f0/0x343 [btrfs] [132408.505075] [] ? btrfs_unpin_free_ino+0x8e/0x99 [btrfs] [132408.505075] [] ? time_hardirqs_off+0x15/0x28 [132408.505075] [] ? trace_hardirqs_off+0xd/0xf [132408.505075] [] ? kfree+0xb6/0x14e [132408.505075] [] kfree+0xe5/0x14e [132408.505075] [] btrfs_unpin_free_ino+0x8e/0x99 [btrfs] [132408.505075] [] caching_kthread+0x29e/0x2d9 [btrfs] [132408.505075] [] ? btrfs_unpin_free_ino+0x99/0x99 [btrfs] [132408.505075] [] kthread+0xef/0xf7 [132408.505075] [] ? time_hardirqs_on+0x15/0x28 [132408.505075] [] ? __kthread_parkme+0xad/0xad [132408.505075] [] ret_from_fork+0x42/0x70 [132408.505075] [] ? __kthread_parkme+0xad/0xad [132408.505075] ffff880023e7d320: redzone 1:0x9f911029d74e35b, redzone 2:0x9f911029d74e35b. [132409.501654] slab: double free detected in cache 'btrfs_free_space', objp ffff880023e7d320 [132409.503355] ------------[ cut here ]------------ [132409.504241] kernel BUG at mm/slab.c:2571! Therefore fix this by having btrfs_unpin_free_ino() acquire the lock that protects the rbtree while doing the searches and removing entries. Fixes: 1c70d8fb4dfa ("Btrfs: fix inode caching vs tree log") Signed-off-by: Filipe Manana Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 6f953ad80fba78eed807fe61d96c4dde50708698 Author: Filipe Manana Date: Sat Jun 13 06:52:56 2015 +0100 Btrfs: use kmem_cache_free when freeing entry in inode cache commit c3f4a1685bb87e59c886ee68f7967eae07d4dffa upstream. The free space entries are allocated using kmem_cache_zalloc(), through __btrfs_add_free_space(), therefore we should use kmem_cache_free() and not kfree() to avoid any confusion and any potential problem. Looking at the kfree() definition at mm/slab.c it has the following comment: /* * (...) * * Don't free memory not originally allocated by kmalloc() * or you will run into trouble. */ So better be safe and use kmem_cache_free(). Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 528feaeaf153863372517c6e713fcc4fe848deeb Author: Firo Yang Date: Thu Jun 11 09:41:10 2015 +0800 md: fix a build warning commit 4e023612325a9034a542bfab79f78b1fe5ebb841 upstream. Warning like this: drivers/md/md.c: In function "update_array_info": drivers/md/md.c:6394:26: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses] !mddev->persistent != info->not_persistent|| Fix it as Neil Brown said: mddev->persistent != !info->not_persistent || Signed-off-by: Firo Yang Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 54b1fb57886f3b2a7be247937efa26d6e305aaa4 Author: Omar Sandoval Date: Tue Jun 2 17:31:00 2015 -0700 Btrfs: don't invalidate root dentry when subvolume deletion fails commit 64ad6c488975d7516230cf7849190a991fd615ae upstream. Since commit bafc9b754f75 ("vfs: More precise tests in d_invalidate"), mounted subvolumes can be deleted because d_invalidate() won't fail. However, we run into problems when we attempt to delete the default subvolume while it is mounted as the root filesystem: # btrfs subvol list / ID 257 gen 306 top level 5 path rootvol ID 267 gen 334 top level 5 path snap1 # btrfs subvol get-default / ID 267 gen 334 top level 5 path snap1 # btrfs inspect-internal rootid / 267 # mount -o subvol=/ /dev/vda1 /mnt # btrfs subvol del /mnt/snap1 Delete subvolume (no-commit): '/mnt/snap1' ERROR: cannot delete '/mnt/snap1' - Operation not permitted # findmnt / findmnt: can't read /proc/mounts: No such file or directory # ls /proc # Markus reported that this same scenario simply led to a kernel oops. This happens because in btrfs_ioctl_snap_destroy(), we call d_invalidate() before we check may_destroy_subvol(), which means that we detach the submounts and drop the dentry before erroring out. Instead, we should only invalidate the dentry once the deletion has succeeded. Additionally, the shrink_dcache_sb() isn't necessary; d_invalidate() will prune the dcache for the deleted subvolume. Fixes: bafc9b754f75 ("vfs: More precise tests in d_invalidate") Reported-by: Markus Schauler Signed-off-by: Omar Sandoval Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 83719f40f525caffa63e2599416241156d4f6a3b Author: Stefan Wahren Date: Tue Jun 2 22:03:28 2015 +0000 ARM: dts: mx23: fix iio-hwmon support commit e8e94ed6285428ab780cd7b0df4622f71eceb39e upstream. In order to get iio-hwmon support, the lradc must be declared as an iio provider. So fix this issue by adding the #io-channel-cells property. Signed-off-by: Stefan Wahren Fixes: bd798f9c7b30 ("ARM: dts: mxs: Add iio-hwmon to mx23 soc") Reviewed-by: Marek Vasut Reviewed-by: Alexandre Belloni Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 2618fae8d09a715fd79a9f8673bd307ab2aa6986 Author: Constantine Shulyupin Date: Fri Jun 26 17:47:44 2015 +0300 hwmon: (nct7802) fix visibility of temp3 commit 56172d81a9bc37a69b95dd627b8d48135c9c7b31 upstream. Excerpt from datasheet: 7.2.32 Mode Selection Register RTD3_MD : 00=Closed , 01=Reserved , 10=Thermistor mode , 11=Voltage sense Show temp3 only in Thermistor mode Signed-off-by: Constantine Shulyupin Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit f94402351ca06e1fd5699e3e01601d517e01d1a8 Author: Stevens, Nick Date: Wed Jul 1 16:07:41 2015 +0000 hwmon: (mcp3021) Fix broken output scaling commit 347d7e45bd09ce09cbc30d5cea9de377eb22f55c upstream. The mcp3021 scaling code is dividing the VDD (full-scale) value in millivolts by the A2D resolution to obtain the scaling factor. When VDD is 3300mV (the standard value) and the resolution is 12-bit (4096 divisions), the result is a scale factor of 3300/4096, which is always one. Effectively, the raw A2D reading is always being returned because no scaling is applied. This patch fixes the issue and simplifies the register-to-volts calculation, removing the unneeded "output_scale" struct member. Signed-off-by: Nick Stevens [Guenter Roeck: Dropped unnecessary value check] Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 7640ca524e936f7e47dc8ecbc463ea1876346f4d Author: Goldwyn Rodrigues Date: Wed Jul 22 12:09:17 2015 -0500 md: Skip cluster setup for dm-raid commit d3b178adb3a3adf54ecf77758138b654c3ee7f09 upstream. There is a bug that the bitmap superblock isn't initialised properly for dm-raid, so a new field can have garbage in new fields. (dm-raid does initialisation in the kernel - md initialised the superblock in mdadm). This means that for dm-raid we cannot currently trust the new ->nodes field. So: - use __GFP_ZERO to initialise the superblock properly for all new arrays - initialise all fields in bitmap_info in bitmap_new_disk_sb - ignore ->nodes for dm arrays (yes, this is a hack) This bug exposes dm-raid to bug in the (still experimental) md-cluster code, so it is suitable for -stable. It does cause crashes. References: https://bugzilla.kernel.org/show_bug.cgi?id=100491 Signed-off-By: Goldwyn Rodrigues Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 0f9457afe159aee56f80b20fff27a6af60f2b7a1 Author: NeilBrown Date: Thu Jun 25 17:06:40 2015 +1000 md: unlock mddev_lock on an error path. commit 9a8c0fa861e4db60409b4dda254cef5e17e4d43c upstream. This error path retuns while still holding the lock - bad. Fixes: 6791875e2e53 ("md: make reconfig_mutex optional for writes to md sysfs files.") Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit adeb846a6d8fdc8b9dc19a65393382838cad727f Author: NeilBrown Date: Thu Jun 25 17:01:40 2015 +1000 md: clear mddev->private when it has been freed. commit bd6919228d7e1867ae9e24ab27e3e4a366c87d21 upstream. If ->private is set when ->run is called, it is assumed to be a 'config' prepared as part of 'reshape'. So it is important when we free that config, that we also clear ->private. This is not often a problem as the mddev will normally be discarded shortly after the config us freed. However if an 'assemble' races with a final close, the assemble can use the old mddev which has a stale ->private. This leads to any of various sorts of crashes. So clear ->private after calling ->free(). Reported-by: Nate Clark Fixes: afa0f557cb15 ("md: rename ->stop to ->free") Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 499b1532e1ee4e3c6ebc1ced5a1d1e75f696262e Author: Lior Amsalem Date: Tue May 26 15:07:32 2015 +0200 dmaengine: mv_xor: bug fix for racing condition in descriptors cleanup commit 9136291f1dbc1d4d1cacd2840fb35f4f3ce16c46 upstream. This patch fixes a bug in the XOR driver where the cleanup function can be called and free descriptors that never been processed by the engine (which result in data errors). The cleanup function will free descriptors based on the ownership bit in the descriptors. Fixes: ff7b04796d98 ("dmaengine: DMA engine driver for Marvell XOR engine") Signed-off-by: Lior Amsalem Signed-off-by: Maxime Ripard Reviewed-by: Ofer Heifetz Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 63544f7d8ab278c0c63d92d093308c0d0c912f07 Author: Steven Rostedt (Red Hat) Date: Fri Jul 17 14:03:26 2015 -0400 tracing: Fix sample output of dynamic arrays commit d6726c8145290bef950ae2538ea6ae1d96a1944b upstream. He Kuang noticed that the trace event samples for arrays was broken: "The output result of trace_foo_bar event in traceevent samples is wrong. This problem can be reproduced as following: (Build kernel with SAMPLE_TRACE_EVENTS=m) $ insmod trace-events-sample.ko $ echo 1 > /sys/kernel/debug/tracing/events/sample-trace/foo_bar/enable $ cat /sys/kernel/debug/tracing/trace event-sample-980 [000] .... 43.649559: foo_bar: foo hello 21 0x15 BIT1|BIT3|0x10 {0x1,0x6f6f6e53,0xff007970,0xffffffff} Snoopy ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The array length is not right, should be {0x1}. (ffffffff,ffffffff) event-sample-980 [000] .... 44.653827: foo_bar: foo hello 22 0x16 BIT2|BIT3|0x10 {0x1,0x2,0x646e6147,0x666c61,0xffffffff,0xffffffff,0x750aeffe,0x7} ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The array length is not right, should be {0x1,0x2}. Gandalf (ffffffff,ffffffff)" This was caused by an update to have __print_array()'s second parameter be the count of items in the array and not the size of the array. As there is already users of __print_array(), it can not change. But the sample code can and we can also improve on the documentation about __print_array() and __get_dynamic_array_len(). Link: http://lkml.kernel.org/r/1436839171-31527-2-git-send-email-hekuang@huawei.com Fixes: ac01ce1410fc2 ("tracing: Make ftrace_print_array_seq compute buf_len") Reported-by: He Kuang Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 624dda42c3e7a00608ca4532b2f7bc127bc0f740 Author: Steven Rostedt (Red Hat) Date: Tue Jul 7 15:05:03 2015 -0400 tracing: Have branch tracer use recursive field of task struct commit 6224beb12e190ff11f3c7d4bf50cb2922878f600 upstream. Fengguang Wu's tests triggered a bug in the branch tracer's start up test when CONFIG_DEBUG_PREEMPT set. This was because that config adds some debug logic in the per cpu field, which calls back into the branch tracer. The branch tracer has its own recursive checks, but uses a per cpu variable to implement it. If retrieving the per cpu variable calls back into the branch tracer, you can see how things will break. Instead of using a per cpu variable, use the trace_recursion field of the current task struct. Simply set a bit when entering the branch tracing and clear it when leaving. If the bit is set on entry, just don't do the tracing. There's also the case with lockdep, as the local_irq_save() called before the recursion can also trigger code that can call back into the function. Changing that to a raw_local_irq_save() will protect that as well. This prevents the recursion and the inevitable crash that follows. Link: http://lkml.kernel.org/r/20150630141803.GA28071@wfg-t540p.sh.intel.com Reported-by: Fengguang Wu Tested-by: Fengguang Wu Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 2161c8679389c9008ec7a1c5c279ced37cc07f5e Author: Steven Rostedt (Red Hat) Date: Thu Jun 25 18:19:37 2015 -0400 tracing: Fix typo from "static inlin" to "static inline" commit cc9e4bde03f2b4cfba52406c021364cbd2a4a0f3 upstream. The trace.h header when called without CONFIG_EVENT_TRACING enabled (seldom done), will not compile because of a typo in the protocol of trace_event_enum_update(). Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit a27274be0112c7d458caba759e1d550fd9985e5f Author: Steven Rostedt (Red Hat) Date: Thu Jun 25 18:10:09 2015 -0400 tracing/filter: Do not allow infix to exceed end of string commit 6b88f44e161b9ee2a803e5b2b1fbcf4e20e8b980 upstream. While debugging a WARN_ON() for filtering, I found that it is possible for the filter string to be referenced after its end. With the filter: # echo '>' > /sys/kernel/debug/events/ext4/ext4_truncate_exit/filter The filter_parse() function can call infix_get_op() which calls infix_advance() that updates the infix filter pointers for the cnt and tail without checking if the filter is already at the end, which will put the cnt to zero and the tail beyond the end. The loop then calls infix_next() that has ps->infix.cnt--; return ps->infix.string[ps->infix.tail++]; The cnt will now be below zero, and the tail that is returned is already passed the end of the filter string. So far the allocation of the filter string usually has some buffer that is zeroed out, but if the filter string is of the exact size of the allocated buffer there's no guarantee that the charater after the nul terminating character will be zero. Luckily, only root can write to the filter. Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit baa7b46259b0dabb66bb4cd0dc28379bc5942c17 Author: Steven Rostedt (Red Hat) Date: Thu Jun 25 18:02:29 2015 -0400 tracing/filter: Do not WARN on operand count going below zero commit b4875bbe7e68f139bd3383828ae8e994a0df6d28 upstream. When testing the fix for the trace filter, I could not come up with a scenario where the operand count goes below zero, so I added a WARN_ON_ONCE(cnt < 0) to the logic. But there is legitimate case that it can happen (although the filter would be wrong). # echo '>' > /sys/kernel/debug/events/ext4/ext4_truncate_exit/filter That is, a single operation without any operands will hit the path where the WARN_ON_ONCE() can trigger. Although this is harmless, and the filter is reported as a error. But instead of spitting out a warning to the kernel dmesg, just fail nicely and report it via the proper channels. Link: http://lkml.kernel.org/r/558C6082.90608@oracle.com Reported-by: Vince Weaver Reported-by: Sasha Levin Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 66963999a2b2f589e108c786bfcb2e2b560d920e Author: Mimi Zohar Date: Thu Jun 11 20:48:33 2015 -0400 ima: update builtin policies commit 24fd03c87695a76f0517df42a37e51b1597d2c8a upstream. This patch defines a builtin measurement policy "tcb", similar to the existing "ima_tcb", but with additional rules to also measure files based on the effective uid and to measure files opened with the "read" mode bit set (eg. read, read-write). Changing the builtin "ima_tcb" policy could potentially break existing users. Instead of defining a new separate boot command line option each time the builtin measurement policy is modified, this patch defines a single generic boot command line option "ima_policy=" to specify the builtin policy and deprecates the use of the builtin ima_tcb policy. [The "ima_policy=" boot command line option is based on Roberto Sassu's "ima: added new policy type exec" patch.] Signed-off-by: Mimi Zohar Signed-off-by: Dr. Greg Wettstein Signed-off-by: Greg Kroah-Hartman commit bf609547cdb2f274fb5bd978affc8649022b5d3a Author: Mimi Zohar Date: Wed Nov 5 07:53:55 2014 -0500 ima: extend "mask" policy matching support commit 4351c294b8c1028077280f761e158d167b592974 upstream. The current "mask" policy option matches files opened as MAY_READ, MAY_WRITE, MAY_APPEND or MAY_EXEC. This patch extends the "mask" option to match files opened containing one of these modes. For example, "mask=^MAY_READ" would match files opened read-write. Signed-off-by: Mimi Zohar Signed-off-by: Dr. Greg Wettstein Signed-off-by: Greg Kroah-Hartman commit 9428e8a37303a363bc4a8ac08501045f2195c02d Author: Mimi Zohar Date: Wed Nov 5 07:48:36 2014 -0500 ima: add support for new "euid" policy condition commit 139069eff7388407f19794384c42a534d618ccd7 upstream. The new "euid" policy condition measures files with the specified effective uid (euid). In addition, for CAP_SETUID files it measures files with the specified uid or suid. Changelog: - fixed checkpatch.pl warnings - fixed avc denied {setuid} messages - based on Roberto's feedback Signed-off-by: Mimi Zohar Signed-off-by: Dr. Greg Wettstein Signed-off-by: Greg Kroah-Hartman commit 2b92ad967d2884fed41469c0c37f3cd14937fad6 Author: Mimi Zohar Date: Thu Jun 11 11:54:42 2015 -0400 ima: fix ima_show_template_data_ascii() commit 45b26133b97871896b8c5241d59f4ff7839db7b2 upstream. This patch fixes a bug introduced in "4d7aeee ima: define new template ima-ng and template fields d-ng and n-ng". Changelog: - change int to uint32 (Roberto Sassu's suggestion) Signed-off-by: Mimi Zohar Signed-off-by: Roberto Sassu Signed-off-by: Greg Kroah-Hartman commit 60e2874ce4570fa546d9c173a5a5cf7b9e966070 Author: Mimi Zohar Date: Tue Apr 21 13:59:31 2015 -0400 evm: labeling pseudo filesystems exception commit 5101a1850bb7ccbf107929dee9af0cd2f400940f upstream. To prevent offline stripping of existing file xattrs and relabeling of them at runtime, EVM allows only newly created files to be labeled. As pseudo filesystems are not persistent, stripping of xattrs is not a concern. Some LSMs defer file labeling on pseudo filesystems. This patch permits the labeling of existing files on pseudo files systems. Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit 0ecc8ea6de19f41bf1332ef9dd472412b9ce4fa3 Author: Mimi Zohar Date: Tue Apr 21 16:54:24 2015 -0400 ima: do not measure or appraise the NSFS filesystem commit cd025f7f94108995383edddfb61fc8afea6c66a9 upstream. Include don't appraise or measure rules for the NSFS filesystem in the builtin ima_tcb and ima_appraise_tcb policies. Changelog: - Update documentation Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit 7869fa6047fe7c5076e70b57a83fb351b42c34c6 Author: Dan Carpenter Date: Tue Apr 7 12:22:11 2015 +0300 ima: cleanup ima_init_policy() a little commit 5577857f8e26e9027271f10daf96361640907300 upstream. It's a bit easier to read this if we split it up into two for loops. Signed-off-by: Dan Carpenter Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit 73cc530acfebd856d803d3f153350a2892715da8 Author: Roberto Sassu Date: Sat Apr 11 17:13:06 2015 +0200 ima: skip measurement of cgroupfs files and update documentation commit 6438de9f3fb5180d78a0422695d0b88c687757d3 upstream. This patch adds a rule in the default measurement policy to skip inodes in the cgroupfs filesystem. Measurements for this filesystem can be avoided, as all the digests collected have the same value of the digest of an empty file. Furthermore, this patch updates the documentation of IMA policies in Documentation/ABI/testing/ima_policy to make it consistent with the policies set in security/integrity/ima/ima_policy.c. Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit 4fd5dc9eece297f49f16f82422ead3a28b11ea70 Author: Colin Ian King Date: Mon Jul 27 15:23:43 2015 +0100 KEYS: ensure we free the assoc array edit if edit is valid commit ca4da5dd1f99fe9c59f1709fb43e818b18ad20e0 upstream. __key_link_end is not freeing the associated array edit structure and this leads to a 512 byte memory leak each time an identical existing key is added with add_key(). The reason the add_key() system call returns okay is that key_create_or_update() calls __key_link_begin() before checking to see whether it can update a key directly rather than adding/replacing - which it turns out it can. Thus __key_link() is not called through __key_instantiate_and_link() and __key_link_end() must cancel the edit. CVE-2015-1333 Signed-off-by: Colin Ian King Signed-off-by: David Howells Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit e47f1631376e53715e14a0d1e25421f3868f90b1 Author: Mimi Zohar Date: Wed Feb 11 07:33:34 2015 -0500 KEYS: fix "ca_keys=" partial key matching commit f2b3dee484f9cee967a54ef05a66866282337519 upstream. The call to asymmetric_key_hex_to_key_id() from ca_keys_setup() silently fails with -ENOMEM. Instead of dynamically allocating memory from a __setup function, this patch defines a variable and calls __asymmetric_key_hex_to_key_id(), a new helper function, directly. This bug was introduced by 'commit 46963b774d44 ("KEYS: Overhaul key identification when searching for asymmetric keys")'. Changelog: - for clarification, rename hexlen to asciihexlen in asymmetric_key_hex_to_key_id() - add size argument to __asymmetric_key_hex_to_key_id() - David Howells - inline __asymmetric_key_hex_to_key_id() - David Howells - remove duplicate strlen() calls Acked-by: David Howells Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit c2c40e1af2a2a78c04120567709344b1bf9f8111 Author: Jarkko Sakkinen Date: Wed Jun 24 17:14:55 2015 +0300 tpm, tpm_crb: fail when TPM2 ACPI table contents look corrupted commit b371616b8537d6450ebca0819defbf53452bebf3 upstream. At least some versions of AMI BIOS have corrupted contents in the TPM2 ACPI table and namely the physical address of the control area is set to zero. This patch changes the driver to fail gracefully when we observe a zero address instead of continuing to ioremap. Signed-off-by: Jarkko Sakkinen Reviewed-by: Peter Huewe Signed-off-by: Peter Huewe Signed-off-by: Greg Kroah-Hartman commit f7ea8a3bd52da9670d32fd9869657a8501edff23 Author: Jason Gunthorpe Date: Tue Jun 30 13:15:31 2015 -0600 tpm: Fix initialization of the cdev commit ba0ef85479c46a2ab354c2220bdb6152f7f4baf3 upstream. When a cdev is contained in a dynamic structure the cdev parent kobj should be set to the kobj that controls the lifetime of the enclosing structure. In TPM's case this is the embedded struct device. Also, cdev_init 0's the whole structure, so all sets must be after, not before. This fixes module ref counting and cdev. Fixes: 313d21eeab92 ("tpm: device class for tpm") Signed-off-by: Jason Gunthorpe Reviewed-by: Dmitry Torokhov Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen Signed-off-by: Peter Huewe Signed-off-by: Greg Kroah-Hartman commit 82bebdad67b9d968cf564166a09aab6e7f4e2301 Author: Hon Ching \\(Vicky\\) Lo Date: Fri May 22 13:23:02 2015 -0400 vTPM: set virtual device before passing to ibmvtpm_reset_crq commit 9d75f08946e8485109458ccf16f714697c207f41 upstream. tpm_ibmvtpm_probe() calls ibmvtpm_reset_crq(ibmvtpm) without having yet set the virtual device in the ibmvtpm structure. So in ibmvtpm_reset_crq, the phype call contains empty unit addresses, ibmvtpm->vdev->unit_address. Signed-off-by: Hon Ching(Vicky) Lo Signed-off-by: Joy Latten Reviewed-by: Ashley Lai Fixes: 132f76294744 ("drivers/char/tpm: Add new device driver to support IBM vTPM") Signed-off-by: Peter Huewe Signed-off-by: Greg Kroah-Hartman commit 510c99974fdbc18f143c41cbd461c522f5ad7164 Author: Jarkko Sakkinen Date: Tue Jun 9 15:07:59 2015 +0300 tpm, tpm_crb: fix le64_to_cpu conversions in crb_acpi_add() commit 49afd7289bd937401c5f7faa193054bc3c41dad6 upstream. le64_to_cpu() was applied twice to the physical addresses read from the control area. This hasn't shown any visible regressions because CRB driver has been tested only on the little endian platofrms so far. Reported-by: Matt Fleming Signed-off-by: Jarkko Sakkinen Reviewed-By: Jason Gunthorpe Fixes: 30fc8d138e91 ("tpm: TPM 2.0 CRB Interface") Signed-off-by: Peter Huewe Signed-off-by: Greg Kroah-Hartman commit 7a8599a5a88f7996db19cf8ecc466fd95e9dcc4e Author: David Fries Date: Fri May 8 19:51:50 2015 -0500 w1_therm reference count family data commit f7134eea05b2fb4a2c0935f8a540539fff01f3eb upstream. A temperature conversion can take 750 ms and when possible the w1_therm slave driver drops the bus_mutex to allow other bus operations, but that includes operations such as a periodic slave search, which can remove this slave when it is no longer detected. If that happens the sl->family_data will be freed and set to NULL causing w1_slave_show to crash when it wakes up. Signed-off-by: David Fries Reported-By: Thorsten Bschorr Tested-by: Thorsten Bschorr Acked-by: Evgeniy Polyakov Signed-off-by: Greg Kroah-Hartman commit f2cb7e30813040794190995f54f42a8addeec8da Author: Brian Foster Date: Tue Jun 23 08:47:20 2015 +1000 xfs: don't truncate attribute extents if no extents exist commit f66bf042693b620133d39af8d2f13615f03eadfc upstream. The xfs_attr3_root_inactive() call from xfs_attr_inactive() assumes that attribute blocks exist to invalidate. It is possible to have an attribute fork without extents, however. Consider the case where the attribute fork is created towards the beginning of xfs_attr_set() but some part of the subsequent attribute set fails. If an inode in such a state hits xfs_attr_inactive(), it eventually calls xfs_dabuf_map() and possibly xfs_bmapi_read(). The former emits a filesystem corruption warning, returns an error that bubbles back up to xfs_attr_inactive(), and leads to destruction of the in-core attribute fork without an on-disk reset. If the inode happens to make it back through xfs_inactive() in this state (e.g., via a concurrent bulkstat that cycles the inode from the reclaim state and releases it), i_afp might not exist when xfs_bmapi_read() is called and causes a NULL dereference panic. A '-p 2' fsstress run to ENOSPC on a relatively small fs (1GB) reproduces these problems. The behavior is a regression caused by: 6dfe5a0 xfs: xfs_attr_inactive leaves inconsistent attr fork state behind ... which removed logic that avoided the attribute extent truncate when no extents exist. Restore this logic to ensure the attribute fork is destroyed and reset correctly if it exists without any allocated extents. Signed-off-by: Brian Foster Reviewed-by: Dave Chinner Signed-off-by: Dave Chinner Signed-off-by: Greg Kroah-Hartman commit 1d94f9fc91f94dacfce82638a485dcf9474dc305 Author: Eric Sandeen Date: Mon Jun 22 09:42:48 2015 +1000 xfs: fix remote symlinks on V5/CRC filesystems commit 2ac56d3d4bd625450a54d4c3f9292d58f6b88232 upstream. If we create a CRC filesystem, mount it, and create a symlink with a path long enough that it can't live in the inode, we get a very strange result upon remount: # ls -l mnt total 4 lrwxrwxrwx. 1 root root 929 Jun 15 16:58 link -> XSLM XSLM is the V5 symlink block header magic (which happens to be followed by a NUL, so the string looks terminated). xfs_readlink_bmap() advanced cur_chunk by the size of the header for CRC filesystems, but never actually used that pointer; it kept reading from bp->b_addr, which is the start of the block, rather than the start of the symlink data after the header. Looks like this problem goes back to v3.10. Fixing this gets us reading the proper link target, again. Signed-off-by: Eric Sandeen Reviewed-by: Dave Chinner Signed-off-by: Dave Chinner Signed-off-by: Greg Kroah-Hartman commit f8a895a6704bba5752c136f7338814c40c891e89 Author: Martin K. Petersen Date: Tue May 19 19:44:17 2015 -0400 libata: Fix regression when the NCQ Send and Receive log page is absent commit eab6ee1ce3c4678224d70338134f7a02005768cb upstream. Commit 5d3abf8ff67f ("libata: Fall back to unqueued READ LOG EXT if the DMA variant fails") allowed us to fall back to the unqueued READ LOG variant if the queued version failed. However, if the device did not support the page at all we would end up looping due to a merge snafu. Ensure we only take the fallback path once. Signed-off-by: Martin K. Petersen Reported-by: Sergey Senozhatsky Tested-by: Sergey Senozhatsky Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 0f974562e301457fb3f314df5ae3bca7d9e0aa6c Author: Daniel Vetter Date: Thu Jul 16 16:47:50 2015 +0200 drm: Stop resetting connector state to unknown commit 5677d67ae3949f09f57357241b88222d49b8c782 upstream. It's causing piles of issues since we've stopped forcing full detect cycles in the sysfs interfaces with commit c484f02d0f02fbbfc6decc945a69aae011041a27 Author: Chris Wilson Date: Fri Mar 6 12:36:42 2015 +0000 drm: Lighten sysfs connector 'status' The original justification for this was that the hpd handlers could use the unknown state as a hint to force a full detection. But current i915 code isn't doing that any more, and no one else really uses reset on resume. So instead just keep the old state around. References: http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/62584 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100641 Cc: Rui Matos Cc: Julien Wajsberg Cc: kuddel.mail@gmx.de Cc: Lennart Poettering Acked-by: Rob Clark Tested-by: Rui Tiago Cação Matos Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 463059b56b8468f31e6112213ac6667d507e6538 Author: Tvrtko Ursulin Date: Tue Jul 14 11:13:08 2015 +0100 drm: Provide compat ioctl for addfb2.1 commit c631d5f90e7ee246536c72f80ade86e9ef4d2f13 upstream. Frame buffer modifiers extensions provided in; commit e3eb3250d84ef97b766312345774367b6a310db8 Author: Rob Clark Date: Thu Feb 5 14:41:52 2015 +0000 drm: add support for tiled/compressed/etc modifier in addfb2 Missed the structure packing/alignment problem where 64-bit members were added after the odd number of 32-bit ones. This makes the compiler produce structures of different sizes under 32- and 64-bit x86 targets and makes the ioctl need explicit compat handling. v2: Removed the typedef. (Daniel Vetter) Signed-off-by: Tvrtko Ursulin Reviewed-by: Daniel Vetter Cc: dri-devel@lists.freedesktop.org Cc: Rob Clark Cc: Daniel Stone Cc: Daniel Vetter [danvet: Squash in compile fix from Mika.] Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 7e230794ec1a9a439c527893b7e7efb69ad33e78 Author: Zhao Junwang Date: Tue Jul 7 17:08:35 2015 +0800 drm: add a check for x/y in drm_mode_setcrtc commit 01447e9f04ba1c49a9534ae6a5a6f26c2bb05226 upstream. legacy setcrtc ioctl does take a 32 bit value which might indeed overflow the checks of crtc_req->x > INT_MAX and crtc_req->y > INT_MAX aren't needed any more with this v2: -polish the annotation according to Daniel's comment Cc: Daniel Vetter Signed-off-by: Zhao Junwang Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit c22488876adbfca5511afed4b828407cb2556a11 Author: Daniel Kurtz Date: Tue Jul 7 17:03:36 2015 +0800 drm/rockchip: use drm_gem_mmap helpers commit 41315b793e13f884cda79389f0d5d44d027e57d1 upstream. Rather than (incompletely [0]) re-implementing drm_gem_mmap() and drm_gem_mmap_obj() helpers, call them directly from the rockchip mmap routines. Once the core functions return successfully, the rockchip mmap routines can still use dma_mmap_attrs() to simply mmap the entire buffer. [0] Previously, we were performing the mmap() without first taking a reference on the underlying gem buffer. This could leak ptes if the gem object is destroyed while userspace is still holding the mapping. Signed-off-by: Daniel Kurtz Reviewed-by: Daniel Vetter Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 8a235410e43ae851e6657d00d3605efc7ff77f76 Author: Alex Deucher Date: Thu Jul 16 10:17:09 2015 -0400 drm/radeon/ci: silence a harmless PCC warning commit bda5e3e97ffe80c5a793383df5681d3581d46ac8 upstream. This has been a source of confusion. Make it debug only. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit d019429c10adf02d4b107ce815ff3c4aa6c3459a Author: Christian König Date: Tue Jul 14 15:58:30 2015 +0200 drm/radeon: fix user ptr race condition commit 12f1384da650bdb835fff63e66fe815ea882fc0e upstream. Port of amdgpu patch 9298e52f8b51d1e4acd68f502832f3a97f8cf892. Signed-off-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit ea039f927524e36c15b5905b4c9469d788591932 Author: Alex Deucher Date: Thu Jul 9 21:08:17 2015 -0400 drm/radeon: add a dpm quirk for Sapphire Radeon R9 270X 2GB GDDR5 commit 5dfc71bc44d91d1620505c064fa22b0b3db58a9d upstream. bug: https://bugs.freedesktop.org/show_bug.cgi?id=76490 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit f72642c67038dc91715dc96b29a05c100a4f26ea Author: Michel Dänzer Date: Fri Jul 3 10:02:27 2015 +0900 drm/radeon: Don't flush the GART TLB if rdev->gart.ptr == NULL commit 233709d2cd6bbaaeda0aeb8d11f6ca7f98563b39 upstream. This can be the case when the GPU is powered off, e.g. via vgaswitcheroo or runpm. When the GPU is powered up again, radeon_gart_table_vram_pin flushes the TLB after setting rdev->gart.ptr to non-NULL. Fixes panic on powering off R7xx GPUs. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61529 Reviewed-by: Christian König Signed-off-by: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 46b334754f07e698c52ffbbbe33d58f303cab8e9 Author: Grigori Goronzy Date: Tue Jul 7 16:27:29 2015 +0900 drm/radeon: unpin cursor BOs on suspend and pin them again on resume (v2) commit f3cbb17bcf676a2fc6aedebe9fbebd59e550c51a upstream. Everything is evicted from VRAM before suspend, so we need to make sure all BOs are unpinned and re-pinned after resume. Fixes broken mouse cursor after resume introduced by commit b9729b17. [Michel Dänzer: Add pinning BOs on resume] v2: [Alex Deucher: merge cursor unpin into fb unpin loop] Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100541 Reviewed-by: Christian König (v1) Signed-off-by: Grigori Goronzy Signed-off-by: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 5161879c7e43ba40edbe2991ec31bfa6f7e2fe30 Author: Michel Dänzer Date: Tue Jul 7 16:27:28 2015 +0900 drm/radeon: Clean up reference counting and pinning of the cursor BOs commit cd404af0c930104462aa91344f07d002cf8248ed upstream. Take a GEM reference for and pin the new cursor BO, unpin and drop the GEM reference for the old cursor BO in radeon_crtc_cursor_set2, and use radeon_crtc->cursor_addr in radeon_set_cursor. This fixes radeon_cursor_reset accidentally incrementing the cursor BO pin count, and cleans up the code a little. Reviewed-by: Grigori Goronzy Reviewed-by: Christian König Signed-off-by: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 7c4cbc81127b31fa179578e8b17b422efc16d966 Author: Mario Kleiner Date: Fri Jul 3 06:03:06 2015 +0200 drm/radeon: Handle irqs only based on irq ring, not irq status regs. commit 07f18f0bb8d8d65badd8b4988b40d329fc0cc6dc upstream. Trying to resolve issues with missed vblanks and impossible values inside delivered kms pageflip completion events showed that radeon's irq handling sometimes doesn't handle valid irqs, but silently skips them. This was observed for vblank interrupts. Although those irqs have corresponding events queued in the gpu's irq ring at time of interrupt, and therefore the corresponding handling code gets triggered by these events, the handling code sometimes silently skipped processing the irq. The reason for those skips is that the handling code double-checks for each irq event if the corresponding irq status bits in the irq status registers are set. Sometimes those bits are not set at time of check for valid irqs, maybe due to some hardware race on some setups? The problem only seems to happen on some machine + card combos sometimes, e.g., never happened during my testing of different PC cards of the DCE-2/3/4 generation a year ago, but happens consistently now on two different Apple Mac cards (RV730, DCE-3, Apple iMac and Evergreen JUNIPER, DCE-4 in a Apple MacPro). It also doesn't happen at each interrupt but only occassionally every couple of hundred or thousand vblank interrupts. This results in XOrg warning messages like "[ 7084.472] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 420120 < target_msc 420121" as well as skipped frames and problems for applications that use kms pageflip events or vblank events, e.g., users of DRI2 and DRI3/Present, Waylands Weston compositor, etc. See also https://bugs.freedesktop.org/show_bug.cgi?id=85203 After some talking to Alex and Michel, we decided to fix this by turning the double-check for asserted irq status bits into a warning. Whenever a irq event is queued in the IH ring, always execute the corresponding interrupt handler. Still check the irq status bits, but only to log a DRM_DEBUG message on a mismatch. This fixed the problems reliably on both previously failing cards, RV-730 dual-head tested on both crtcs (pipes D1 and D2) and a triple-output Juniper HD-5770 card tested on all three available crtcs (D1/D2/D3). The r600 and evergreen irq handling is therefore tested, but the cik an si handling is only compile tested due to lack of hw. Reviewed-by: Christian König Signed-off-by: Mario Kleiner CC: Michel Dänzer CC: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 56308551a9569ea10791092a99c9f6b5b2d4ddf8 Author: Grigori Goronzy Date: Fri Jul 3 01:54:11 2015 +0200 drm/radeon: fix HDP flushing commit 54e03986133468e02cb01b76215e4d53a9cf6380 upstream. This was regressed by commit 39e7f6f8, although I don't know of any actual issues caused by it. The storage domain is read without TTM locking now, but the lock never helped to prevent any races. Reviewed-by: Christian König Signed-off-by: Grigori Goronzy Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 8b941a43ea7709111d3cbea2bdfcc678975255da Author: Alex Deucher Date: Tue Jun 30 09:30:01 2015 -0400 drm/radeon: only check the sink type on DP connectors commit 479e9a95120aaae0bf0d3e0b5b26b36ac4a347b6 upstream. Avoids a crash on pre-DP asics that support HDMI. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit d1a4362d41e4feb52df6464f70fb64f21b894623 Author: Alex Deucher Date: Mon Jun 29 11:09:11 2015 -0400 Revert "drm/radeon: dont switch vt on suspend" commit ac9134906b3f5c2b45dc80dab0fee792bd516d52 upstream. This reverts commit b9729b17a414f99c61f4db9ac9f9ed987fa0cbfe. This seems to break the cursor on resume for lots of systems. Signed-off-by: Greg Kroah-Hartman commit 7b49262b642511a16699cc63cf2a716739f0c43f Author: Jérôme Glisse Date: Fri Jun 19 10:32:16 2015 -0400 drm/radeon: SDMA fix hibernation (CI GPU family). commit 2ba8d1bb8f6b589037f7db1f01144fc80750e8f7 upstream. In order for hibernation to reliably work we need to properly turn off the SDMA block, sadly after numerous attemps i haven't not found proper sequence for clean and full shutdown. So simply reset both SDMA block, this makes hibernation works reliably on sea island GPU family (CI) Hibernation and suspend to ram were tested (several times) on : Bonaire Hawaii Mullins Kaveri Kabini Signed-off-by: Jérôme Glisse Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit e25083389dcf06d65d56a64c1eca4c2a79e53556 Author: Jérôme Glisse Date: Fri Jun 19 10:32:15 2015 -0400 drm/radeon: compute ring fix hibernation (CI GPU family) v2. commit 161569deaa03cf3c00ed63352006193f250b0648 upstream. In order for hibernation to reliably work we need to cleanup more thoroughly the compute ring. Hibernation is different from suspend resume as when we resume from hibernation the hardware is first fully initialize by regular kernel then freeze callback happens (which correspond to a suspend inside the radeon kernel driver) and turn off each of the block. It turns out we were not cleanly shutting down the compute ring. This patch fix that. Hibernation and suspend to ram were tested (several times) on : Bonaire Hawaii Mullins Kaveri Kabini Changed since v1: - Factor the ring stop logic into a function taking ring as arg. Signed-off-by: Jérôme Glisse Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 1f977d7e942519127aea0a08e9d08437b363cf19 Author: Chris Wilson Date: Thu Jul 16 12:37:56 2015 +0100 drm/i915: Use two 32bit reads for select 64bit REG_READ ioctls commit 648a9bc5308d952f2c80772301b339f73026f013 upstream. Since the hardware sometimes mysteriously totally flummoxes the 64bit read of a 64bit register when read using a single instruction, split the read into two instructions. Since the read here is of automatically incrementing timestamp counters, we also have to be very careful in order to make sure that it does not increment between the two instructions. However, since userspace tried to workaround this issue and so enshrined this ABI for a broken hardware read and in the process neglected that the read only fails in some environments, we have to introduce a new uABI flag for userspace to request the 2x32 bit accurate read of the timestamp. v2: Fix alignment check and include details of the workaround for userspace. Reported-by: Karol Herbst Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91317 Testcase: igt/gem_reg_read Signed-off-by: Chris Wilson Cc: Michał Winiarski Tested-by: Michał Winiarski Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 6fff1aa7fc51334cb71a358f3f536fe9d5d6c994 Author: Daniel Vetter Date: Tue Jul 14 12:29:27 2015 +0200 Revert "drm/i915: Declare the swizzling unknown for L-shaped configurations" commit d82c0ba6e306f079407f07003e53c262d683397b upstream. This reverts commit 19ee835cdb0b5a8eb11a68f25a51b8039d564488. It breaks existing old userspace which doesn't handle UNKNOWN swizzling correct. Yes UNKNOWN was a thing back in 2009 and probably still is on some other platforms, but it still pretty clearly broke the testers machine. If we want this we need to extend the ioctl with new paramters that only new userspace looks at. Cc: Harald Arnesen Cc: Chris Wilson Reported-by: Harald Arnesen Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 7bd3a9a9f4c231c8e4c7233f2e0cd83db12726dc Author: Tvrtko Ursulin Date: Mon Jul 13 16:51:39 2015 +0100 drm/i915: Forward all core DRM ioctls to core compat handling commit ac7e7ab1c3243b10b41653cc8d8536088d83b152 upstream. Previously only core DRM ioctls under the DRM_COMMAND_BASE were being forwarded, but the drm.h header suggests (and reality confirms) ones after (and including) DRM_COMMAND_END should be forwarded as well. We need this to correctly forward the compat ioctl for the botched-up addfb2.1 extension. Signed-off-by: Tvrtko Ursulin Cc: Daniel Vetter [danvet: Explain why this is suddenly needed and add cc: stable.] Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit e639564b6050d71ca2b4e575685b6f7d3642d18a Author: Tomas Elf Date: Thu Jul 9 15:30:57 2015 +0100 drm/i915: Snapshot seqno of most recently submitted request. commit 94f7bbe1509731bdef651d7fb235b2c31fb23be8 upstream. The hang checker needs to inspect whether or not the ring request list is empty as well as if the given engine has reached or passed the most recently submitted request. The problem with this is that the hang checker cannot grab the struct_mutex, which is required in order to safely inspect requests since requests might be deallocated during inspection. In the past we've had kernel panics due to this very unsynchronized access in the hang checker. One solution to this problem is to not inspect the requests directly since we're only interested in the seqno of the most recently submitted request - not the request itself. Instead the seqno of the most recently submitted request is stored separately, which the hang checker then inspects, circumventing the issue of synchronization from the hang checker entirely. This fixes a regression introduced in commit 44cdd6d219bc64f6810b8ed0023a4d4db9e0fe68 Author: John Harrison Date: Mon Nov 24 18:49:40 2014 +0000 drm/i915: Convert 'ring_idle()' to use requests not seqnos v2 (Chris Wilson): - Pass current engine seqno to ring_idle() from i915_hangcheck_elapsed() rather than compute it over again. - Remove extra whitespace. Issue: VIZ-5998 Signed-off-by: Tomas Elf Reviewed-by: Chris Wilson [danvet: Add regressing commit citation provided by Chris.] Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 0f2bb042f21bdb28f20efcf1ff1c507e2f8b3caa Author: Chris Wilson Date: Mon Jun 29 14:01:19 2015 +0100 drm/i915: Declare the swizzling unknown for L-shaped configurations commit 19ee835cdb0b5a8eb11a68f25a51b8039d564488 upstream. The old style of memory interleaving swizzled upto the end of the first even bank of memory, and then used the remainder as unswizzled on the unpaired bank - i.e. swizzling is not constant for all memory. This causes problems when we try to migrate memory and so the kernel prevents migration at all when we detect L-shaped inconsistent swizzling. However, this issue also extends to userspace who try to manually detile into memory as the swizzling for an individual page is unknown (it depends on its physical address only known to the kernel), userspace cannot correctly swizzle objects. v2: Mark the global swizzling as unknown rather than adjust the value reported to userspace. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91105 Signed-off-by: Chris Wilson Cc: Daniel Vetter Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit fb07c9c85095d9520c4d4db69bef70442ec62a72 Author: Jani Nikula Date: Fri Jun 26 14:18:56 2015 +0300 drm/i915: fix backlight after resume on 855gm commit 2059ac3b1304cb6a82f9d90762dea9f556831627 upstream. Some 855gm models (at least ThinkPad X40) regressed because of commit b0cd324faed23d10d66ba6ade66579c681feef6f Author: Jani Nikula Date: Wed Nov 12 16:25:43 2014 +0200 drm/i915: don't save/restore backlight hist ctl registers which tried to make our driver more robust by not blindly saving and restoring registers, but it failed to take into account commit 0eb96d6ed38430b72897adde58f5477a6b71757a Author: Jesse Barnes Date: Wed Oct 14 12:33:41 2009 -0700 drm/i915: save/restore BLC histogram control reg across suspend/resume Fix the regression by enabling hist ctl on gen2. v2: Improved the comment. v3: Improved the comment, again. Reported-and-tested-by: Philipp Gesang References: http://mid.gmane.org/20150623222648.GD12335@acheron Fixes: b0cd324faed2 ("drm/i915: don't save/restore backlight hist ctl registers") Cc: Ville Syrjälä Acked-by: Chris Wilson Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 6947522ca7e23f92dc5e29fa7d2a3e68df3d7d04 Author: Rodrigo Vivi Date: Thu May 28 11:07:11 2015 -0700 drm/i915: Fix IPS related flicker commit ac88cd738425e04dbed3706621cf613a00708834 upstream. We cannot let IPS enabled with no plane on the pipe: BSpec: "IPS cannot be enabled until after at least one plane has been enabled for at least one vertical blank." and "IPS must be disabled while there is still at least one plane enabled on the same pipe as IPS." This restriction apply to HSW and BDW. However a shortcut path on update primary plane function to make primary plane invisible by setting DSPCTRL to 0 was leting IPS enabled while there was no other plane enabled on the pipe causing flickerings that we were believing that it was caused by that other restriction where ips cannot be used when pixel rate is greater than 95% of cdclok. v2: Don't mess with Atomic path as pointed out by Ville. Reference: https://bugs.freedesktop.org/show_bug.cgi?id=85583 Cc: Ville Syrjälä Cc: Paulo Zanoni Signed-off-by: Rodrigo Vivi Reviewed-by: Ville Syrjälä Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 28362ad0c52531e85a296ba2c3623c220101c628 Author: Michel Thierry Date: Thu Jun 25 12:59:38 2015 +0100 drm/i915/ppgtt: Break loop in gen8_ppgtt_clear_range failure path commit 00245266b4be4fbe989ee073663f56716da6c1f3 upstream. If for some reason [1], the page directory/table does not exist, clear_range would end up in an infinite while loop. Introduced by commit 06fda602dbca ("drm/i915: Create page table allocators"). [1] This is already being addressed in one of Mika's patches: http://mid.gmane.org/1432314314-23530-17-git-send-email-mika.kuoppala@intel.com Cc: Mika Kuoppala Reported-by: John Harrison Signed-off-by: Michel Thierry Reviewed-by: Mika Kuoppala Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 598f69d4fb04f188a819bf649c0b35dd4225dc8d Author: Alex Deucher Date: Mon May 18 11:11:48 2015 -0400 drm/radeon: clean up radeon_audio_enable commit 010621936103fcfc15375ccdc92c0f583923d489 upstream. - make it static - fix mask/bool handling for last param Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 32d12fc20e3c726ca858d0e5055fb596fce2f8bc Author: Alex Deucher Date: Fri May 15 11:48:52 2015 -0400 drm/radeon: take the mode_config mutex when dealing with hpds (v2) commit 39fa10f7e21574a70cecf1fed0f9b36535aa68a0 upstream. Since we are messing with state in the worker. v2: drop the changes in the mst worker Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit c074d39c847fa25c63bff1361ac0518ccd1f2fef Author: Andrey Ryabinin Date: Mon May 25 13:29:44 2015 +0300 drm/atomic: fix out of bounds read in for_each_*_in_state helpers commit 60f207a5b6d8f23c2e8388b415e8d5c7311cc79d upstream. for_each_*_in_state validate array index after access to array elements, thus perform out of bounds read. Fix this by validating index in the first place and read array element iff validation was successful. Fixes: df63b9994eaf ("drm/atomic: Add for_each_{connector,crtc,plane}_in_state helper macros") Signed-off-by: Andrey Ryabinin Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit db4d9159da3f595b964d986cb53d33fd24e5774c Author: Geert Uytterhoeven Date: Tue May 5 18:32:17 2015 +0200 drm/bridge: ptn3460: Include linux/gpio/consumer.h commit dad3c3503462f59c6bec7edfa19dbde1857962c0 upstream. If GPIOLIB=n and asm-generic/gpio.h is not used: drivers/gpu/drm/bridge/ptn3460.c: In function ‘ptn3460_pre_enable’: drivers/gpu/drm/bridge/ptn3460.c:135: error: implicit declaration of function ‘gpiod_set_value’ drivers/gpu/drm/bridge/ptn3460.c: In function ‘ptn3460_probe’: drivers/gpu/drm/bridge/ptn3460.c:333: error: implicit declaration of function ‘devm_gpiod_get’ drivers/gpu/drm/bridge/ptn3460.c:333: warning: assignment makes pointer from integer without a cast drivers/gpu/drm/bridge/ptn3460.c:340: error: implicit declaration of function ‘gpiod_direction_output’ drivers/gpu/drm/bridge/ptn3460.c:346: warning: assignment makes pointer from integer without a cast Add the missing #include to fix this. Fixes: af478d8823 ("drm/bridge: ptn3460: use gpiod interface") Signed-off-by: Geert Uytterhoeven Cc: David Airlie Cc: dri-devel@lists.freedesktop.org Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit e0cf83cc3de0341d8cabbb23097ad85f5ce97a11 Author: Frediano Ziglio Date: Wed Jun 3 12:09:10 2015 +0100 drm/qxl: Do not leak memory if qxl_release_list_add fails commit 8451cc964c1d193b989c41a44e5e77109cc696f8 upstream. If the function fails reference counter to the object is not decremented causing leaks. This is hard to spot as it happens only on very low memory situations. Signed-off-by: Frediano Ziglio Reviewed-by: Dave Airlie Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 3d47c41f985273eaee48e8b1b72a41f5b126cd70 Author: Frediano Ziglio Date: Wed Jun 3 12:09:09 2015 +0100 drm/qxl: Do not cause spice-server to clean our objects commit 2fa19535ca6abcbfd1ccc9ef694db52f49f77747 upstream. If objects are moved back from system memory to VRAM (and spice id created again) memory is already initialized so we need to set flag to not clear memory. If you don't do it after a while using desktop many images turns to black or transparents. Signed-off-by: Frediano Ziglio Reviewed-by: Dave Airlie Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 3950be0f2d0feef1a8e647af82af861cd020c81e Author: Thierry Reding Date: Thu Jun 11 18:33:48 2015 +0200 drm/tegra: dpaux: Fix transfers larger than 4 bytes commit 3c1dae0a07c651526f8e878d223a88f82caa5a50 upstream. The DPAUX read/write FIFO registers aren't sequential in the register space, causing transfers larger than 4 bytes to cause accesses to non- existing FIFO registers. Fixes: 6b6b604215c6 ("drm/tegra: Add eDP support") Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit c8f84f037a61845643f4f86bf9ba49494a65e2c0 Author: Daniel Vetter Date: Mon Jun 22 17:31:59 2015 +1000 drm/dp/mst: make sure mst_primary mstb is valid in work function commit 9254ec496a1dbdddeab50021a8138dc627a8166a upstream. This validates the mst_primary under the lock, and then calls into the check and send function. This makes the code a lot easier to understand the locking rules in. Signed-off-by: Daniel Vetter Reviewed-by: Daniel Vetter Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit e60bd2d701a57d0cd9fe53de5e1426af03874c0d Author: Dave Airlie Date: Mon Jun 22 14:40:44 2015 +1000 drm/dp/mst: take lock around looking up the branch device on hpd irq commit 9eb1e57f564d4e6e10991402726cc83fe0b9172f upstream. If we are doing an MST transaction and we've gotten HPD and we lookup the device from the incoming msg, we should take the mgr lock around it, so that mst_primary and mstb->ports are valid. Reviewed-by: Daniel Vetter Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 5c507167d2ef467ecd2ec4ad40a0bd70b4fad814 Author: Dave Airlie Date: Mon Jun 15 10:34:28 2015 +1000 drm/dp/mst: close deadlock in connector destruction. commit 6b8eeca65b18ae77e175cc2b6571731f0ee413bf upstream. I've only seen this once, and I failed to capture the lockdep backtrace, but I did some investigations. If we are calling into the MST layer from EDID probing, we have the mode_config mutex held, if during that EDID probing, the MST hub goes away, then we can get a deadlock where the connector destruction function in the driver tries to retake the mode config mutex. This offloads connector destruction to a workqueue, and avoid the subsequenct lock ordering issue. Acked-by: Daniel Vetter Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 0f0b7b10c3545704cf0d1705e33f1cc5a9fe8097 Author: Daniel Vetter Date: Tue Jun 23 16:35:06 2015 +0200 drm/vgem: Set unique to "vgem" commit fa2f97dd33c2c32a06a5ea7f6e87af06a2e26baa upstream. Since there's only one global instance ever we don't need to have anything fancy. Stops a WARNING in the get_unique ioctl that the unique name isn't set. Reportedy-and-tested-by: Fabio Coatti Cc: Fabio Coatti Signed-off-by: Daniel Vetter Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 95f9b41004efdfe910aaf91b5d79f32d532845b1 Author: Pawel Moll Date: Thu Apr 2 18:50:32 2015 +0100 bus: arm-ccn: Fix node->XP config conversion commit a18f8e97fe69195823d7fb5c68a8d6565f39db4b upstream. Events defined as watchpoints on nodes must have their config values converted so that they apply to the respective node's XP. The function setting new values was using wrong mask for the "port" field, resulting in corrupted value. Fixed now. Signed-off-by: Pawel Moll Signed-off-by: Greg Kroah-Hartman commit 8aef146bbff57b508e8adfb3541dbc464abe3676 Author: Boris Brezillon Date: Wed Jun 17 10:59:05 2015 +0200 ARM: at91/dt: update udc compatible strings commit 6540165cf41655810ee67b78f01537af022a636a upstream. at91sam9g45, at91sam9x5 and sama5 SoCs should not use "atmel,at91sam9rl-udc" for their USB device compatible property since this compatible is attached to a specific hardware bug fix. Signed-off-by: Boris Brezillon Acked-by: Alexandre Belloni Tested-by: Bo Shen Acked-by: Nicolas Ferre Signed-off-by: Kevin Hilman Signed-off-by: Greg Kroah-Hartman commit 70e421867746a693dd01b05531c4787e0747666e Author: Nicolas Ferre Date: Wed Jun 17 10:59:04 2015 +0200 ARM: at91/dt: trivial: fix USB udc compatible string commit 50f0a44991516b5b9744ecb2c080c2ec6ad21b25 upstream. To please checkpatch and the tiresome reader, add the "atmel," prefix to the USB udc compatible string. Signed-off-by: Nicolas Ferre Signed-off-by: Kevin Hilman Signed-off-by: Greg Kroah-Hartman commit 6e853d1593afa65bcddaa991b1b4fef508262317 Author: Nicolas Ferre Date: Mon May 11 13:00:31 2015 +0200 tty/serial: at91: RS485 mode: 0 is valid for delay_rts_after_send commit 8687634b7908c42eb700e0469e110e02833611d1 upstream. In RS485 mode, we may want to set the delay_rts_after_send value to 0. In the datasheet, the 0 value is said to "disable" the Transmitter Timeguard but this is exactly the expected behavior if we want no delay... Moreover, if the value was set to non-zero value by device-tree or earlier ioctl command, it was impossible to change it back to zero. Reported-by: Sami Pietikäinen Signed-off-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman commit e4b5f20b9d80d0d87af5d1393f6fdab98245dc41 Author: ludovic.desroches@atmel.com Date: Mon Jun 8 15:55:48 2015 +0200 ARM: at91/dt: sama5d4: fix dma conf for aes, sha and tdes nodes commit aabbe8f1a561dd8318e693830d9ae377c9a04d2b upstream. The xdmac channel configuration is done in one cell not two. This error prevents from probing devices correctly. Signed-off-by: Ludovic Desroches Fixes: 83906783b766 ("ARM: at91/dt: sama5d4: add aes, sha and tdes nodes") Acked-by: Nicolas Ferre Signed-off-by: Kevin Hilman Signed-off-by: Greg Kroah-Hartman commit 85d5e517fe566cc3581d2220c321e9ee11d2022f Author: Ludovic Desroches Date: Thu May 28 11:55:16 2015 +0200 ARM: at91/dt: sama5d4ek: mci0 uses slot 0 commit ea25525ce0d195724fead07fe6562fe478a3bf6f upstream. Mci0 uses slot 0 not 1. Signed-off-by: Ludovic Desroches Fixes: 7a4752677c44 ("ARM: at91: dt: add device tree file for SAMA5D4ek board") Signed-off-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman commit f7639d364c02eff91f433aca4e2d9ddaf37fb099 Author: Martin K. Petersen Date: Wed Jul 22 07:57:12 2015 -0400 block: Do a full clone when splitting discard bios commit f3f5da624e0a891c34d8cd513c57f1d9b0c7dadc upstream. This fixes a data corruption bug when using discard on top of MD linear, raid0 and raid10 personalities. Commit 20d0189b1012 "block: Introduce new bio_split()" permits sharing the bio_vec between the two resulting bios. That is fine for read/write requests where the bio_vec is immutable. For discards, however, we need to be able to attach a payload and update the bio_vec so the page can get mapped to a scatterlist entry. Therefore the bio_vec can not be shared when splitting discards and we must do a full clone. Signed-off-by: Martin K. Petersen Reported-by: Seunguk Shin Tested-by: Seunguk Shin Cc: Seunguk Shin Cc: Jens Axboe Cc: Kent Overstreet Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit adc7a64b2882aba125431dd22e4e364b71ff37c6 Author: Ming Lei Date: Tue May 5 19:49:55 2015 +0800 block: loop: avoiding too many pending per work I/O commit 4d4e41aef9429872ea3b105e83426941f7185ab6 upstream. If there are too many pending per work I/O, too many high priority work thread can be generated so that system performance can be effected. This patch limits the max_active parameter of workqueue as 16. This patch fixes Fedora 22 live booting performance regression when it is booted from squashfs over dm based on loop, and looks the following reasons are related with the problem: - not like other filesyststems(such as ext4), squashfs is a bit special, and I observed that increasing I/O jobs to access file in squashfs only improve I/O performance a little, but it can make big difference for ext4 - nested loop: both squashfs.img and ext3fs.img are mounted as loop block, and ext3fs.img is inside the squashfs - during booting, lots of tasks may run concurrently Fixes: b5dd2f6047ca108001328aac0e8588edd15f1778 Cc: Justin M. Forbes Signed-off-by: Ming Lei Acked-by: Tejun Heo Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 7c9da37f27a40fabe91dae40efb6117e97469326 Author: Ming Lei Date: Tue May 5 19:49:54 2015 +0800 block: loop: convert to per-device workqueue commit f4aa4c7bbac6c4afdd4adccf90898c1a3685396d upstream. Documentation/workqueue.txt: If there is dependency among multiple work items used during memory reclaim, they should be queued to separate wq each with WQ_MEM_RECLAIM. Loop devices can be stacked, so we have to convert to per-device workqueue. One example is Fedora live CD. Fixes: b5dd2f6047ca108001328aac0e8588edd15f1778 Cc: Justin M. Forbes Signed-off-by: Ming Lei Acked-by: Tejun Heo Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 4f27844f84d6dd76fe84d25c5bece18295d870f6 Author: Tomas Winkler Date: Thu Jul 16 15:50:45 2015 +0200 mmc: block: Add missing mmc_blk_put() in power_ro_lock_show() commit 9098f84cced870f54d8c410dd2444cfa61467fa0 upstream. Enclosing mmc_blk_put() is missing in power_ro_lock_show() sysfs handler, let's add it. Fixes: add710eaa886 ("mmc: boot partition ro lock support") Signed-off-by: Tomas Winkler Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit be22af9f28db4b669969b0ea231d5ecb4dc7b01d Author: Joe Thornber Date: Fri Jul 3 14:51:32 2015 +0100 dm btree: silence lockdep lock inversion in dm_btree_del() commit 1c7518794a3647eb345d59ee52844e8a40405198 upstream. Allocate memory using GFP_NOIO when deleting a btree. dm_btree_del() can be called via an ioctl and we don't want to recurse into the FS or block layer. Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit b2ce140833c6cc81068f2c9d2cbefd78be7550bf Author: Joe Thornber Date: Fri Jul 3 10:22:42 2015 +0100 dm thin: allocate the cell_sort_array dynamically commit a822c83e47d97cdef38c4352e1ef62d9f46cfe98 upstream. Given the pool's cell_sort_array holds 8192 pointers it triggers an order 5 allocation via kmalloc. This order 5 allocation is prone to failure as system memory gets more fragmented over time. Fix this by allocating the cell_sort_array using vmalloc. Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 3fa6173cb7abee0d4fe493bc71665aa12188bace Author: Dennis Yang Date: Fri Jun 26 15:25:48 2015 +0100 dm btree remove: fix bug in redistribute3 commit 4c7e309340ff85072e96f529582d159002c36734 upstream. redistribute3() shares entries out across 3 nodes. Some entries were being moved the wrong way, breaking the ordering. This manifested as a BUG() in dm-btree-remove.c:shift() when entries were removed from the btree. For additional context see: https://www.redhat.com/archives/dm-devel/2015-May/msg00113.html Signed-off-by: Dennis Yang Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 0cb6b5abbc5f4a4e237c9c42c4a5014217038891 Author: Joe Thornber Date: Wed Jun 17 13:35:19 2015 +0100 dm space map metadata: fix occasional leak of a metadata block on resize commit 6096d91af0b65a3967139b32d5adbb3647858a26 upstream. The metadata space map has a simplified 'bootstrap' mode that is operational when extending the space maps. Whilst in this mode it's possible for some refcount decrement operations to become queued (eg, as a result of shadowing one of the bitmap indexes). These decrements were not being applied when switching out of bootstrap mode. The effect of this bug was the leaking of a 4k metadata block. This is detected by the latest version of thin_check as a non fatal error. Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 3198d36127dc9015017926b4d905cc62de962f90 Author: Mikulas Patocka Date: Fri Jun 5 09:50:42 2015 -0400 dm stats: fix divide by zero if 'number_of_areas' arg is zero commit dd4c1b7d0c95be1c9245118a3accc41a16f1db67 upstream. If the number_of_areas argument was zero the kernel would crash on div-by-zero. Add better input validation. Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 3bf9ad4c48534dd0d7f201e315c340069a244664 Author: Joe Thornber Date: Wed May 20 10:30:32 2015 +0100 dm cache: fix race when issuing a POLICY_REPLACE operation commit fb4100ae7f312c3d614b37621c2b17b3b7cf65f8 upstream. There is a race between a policy deciding to replace a cache entry, the core target writing back any dirty data from this block, and other IO threads doing IO to the same block. This sort of problem is avoided most of the time by the core target grabbing a bio prison cell before making the request to the policy. But for a demotion the core target doesn't know which block will be demoted, so can't do this in advance. Fix this demotion race by introducing a callback to the policy interface that allows the policy to grab the cell on behalf of the core target. Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 0906f9b902c18323bd82945a272432ba3330191a Author: AMAN DEEP Date: Tue Jul 21 17:20:27 2015 +0300 usb: xhci: Bugfix for NULL pointer deference in xhci_endpoint_init() function commit 3496810663922617d4b706ef2780c279252ddd6a upstream. virt_dev->num_cached_rings counts on freed ring and is not updated correctly. In xhci_free_or_cache_endpoint_ring() function, the free ring is added into cache and then num_rings_cache is incremented as below: virt_dev->ring_cache[rings_cached] = virt_dev->eps[ep_index].ring; virt_dev->num_rings_cached++; here, free ring pointer is added to a current index and then index is incremented. So current index always points to empty location in the ring cache. For getting available free ring, current index should be decremented first and then corresponding ring buffer value should be taken from ring cache. But In function xhci_endpoint_init(), the num_rings_cached index is accessed before decrement. virt_dev->eps[ep_index].new_ring = virt_dev->ring_cache[virt_dev->num_rings_cached]; virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL; virt_dev->num_rings_cached--; This is bug in manipulating the index of ring cache. And it should be as below: virt_dev->num_rings_cached--; virt_dev->eps[ep_index].new_ring = virt_dev->ring_cache[virt_dev->num_rings_cached]; virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL; Signed-off-by: Aman Deep Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit e951f84074b84a3f5aecbffd01da74576e0068d5 Author: Lu Baolu Date: Tue Jun 16 09:08:26 2015 +0800 usb: core: lpm: set lpm_capable for root hub device commit 2d2a316765d956bc5cb6bb367b2ec52ca59ab8e9 upstream. Commit 25cd2882e2fc ("usb/xhci: Change how we indicate a host supports Link PM.") removed the code to set lpm_capable for USB 3.0 super-speed root hub. The intention of that change was to avoid touching usb core internal field, a.k.a. lpm_capable, and let usb core to set it by checking U1 and U2 exit latency values in the descriptor. Usb core checks and sets lpm_capable in hub_port_init(). Unfortunately, root hub is a special usb device as it has no parent. Hub_port_init() will never be called for a root hub device. That means lpm_capable will by no means be set for the root hub. As the result, lpm isn't functional at all in Linux kernel. This patch add the code to check and set lpm_capable when registering a root hub device. It could be back-ported to kernels as old as v3.15, that contains the Commit 25cd2882e2fc ("usb/xhci: Change how we indicate a host supports Link PM."). Reported-by: Kevin Strasser Signed-off-by: Lu Baolu Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 2c231aeff7e41ddd011417973262b78914b45899 Author: Alan Stern Date: Tue Jun 30 11:25:54 2015 -0400 USB: OHCI: Fix race between ED unlink and URB submission commit 7d8021c967648accd1b78e5e1ddaad655cd2c61f upstream. This patch fixes a bug introduced by commit 977dcfdc6031 ("USB: OHCI: don't lose track of EDs when a controller dies"). The commit changed ed_state from ED_UNLINK to ED_IDLE too early, before finish_urb() had been called. The user-visible consequence is that the driver occasionally crashes or locks up when an URB is submitted while another URB for the same endpoint is being unlinked. This patch moves the ED state change later, to the right place. The drawback is that now we may unnecessarily execute some instructions multiple times when a controller dies. Since controllers dying is an exceptional occurrence, a little wasted time won't matter. Signed-off-by: Alan Stern Reported-by: Heiko Przybyl Tested-by: Heiko Przybyl Fixes: 977dcfdc60311e7aa571cabf6f39c36dde13339e Signed-off-by: Greg Kroah-Hartman commit ba4ba9b026589f920909f6a5f2e3bfa861b162fb Author: Johannes Thumshirn Date: Wed Jul 8 17:26:37 2015 +0200 USB: serial: Destroy serial_minors IDR on module exit commit d23f47d4927fd2f61b3a754d83c7bcec215b5cfe upstream. Destroy serial_minors IDR on module exit, reclaiming the allocated memory. This was detected by the following semantic patch (written by Luis Rodriguez ) @ defines_module_init @ declarer name module_init, module_exit; declarer name DEFINE_IDR; identifier init; @@ module_init(init); @ defines_module_exit @ identifier exit; @@ module_exit(exit); @ declares_idr depends on defines_module_init && defines_module_exit @ identifier idr; @@ DEFINE_IDR(idr); @ on_exit_calls_destroy depends on declares_idr && defines_module_exit @ identifier declares_idr.idr, defines_module_exit.exit; @@ exit(void) { ... idr_destroy(&idr); ... } @ missing_module_idr_destroy depends on declares_idr && defines_module_exit && !on_exit_calls_destroy @ identifier declares_idr.idr, defines_module_exit.exit; @@ exit(void) { ... +idr_destroy(&idr); } Signed-off-by: Johannes Thumshirn Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 8701f782b511f75be55315c92426f7197908ea86 Author: Claudio Cappelli Date: Wed Jun 10 20:38:30 2015 +0200 USB: option: add 2020:4000 ID commit f6d7fb37f92622479ef6da604f27561f5045ba1e upstream. Add device Olivetti Olicard 300 (Network Connect: MT6225) - IDs 2020:4000. T: Bus=01 Lev=02 Prnt=04 Port=00 Cnt=01 Dev#= 10 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2020 ProdID=4000 Rev=03.00 S: Manufacturer=Network Connect S: Product=MT6225 C: #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 Driver=option I: If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage Signed-off-by: Claudio Cappelli Suggested-by: Lars Melin [johan: amend commit message with devices info ] Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 7e5423dc7b2589e2f781274da8f112fb13c07a50 Author: Peter Sanford Date: Thu Jun 25 17:40:05 2015 -0700 USB: cp210x: add ID for Aruba Networks controllers commit f98a7aa81eeeadcad25665c3501c236d531d4382 upstream. Add the USB serial console device ID for Aruba Networks 7xxx series controllers which have a USB port for their serial console. Signed-off-by: Peter Sanford Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 13d5f386c4978fd3ab9bbe92013ede0c21bbaed1 Author: Felipe Balbi Date: Tue Jun 2 13:03:36 2015 -0500 usb: musb: host: rely on port_mode to call musb_start() commit be9d39881fc4fa39a64b6eed6bab5d9ee5125344 upstream. Currently, we're calling musb_start() twice for DRD ports in some situations. This has been observed to cause enumeration issues after suspend/resume cycles with AM335x. In order to fix the problem, we just have to fix the check on musb_has_gadget() so that it only returns true if current mode is Host and ignore the fact that we have or not a gadget driver loaded. Fixes: ae44df2e21b5 (usb: musb: call musb_start() only once in OTG mode) Cc: Sebastian Andrzej Siewior Tested-by: Sekhar Nori Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 1fd1fe35f15436869e182c1fb075d9f837dcf0c2 Author: Michal Nazarewicz Date: Fri Jun 19 23:56:34 2015 +0200 usb: f_mass_storage: limit number of reported LUNs commit 8515bac01a983d277148e4fcc5f235bf603de577 upstream. Mass storage function created via configfs always reports eight LUNs to the hosts even if only one LUN has been configured. Adjust the number when the USB function is allocated based on LUNs that user has created. Tested-by: Gregory CLEMENT Signed-off-by: Michal Nazarewicz Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 35dff3a0bd57b32df5d7990fddbf4e54d96a4621 Author: Alexey Khoroshilov Date: Sun Jul 19 23:13:28 2015 +0700 usb: gadget: mv_udc_core: fix phy_regs I/O memory leak commit 53e20f2eb161fbe9eea28b54dccc870cec94eca2 upstream. There was an omission in transition to devm_xxx resource handling. iounmap(udc->phy_regs) were removed, but ioremap() was left without devm_. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov Fixes: 3517c31a8ece6 ("usb: gadget: mv_udc: use devm_xxx for probe") Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 4db43b5199062e0c6f0424462ce8c4978bcecf15 Author: Rui Miguel Silva Date: Mon May 18 16:02:07 2015 +0100 usb: gadget: f_fs: do not set cancel function on synchronous {read,write} commit 4088acf1e845aba35f30fb91dee10649edbd0e84 upstream. do not try to set cancel function in synchronous operations in ffs_epfile_{read,write}_iter. Acked-by: Al Viro Signed-off-by: Rui Miguel Silva Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit c856349b0e83bf406242a1a3e44f8391d71fd5a8 Author: Kishon Vijay Abraham I Date: Thu Jun 11 22:12:11 2015 +0530 usb: gadget: composite: Fix NULL pointer dereference commit b4c21f0bdd2c0cd5d5be1bb56f0a28dae5041eed upstream. commit f563d230903210acc ("usb: gadget: composite: add req_match method to usb_function") accesses cdev->config even before set config is invoked causing a NULL pointer dereferencing error while running Lecroy Mass Storage Compliance test. Fix it here by accessing cdev->config only if it is non NULL. Fixes: commit f563d230903210acc ("usb: gadget: composite: add req_match method to usb_function"). Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit a808fa062ff7ec85b7b0a344df52329083f044b0 Author: Thomas Hebb Date: Thu Jul 2 01:04:18 2015 -0400 phy: berlin-usb: fix divider for BG2CD commit 96696a9df935d15fd2e89603454c20a692ec232a upstream. The marvell,berlin2cd-usb-phy compatible incorrectly sets the PLL divider to BG2's value instead of BG2CD/BG2Q's. Change it to the right value. Signed-off-by: Thomas Hebb Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Greg Kroah-Hartman commit cc4c7d238d166b4e92878a113f00f7e6d4044041 Author: Stefan Wahren Date: Mon Jun 15 04:37:00 2015 +0000 usb: phy: mxs: suspend to RAM causes NULL pointer dereference commit 543aa4867d4a2dff5fc11e1b688197ee3bad7f89 upstream. Triggering suspend to RAM via sysfs on a i.MX28 causes a NULL pointer dereference. This patch avoids the oops in mxs_phy_get_vbus_status() by aborting since there is no syscon available. Signed-off-by: Stefan Wahren Fixes: efdbd3a5d6e ("usb: phy: mxs: do not set PWD.RXPWD1PT1 for low speed connection") Acked-by: Peter Chen Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit d1221a608bd19cc6b539cffacfad3e104fcff0ef Author: NeilBrown Date: Thu Apr 16 18:03:04 2015 +1000 phy: twl4030-usb: remove incorrect pm_runtime_get_sync() in probe function. commit 4724e27114c4a7eceeee07db227a17fcab6f165c upstream. The USB phy should initialize with power-off, and will be powered on by the USB system when a cable connection is detected. Having this pm_runtime_get_sync() during probe causes the phy to *always* be powered on. Removing it returns to sensible power management. Fixes: 96be39ab34b77c6f6f5cd6ae03aac6c6449ee5c4 Signed-off-by: NeilBrown Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Greg Kroah-Hartman commit f32f8e6652d70c8453129fc4b9048a1eef6bc48c Author: Dan Carpenter Date: Mon May 18 15:29:51 2015 +0300 USB: devio: fix a condition in async_completed() commit 83ed07c5db71bc02bd646d6eb60b48908235cdf9 upstream. Static checkers complain that the current condition is never true. It seems pretty likely that it's a typo and "URB" was intended instead of "USB". Fixes: 3d97ff63f899 ('usbdevfs: Use scatter-gather lists for large bulk transfers') Signed-off-by: Dan Carpenter Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 2c2e438cbb85386f4622626bfcb20f799980c9e1 Author: Robert Schlabbach Date: Tue May 26 00:27:30 2015 +0200 usb: core: Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset commit fb6d1f7df5d25299fd7b3e84b72b8851d3634764 upstream. Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset. Dissolve the function hub_port_finish_reset() completely and divide the actions to be taken into those which need to be done after each reset attempt and those which need to be done after the full procedure is complete, and place them in the appropriate places in hub_port_reset(). Also, remove an unneeded forward declaration of hub_port_reset(). Verbose Problem Description: USB 3.0 devices may be "lost for good" during a hub port reset. This makes Linux unable to boot from USB 3.0 devices in certain constellations of host controllers and devices, because the USB device is lost during initialization, preventing the rootfs from being mounted. The underlying problem is that in the affected constellations, during the processing inside hub_port_reset(), the hub link state goes from 0 to SS.inactive after the initial reset, and back to 0 again only after the following "warm" reset. However, hub_port_finish_reset() is called after each reset attempt and sets the state the connected USB device based on the "preliminary" status of the hot reset to USB_STATE_NOTATTACHED due to SS.inactive, yet when the following warm reset is complete and hub_port_finish_reset() is called again, its call to set the device to USB_STATE_DEFAULT is blocked by usb_set_device_state() which does not allow taking USB devices out of USB_STATE_NOTATTACHED state. Thanks to Alan Stern for guiding me to the proper solution and how to submit it. Link: http://lkml.kernel.org/r/trinity-25981484-72a9-4d46-bf17-9c1cf9301a31-1432073240136%20()%203capp-gmx-bs27 Signed-off-by: Robert Schlabbach Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit b7473317530efd0b80cfdeba8a196a4d8fe49d69 Author: John Youn Date: Mon Sep 17 00:00:00 2001 -0700 usb: dwc3: Reset the transfer resource index on SET_INTERFACE commit aebda618718157a69c0dc0adb978d69bc2b8723c upstream. This fixes an issue introduced in commit b23c843992b6 (usb: dwc3: gadget: fix DEPSTARTCFG for non-EP0 EPs) that made sure we would only use DEPSTARTCFG once per SetConfig. The trick is that we should use one DEPSTARTCFG per SetConfig *OR* SetInterface. SetInterface was completely missed from the original patch. This problem became aparent after commit 76e838c9f776 (usb: dwc3: gadget: return error if command sent to DEPCMD register fails) added checking of the return status of device endpoint commands. 'Set Endpoint Transfer Resource' command was caught failing occasionally. This is because the Transfer Resource Index was not getting reset during a SET_INTERFACE request. Finally, to fix the issue, was we have to do is make sure that our start_config_issued flag gets reset whenever we receive a SetInterface request. To verify the problem (and its fix), all we have to do is run test 9 from testusb with 'testusb -t 9 -s 2048 -a -c 5000'. Tested-by: Huang Rui Tested-by: Subbaraya Sundeep Bhatta Fixes: b23c843992b6 (usb: dwc3: gadget: fix DEPSTARTCFG for non-EP0 EPs) Signed-off-by: John Youn Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 0343379cabd1736cce291f4555d239a66813f987 Author: Felipe Balbi Date: Fri May 29 10:06:38 2015 -0500 usb: dwc3: gadget: don't clear EP_BUSY too early commit e18b7975c885bc3a938b9a76daf32957ea0235fa upstream. In case of non-Isochronous transfers, we don't want to clear DWC3_EP_BUSY flag until XferComplete event. That's because XferInProgress was only enabled so we can recycle TRBs and usb_requests quicker, but there are still other pending requests being transferred. In order to make sure we don't allow for another StartTransfer command while the HW is still processing other transfers, we must keep DWC3_EP_BUSY flag set and this what this patch does. Fixes: f3af36511e60 (usb: dwc3: gadget: always enable IOC on bulk/interrupt transfers) Reported-by: sundeep subbaraya Tested-by: sundeep subbaraya Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit f46bc2957ec103ae9dccf4eb55ad2c40173c5144 Author: Subbaraya Sundeep Bhatta Date: Thu May 21 15:46:48 2015 +0530 usb: dwc3: gadget: return error if command sent to DEPCMD register fails commit 76e838c9f7765f9a6205b4d558d75a66104bc60d upstream. We need to return error to caller if command is not sent to controller succesfully. Signed-off-by: Subbaraya Sundeep Bhatta Fixes: 72246da40f37 (usb: Introduce DesignWare USB3 DRD Driver) Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 2dc7e2d5d7dca18c9f8a8cf5c0d2d3c5591af9a8 Author: Subbaraya Sundeep Bhatta Date: Thu May 21 15:46:47 2015 +0530 usb: dwc3: gadget: return error if command sent to DGCMD register fails commit 891b1dc022955d36cf4c0f42d383226a930db7ed upstream. We need to return error to caller if command is not sent to controller succesfully. Signed-off-by: Subbaraya Sundeep Bhatta Fixes: b09bb64239c8 (usb: dwc3: gadget: implement Global Command support) Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 5a01a6e9d6f4a24039ceec3f9a38b196395d096d Author: Arne Fitzenreiter Date: Wed Jul 15 13:54:37 2015 +0200 libata: force disable trim for SuperSSpeed S238 commit cda57b1b05cf7b8b99ab4b732bea0b05b6c015cc upstream. This device loses blocks, often the partition table area, on trim. Disable TRIM. http://pcengines.ch/msata16a.htm Signed-off-by: Arne Fitzenreiter Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 5f5cc9ddc13efb5f1d2797e9b8df1d4c6e97296b Author: Martin K. Petersen Date: Wed Jul 15 21:03:23 2015 -0400 libata: Do not blacklist M510DC commit 9051bd393cf25e76dfb45409792719a854661500 upstream. A new Micron drive was just announced, once again recycling the first part of the model string. Add an underscore to the M510/M550 pattern to avoid picking up the new DC drive. Signed-off-by: Martin K. Petersen Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 3b1c86a973f2e665c1697d965e459bf1b6713825 Author: David Milburn Date: Mon Jul 13 11:48:23 2015 -0500 libata: add ATA_HORKAGE_MAX_SEC_1024 to revert back to previous max_sectors limit commit af34d637637eabaf49406eb35c948cd51ba262a6 upstream. Since no longer limiting max_sectors to BLK_DEF_MAX_SECTORS (commit 34b48db66e08), data corruption may occur on ST380013AS drive configured on 82801JI (ICH10 Family) SATA controller. This patch will allow the driver to limit max_sectors as before # cat /sys/block/sdb/queue/max_sectors_kb 512 I was able to double the max_sectors_kb value up to 16384 on linux-4.2.0-rc2 before seeing corruption, but seems safer to use previous limit. Without this patch max_sectors_kb will be 32767. tj: Minor comment update. Reported-by: Jeff Moyer Signed-off-by: David Milburn Signed-off-by: Tejun Heo Fixes: 34b48db66e08 ("block: remove artifical max_hw_sectors cap") Signed-off-by: Greg Kroah-Hartman commit 54150eb4cde1b758d788045d3ddc7ee336ce3d6d Author: Arne Fitzenreiter Date: Wed Jul 15 13:54:36 2015 +0200 libata: add ATA_HORKAGE_NOTRIM commit 71d126fd28de2d4d9b7b2088dbccd7ca62fad6e0 upstream. Some devices lose data on TRIM whether queued or not. This patch adds a horkage to disable TRIM. tj: Collapsed unnecessary if() nesting. Signed-off-by: Arne Fitzenreiter Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit e77d2137a071122135da5fa2418d5a7720bf7b07 Author: Martin K. Petersen Date: Mon May 4 21:54:19 2015 -0400 libata: Expose TRIM capability in sysfs commit f303074160d3401970ccae082014e1ee5a9a52c5 upstream. Create a sysfs "trim" attribute for each ata_device that displays whether DSM TRIM is "unsupported", "unqueued", "forced_unqueued" (blacklisted) or "queued". Signed-off-by: Martin K. Petersen Reviewed-by: Hannes Reinecke Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit a1fcca3abfc219a53e397d131d253603d9f04015 Author: Martin K. Petersen Date: Mon May 4 21:54:21 2015 -0400 libata: Fall back to unqueued READ LOG EXT if the DMA variant fails commit 5d3abf8ff67f49271a42c0f7fa4f20f9e046bf0e upstream. Some devices advertise support for the READ/WRITE LOG DMA EXT commands but fail when we try to issue them. This can lead to queued TRIM being unintentionally disabled since the relevant feature flag is located in a general purpose log page. Fall back to unqueued READ LOG EXT if the DMA variant fails while reading a log page. Signed-off-by: Martin K. Petersen Reviewed-by: Hannes Reinecke Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 822d2eac314e6d7ffc3e98d71676d3d9f6ef7894 Author: Mikulas Patocka Date: Wed Jul 8 13:06:12 2015 -0400 libata: increase the timeout when setting transfer mode commit d531be2ca2f27cca5f041b6a140504999144a617 upstream. I have a ST4000DM000 disk. If Linux is booted while the disk is spun down, the command that sets transfer mode causes the disk to spin up. The spin-up takes longer than the default 5s timeout, so the command fails and timeout is reported. Fix this by increasing the timeout to 15s, which is enough for the disk to spin up. Signed-off-by: Mikulas Patocka Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 5c040d16a3786184356bb0baaa6bc74294bfd88f Author: Aleksei Mamlin Date: Wed Jul 1 13:48:30 2015 +0300 libata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk for HP 250GB SATA disk VB0250EAVER commit 08c85d2a599d967ede38a847f5594447b6100642 upstream. Enabling AA on HP 250GB SATA disk VB0250EAVER causes errors: [ 3.788362] ata3.00: failed to enable AA (error_mask=0x1) [ 3.789243] ata3.00: failed to enable AA (error_mask=0x1) Add the ATA_HORKAGE_BROKEN_FPDMA_AA for this specific harddisk. tj: Collected FPDMA_AA entries and updated comment. Signed-off-by: Aleksei Mamlin Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit eda7047688d78e9450a73d82fef825fc3c384c70 Author: Martin K. Petersen Date: Thu Jun 18 14:50:18 2015 -0400 libata: Do not blacklist Micron M500DC commit 243918be6393f643e513a26e7882e6ae06ff7717 upstream. Queued TRIM got disabled on Micron M500DC drives thanks to the "Micron_M500*" pattern we had in place to accommodate the previous generation of this drive family. Tweak the blacklist entry slightly so we only disable queued TRIM for the non-DC variants of M500 drives. Signed-off-by: Martin K. Petersen Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 3041c3fb3bfc12bc2a5c9aa69d76cdb4c6f0476d Author: Peter Ujfalusi Date: Thu Jun 4 16:04:15 2015 +0300 ASoC: tas2552: Fix kernel crash caused by wrong kcontrol entry commit 1cf0f44811b754b64283b11ef0e60cb0de07b29c upstream. SOC_DAPM_SINGLE("Playback AMP", ..) should not be under kcontrols. It causes kernel crash (NULL pointer) when the mixers are listed. Signed-off-by: Peter Ujfalusi Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 849349aa2dabe93aee517f337e2394ab62921393 Author: Peter Ujfalusi Date: Thu Jun 4 16:04:14 2015 +0300 ASoC: tas2552: Fix kernel crash when the codec is loaded but not part of a card commit 80ba2669ec8c3e6517aa935001f6cb8809bf3df4 upstream. If the card is not part of any card the tas_data->codec is NULL since it is set only during snd_soc_codec_driver.probe, which is not yet called. Signed-off-by: Peter Ujfalusi Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 01567c41cfbca8fdc28565f0c33e89bbcb87ae2d Author: Zidan Wang Date: Thu Jun 11 19:14:36 2015 +0800 ASoC: wm8960: the enum of "DAC Polarity" should be wm8960_enum[1] commit a077e81ec61e07a7f86997d045109f06719fbffe upstream. the enum of "DAC Polarity" should be wm8960_enum[1]. Signed-off-by: Zidan Wang Acked-by: Charles Keepax Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 142796fdb1a12dfc52a5dfa152849b19b62ef3bf Author: Axel Lin Date: Mon May 11 09:04:06 2015 +0800 ASoC: wm8903: Fix define for WM8903_VMID_RES_250K commit ebb6ad73e645b8f2d098dd3c41d2ff0da4146a02 upstream. VMID Control 0 BIT[2:1] is VMID Divider Enable and Select 00 = VMID disabled (for OFF mode) 01 = 2 x 50kΩ divider (for normal operation) 10 = 2 x 250kΩ divider (for low power standby) 11 = 2 x 5kΩ divider (for fast start-up) So WM8903_VMID_RES_250K should be 2 << 1, which is 4. Signed-off-by: Axel Lin Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 98384697170b16d11a47d3e192ee4a0f5f8d7970 Author: Axel Lin Date: Fri May 15 09:15:16 2015 +0800 ASoC: wm8955: Fix setting wrong register for WM8955_K_8_0_MASK bits commit 12c350050538c7dc779c083b7342bfd20f74949c upstream. WM8955_K_8_0_MASK bits is controlled by WM8955_PLL_CONTROL_3 rather than WM8955_PLL_CONTROL_2. Signed-off-by: Axel Lin Acked-by: Charles Keepax Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 5d799a8697f8d2bfa228be19f1ac72d8e98ce895 Author: Axel Lin Date: Sun May 10 11:35:06 2015 +0800 ASoC: wm8737: Fixup setting VMID Impedance control register commit 14ba3ec1de043260cecd9e828ea2e3a0ad302893 upstream. According to the datasheet: R10 (0Ah) VMID Impedance Control BIT 3:2 VMIDSEL DEFAULT 00 DESCRIPTION: VMID impedance selection control 00: 75kΩ output 01: 300kΩ output 10: 2.5kΩ output WM8737_VMIDSEL_MASK is 0xC (VMIDSEL - [3:2]), so it needs to left shift WM8737_VMIDSEL_SHIFT bits for setting these bits. Signed-off-by: Axel Lin Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 91ff38153a7ba011a9bd56a0ffa52f6bed9d1059 Author: Arnd Bergmann Date: Tue May 19 14:47:32 2015 +0200 ASoC: omap: fix up SND_OMAP_SOC_OMAP_ABE_TWL6040 dependency, again commit 0574eab363ace70ef275d4caad6eadc458d33728 upstream. I tried to fix this before and submitted a working patch, but after some discussion we came up with what seemed to be a nicer solution, resulting in commit 3d4cf65e2d ("ASoC: omap: fix up SND_OMAP_SOC_OMAP_ABE_TWL6040 dependency"). Unfortunately, that version was incomplete, and we still get this build error: drivers/clk/clk-palmas.c:46:16: error: field 'hw' has incomplete type drivers/clk/clk-palmas.c: In function 'to_palmas_clks_info': drivers/clk/clk-palmas.c:54:74: warning: initialization from incompatible pointer type [-Winc This happens only in randconfig builds that turn on MFD_PALMAS on a platform other than OMAP2+ when COMPILE_TEST is set but COMMON_CLK is not. The new approach is only 'select COMMON_CLK_PALMAS' if we know that we are on an OMAP5 platform and MFD_PALMAS is already set. This patch has survived thousands of randconfig builds and I don't see a remaining hole in the logic. Fixes: 3d4cf65e2d ("ASoC: omap: fix up SND_OMAP_SOC_OMAP_ABE_TWL6040 dependency") Signed-off-by: Arnd Bergmann Acked-by: Peter Ujfalusi Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit ebfcb43f3fab1a01fa04bd5b167826c0b1d97742 Author: Dan Carpenter Date: Wed Jun 10 18:37:23 2015 +0300 ASoC: imx-wm8962: Add a missing error check commit 474ff0ae23b834e9fc18374d14bb5f3e7b3828b4 upstream. My static checker complains that: sound/soc/fsl/imx-wm8962.c:196 imx_wm8962_probe() warn: we tested 'ret' before and it was 'false' The intent was that we use "ret" to check imx_audmux_v2_configure_port(). Fixes: 8de2ae2a7f1f ('ASoC: fsl: add imx-wm8962 machine driver') Signed-off-by: Dan Carpenter Otherwise, Acked-by: Nicolin Chen Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit d23555e426b6531eccb1018714adfc1e6f762c6d Author: Arnd Bergmann Date: Thu May 21 11:07:08 2015 +0200 ASoC: qcom: remove incorrect dependencies commit a7310c496f376b945e7e61f64d69c9c0a93ee1ee upstream. Compile-tests show a warning for the newly added SND_SOC_STORM symbol: warning: (SND_SOC_STORM) selects SND_SOC_LPASS_CPU which has unmet direct dependencies (SOUND && !M68K && !UML && SND && SND_SOC && SND_SOC_QCOM) The problem is that it can be selected for COMPILE_TEST on non-QCOM builds, but the symbols it selects have a dependency. Dropping the dependencies makes it work without warnings and no other side-effects, because these are not user-visible. Signed-off-by: Arnd Bergmann Fixes: f380dd3f3cd ("ASoC: qcom: Add ability to build QCOM drivers") Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b5bb3aa87c167fcf227996e8ea6fc28332f316b4 Author: Axel Lin Date: Tue May 26 20:35:08 2015 +0800 ASoC: max98925: Fix mask for setting DAI invert mode commit 0b51601d4504f46f585eed823485101390f0b588 upstream. The M98925_DAI_WCI_MASK bit is not updated with current code. To properly set the DAI invert mode, the mask should be M98925_DAI_BCI_MASK | M98925_DAI_WCI_MASK. Signed-off-by: Axel Lin Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit d83057a32525626d96217f0112c7197b223180fe Author: Nicolas Boichat Date: Fri Jun 5 18:42:12 2015 +0800 ASoC: rt5645: Init jack_detect_work before registering irq commit 7ea3470a7277380248135a592a849e1c27960b2f upstream. Prevents frequent panic on boot, if the irq handler rt5645_irq gets called before the workqueue rt5645_jack_detect_work is initialized. Signed-off-by: Nicolas Boichat Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b955267c9fd99df9a4fcf1b2b570c3c1fa89d8ba Author: Richard Fitzgerald Date: Thu May 28 14:28:12 2015 +0100 ASoC: arizona: Fix noise generator gain TLV commit 15575ed544910464715df5c45a44b9732e415b93 upstream. The Arizona codec drivers had an incorrect dB scaling for the noise generator gain that started at 0dB and went upwards. Actually the highest setting is 0dB. Signed-off-by: Richard Fitzgerald Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 27b76178c496bdb4fc24278ff9e659dc0a5db10f Author: Mauro Carvalho Chehab Date: Tue Apr 28 18:51:17 2015 -0300 cx24116: fix a buffer overflow when checking userspace params commit 1fa2337a315a2448c5434f41e00d56b01a22283c upstream. The maximum size for a DiSEqC command is 6, according to the userspace API. However, the code allows to write up much more values: drivers/media/dvb-frontends/cx24116.c:983 cx24116_send_diseqc_msg() error: buffer overflow 'd->msg' 6 <= 23 Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 22ab213ceae3260d181316f7361419fbe4a5682c Author: Mauro Carvalho Chehab Date: Tue Apr 28 18:34:40 2015 -0300 s5h1420: fix a buffer overflow when checking userspace params commit 12f4543f5d6811f864e6c4952eb27253c7466c02 upstream. The maximum size for a DiSEqC command is 6, according to the userspace API. However, the code allows to write up to 7 values: drivers/media/dvb-frontends/s5h1420.c:193 s5h1420_send_master_cmd() error: buffer overflow 'cmd->msg' 6 <= 7 Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 755d7f5c163af374219462e707cdd9b83ee2f830 Author: Hans Verkuil Date: Fri Mar 27 15:17:56 2015 -0300 saa7164: fix querycap warning commit 534bc3e2ee93835badca753bedce8073c67caa92 upstream. Fix the VIDIOC_QUERYCAP warning due to the missing device_caps. Don't fill in the version field, the V4L2 core will do that for you. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 16eeb2182fb8f31a91e831f6f1ead91f373df4f6 Author: Mauro Carvalho Chehab Date: Tue Apr 28 19:02:19 2015 -0300 af9013: Don't accept invalid bandwidth commit d7b76c91f471413de9ded837bddeca2164786571 upstream. If userspace sends an invalid bandwidth, it should either return EINVAL or switch to auto mode. This driver will go past an array and program the hardware on a wrong way if this happens. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit ce99975dce28f20447fb72ddc8f8bf482d4f2559 Author: Mauro Carvalho Chehab Date: Tue Apr 28 19:03:59 2015 -0300 cx24117: fix a buffer overflow when checking userspace params commit 82e3b88b679049f043fe9b03991d6d66fc0a43c8 upstream. The maximum size for a DiSEqC command is 6, according to the userspace API. However, the code allows to write up much more values: drivers/media/dvb-frontends/cx24116.c:983 cx24116_send_diseqc_msg() error: buffer overflow 'd->msg' 6 <= 23 Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit a7faceb949f9511c17172200738a621b7f0ef0ff Author: Hans Verkuil Date: Fri Apr 24 03:55:07 2015 -0300 cx18: add missing caps for the PCM video device commit 2b4fd3ede3bab65ef5b97387b90899d11e4d3202 upstream. The cx18 PCM video device didn't have any capabilities set, which caused a warnings in the v4l2 core: [ 6.229393] ------------[ cut here ]------------ [ 6.229414] WARNING: CPU: 1 PID: 593 at drivers/media/v4l2-core/v4l2-ioctl.c:1025 v4l_querycap+0x41/0x70 [videodev]() [ 6.229415] Modules linked in: cx18_alsa mxl5005s s5h1409 tuner_simple tuner_types cs5345 tuner intel_rapl iosf_mbi x86_pkg_temp_thermal coretemp raid1 snd_hda_codec_realtek kvm_intel snd_hda_codec_generic snd_hda_codec_hdmi kvm snd_oxygen(+) snd_hda_intel snd_oxygen_lib snd_hda_controller snd_hda_codec snd_mpu401_uart iTCO_wdt snd_rawmidi iTCO_vendor_support snd_hwdep crct10dif_pclmul crc32_pclmul crc32c_intel snd_seq cx18 snd_seq_device ghash_clmulni_intel videobuf_vmalloc tveeprom cx2341x snd_pcm serio_raw videobuf_core vfat dvb_core fat v4l2_common snd_timer videodev snd lpc_ich i2c_i801 joydev mfd_core mei_me media soundcore tpm_infineon soc_button_array tpm_tis mei shpchp tpm nfsd auth_rpcgss nfs_acl lockd grace sunrpc binfmt_misc i915 nouveau mxm_wmi wmi e1000e ttm i2c_algo_bit drm_kms_helper [ 6.229444] drm ptp pps_core video [ 6.229446] CPU: 1 PID: 593 Comm: v4l_id Not tainted 3.19.3-200.fc21.x86_64 #1 [ 6.229447] Hardware name: Gigabyte Technology Co., Ltd. Z87-D3HP/Z87-D3HP-CF, BIOS F6 01/20/2014 [ 6.229448] 0000000000000000 00000000d12b1131 ffff88042dacfc28 ffffffff8176e215 [ 6.229449] 0000000000000000 0000000000000000 ffff88042dacfc68 ffffffff8109bc1a [ 6.229451] ffffffffa0594000 ffff88042dacfd90 0000000000000000 ffffffffa04e2140 [ 6.229452] Call Trace: [ 6.229466] [] dump_stack+0x45/0x57 [ 6.229469] [] warn_slowpath_common+0x8a/0xc0 [ 6.229472] [] warn_slowpath_null+0x1a/0x20 [ 6.229474] [] v4l_querycap+0x41/0x70 [videodev] [ 6.229477] [] __video_do_ioctl+0x29c/0x320 [videodev] [ 6.229479] [] ? do_last+0x2f1/0x1210 [ 6.229491] [] video_usercopy+0x366/0x5d0 [videodev] [ 6.229494] [] ? v4l_querycap+0x70/0x70 [videodev] [ 6.229497] [] video_ioctl2+0x15/0x20 [videodev] [ 6.229499] [] v4l2_ioctl+0x164/0x180 [videodev] [ 6.229501] [] do_vfs_ioctl+0x2f8/0x500 [ 6.229502] [] SyS_ioctl+0x81/0xa0 [ 6.229505] [] system_call_fastpath+0x12/0x17 [ 6.229506] ---[ end trace dacd80d4b19277ea ]--- Added the necessary capabilities to stop this warning. Signed-off-by: Hans Verkuil Reported-by: Laura Abbott Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 60f69783daf3967b828eb71eafd76d2ce3fabc6c Author: David Härdeman Date: Mon Mar 30 17:51:01 2015 -0300 rc-core: fix dib0700 scancode generation for RC5 commit 4d298b8539ed59f1d69d3aa6e41a2c4908137612 upstream. commit af3a4a9bbeb0 ("[media] dib0700: NEC scancode cleanup") cleaned up the NEC scancode logic but overlooked the RC5 case. This patch brings the RC5 case in line with the NEC code and makes the struct self-documenting. Signed-off-by: David Härdeman Reported-by: David Cimbůrek Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 1202e777b67d669aef34326da1f248c933735c78 Author: Thomas Reitmayr Date: Fri May 1 20:18:04 2015 -0300 media: Fix regression in some more dib0700 based devices commit e989a73ebd09d22c22ead51fa363a2f56f70f28a upstream. Fix an oops during device initialization by correctly setting size_of_priv instead of leaving it 0. The regression was introduced by 8abe4a0a3f6d4217b16a ("[media] dib7000: export just one symbol") and only fixed for one type of dib0700 based devices in 9e334c75642b6e5bfb95 ("[media] Fix regression in some dib0700 based devices"). Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=92301 Fixes: 8abe4a0a3f6d4217b16a ("[media] dib7000: export just one symbol") Signed-off-by: Thomas Reitmayr Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 24dade33c059e297602a100d5e3b34de3106e259 Author: Laurent Pinchart Date: Fri Jun 19 08:50:07 2015 -0300 vb2: Don't WARN when v4l2_buffer.bytesused is 0 for multiplanar buffers commit 77a3c6fd90c94f635edb00d4a65f485687538791 upstream. Commit f61bf13b6a07 ("[media] vb2: add allow_zero_bytesused flag to the vb2_queue struct") added a WARN_ONCE to catch usage of a deprecated API using a zero value for v4l2_buffer.bytesused. However, the condition is checked incorrectly, as the v4L2_buffer bytesused field is supposed to be ignored for multiplanar buffers. This results in spurious warnings when using the multiplanar API. Fix it by checking v4l2_buffer.bytesused for uniplanar buffers and v4l2_plane.bytesused for multiplanar buffers. Fixes: f61bf13b6a07 ("[media] vb2: add allow_zero_bytesused flag to the vb2_queue struct") Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit b7bc8d0ac57d3728d0a2c14db9dec2cf5cf02b15 Author: Jan Leupold Date: Wed Jun 17 18:21:36 2015 +0200 iio: adc: at91_adc: allow to use full range of startup time commit 2ab5f39bc7825808e0fa1e7e5f0b23e174563467 upstream. The DT-Property "atmel,adc-startup-time" is stored in an u8 for a microsecond value. When trying to increase the value of STARTUP in Register AT91_ADC_MR some higher values can't be reached. Change the type in function parameter and private structure field from u8 to u32. Signed-off-by: Jan Leupold [nicolas.ferre@atmel.com: change commit message, increase u16 to u32 for startup time] Signed-off-by: Nicolas Ferre Acked-by: Alexandre Belloni Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 4cb9ad71fc2b17e1b8540de8943b5d7f5019e922 Author: Heiko Stuebner Date: Mon May 25 22:36:58 2015 +0200 iio: adc: rockchip_saradc: add missing MODULE_* data commit dc7b8d98ac003c9f1e83a5f927c372dac6f114a1 upstream. The module-data is currently missing. This includes the license-information which makes the driver taint the kernel and miss symbols when compiled as module. Fixes: 44d6f2ef94f9 ("iio: adc: add driver for Rockchip saradc") Signed-off-by: Heiko Stuebner Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 2f69632bdd525e69893f029c528b4d6dc8e123a1 Author: Daniel Baluta Date: Thu Jun 11 18:49:34 2015 +0300 iio: proximity: sx9500: Fix proximity value commit fd1883f07cb434707e50c4c9a16e3ed4b3a5e74f upstream. Because of the ABI confusion proximity value exposed by SX9500 was inverted. Signed-off-by: Daniel Baluta Reviewed-by: Vlad Dogaru Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit f3a389420f672f820de69fb583fcab4502aa494e Author: Daniel Baluta Date: Thu Jun 11 18:49:33 2015 +0300 iio: ABI: Clarify proximity output value commit bdc10d57f236b534fb675a4bbefd10017aeb2b26 upstream. Current description for proximity measurement is ambiguous. While the first part says that proximity is measured by observing reflectivity, the second part incorrectly infers that reported values should behave like a distance. This is because of AS3935 lightning sensor which uses the proximity API, while not being a true proximity sensor. Note this is marked for stable as it accompanies a fix in ABI usage to the sx9500 driver which would otherwise appear to be correct. Fixes: 614e8842ddf ("iio: ABI: add clarification for proximity") Signed-off-by: Daniel Baluta Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit b2789eb0e024b09fde4d3a3b0ddae12d3a650902 Author: Fabio Estevam Date: Sun May 24 17:39:04 2015 -0300 iio: twl4030-madc: Pass the IRQF_ONESHOT flag commit 6c0d48cb29c29b306ba3548afb45154d22eb4d78 upstream. Since commit 1c6c69525b40 ("genirq: Reject bogus threaded irq requests") threaded IRQs without a primary handler need to be requested with IRQF_ONESHOT, otherwise the request will fail. So pass the IRQF_ONESHOT flag in this case. The semantic patch that makes this change is available in scripts/coccinelle/misc/irqf_oneshot.cocci. Signed-off-by: Fabio Estevam Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 21b9c4eca727901b770d387aead27b344dc7f9f6 Author: Peter Meerwald Date: Sun Jun 21 23:50:21 2015 +0200 iio: tmp006: Check channel info on write commit 8d05abfaeff52bdf66aba3a3a337dcdbdb4911bf upstream. only SAMP_FREQ is writable Will lead to SAMP_FREQ being written by any attempt to write to the other exported attributes and hence a rather unexpected result! Signed-off-by: Peter Meerwald Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 85250adce4a27debef10bd510ddfc4de928b4586 Author: Adriana Reus Date: Fri Jun 12 18:10:23 2015 +0300 iio: inv-mpu: Specify the expected format/precision for write channels commit 6a3c45bb5a385be7049a7725a4fe93eaa76915f4 upstream. The gyroscope needs IIO_VAL_INT_PLUS_NANO for the scale channel and unless specified write returns MICRO by default. This needs to be properly specified so that write operations into scale have the expected behaviour. Signed-off-by: Adriana Reus Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 734f561a7a7d2ccf792f53f35187136f61d38835 Author: JM Friedt Date: Fri Jun 19 14:48:06 2015 +0200 iio: DAC: ad5624r_spi: fix bit shift of output data value commit adfa969850ae93beca57f7527f0e4dc10cbe1309 upstream. The value sent on the SPI bus is shifted by an erroneous number of bits. The shift value was already computed in the iio_chan_spec structure and hence subtracting this argument to 16 yields an erroneous data position in the SPI stream. Signed-off-by: JM Friedt Acked-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit cfdbaedd8da7b45b0043b709f688663edfab49f2 Author: Peter Meerwald Date: Sun Jun 14 23:09:35 2015 +0200 iio: light: tcs3414: Fix bug preventing to set integration time commit 33361e5678a541f82f29f85467d589e7bf8da76b upstream. the millisecond values in tcs3414_times should be checked against val2, not val, which is always zero. Signed-off-by: Peter Meerwald Reported-by: Stephan Kleisinger Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 5354bc06756b59dc89d6ce24658e747e6753a926 Author: Hartmut Knaack Date: Mon Jun 15 23:48:24 2015 +0200 iio:accel:bmc150-accel: fix counting direction commit 7a1d0d91c94305fa5802a53df3a54c0ea1963c48 upstream. In bmc150_accel_unregister_triggers() triggers should be unregistered in reverse order of registration. Trigger registration starts with number 0, counting up. In consequence, trigger number needs to be count down here. Signed-off-by: Hartmut Knaack Reviewed-by: Octavian Purdila Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 62d59f98d13440855e140a68ba6996fd3ff89b50 Author: Hartmut Knaack Date: Sun Jun 21 12:15:50 2015 +0200 iio:adc:cc10001_adc: fix Kconfig dependency commit b2b3c3dc6a7bef886850920f5f5dca041b443aa0 upstream. The Cosmic Circuits 10001 ADC driver depends on HAS_IOMEM, HAVE_CLK and REGULATOR together, not just any of these. Signed-off-by: Hartmut Knaack Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 19d75d2ca962e8a7d3e2351f9062bd7093e0941f Author: Hartmut Knaack Date: Thu Jun 18 00:31:59 2015 +0200 iio:light:cm3323: clear bitmask before set commit c288503b32e8c5534062a05ec565d28bffa06db3 upstream. When setting the bits for integration time, the appropriate bitmask needs to be cleared first. Signed-off-by: Hartmut Knaack Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit a6edb0fca0fa693468a340a8200efdfa7e9a4f9b Author: Alexander Sverdlin Date: Fri Jun 12 14:41:16 2015 +0200 i2c: use parent adapter quirks in mux commit dc362d50ba94eaf2b1f11eecd81eb1d040d2d6e6 upstream. Inherit parent adapter quirks in MUX in case the devices on the multiplexed buses are interested in the adapter limitations. Signed-off-by: Łukasz Gemborowski Signed-off-by: Alexander Sverdlin Signed-off-by: Wolfram Sang Fixes: b7f625840267b1 ("i2c: add quirk checks to core") Signed-off-by: Greg Kroah-Hartman commit ab33fd4b630206d0d7b55c6df9acdb4623c1ec5b Author: Alexander Sverdlin Date: Fri Jun 12 14:41:00 2015 +0200 i2c: mux: pca954x: Use __i2c_transfer because of quirks commit 0a8237ae319ab5988d40a7a9b33d68846aae34b4 upstream. pca9541 and pca954x are calling master_xfer() of the parent adapter directly thus bypassing the quirks checks of the adapter. Use __i2c_transfer() instead. Signed-off-by: Alexander Sverdlin Tested-by: Łukasz Gemborowski Acked-by: Laurent Pinchart Reviewed-by: Jisheng Zhang Signed-off-by: Wolfram Sang Fixes: b7f625840267b1 ("i2c: add quirk checks to core") Signed-off-by: Greg Kroah-Hartman commit f7c70cbf6bfff389b8d4448c801997a6181327dc Author: Alexander Sverdlin Date: Fri Jun 12 14:40:37 2015 +0200 i2c: mux: Use __i2c_transfer() instead of calling parent's master_xfer() commit e766f338a74200b8104b1165776b19f56e252834 upstream. Newly introduced quirks infrastructure doesn't work for the devices behind MUXes because MUX's master_xfer() calls parent's master_xfer() directly without checking the quirks. Instead of duplicating check code in MUX just call __i2c_transfer() instead. This has a side effect on tracing (messages will appear on both MUX bus and parent bus), but maybe that's not bad at the end. Signed-off-by: Alexander Sverdlin Tested-by: Łukasz Gemborowski Signed-off-by: Wolfram Sang Fixes: b7f625840267b1 ("i2c: add quirk checks to core") Signed-off-by: Greg Kroah-Hartman commit 790d203b212fe6c73564bfc1258d7993692f9fc6 Author: Cyrille Pitchen Date: Tue Jun 9 18:22:14 2015 +0200 i2c: at91: fix a race condition when using the DMA controller commit 93563a6a71bb69dd324fc7354c60fb05f84aae6b upstream. For TX transactions, the TXCOMP bit in the Status Register is cleared when the first data is written into the Transmit Holding Register. In the lines from at91_do_twi_transfer(): at91_twi_write_data_dma(dev); at91_twi_write(dev, AT91_TWI_IER, AT91_TWI_TXCOMP); the TXCOMP interrupt may be enabled before the DMA controller has actually started to write into the THR. In such a case, the TXCOMP bit is still set into the Status Register so the interrupt is triggered immediately. The driver understands that a transaction completion has occurred but this transaction hasn't started yet. Hence the TXCOMP interrupt is no longer enabled by at91_do_twi_transfer() but instead by at91_twi_write_data_dma_callback(). Also, the TXCOMP bit in the Status Register in not a clear on read flag but a snapshot of the transmission state at the time the Status Register is read. When a NACK error is dectected by the I2C controller, the TXCOMP, NACK and TXRDY bits are set together to 1 in the SR. If enabled, the TXCOMP interrupt is triggered at the same time. Also setting the TXRDY to 1 triggers the DMA controller to write the next data into the THR. Such a write resets the TXCOMP bit to 0 in the SR. So depending on when the interrupt handler reads the SR, it may fail to detect the NACK error if it relies on the TXCOMP bit. The NACK bit and its interrupt should be used instead. For RX transactions, the TXCOMP bit in the Status Register is cleared when the START bit is set into the Control Register. However to unify the management of the TXCOMP bit when the DMA controller is used, the TXCOMP interrupt is now enabled by the DMA callbacks for both TX and RX transfers. Signed-off-by: Cyrille Pitchen Acked-by: Ludovic Desroches Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 29c1b3c87b50260525575d260efd6af66a25bf4d Author: Stefan Agner Date: Thu May 21 17:29:35 2015 +0200 rtc: snvs: fix wakealarm by call enable_irq_wake earlier commit 119434f44c78df8c4b6d67f835448542a4bd7e91 upstream. When entering suspend while an wakeup alarm is set, enable_set_wake should make sure that the RTC interrupt keep being enabled and the .irq_set_wake for the RTC interrupt get called. However, since the driver uses the suspend_noirq callback, the call to enable_irq_wake has been made after disabling the interrupts. While .irq_set_wake has been called properly, the interrupt remained disabled. Use the suspend callback to call enable_irq_wake early enough to ensure the RTC interrupt remains enabled. Fixes: 7654e9d4fd8f ("drivers/rtc/rtc-snvs: fix suspend/resume") Signed-off-by: Stefan Agner Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 0268313777f9ff4c61adfee1b726dbde2f68ed44 Author: Christophe Ricard Date: Sat Jun 6 13:16:44 2015 +0200 NFC: st21nfcb: remove st21nfcb_nci_i2c_disable commit 4ac82e894825126816d7b7f662743335ce2b015e upstream. ndlc_remove already calls st21nfcb_nci_i2c_disable and phy->powered is already set to 0. Signed-off-by: Christophe Ricard Signed-off-by: Samuel Ortiz Signed-off-by: Greg Kroah-Hartman commit fff9252c7de221c9dc0c9b7e49815e1ebb15f0aa Author: Christophe Ricard Date: Sat Jun 6 13:16:43 2015 +0200 NFC: st21nfcb: Do not remove header once the payload is sent commit 09f39a950523b1bb830c30a8670b77e0067da092 upstream. Once the data is sent, we need to preserve the full frame for the ndlc state machine. If the NDLC ACK is not received in time, the ndlc layer will resend the same frame. Having the header byte pulled will corrupt the frame. Signed-off-by: Christophe Ricard Signed-off-by: Samuel Ortiz Signed-off-by: Greg Kroah-Hartman commit 25cd02f381876793dc5acd14d87f0dffccad1973 Author: Firo Yang Date: Sat Jun 6 13:16:42 2015 +0200 NFC: st21nfcb: Remove inappropriate kfree on a devm_kzalloc pointer commit 38bd83f04c5e9695011dc5c294e0c4e6a9f9052d upstream. Since ndev->driver_data is allocated by devm_kzalloc(), we do not need the inappropriate kfree to free it in driver's remove function. Freeing will trigger when driver unloads. Acked-by: Christophe Ricard Signed-off-by: Firo Yang Signed-off-by: Samuel Ortiz Signed-off-by: Greg Kroah-Hartman commit 99d0ebdb4b9811ebe8e89ab07480b7836b4aa87a Author: Joseph Qi Date: Mon Jun 15 14:36:01 2015 -0400 jbd2: fix ocfs2 corrupt when updating journal superblock fails commit 6f6a6fda294506dfe0e3e0a253bb2d2923f28f0a upstream. If updating journal superblock fails after journal data has been flushed, the error is omitted and this will mislead the caller as a normal case. In ocfs2, the checkpoint will be treated successfully and the other node can get the lock to update. Since the sb_start is still pointing to the old log block, it will rewrite the journal data during journal recovery by the other node. Thus the new updates will be overwritten and ocfs2 corrupts. So in above case we have to return the error, and ocfs2_commit_cache will take care of the error and prevent the other node to do update first. And only after recovering journal it can do the new updates. The issue discussion mail can be found at: https://oss.oracle.com/pipermail/ocfs2-devel/2015-June/010856.html http://comments.gmane.org/gmane.comp.file-systems.ext4/48841 [ Fixed bug in patch which allowed a non-negative error return from jbd2_cleanup_journal_tail() to leak out of jbd2_fjournal_flush(); this was causing xfstests ext4/306 to fail. -- Ted ] Reported-by: Yiwen Jiang Signed-off-by: Joseph Qi Signed-off-by: Theodore Ts'o Tested-by: Yiwen Jiang Cc: Junxiao Bi Signed-off-by: Greg Kroah-Hartman commit 14624906f5f4356dd69e62b2ed671275cb3a0ed3 Author: Dmitry Monakhov Date: Mon Jun 15 00:18:02 2015 -0400 jbd2: use GFP_NOFS in jbd2_cleanup_journal_tail() commit b4f1afcd068f6e533230dfed00782cd8a907f96b upstream. jbd2_cleanup_journal_tail() can be invoked by jbd2__journal_start() So allocations should be done with GFP_NOFS [Full stack trace snipped from 3.10-rh7] [] dump_stack+0x19/0x1b [] warn_slowpath_common+0x61/0x80 [] warn_slowpath_null+0x1a/0x20 [] slab_pre_alloc_hook.isra.31.part.32+0x15/0x17 [] kmem_cache_alloc+0x55/0x210 [] ? mempool_alloc_slab+0x15/0x20 [] mempool_alloc_slab+0x15/0x20 [] mempool_alloc+0x69/0x170 [] ? _raw_spin_unlock_irq+0xe/0x20 [] ? finish_task_switch+0x5d/0x150 [] bio_alloc_bioset+0x1be/0x2e0 [] blkdev_issue_flush+0x99/0x120 [] jbd2_cleanup_journal_tail+0x93/0xa0 [jbd2] -->GFP_KERNEL [] jbd2_log_do_checkpoint+0x221/0x4a0 [jbd2] [] __jbd2_log_wait_for_space+0xa7/0x1e0 [jbd2] [] start_this_handle+0x2d8/0x550 [jbd2] [] ? __memcg_kmem_put_cache+0x29/0x30 [] ? kmem_cache_alloc+0x130/0x210 [] jbd2__journal_start+0xba/0x190 [jbd2] [] ? lru_cache_add+0xe/0x10 [] ? ext4_da_write_begin+0xf9/0x330 [ext4] [] __ext4_journal_start_sb+0x77/0x160 [ext4] [] ext4_da_write_begin+0xf9/0x330 [ext4] [] generic_file_buffered_write_iter+0x10c/0x270 [] __generic_file_write_iter+0x178/0x390 [] __generic_file_aio_write+0x8b/0xb0 [] generic_file_aio_write+0x5d/0xc0 [] ext4_file_write+0xa9/0x450 [ext4] [] ? pipe_read+0x379/0x4f0 [] do_sync_write+0x90/0xe0 [] vfs_write+0xbd/0x1e0 [] SyS_write+0x58/0xb0 [] system_call_fastpath+0x16/0x1b Signed-off-by: Dmitry Monakhov Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit a345e343e0f6cccbb8d3891044b94d1d66407a11 Author: Michal Hocko Date: Sun Jul 5 12:33:44 2015 -0400 ext4: replace open coded nofail allocation in ext4_free_blocks() commit 7444a072c387a93ebee7066e8aee776954ab0e41 upstream. ext4_free_blocks is looping around the allocation request and mimics __GFP_NOFAIL behavior without any allocation fallback strategy. Let's remove the open coded loop and replace it with __GFP_NOFAIL. Without the flag the allocator has no way to find out never-fail requirement and cannot help in any way. Signed-off-by: Michal Hocko Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 8591fac57a6cf0c98269c9525e43c17b76835068 Author: Eryu Guan Date: Sat Jul 4 00:03:44 2015 -0400 ext4: correctly migrate a file with a hole at the beginning commit 8974fec7d72e3e02752fe0f27b4c3719c78d9a15 upstream. Currently ext4_ind_migrate() doesn't correctly handle a file which contains a hole at the beginning of the file. This caused the migration to be done incorrectly, and then if there is a subsequent following delayed allocation write to the "hole", this would reclaim the same data blocks again and results in fs corruption. # assmuing 4k block size ext4, with delalloc enabled # skip the first block and write to the second block xfs_io -fc "pwrite 4k 4k" -c "fsync" /mnt/ext4/testfile # converting to indirect-mapped file, which would move the data blocks # to the beginning of the file, but extent status cache still marks # that region as a hole chattr -e /mnt/ext4/testfile # delayed allocation writes to the "hole", reclaim the same data block # again, results in i_blocks corruption xfs_io -c "pwrite 0 4k" /mnt/ext4/testfile umount /mnt/ext4 e2fsck -nf /dev/sda6 ... Inode 53, i_blocks is 16, should be 8. Fix? no ... Signed-off-by: Eryu Guan Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit c23d1fbb672464b34894305a70268fcd52eec683 Author: Eryu Guan Date: Fri Jul 3 23:56:50 2015 -0400 ext4: be more strict when migrating to non-extent based file commit d6f123a9297496ad0b6335fe881504c4b5b2a5e5 upstream. Currently the check in ext4_ind_migrate() is not enough before doing the real conversion: a) delayed allocated extents could bypass the check on eh->eh_entries and eh->eh_depth This can be demonstrated by this script xfs_io -fc "pwrite 0 4k" -c "pwrite 8k 4k" /mnt/ext4/testfile chattr -e /mnt/ext4/testfile where testfile has two extents but still be converted to non-extent based file format. b) only extent length is checked but not the offset, which would result in data lose (delalloc) or fs corruption (nodelalloc), because non-extent based file only supports at most (12 + 2^10 + 2^20 + 2^30) blocks This can be demostrated by xfs_io -fc "pwrite 5T 4k" /mnt/ext4/testfile chattr -e /mnt/ext4/testfile sync If delalloc is enabled, dmesg prints EXT4-fs warning (device dm-4): ext4_block_to_path:105: block 1342177280 > max in inode 53 EXT4-fs (dm-4): Delayed block allocation failed for inode 53 at logical offset 1342177280 with max blocks 1 with error 5 EXT4-fs (dm-4): This should not happen!! Data will be lost If delalloc is disabled, e2fsck -nf shows corruption Inode 53, i_size is 5497558142976, should be 4096. Fix? no Fix the two issues by a) forcing all delayed allocation blocks to be allocated before checking eh->eh_depth and eh->eh_entries b) limiting the last logical block of the extent is within direct map Signed-off-by: Eryu Guan Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 864c38b9d91bc101c804cb604b74c4edda76c377 Author: Lukas Czerner Date: Fri Jul 3 21:13:55 2015 -0400 ext4: fix reservation release on invalidatepage for delalloc fs commit 9705acd63b125dee8b15c705216d7186daea4625 upstream. On delalloc enabled file system on invalidatepage operation in ext4_da_page_release_reservation() we want to clear the delayed buffer and remove the extent covering the delayed buffer from the extent status tree. However currently there is a bug where on the systems with page size > block size we will always remove extents from the start of the page regardless where the actual delayed buffers are positioned in the page. This leads to the errors like this: EXT4-fs warning (device loop0): ext4_da_release_space:1225: ext4_da_release_space: ino 13, to_free 1 with only 0 reserved data blocks This however can cause data loss on writeback time if the file system is in ENOSPC condition because we're releasing reservation for someones else delayed buffer. Fix this by only removing extents that corresponds to the part of the page we want to invalidate. This problem is reproducible by the following fio receipt (however I was only able to reproduce it with fio-2.1 or older. [global] bs=8k iodepth=1024 iodepth_batch=60 randrepeat=1 size=1m directory=/mnt/test numjobs=20 [job1] ioengine=sync bs=1k direct=1 rw=randread filename=file1:file2 [job2] ioengine=libaio rw=randwrite direct=1 filename=file1:file2 [job3] bs=1k ioengine=posixaio rw=randwrite direct=1 filename=file1:file2 [job5] bs=1k ioengine=sync rw=randread filename=file1:file2 [job7] ioengine=libaio rw=randwrite filename=file1:file2 [job8] ioengine=posixaio rw=randwrite filename=file1:file2 [job10] ioengine=mmap rw=randwrite bs=1k filename=file1:file2 [job11] ioengine=mmap rw=randwrite direct=1 filename=file1:file2 Signed-off-by: Lukas Czerner Signed-off-by: Theodore Ts'o Reviewed-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit ad7f8a81e1cf1a999f633c08cee61975daceff08 Author: Nikolay Borisov Date: Thu Jul 2 01:34:07 2015 -0400 ext4: avoid deadlocks in the writeback path by using sb_getblk_gfp commit c45653c341f5c8a0ce19c8f0ad4678640849cb86 upstream. Switch ext4 to using sb_getblk_gfp with GFP_NOFS added to fix possible deadlocks in the page writeback path. Signed-off-by: Nikolay Borisov Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 1fdc8c7f1e7d853644c0ad5661ae2e6dfab7baa2 Author: Nikolay Borisov Date: Thu Jul 2 01:32:44 2015 -0400 bufferhead: Add _gfp version for sb_getblk() commit bd7ade3cd9b0850264306f5c2b79024a417b6396 upstream. sb_getblk() is used during ext4 (and possibly other FSes) writeback paths. Sometimes such path require allocating memory and guaranteeing that such allocation won't block. Currently, however, there is no way to provide user flags for sb_getblk which could lead to deadlocks. This patch implements a sb_getblk_gfp with the only difference it can accept user-provided GFP flags. Signed-off-by: Nikolay Borisov Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit ae82e119e810848c6596031c1bed8c9a38e70322 Author: Theodore Ts'o Date: Wed Jul 1 23:37:46 2015 -0400 ext4: fix fencepost error in lazytime optimization commit 0f0ff9a9f3fa2ec6f427603fd521d5f3a0b076d1 upstream. Commit 8f4d8558391: "ext4: fix lazytime optimization" was not a complete fix. In the case where the inode number is a multiple of 16, and we could still end up updating an inode with dirty timestamps written to the wrong inode on disk. Oops. This can be easily reproduced by using generic/005 with a file system with metadata_csum and lazytime enabled. Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 1c1964376ab16bc80dc24db2972a9d8f9120c9a4 Author: Theodore Ts'o Date: Tue Jun 23 11:03:54 2015 -0400 ext4: set lazytime on remount if MS_LAZYTIME is set by mount commit a2fd66d069d86d793e9d39d4079b96f46d13f237 upstream. Newer versions of mount parse the lazytime feature and pass it to the mount system call via the flags field in the mount system call, removing the lazytime string from the mount options list. So we need to check for the presence of MS_LAZYTIME and set it in sb->s_flags in order for this flag to be set on a remount. Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit c632b53d850c401b63d5a308b2faafa98d8140af Author: Darrick J. Wong Date: Sun Jun 21 21:10:51 2015 -0400 ext4: don't retry file block mapping on bigalloc fs with non-extent file commit 292db1bc6c105d86111e858859456bcb11f90f91 upstream. ext4 isn't willing to map clusters to a non-extent file. Don't signal this with an out of space error, since the FS will retry the allocation (which didn't fail) forever. Instead, return EUCLEAN so that the operation will fail immediately all the way back to userspace. (The fix is either to run e2fsck -E bmap2extent, or to chattr +e the file.) Signed-off-by: Darrick J. Wong Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 1d54c6bb0c889f29f829dd400b5af3e5874fbfa0 Author: Theodore Ts'o Date: Sat Jun 20 22:50:33 2015 -0400 ext4: call sync_blockdev() before invalidate_bdev() in put_super() commit 89d96a6f8e6491f24fc8f99fd6ae66820e85c6c1 upstream. Normally all of the buffers will have been forced out to disk before we call invalidate_bdev(), but there will be some cases, where a file system operation was aborted due to an ext4_error(), where there may still be some dirty buffers in the buffer cache for the device. So try to force them out to memory before calling invalidate_bdev(). This fixes a warning triggered by generic/081: WARNING: CPU: 1 PID: 3473 at /usr/projects/linux/ext4/fs/block_dev.c:56 __blkdev_put+0xb5/0x16f() Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 2171417e120ae8825ea0ea263667e47ba9d1aa36 Author: Theodore Ts'o Date: Fri Jun 12 23:45:33 2015 -0400 ext4: fix race between truncate and __ext4_journalled_writepage() commit bdf96838aea6a265f2ae6cbcfb12a778c84a0b8e upstream. The commit cf108bca465d: "ext4: Invert the locking order of page_lock and transaction start" caused __ext4_journalled_writepage() to drop the page lock before the page was written back, as part of changing the locking order to jbd2_journal_start -> page_lock. However, this introduced a potential race if there was a truncate racing with the data=journalled writeback mode. Fix this by grabbing the page lock after starting the journal handle, and then checking to see if page had gotten truncated out from under us. This fixes a number of different warnings or BUG_ON's when running xfstests generic/086 in data=journalled mode, including: jbd2_journal_dirty_metadata: vdc-8: bad jh for block 115643: transaction (ee3fe7 c0, 164), jh->b_transaction ( (null), 0), jh->b_next_transaction ( (null), 0), jlist 0 - and - kernel BUG at /usr/projects/linux/ext4/fs/jbd2/transaction.c:2200! ... Call Trace: [] ? __ext4_journalled_invalidatepage+0x117/0x117 [] __ext4_journalled_invalidatepage+0x10f/0x117 [] ? __ext4_journalled_invalidatepage+0x117/0x117 [] ? lock_buffer+0x36/0x36 [] ext4_journalled_invalidatepage+0xd/0x22 [] do_invalidatepage+0x22/0x26 [] truncate_inode_page+0x5b/0x85 [] truncate_inode_pages_range+0x156/0x38c [] truncate_inode_pages+0x11/0x15 [] truncate_pagecache+0x55/0x71 [] ext4_setattr+0x4a9/0x560 [] ? current_kernel_time+0x10/0x44 [] notify_change+0x1c7/0x2be [] do_truncate+0x65/0x85 [] ? file_ra_state_init+0x12/0x29 - and - WARNING: CPU: 1 PID: 1331 at /usr/projects/linux/ext4/fs/jbd2/transaction.c:1396 irty_metadata+0x14a/0x1ae() ... Call Trace: [] ? console_unlock+0x3a1/0x3ce [] dump_stack+0x48/0x60 [] warn_slowpath_common+0x89/0xa0 [] ? jbd2_journal_dirty_metadata+0x14a/0x1ae [] warn_slowpath_null+0x14/0x18 [] jbd2_journal_dirty_metadata+0x14a/0x1ae [] __ext4_handle_dirty_metadata+0xd4/0x19d [] write_end_fn+0x40/0x53 [] ext4_walk_page_buffers+0x4e/0x6a [] ext4_writepage+0x354/0x3b8 [] ? mpage_release_unused_pages+0xd4/0xd4 [] ? wait_on_buffer+0x2c/0x2c [] ? ext4_writepage+0x3b8/0x3b8 [] __writepage+0x10/0x2e [] write_cache_pages+0x22d/0x32c [] ? ext4_writepage+0x3b8/0x3b8 [] ext4_writepages+0x102/0x607 [] ? sched_clock_local+0x10/0x10e [] ? __lock_is_held+0x2e/0x44 [] ? lock_is_held+0x43/0x51 [] do_writepages+0x1c/0x29 [] __writeback_single_inode+0xc3/0x545 [] writeback_sb_inodes+0x21f/0x36d ... Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit be43d21df90d10f5f10252c114f5fb024b7ba5ae Author: Srinivas Pandruvada Date: Mon Jun 1 16:36:27 2015 -0700 hid-sensor: Fix suspend/resume delay commit 1e25aa9641e8f3fa39cd5e46b4afcafd7f12a44b upstream. By default all the sensors are runtime suspended state (lowest power state). During Linux suspend process, all the run time suspended devices are resumed and then suspended. This caused all sensors to power up and introduced delay in suspend time, when we introduced runtime PM for HID sensors. The opposite process happens during resume process. To fix this, we do powerup process of the sensors only when the request is issued from user (raw or tiggerred). In this way when runtime, resume calls for powerup it will simply return as this will not match user requested state. Note this is a regression fix as the increase in suspend / resume times can be substantial (report of 8 seconds on Len's laptop!) Signed-off-by: Srinivas Pandruvada Tested-by: Len Brown Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 366031c6dd1c6b57a9d48a66cdc48e21c994a1bd Author: Ian Abbott Date: Fri Jun 12 16:37:41 2015 +0100 staging: comedi: cb_pcimdas: fix handlers for DI and DO subdevices commit b08ad6657aacf9b5d7c4b22de2ba891b152d0528 upstream. Normally, low-level Comedi drivers set an `insn_bits` handler for digital input (DI), digital output (DO) and digital input/output (DIO) subdevice types to handle normal reading and writing of digital channels. The "cb_pcimdas" driver currently has an `insn_read` handler for the DI subdevice and an `insn_write` handler for the DO subdevice. However, the actual handler functions `cb_pcimdas_di_insn_read()` and `cb_pcimdas_do_insn_write()` are written to behave like `insn_bits` handlers. Something's wrong there! To fix it, set the functions as `insn_bits` handlers and rename them for consistency. Fixes: e56d03dee14a ("staging: comedi: cb_pcimdas: add main connector digital input/output") Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman commit 92c09183c74a03d85f2184992c9b0e3308c8bb8d Author: Haggai Eran Date: Sat May 23 23:13:51 2015 +0300 staging: rtl8712: prevent buffer overrun in recvbuf2recvframe commit cab462140f8a183e3cca0b51c8b59ef715cb6148 upstream. With an RTL8191SU USB adaptor, sometimes the hints for a fragmented packet are set, but the packet length is too large. Allocate enough space to prevent memory corruption and a resulting kernel panic [1]. [1] http://www.spinics.net/lists/linux-wireless/msg136546.html Signed-off-by: Haggai Eran ACKed-by: Larry Finger Signed-off-by: Greg Kroah-Hartman commit c79d02758654aeef5448f9b42952e699dd2c5463 Author: Malcolm Priestley Date: Sun May 31 10:35:28 2015 +0100 staging: vt6655: device_rx_srv check sk_buff is NULL commit b5eeed8cb6097c8ea660b6598d36fdbb94065a22 upstream. There is a small chance that pRD->pRDInfo->skb could go NULL while the interrupt is processing. Put NULL check on loop to break out. Signed-off-by: Malcolm Priestley Signed-off-by: Greg Kroah-Hartman commit a225aecb12853c4231aac1dc2927755bb2a068a1 Author: Malcolm Priestley Date: Thu Jul 9 17:01:24 2015 +0100 staging: vt6655: check ieee80211_bss_conf bssid not NULL commit 8e8e9198920ddfa920191069ae02eba75d39e653 upstream. Sometimes bssid can go null on failed association. Signed-off-by: Malcolm Priestley Signed-off-by: Greg Kroah-Hartman commit c4fdcdb1689f93b8b048e09c03924e730dfad600 Author: Malcolm Priestley Date: Thu Jul 9 17:03:57 2015 +0100 staging: vt6656: check ieee80211_bss_conf bssid not NULL commit d309509f84725f99326cc73d3b00aae096b374ae upstream. Sometimes bssid can go null on failed association. Signed-off-by: Malcolm Priestley Signed-off-by: Greg Kroah-Hartman commit 6ab8bb14ed9e6b7979da424bdafc959fd602c42a Author: Lennert Buytenhek Date: Wed Jun 3 10:50:19 2015 +0300 ieee802154: Fix sockaddr_ieee802154 implicit padding information leak. commit 8a70cefa3037d62e7c0b6068a66675def1a330c9 upstream. The AF_IEEE802154 sockaddr looks like this: struct sockaddr_ieee802154 { sa_family_t family; /* AF_IEEE802154 */ struct ieee802154_addr_sa addr; }; struct ieee802154_addr_sa { int addr_type; u16 pan_id; union { u8 hwaddr[IEEE802154_ADDR_LEN]; u16 short_addr; }; }; On most architectures there will be implicit structure padding here, in two different places: * In struct sockaddr_ieee802154, two bytes of padding between 'family' (unsigned short) and 'addr', so that 'addr' starts on a four byte boundary. * In struct ieee802154_addr_sa, two bytes at the end of the structure, to make the structure 16 bytes. When calling recvmsg(2) on a PF_IEEE802154 SOCK_DGRAM socket, the ieee802154 stack constructs a struct sockaddr_ieee802154 on the kernel stack without clearing these padding fields, and, depending on the addr_type, between four and ten bytes of uncleared kernel stack will be copied to userspace. We can't just insert two 'u16 __pad's in the right places and zero those before copying an address to userspace, as not all architectures insert this implicit padding -- from a quick test it seems that avr32, cris and m68k don't insert this padding, while every other architecture that I have cross compilers for does insert this padding. The easiest way to plug the leak is to just memset the whole struct sockaddr_ieee802154 before filling in the fields we want to fill in, and that's what this patch does. Signed-off-by: Lennert Buytenhek Acked-by: Alexander Aring Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 33e1432c291b72339b03ea3450d7840cdba1dbe1 Author: Vincent Fann Date: Fri May 15 21:29:27 2015 -0500 rtlwifi: Remove the clear interrupt routine from all drivers commit 1277fa2ab2f9a624a4b0177119ca13b5fd65edd0 upstream. Several of these drivers have there TX randomly blocked for 3~5 seconds while measuring tx throughput (iperf). The root couse happens in rtl_pci_flush(). The function uses a while-loop to wait for TX queue length to decrease to 0. The TX queue length counts the number of packets that are queued in the driver. The driver relys on the TX OK interrupt to return skb and reduce TX queue length. The interrupt subroutine disables interupts, reads the interrupt registers, and then clears the registers in the beginning of _rtl_pci_interrupt(). After all interupts process are finished, the driver invokes enable_interrupt() to enable interupts. This behavior is normal for an interrupt subroutine. But enable_interrupt() invokes clear_interrupt() again. This unexpected interrupt clearing may cleari me fresh TX OK interrupts. These missing interrupts cause TX queue length to never reduce to 0i, which causes rtl_pci_flush() to be stuck in unterminated while-loop. This patch removes clear_interrupt() in enable_interrupt() to avoid this behavior. Signed-off-by: Vincent Fann Signed-off-by: Shao Fu Signed-off-by: Larry Finger Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 01fe812522c67852943800c724199836a66d3a52 Author: Dan Carpenter Date: Thu May 14 11:34:48 2015 +0300 ath9k_htc: memory corruption calling set_bit() commit 191f1aeeb93bb58e56f4d1868294ae22f3f67d4e upstream. In d8a2c51cdcae ('ath9k_htc: Use atomic operations for op_flags') we changed things like this: - if (priv->op_flags & OP_TSF_RESET) { + if (test_bit(OP_TSF_RESET, &priv->op_flags)) { The problem is that test_bit() takes a bit number and not a mask. It means that when we do: set_bit(OP_TSF_RESET, &priv->op_flags); Then it sets the (1 << 6) bit instead of the 6 bit so we are setting a bit which is past the end of the unsigned long. Fixes: d8a2c51cdcae ('ath9k_htc: Use atomic operations for op_flags') Signed-off-by: Dan Carpenter Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit f3a16a0597a773deb7ee578c3453e62cc1f9e222 Author: Felix Fietkau Date: Tue Jun 2 10:38:32 2015 +0200 ath9k: fix DMA stop sequence for AR9003+ commit 300f77c08ded96d33f492aaa02549103852f0c12 upstream. AR93xx and newer needs to stop rx before tx to avoid getting the DMA engine or MAC into a stuck state. This should reduce/fix the occurence of "Failed to stop Tx DMA" logspam. Signed-off-by: Felix Fietkau Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit b5c06428d38a0d74d90901d2c3fcf8ad29292216 Author: Chris Mason Date: Tue Jul 14 16:25:30 2015 -0400 Bluetooth: btbcm: allow btbcm_read_verbose_config to fail on Apple commit 7bee8b08c428b63aa4a3765bb907602e36355378 upstream. Commit 1c8ba6d013 moved around the setup code for broadcomm chips, and also added btbcm_read_verbose_config() to read extra information about the hardware. It's returning errors on some macbooks: Bluetooth: hci0: BCM: Read verbose config info failed (-16) Which makes us error out of the setup function. Since this probe isn't critical to operate the chip, this patch just changes things to carry on when it fails. Signed-off-by: Chris Mason Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 6665e53d7bd3e84d1f203b4d747d0c06c4bbf345 Author: Aleksei Volkov Date: Mon Jun 8 12:02:10 2015 +0300 Bluetooth: btusb: Correct typo in Roper Class 1 Bluetooth Dongle commit 2eeac871697ac24a77b6d7953bd711b490e83ac7 upstream. That patch corrects the typo in usb vendor id for Roper Class 1 Bluetooth Dongle. Problem with typo is present since 4.0 kernel. Content /sys/kernel/debug/usb/devices for these dongle: T: Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1310 ProdID=0001 Rev=15.00 S: Manufacturer=SiW S: Product=SiW S: SerialNumber=E7BB050D0B00 C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr= 50mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Aleksei Volkov Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 2f5ce3a02ce2e5dbf14f4f391cb88a4682b0019d Author: Marcel Holtmann Date: Sun Jun 7 09:47:08 2015 +0200 Bluetooth: btusb: Fix secure send command length alignment on Intel 8260 commit e66890a96abbb746e1229c3067471be36dc49b34 upstream. This patch fixes the command length alignment issue for Intel Bluetooth 8260. The length of parameters in the firmware downloading command must be multiplication of 4. If not, the command must append Intel_NOP command with extra parameters, zeros, at the end, and the firmware file is already included Intel_NOP command for alignment. This patch checks the next command and if the next command is Intel_NOP command, it reads the Intel_NOP command and send them together. For example, if the data from the firmware file looks like this: 8E FC 03 11 22 33 02 FC 03 00 00 00 Previously, btusb sends two commands: 09 FC 06 8E FC 03 11 22 33 09 FC 06 02 FC 03 00 00 00 This won't work because the length of parameters are 6 which violates the 4 byte alignment. This patch will append them together and send as one command: 09 FC 0C 8E FC 03 11 22 33 02 FC 03 00 00 00 Based on previous work from Tedd Ho-Jeong An Reported-by: Tedd Ho-Jeong An Signed-off-by: Marcel Holtmann Tested-by: Tedd Ho-Jeong An Signed-off-by: Johan Hedberg Signed-off-by: Greg Kroah-Hartman commit a5b637f8893adb8ccd17f6f92158241e8537aba8 Author: Marcel Holtmann Date: Sun Jun 7 09:42:19 2015 +0200 Bluetooth: btusb: Fix memory leak in Intel setup routine commit ecffc80478cdce122f0ecb6a4e4f909132dd5c47 upstream. The SKB returned from the Intel specific version information command is missing a kfree_skb. Signed-off-by: Marcel Holtmann Signed-off-by: Johan Hedberg Signed-off-by: Greg Kroah-Hartman commit 2bd8b830dafea36e902518dd4be77e9432634c2d Author: Marcel Holtmann Date: Sat Jun 6 06:06:49 2015 +0200 Bluetooth: Fix race condition with user channel and setup stage commit 781f899f2f9d8b71e35225a087f90052059486c5 upstream. During the initial setup stage of a controller, the low-level transport is actually active. This means that HCI_UP is true. To avoid toggling the transport off and back on again for normal operation the kernel holds a grace period with HCI_AUTO_OFF that will turn the low-level transport off in case no user is present. The idea of the grace period is important to avoid having to initialize all of the controller twice. So legacy ioctl and the new management interface knows how to clear this grace period and then start normal operation. For the user channel operation this grace period has not been taken into account which results in the problem that HCI_UP and HCI_AUTO_OFF are set and the kernel will return EBUSY. However from a system point of view the controller is ready to be grabbed by either the ioctl, the management interface or the user channel. This patch brings the user channel to the same level as the other two entries for operating a controller. Signed-off-by: Marcel Holtmann Signed-off-by: Johan Hedberg Signed-off-by: Greg Kroah-Hartman commit 4c3c2d140a873c9330dd51119aa9e13225cd65ef Author: Greg Ungerer Date: Tue Jul 7 14:21:21 2015 +1000 m68knommu: force setting of CONFIG_CLOCK_FREQ for ColdFire commit d9ee489619744ee5ac246b8fb3dd65bb078d2f0a upstream. It is possible to disable the clock selection at configuration time, but for ColdFire targets we always expect a clock frequency to be selected. This results in the following compile time error: CC arch/m68k/kernel/asm-offsets.s In file included from ./arch/m68k/include/asm/timex.h:14:0, from include/linux/timex.h:65, from include/linux/sched.h:19, from arch/m68k/kernel/asm-offsets.c:14: ./arch/m68k/include/asm/coldfire.h:25:2: error: #error "Don't know what your ColdFire CPU clock frequency is??" Remove CONFIG_CLOCK_SELECT completely and always enable CONFIG_CLOCK_FREQ for ColdFire. Signed-off-by: Greg Ungerer Acked-by: Geert Uytterhoeven Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 250cb4138bda236ea39bc430421c84e3b1586630 Author: Greg Ungerer Date: Tue Jul 7 15:44:02 2015 +1000 m68knommu: make ColdFire SoC selection a choice commit fa95a1dd0819c9041a873b10a6d83b5134964154 upstream. It would be nice if we could support multiple ColdFire SoC types in a single binary - but currently the code simply does not support it. Change the SoC selection config options to be a choice instead of individual selectable entries. This fixes problems with building allnoconfig, and means that a sane linux kernel is generated for a single ColdFire SoC type. Signed-off-by: Greg Ungerer Acked-by: Geert Uytterhoeven Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 9366d297b6e2949761ae79fd275c972c1384076c Author: Andrew Morton Date: Fri Jul 17 16:23:28 2015 -0700 openrisc: fix CONFIG_UID16 setting commit 04ea1e91f85615318ea91ce8ab50cb6a01ee4005 upstream. openrisc-allnoconfig: kernel/uid16.c: In function 'SYSC_setgroups16': kernel/uid16.c:184:2: error: implicit declaration of function 'groups_alloc' kernel/uid16.c:184:13: warning: assignment makes pointer from integer without a cast openrisc shouldn't be setting CONFIG_UID16 when CONFIG_MULTIUSER=n. Fixes: 2813893f8b197a1 ("kernel: conditionally support non-root users, groups and capabilities") Reported-by: Fengguang Wu Cc: Iulia Manda Cc: Josh Triplett Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 6d033f883bc7eb4d2bfcbfaef48a8c7441942430 Author: Thomas Petazzoni Date: Tue Jun 9 18:46:58 2015 +0200 pinctrl: mvebu: armada-xp: fix functions of MPP48 commit ea78b9511a54d0de026e04b5da86b30515072f31 upstream. There was a mistake in the definition of the functions for MPP48 on Marvell Armada XP. The second function is dev(clkout), and not tclk. Signed-off-by: Thomas Petazzoni Fixes: 463e270f766a ("pinctrl: mvebu: add pinctrl driver for Armada XP") Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 42ae173f64203d396a68d82a7962fd19e4d7a819 Author: Thomas Petazzoni Date: Tue Jun 9 18:46:57 2015 +0200 pinctrl: mvebu: armada-xp: remove non-existing VDD cpu_pd functions commit 80b3d04feab5e69d51cb2375eb989a7165e43e3b upstream. The latest version of the Armada XP datasheet no longer documents the VDD cpu_pd functions, which might indicate they are not working and/or not supported. This commit ensures the pinctrl driver matches the datasheet. Signed-off-by: Thomas Petazzoni Fixes: 463e270f766a ("pinctrl: mvebu: add pinctrl driver for Armada XP") Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 51ba8d4f98ba8d6f5504577ddc4db2b1a657260e Author: Thomas Petazzoni Date: Tue Jun 9 18:46:56 2015 +0200 pinctrl: mvebu: armada-xp: remove non-existing NAND pins commit bc99357f3690c11817756adfee0ece811a3db2e7 upstream. After updating to a more recent version of the Armada XP datasheet, we realized that some of the pins documented as having a NAND-related functionality in fact did not have such functionality. This commit updates the pinctrl driver accordingly. Signed-off-by: Thomas Petazzoni Fixes: 463e270f766a ("pinctrl: mvebu: add pinctrl driver for Armada XP") Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 665a170e81d002fe355e03cef2ae01401de97d71 Author: Thomas Petazzoni Date: Tue Jun 9 18:47:01 2015 +0200 pinctrl: mvebu: armada-39x: fix incorrect total number of GPIOs commit 7c580311a2cb3bb0d0188665c9c69227aed650ea upstream. The pinctrl_gpio_range[] array described a first bank of 32 GPIOs and a second one of 27 GPIOs. However, since there is a total of 60 MPP pins that can be muxed as GPIOs, the second bank really has 28 GPIOs. Signed-off-by: Thomas Petazzoni Fixes: ee086577abe7f ("pinctrl: mvebu: add pinctrl driver for Marvell Armada 39x") Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 32ebad3d19ecad29837467bf4a6d0857a50ed03d Author: Thomas Petazzoni Date: Tue Jun 9 18:47:00 2015 +0200 pinctrl: mvebu: armada-38x: fix incorrect total number of GPIOs commit 27e7cd016558bf787b128fd882cdd90409ae4036 upstream. The pinctrl_gpio_range[] array described a first bank of 32 GPIOs and a second one of 27 GPIOs. However, since there is a total of 60 MPP pins that can be muxed as GPIOs, the second bank really has 28 GPIOs. Signed-off-by: Thomas Petazzoni Fixes: ca6d9a084b56f ("pinctrl: mvebu: add pin-muxing driver for the Marvell Armada 380/385") Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 1d3f0ee87cec8957c39d6b08be076b0a11f9fb4c Author: Thomas Petazzoni Date: Tue Jun 9 18:46:53 2015 +0200 pinctrl: mvebu: armada-38x: fix PCIe functions commit 331642fbf24a1c16b2669ca0a6479b5fcd6dd5b2 upstream. A new revision of the Marvell Armada 38x hardware datasheet unveiled that the definition of some of the PCIe functions were not correct. This commit fixes the pinctrl driver accordingly. Some PCIe functions simply do not exist, some of the PCIe functions in fact were corresponding to other functions, and some PCIe functions have been added. Note: the seemingly unrelated removal of spi(cs2) on MPP47 is related: this function is in fact implemented on MPP43, instead of a PCIe function. Signed-off-by: Thomas Petazzoni Fixes: ca6d9a084b56f ("pinctrl: mvebu: add pin-muxing driver for the Marvell Armada 380/385") Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 7f6d2a35acdd503e4bc35f790ccfefffba1872cc Author: Thomas Petazzoni Date: Tue Jun 9 18:46:55 2015 +0200 pinctrl: mvebu: armada-375: remove non-existing NAND re/we pins commit e5447d26092c72ef3346615ee558c9112ef8063f upstream. After updating to a more recent version of the Armada 375, we realized that some of the pins documented as having a NAND-related functionality in fact did not have such functionality. This commit updates the pinctrl driver accordingly. Signed-off-by: Thomas Petazzoni Fixes: ce3ed59dcddd ("pinctrl: mvebu: add pin-muxing driver for the Marvell Armada 375") Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 2893c1e916f58001b534b3050c6413b9d050a00d Author: Thomas Petazzoni Date: Tue Jun 9 18:46:59 2015 +0200 pinctrl: mvebu: armada-375: remove incorrect space in pin description commit d538990ee12b162f7ce6c0fcef3b643800102676 upstream. There was an incorrect space in the definition of the function of one pin in the Armada 375 pinctrl driver, which this commit fixes. Signed-off-by: Thomas Petazzoni Fixes: ce3ed59dcddd ("pinctrl: mvebu: add pin-muxing driver for the Marvell Armada 375") Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit f1a1a4b4cf987c0609aba4f45ddd44d7719d03e0 Author: Thomas Petazzoni Date: Tue Jun 9 18:46:54 2015 +0200 pinctrl: mvebu: armada-370: fix spi0 pin description commit 438881dfddb9107ef0eb30b49368e91e092f0b3e upstream. Due to a mistake, the CS0 and CS1 SPI0 functions were incorrectly named "spi0-1" instead of just "spi0". This commit fixes that. This DT binding change does not affect any of the in-tree users. Signed-off-by: Thomas Petazzoni Fixes: 5f597bb2be57 ("pinctrl: mvebu: add pinctrl driver for Armada 370") Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 09ed2dbb1a7e827c09115e46e59dfe03b8ccac94 Author: Masahiro Yamada Date: Wed May 20 17:42:31 2015 +0900 pinctrl: zynq: fix offset address for {SD0,SD1}_WP_CD_SEL commit 5cf021d52026c0e998756a3bdb475aae2e8a68a4 upstream. The address for SD0_WP_CD_SEL, SD1_WP_CD_SEL is 0xf8000830, 0xf8000834, respectively. Each offset address must be prefixed with 0x. Fixes: add958cee967 "pinctrl: Add driver for Zynq" Signed-off-by: Masahiro Yamada Reviewed-by: Sören Brinkmann Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit fc25a0db97a0417990c4f380f04ecf0d0ca095a6 Author: Masahiro Yamada Date: Wed May 20 17:42:30 2015 +0900 pinctrl: zynq: fix DEFINE_ZYNQ_PINMUX_FUNCTION_MUX macro commit 4f652cea020aac42972cb7c9788b470ed45aa228 upstream. The offset to the mux register is missing. Fixes: add958cee967 "pinctrl: Add driver for Zynq" Signed-off-by: Masahiro Yamada Reviewed-by: Sören Brinkmann Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman