commit 5f1d25a9a8c999ddb1a18a6b167f1284a46e4dd1 Author: Greg Kroah-Hartman Date: Fri Oct 27 10:39:17 2017 +0200 Linux 4.13.10 commit 2fbb8bf749b598085045b9485a46414f3baddfac Author: Arnd Bergmann Date: Fri Oct 13 09:47:47 2017 -0700 xfs: move two more RT specific functions into CONFIG_XFS_RT commit 785545c8982604fe3ba79d16409e83993be77d5e upstream. The last cleanup introduced two harmless warnings: fs/xfs/xfs_fsmap.c:480:1: warning: '__xfs_getfsmap_rtdev' defined but not used fs/xfs/xfs_fsmap.c:372:1: warning: 'xfs_getfsmap_rtdev_rtbitmap_helper' defined but not used This moves those two functions as well. Fixes: bb9c2e543325 ("xfs: move more RT specific code under CONFIG_XFS_RT") Signed-off-by: Arnd Bergmann Reviewed-by: Brian Foster Acked-by: Geert Uytterhoeven Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman commit 1e1427356d8d127f15fd273e82b992fb5928178d Author: Brian Foster Date: Fri Oct 13 09:47:46 2017 -0700 xfs: trim writepage mapping to within eof commit 40214d128e07dd21bb07a8ed6a7fe2f911281ab2 upstream. The writeback rework in commit fbcc02561359 ("xfs: Introduce writeback context for writepages") introduced a subtle change in behavior with regard to the block mapping used across the ->writepages() sequence. The previous xfs_cluster_write() code would only flush pages up to EOF at the time of the writepage, thus ensuring that any pages due to file-extending writes would be handled on a separate cycle and with a new, updated block mapping. The updated code establishes a block mapping in xfs_writepage_map() that could extend beyond EOF if the file has post-eof preallocation. Because we now use the generic writeback infrastructure and pass the cached mapping to each writepage call, there is no implicit EOF limit in place. If eofblocks trimming occurs during ->writepages(), any post-eof portion of the cached mapping becomes invalid. The eofblocks code has no means to serialize against writeback because there are no pages associated with post-eof blocks. Therefore if an eofblocks trim occurs and is followed by a file-extending buffered write, not only has the mapping become invalid, but we could end up writing a page to disk based on the invalid mapping. Consider the following sequence of events: - A buffered write creates a delalloc extent and post-eof speculative preallocation. - Writeback starts and on the first writepage cycle, the delalloc extent is converted to real blocks (including the post-eof blocks) and the mapping is cached. - The file is closed and xfs_release() trims post-eof blocks. The cached writeback mapping is now invalid. - Another buffered write appends the file with a delalloc extent. - The concurrent writeback cycle picks up the just written page because the writeback range end is LLONG_MAX. xfs_writepage_map() attributes it to the (now invalid) cached mapping and writes the data to an incorrect location on disk (and where the file offset is still backed by a delalloc extent). This problem is reproduced by xfstests test generic/464, which triggers racing writes, appends, open/closes and writeback requests. To address this problem, trim the mapping used during writeback to within EOF when the mapping is validated. This ensures the mapping is revalidated for any pages encountered beyond EOF as of the time the current mapping was cached or last validated. Reported-by: Eryu Guan Diagnosed-by: Eryu Guan Signed-off-by: Brian Foster Reviewed-by: Dave Chinner Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman commit 9df9b634f637c37f5e05f794ccd20150bafb3fa8 Author: Dave Chinner Date: Fri Oct 13 09:47:45 2017 -0700 xfs: cancel dirty pages on invalidation commit 793d7dbe6d82a50b9d14bf992b9eaacb70a11ce6 upstream. Recently we've had warnings arise from the vm handing us pages without bufferheads attached to them. This should not ever occur in XFS, but we don't defend against it properly if it does. The only place where we remove bufferheads from a page is in xfs_vm_releasepage(), but we can't tell the difference here between "page is dirty so don't release" and "page is dirty but is being invalidated so release it". In some places that are invalidating pages ask for pages to be released and follow up afterward calling ->releasepage by checking whether the page was dirty and then aborting the invalidation. This is a possible vector for releasing buffers from a page but then leaving it in the mapping, so we really do need to avoid dirty pages in xfs_vm_releasepage(). To differentiate between invalidated pages and normal pages, we need to clear the page dirty flag when invalidating the pages. This can be done through xfs_vm_invalidatepage(), and will result xfs_vm_releasepage() seeing the page as clean which matches the bufferhead state on the page after calling block_invalidatepage(). Hence we can re-add the page dirty check in xfs_vm_releasepage to catch the case where we might be releasing a page that is actually dirty and so should not have the bufferheads on it removed. This will remove one possible vector of "dirty page with no bufferheads" and so help narrow down the search for the root cause of that problem. Signed-Off-By: Dave Chinner Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman commit cd3f0bee1b94c64d0d0e898902e29ae65e5b639d Author: Eric Sandeen Date: Mon Oct 9 21:08:06 2017 -0700 xfs: handle error if xfs_btree_get_bufs fails commit 93e8befc17f6d6ea92b0aee3741ceac8bca4590f upstream. Jason reported that a corrupted filesystem failed to replay the log with a metadata block out of bounds warning: XFS (dm-2): _xfs_buf_find: Block out of range: block 0x80270fff8, EOFS 0x9c40000 _xfs_buf_find() and xfs_btree_get_bufs() return NULL if that happens, and then when xfs_alloc_fix_freelist() calls xfs_trans_binval() on that NULL bp, we oops with: BUG: unable to handle kernel NULL pointer dereference at 00000000000000f8 We don't handle _xfs_buf_find errors very well, every caller higher up the stack gets to guess at why it failed. But we should at least handle it somehow, so return EFSCORRUPTED here. Reported-by: Jason L Tibbitts III Signed-off-by: Eric Sandeen Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman commit 58cfca25f540f9872cbccef63241d9164c74a978 Author: Brian Foster Date: Mon Oct 9 11:38:56 2017 -0700 xfs: reinit btree pointer on attr tree inactivation walk commit f35c5e10c6ed6ba52a8dd8573924a80b6a02f03f upstream. xfs_attr3_root_inactive() walks the attr fork tree to invalidate the associated blocks. xfs_attr3_node_inactive() recursively descends from internal blocks to leaf blocks, caching block address values along the way to revisit parent blocks, locate the next entry and descend down that branch of the tree. The code that attempts to reread the parent block is unsafe because it assumes that the local xfs_da_node_entry pointer remains valid after an xfs_trans_brelse() and re-read of the parent buffer. Under heavy memory pressure, it is possible that the buffer has been reclaimed and reallocated by the time the parent block is reread. This means that 'btree' can point to an invalid memory address, lead to a random/garbage value for child_fsb and cause the subsequent read of the attr fork to go off the rails and return a NULL buffer for an attr fork offset that is most likely not allocated. Note that this problem can be manufactured by setting XFS_ATTR_BTREE_REF to 0 to prevent LRU caching of attr buffers, creating a file with a multi-level attr fork and removing it to trigger inactivation. To address this problem, reinit the node/btree pointers to the parent buffer after it has been re-read. This ensures btree points to a valid record and allows the walk to proceed. Signed-off-by: Brian Foster Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman commit 659a9989b68bb75d403e985dd6ad50b45bc62a11 Author: Dave Chinner Date: Mon Oct 9 11:37:23 2017 -0700 xfs: don't change inode mode if ACL update fails commit 67f2ffe31d1a683170c2ba0ecc643e42a5fdd397 upstream. If we get ENOSPC half way through setting the ACL, the inode mode can still be changed even though the ACL does not exist. Reorder the operation to only change the mode of the inode if the ACL is set correctly. Whilst this does not fix the problem with crash consistency (that requires attribute addition to be a deferred op) it does prevent ENOSPC and other non-fatal errors setting an xattr to be handled sanely. This fixes xfstests generic/449. Signed-Off-By: Dave Chinner Reviewed-by: Brian Foster Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman commit 88ccd3b6884ad7a04ff0222089184196636805ed Author: Dave Chinner Date: Mon Oct 9 11:37:22 2017 -0700 xfs: move more RT specific code under CONFIG_XFS_RT commit bb9c2e5433250f5b477035dc478314f8e6dd5e36 upstream. Various utility functions and interfaces that iterate internal devices try to reference the realtime device even when RT support is not compiled into the kernel. Make sure this code is excluded from the CONFIG_XFS_RT=n build, and where appropriate stub functions to return fatal errors if they ever get called when RT support is not present. Signed-Off-By: Dave Chinner Reviewed-by: Brian Foster Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman commit 5733ebee586c3bc8f5460f25a7401a3ae5cb7525 Author: Dave Chinner Date: Mon Oct 9 11:37:22 2017 -0700 xfs: Don't log uninitialised fields in inode structures commit 20413e37d71befd02b5846acdaf5e2564dd1c38e upstream. Prevent kmemcheck from throwing warnings about reading uninitialised memory when formatting inodes into the incore log buffer. There are several issues here - we don't always log all the fields in the inode log format item, and we never log the inode the di_next_unlinked field. In the case of the inode log format item, this is exacerbated by the old xfs_inode_log_format structure padding issue. Hence make the padded, 64 bit aligned version of the structure the one we always use for formatting the log and get rid of the 64 bit variant. This means we'll always log the 64-bit version and so recovery only needs to convert from the unpadded 32 bit version from older 32 bit kernels. Signed-Off-By: Dave Chinner Tested-by: Tetsuo Handa Reviewed-by: Brian Foster Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman commit 199a7448c097514a029d29e666e3dbb3bdd01f92 Author: Christoph Hellwig Date: Tue Oct 3 08:58:33 2017 -0700 xfs: handle racy AIO in xfs_reflink_end_cow commit e12199f85d0ad1b04ce6c425ad93cd847fe930bb upstream. If we got two AIO writes into a COW area the second one might not have any COW extents left to convert. Handle that case gracefully instead of triggering an assert or accessing beyond the bounds of the extent list. Signed-off-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman commit ee5d69c908a1d521be0e3d9adaeed84d644be5ef Author: Darrick J. Wong Date: Mon Sep 18 09:41:18 2017 -0700 xfs: always swap the cow forks when swapping extents commit 52bfcdd7adbc26639bc7b2356ab9a3f5dad68ad6 upstream. Since the CoW fork exists as a secondary data structure to the data fork, we must always swap cow forks during swapext. We also need to swap the extent counts and reset the cowblocks tags. Reviewed-by: Brian Foster Reviewed-by: Christoph Hellwig Signed-off-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman commit 2888145444f1cca68d001be9fbf80930c7383a23 Author: Carlos Maiolino Date: Fri Sep 22 11:47:46 2017 -0700 xfs: Capture state of the right inode in xfs_iflush_done commit 842f6e9f786226c58fcbd5ef80eadca72fdfe652 upstream. My previous patch: d3a304b6292168b83b45d624784f973fdc1ca674 check for XFS_LI_FAILED flag xfs_iflush done, so the failed item can be properly resubmitted. In the loop scanning other inodes being completed, it should check the current item for the XFS_LI_FAILED, and not the initial one. The state of the initial inode is checked after the loop ends Kudos to Eric for catching this. Signed-off-by: Carlos Maiolino Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman commit d0fa252b207fc7802e56e351874d94c25c484e1b Author: Darrick J. Wong Date: Mon Sep 18 09:42:09 2017 -0700 xfs: perag initialization should only touch m_ag_max_usable for AG 0 commit 9789dd9e1d939232e8ff4c50ef8e75aa6781b3fb upstream. We call __xfs_ag_resv_init to make a per-AG reservation for each AG. This makes the reservation per-AG, not per-filesystem. Therefore, it is incorrect to adjust m_ag_max_usable for each AG. Adjust it only when we're reserving AG 0's blocks so that we only do it once per fs. Signed-off-by: Darrick J. Wong Reviewed-by: Brian Foster Signed-off-by: Greg Kroah-Hartman commit 8da6f7fbe43c1783d4fdf9af6d5457194e50a60d Author: Eryu Guan Date: Thu Sep 21 11:26:18 2017 -0700 xfs: update i_size after unwritten conversion in dio completion commit ee70daaba82d70766d0723b743d9fdeb3b06102a upstream. Since commit d531d91d6990 ("xfs: always use unwritten extents for direct I/O writes"), we start allocating unwritten extents for all direct writes to allow appending aio in XFS. But for dio writes that could extend file size we update the in-core inode size first, then convert the unwritten extents to real allocations at dio completion time in xfs_dio_write_end_io(). Thus a racing direct read could see the new i_size and find the unwritten extents first and read zeros instead of actual data, if the direct writer also takes a shared iolock. Fix it by updating the in-core inode size after the unwritten extent conversion. To do this, introduce a new boolean argument to xfs_iomap_write_unwritten() to tell if we want to update in-core i_size or not. Suggested-by: Brian Foster Reviewed-by: Brian Foster Signed-off-by: Eryu Guan Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman commit a9eac76e958b0a2405cbde78cce557f903734f0a Author: Eryu Guan Date: Mon Sep 18 11:39:23 2017 -0700 xfs: report zeroed or not correctly in xfs_zero_range() commit d20a5e3851969fa685f118a80e4df670255a4e8d upstream. The 'did_zero' param of xfs_zero_range() was not passed to iomap_zero_range() correctly. This was introduced by commit 7bb41db3ea16 ("xfs: handle 64-bit length in xfs_iozero"), and found by code inspection. Signed-off-by: Eryu Guan Reviewed-by: Carlos Maiolino Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman commit 67d51bdcc9f413216ab3443189ce400445043955 Author: Helge Deller Date: Mon Sep 18 11:34:16 2017 -0700 fs/xfs: Use %pS printk format for direct addresses commit e150dcd459e1b441eaf08f341a986f04e61bf3b8 upstream. Use the %pS instead of the %pF printk format specifier for printing symbols from direct addresses. This is needed for the ia64, ppc64 and parisc64 architectures. Signed-off-by: Helge Deller Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman commit 2bf3122f2130ff66dfc2e1ea662e4d4d2d05efb1 Author: Darrick J. Wong Date: Mon Sep 18 09:41:17 2017 -0700 xfs: evict CoW fork extents when performing finsert/fcollapse commit 3af423b03435c81036fa710623d3ae92fbe346a3 upstream. When we perform an finsert/fcollapse operation, cancel all the CoW extents for the affected file offset range so that they don't end up pointing to the wrong blocks. Reported-by: Amir Goldstein Reviewed-by: Carlos Maiolino Reviewed-by: Christoph Hellwig Signed-off-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman commit a58a0826656d3159fd0cd0d8be63a80edf4dae07 Author: Darrick J. Wong Date: Mon Sep 18 09:41:16 2017 -0700 xfs: don't unconditionally clear the reflink flag on zero-block files commit cc6f77710a6de6210f9feda7cd53e2f5ee7a7e69 upstream. If we have speculative cow preallocations hanging around in the cow fork, don't let a truncate operation clear the reflink flag because if we do then there's a chance we'll forget to free those extents when we destroy the incore inode. Reported-by: Amir Goldstein Reviewed-by: Carlos Maiolino Reviewed-by: Christoph Hellwig Signed-off-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman commit c61e905e0ee2b0c603deb2a92590052fa6351dab Author: Chandan Rajendra Date: Fri Sep 22 11:47:33 2017 -0700 iomap_dio_rw: Allocate AIO completion queue before submitting dio commit 546e7be8244dc050effef0555df5b8d94d10dafc upstream. Executing xfs/104 test in a loop on Linux-v4.13 kernel on a ppc64 machine can cause the following NULL pointer dereference, .queue_work_on+0x4c/0x80 .iomap_dio_bio_end_io+0xbc/0x1f0 .bio_endio+0x118/0x1f0 .blk_update_request+0xd0/0x470 .blk_mq_end_request+0x24/0xc0 .lo_complete_rq+0x40/0xe0 .__blk_mq_complete_request_remote+0x28/0x40 .flush_smp_call_function_queue+0xc4/0x1e0 .smp_ipi_demux_relaxed+0x8c/0x100 .icp_hv_ipi_action+0x54/0xa0 .__handle_irq_event_percpu+0x84/0x2c0 .handle_irq_event_percpu+0x28/0x80 .handle_percpu_irq+0x78/0xc0 .generic_handle_irq+0x40/0x70 .__do_irq+0x88/0x200 .call_do_irq+0x14/0x24 .do_IRQ+0x84/0x130 This occurs due to the following sequence of events, 1. Allocate dio for Direct I/O write. 2. Invoke iomap_apply() until iov_iter_count() bytes have been submitted. - Assume that we have submitted atleast one bio. Hence iomap_dio->ref value will be >= 2. - If during the second iteration, iomap_apply() ends up returning -ENOSPC, we would break out of the loop and since the 'ret' value is a negative number we end up not allocating memory for super_block->s_dio_done_wq. 3. Meanwhile, iomap_dio_bio_end_io() is invoked for bios that have been submitted and here the code ends up dereferencing the NULL pointer stored at super_block->s_dio_done_wq. This commit fixes the bug by allocating memory for super_block->s_dio_done_wq before iomap_apply() is invoked. Reported-by: Eryu Guan Reviewed-by: Christoph Hellwig Tested-by: Eryu Guan Signed-off-by: Chandan Rajendra Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman commit 82d745a55779171d51eb4ce534a11e958ebd7b58 Author: Takashi Iwai Date: Mon Oct 16 11:39:28 2017 +0200 ALSA: hda - Fix incorrect TLV callback check introduced during set_fs() removal commit a91d66129fb9bcead12af3ed2008d6ddbf179509 upstream. The commit 99b5c5bb9a54 ("ALSA: hda - Remove the use of set_fs()") converted the get_kctl_0dB_offset() call for killing set_fs() usage in HD-audio codec code. The conversion assumed that the TLV callback used in HD-audio code is only snd_hda_mixer_amp() and applies the TLV calculation locally. Although this assumption is correct, and all slave kctls are actually with that callback, the current code is still utterly buggy; it doesn't hit this condition and falls back to the next check. It's because the function gets called after adding slave kctls to vmaster. By assigning a slave kctl, the slave kctl object is faked inside vmaster code, and the whole kctl ops are overridden. Thus the callback op points to a different value from what we've assumed. More badly, as reported by the KERNEXEC and UDEREF features of PaX, the code flow turns into the unexpected pitfall. The next fallback check is SNDRV_CTL_ELEM_ACCESS_TLV_READ access bit, and this always hits for each kctl with TLV. Then it evaluates the callback function pointer wrongly as if it were a TLV array. Although currently its side-effect is fairly limited, this incorrect reference may lead to an unpleasant result. For addressing the regression, this patch introduces a new helper to vmaster code, snd_ctl_apply_vmaster_slaves(). This works similarly like the existing map_slaves() in hda_codec.c: it loops over the slave list of the given master, and applies the given function to each slave. Then the initializer function receives the right kctl object and we can compare the correct pointer instead of the faked one. Also, for catching the similar breakage in future, give an error message when the unexpected TLV callback is found and bail out immediately. Fixes: 99b5c5bb9a54 ("ALSA: hda - Remove the use of set_fs()") Reported-by: PaX Team Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1aacf045279a55f7d2b2ab72e19925e8ca4c596b Author: Shawn Lin Date: Tue Oct 17 11:38:04 2017 +0800 arm64: dts: rockchip: correct vqmmc voltage for rk3399 platforms commit b31ce3041787b61f2dad39d2dcda5c4a81d10e2b upstream. The vcc_sd or vcc_sdio used for IO voltage for sdmmc and sdio interface on rk3399 platform have a limitation that it can't be larger than 3.0v, otherwise it has a potential risk for the chip. Correct all of them. Fixes: 171582e00db1 ("arm64: dts: rockchip: add support for firefly-rk3399 board") Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM") Fixes: 8164a84cca12 ("arm64: dts: rockchip: Add support for rk3399 sapphire SOM") Cc: stable@vger.kernel.org Signed-off-by: Shawn Lin Tested-by: Klaus Goger Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman commit 7610595830bbec52079a40e8d3928f6261c02dcc Author: Eric Sesterhenn Date: Sun Oct 8 20:02:32 2017 +0200 pkcs7: Prevent NULL pointer dereference, since sinfo is not always set. commit 68a1fdbbf8bd3378325e45c19e167a165f9ffc3a upstream. The ASN.1 parser does not necessarily set the sinfo field, this patch prevents a NULL pointer dereference on broken input. Fixes: 99db44350672 ("PKCS#7: Appropriately restrict authenticated attributes and content type") Signed-off-by: Eric Sesterhenn Signed-off-by: David Howells Signed-off-by: Greg Kroah-Hartman commit 24a33a0c96f3e976c18e4321ca09f71cb835a9b5 Author: David Howells Date: Thu Oct 12 16:00:41 2017 +0100 KEYS: don't let add_key() update an uninstantiated key commit 60ff5b2f547af3828aebafd54daded44cfb0807a upstream. Currently, when passed a key that already exists, add_key() will call the key's ->update() method if such exists. But this is heavily broken in the case where the key is uninstantiated because it doesn't call __key_instantiate_and_link(). Consequently, it doesn't do most of the things that are supposed to happen when the key is instantiated, such as setting the instantiation state, clearing KEY_FLAG_USER_CONSTRUCT and awakening tasks waiting on it, and incrementing key->user->nikeys. It also never takes key_construction_mutex, which means that ->instantiate() can run concurrently with ->update() on the same key. In the case of the "user" and "logon" key types this causes a memory leak, at best. Maybe even worse, the ->update() methods of the "encrypted" and "trusted" key types actually just dereference a NULL pointer when passed an uninstantiated key. Change key_create_or_update() to wait interruptibly for the key to finish construction before continuing. This patch only affects *uninstantiated* keys. For now we still allow a negatively instantiated key to be updated (thereby positively instantiating it), although that's broken too (the next patch fixes it) and I'm not sure that anyone actually uses that functionality either. Here is a simple reproducer for the bug using the "encrypted" key type (requires CONFIG_ENCRYPTED_KEYS=y), though as noted above the bug pertained to more than just the "encrypted" key type: #include #include #include int main(void) { int ringid = keyctl_join_session_keyring(NULL); if (fork()) { for (;;) { const char payload[] = "update user:foo 32"; usleep(rand() % 10000); add_key("encrypted", "desc", payload, sizeof(payload), ringid); keyctl_clear(ringid); } } else { for (;;) request_key("encrypted", "desc", "callout_info", ringid); } } It causes: BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 IP: encrypted_update+0xb0/0x170 PGD 7a178067 P4D 7a178067 PUD 77269067 PMD 0 PREEMPT SMP CPU: 0 PID: 340 Comm: reproduce Tainted: G D 4.14.0-rc1-00025-g428490e38b2e #796 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 task: ffff8a467a39a340 task.stack: ffffb15c40770000 RIP: 0010:encrypted_update+0xb0/0x170 RSP: 0018:ffffb15c40773de8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8a467a275b00 RCX: 0000000000000000 RDX: 0000000000000005 RSI: ffff8a467a275b14 RDI: ffffffffb742f303 RBP: ffffb15c40773e20 R08: 0000000000000000 R09: ffff8a467a275b17 R10: 0000000000000020 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: ffff8a4677057180 R15: ffff8a467a275b0f FS: 00007f5d7fb08700(0000) GS:ffff8a467f200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 0000000077262005 CR4: 00000000001606f0 Call Trace: key_create_or_update+0x2bc/0x460 SyS_add_key+0x10c/0x1d0 entry_SYSCALL_64_fastpath+0x1f/0xbe RIP: 0033:0x7f5d7f211259 RSP: 002b:00007ffed03904c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000f8 RAX: ffffffffffffffda RBX: 000000003b2a7955 RCX: 00007f5d7f211259 RDX: 00000000004009e4 RSI: 00000000004009ff RDI: 0000000000400a04 RBP: 0000000068db8bad R08: 000000003b2a7955 R09: 0000000000000004 R10: 000000000000001a R11: 0000000000000246 R12: 0000000000400868 R13: 00007ffed03905d0 R14: 0000000000000000 R15: 0000000000000000 Code: 77 28 e8 64 34 1f 00 45 31 c0 31 c9 48 8d 55 c8 48 89 df 48 8d 75 d0 e8 ff f9 ff ff 85 c0 41 89 c4 0f 88 84 00 00 00 4c 8b 7d c8 <49> 8b 75 18 4c 89 ff e8 24 f8 ff ff 85 c0 41 89 c4 78 6d 49 8b RIP: encrypted_update+0xb0/0x170 RSP: ffffb15c40773de8 CR2: 0000000000000018 Reported-by: Eric Biggers Signed-off-by: David Howells cc: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit ad4aa448c9b26d7cef15733daafd3cae5462daf0 Author: Eric Biggers Date: Mon Oct 9 12:40:00 2017 -0700 FS-Cache: fix dereference of NULL user_key_payload commit d124b2c53c7bee6569d2a2d0b18b4a1afde00134 upstream. When the file /proc/fs/fscache/objects (available with CONFIG_FSCACHE_OBJECT_LIST=y) is opened, we request a user key with description "fscache:objlist", then access its payload. However, a revoked key has a NULL payload, and we failed to check for this. request_key() *does* skip revoked keys, but there is still a window where the key can be revoked before we access its payload. Fix it by checking for a NULL payload, treating it like a key which was already revoked at the time it was requested. Fixes: 4fbf4291aa15 ("FS-Cache: Allow the current state of all objects to be dumped") Reviewed-by: James Morris Signed-off-by: Eric Biggers Signed-off-by: David Howells Signed-off-by: Greg Kroah-Hartman commit f45b8fe12221c178ce708b1c9d634634f2261802 Author: David Howells Date: Wed Oct 4 16:43:25 2017 +0100 KEYS: Fix race between updating and finding a negative key commit 363b02dab09b3226f3bd1420dad9c72b79a42a76 upstream. Consolidate KEY_FLAG_INSTANTIATED, KEY_FLAG_NEGATIVE and the rejection error into one field such that: (1) The instantiation state can be modified/read atomically. (2) The error can be accessed atomically with the state. (3) The error isn't stored unioned with the payload pointers. This deals with the problem that the state is spread over three different objects (two bits and a separate variable) and reading or updating them atomically isn't practical, given that not only can uninstantiated keys change into instantiated or rejected keys, but rejected keys can also turn into instantiated keys - and someone accessing the key might not be using any locking. The main side effect of this problem is that what was held in the payload may change, depending on the state. For instance, you might observe the key to be in the rejected state. You then read the cached error, but if the key semaphore wasn't locked, the key might've become instantiated between the two reads - and you might now have something in hand that isn't actually an error code. The state is now KEY_IS_UNINSTANTIATED, KEY_IS_POSITIVE or a negative error code if the key is negatively instantiated. The key_is_instantiated() function is replaced with key_is_positive() to avoid confusion as negative keys are also 'instantiated'. Additionally, barriering is included: (1) Order payload-set before state-set during instantiation. (2) Order state-read before payload-read when using the key. Further separate barriering is necessary if RCU is being used to access the payload content after reading the payload pointers. Fixes: 146aa8b1453b ("KEYS: Merge the type-specific data with the payload data") Reported-by: Eric Biggers Signed-off-by: David Howells Reviewed-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit e56be12012c28ec61ec5787a232e82be878ed4a9 Author: Eric Biggers Date: Mon Oct 9 12:51:27 2017 -0700 ecryptfs: fix dereference of NULL user_key_payload commit f66665c09ab489a11ca490d6a82df57cfc1bea3e upstream. In eCryptfs, we failed to verify that the authentication token keys are not revoked before dereferencing their payloads, which is problematic because the payload of a revoked key is NULL. request_key() *does* skip revoked keys, but there is still a window where the key can be revoked before we acquire the key semaphore. Fix it by updating ecryptfs_get_key_payload_data() to return -EKEYREVOKED if the key payload is NULL. For completeness we check this for "encrypted" keys as well as "user" keys, although encrypted keys cannot be revoked currently. Alternatively we could use key_validate(), but since we'll also need to fix ecryptfs_get_key_payload_data() to validate the payload length, it seems appropriate to just check the payload pointer. Fixes: 237fead61998 ("[PATCH] ecryptfs: fs/Makefile and fs/Kconfig") Reviewed-by: James Morris Cc: Michael Halcrow Signed-off-by: Eric Biggers Signed-off-by: David Howells Signed-off-by: Greg Kroah-Hartman commit 363ce0b01fe0a0e9e14886e451b077534b7fe7a2 Author: Eric Biggers Date: Mon Oct 9 12:46:18 2017 -0700 fscrypt: fix dereference of NULL user_key_payload commit d60b5b7854c3d135b869f74fb93eaf63cbb1991a upstream. When an fscrypt-encrypted file is opened, we request the file's master key from the keyrings service as a logon key, then access its payload. However, a revoked key has a NULL payload, and we failed to check for this. request_key() *does* skip revoked keys, but there is still a window where the key can be revoked before we acquire its semaphore. Fix it by checking for a NULL payload, treating it like a key which was already revoked at the time it was requested. Fixes: 88bd6ccdcdd6 ("ext4 crypto: add encryption key management facilities") Reviewed-by: James Morris Signed-off-by: Eric Biggers Signed-off-by: David Howells Signed-off-by: Greg Kroah-Hartman commit cc757d55c90369e947bcd9e986c188d16901f40e Author: Eric Biggers Date: Mon Oct 9 12:43:20 2017 -0700 lib/digsig: fix dereference of NULL user_key_payload commit 192cabd6a296cbc57b3d8c05c4c89d87fc102506 upstream. digsig_verify() requests a user key, then accesses its payload. However, a revoked key has a NULL payload, and we failed to check for this. request_key() *does* skip revoked keys, but there is still a window where the key can be revoked before we acquire its semaphore. Fix it by checking for a NULL payload, treating it like a key which was already revoked at the time it was requested. Fixes: 051dbb918c7f ("crypto: digital signature verification support") Reviewed-by: James Morris Cc: Dmitry Kasatkin Signed-off-by: Eric Biggers Signed-off-by: David Howells Signed-off-by: Greg Kroah-Hartman commit f5e97214207fd5ec112c2d61b2026a945b562699 Author: Borislav Petkov Date: Wed Oct 18 13:12:25 2017 +0200 x86/microcode/intel: Disable late loading on model 79 commit 723f2828a98c8ca19842042f418fb30dd8cfc0f7 upstream. Blacklist Broadwell X model 79 for late loading due to an erratum. Signed-off-by: Borislav Petkov Acked-by: Tony Luck Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/20171018111225.25635-1-bp@alien8.de Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 510e27f884d1912682231f443b0e110e5d1ab1a9 Author: Larry Finger Date: Wed Sep 20 16:15:05 2017 -0500 rtlwifi: rtl8821ae: Fix connection lost problem commit b8b8b16352cd90c6083033fd4487f04fae935c18 upstream. In commit 40b368af4b75 ("rtlwifi: Fix alignment issues"), the read of REG_DBI_READ was changed from 16 to 8 bits. For unknown reasonsi this change results in reduced stability for the wireless connection. This regression was located using bisection. Fixes: 40b368af4b75 ("rtlwifi: Fix alignment issues") Reported-and-tested-by: James Cameron Signed-off-by: Larry Finger Cc: Ping-Ke Shih Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 74c66c0bbfed46dd1c6df6171909de2cf7e52065 Author: David Kozub Date: Thu Oct 19 22:57:02 2017 +0200 clockevents/drivers/cs5535: Improve resilience to spurious interrupts commit eb39a7c0355393c5a8d930f342ad7a6231b552c4 upstream. The interrupt handler mfgpt_tick() is not robust versus spurious interrupts which happen before the clock event device is registered and fully initialized. The reason is that the safe guard against spurious interrupts solely checks for the clockevents shutdown state, but lacks a check for detached state. If the interrupt hits while the device is in detached state it passes the safe guard and dereferences the event handler call back which is NULL. Add the missing state check. Fixes: 8f9327cbb6e8 ("clockevents/drivers/cs5535: Migrate to new 'set-state' interface") Suggested-by: Thomas Gleixner Signed-off-by: David Kozub Signed-off-by: Thomas Gleixner Cc: Daniel Lezcano Link: https://lkml.kernel.org/r/20171020093103.3317F6004D@linux.fjfi.cvut.cz Signed-off-by: Greg Kroah-Hartman commit 59a33c5b7290ba0cd9cd4f136d9cc452b7559a7f Author: Jan Luebbe Date: Mon Aug 28 17:25:16 2017 +0200 bus: mbus: fix window size calculation for 4GB windows commit 2bbbd96357ce76cc45ec722c00f654aa7b189112 upstream. At least the Armada XP SoC supports 4GB on a single DRAM window. Because the size register values contain the actual size - 1, the MSB is set in that case. For example, the SDRAM window's control register's value is 0xffffffe1 for 4GB (bits 31 to 24 contain the size). The MBUS driver reads back each window's size from registers and calculates the actual size as (control_reg | ~DDR_SIZE_MASK) + 1, which overflows for 32 bit values, resulting in other miscalculations further on (a bad RAM window for the CESA crypto engine calculated by mvebu_mbus_setup_cpu_target_nooverlap() in my case). This patch changes the type in 'struct mbus_dram_window' from u32 to u64, which allows us to keep using the same register calculation code in most MBUS-using drivers (which calculate ->size - 1 again). Fixes: fddddb52a6c4 ("bus: introduce an Marvell EBU MBus driver") Signed-off-by: Jan Luebbe Signed-off-by: Gregory CLEMENT Signed-off-by: Greg Kroah-Hartman commit ec4b421221dea856379be8fd4ecc66fec1ade6ce Author: Chen-Yu Tsai Date: Fri Sep 8 15:50:09 2017 +0800 ARM: dts: sun6i: Fix endpoint IDs in second display pipeline commit a231d2783c332ef3e3ba238e82dbe599ff41ba14 upstream. When the second display pipeline device nodes for the A31/A31s were added, it was not known that the TCONs could (through either DRCs) select either backend as their input. Thus in the endpoints connecting these components together, the endpoint IDs were set to 0, while in fact they should have been set to 1. Fixes: 9a26882a7378 ("ARM: dts: sun6i: Add second display pipeline device nodes") Signed-off-by: Chen-Yu Tsai Signed-off-by: Maxime Ripard Signed-off-by: Greg Kroah-Hartman commit d26c0a8723f859c0a87ad989fb977f798fddc50f Author: Arnd Bergmann Date: Fri Sep 22 23:29:12 2017 +0200 brcmsmac: make some local variables 'static const' to reduce stack size commit c503dd38f850be28867ef7a42d9abe5ade81a9bd upstream. With KASAN and a couple of other patches applied, this driver is one of the few remaining ones that actually use more than 2048 bytes of kernel stack: broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy_gainctrl': broadcom/brcm80211/brcmsmac/phy/phy_n.c:16065:1: warning: the frame size of 3264 bytes is larger than 2048 bytes [-Wframe-larger-than=] broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy': broadcom/brcm80211/brcmsmac/phy/phy_n.c:17138:1: warning: the frame size of 2864 bytes is larger than 2048 bytes [-Wframe-larger-than=] Here, I'm reducing the stack size by marking as many local variables as 'static const' as I can without changing the actual code. This is the first of three patches to improve the stack usage in this driver. It would be good to have this backported to stabl kernels to get all drivers in 'allmodconfig' below the 2048 byte limit so we can turn on the frame warning again globally, but I realize that the patch is larger than the normal limit for stable backports. The other two patches do not need to be backported. Acked-by: Arend van Spriel Signed-off-by: Arnd Bergmann Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit afc62a9460f24eab1c91752b3fb08ffbe16ffcb0 Author: Kevin Cernekee Date: Sat Sep 16 21:08:24 2017 -0700 brcmfmac: Add check for short event packets commit dd2349121bb1b8ff688c3ca6a2a0bea9d8c142ca upstream. The length of the data in the received skb is currently passed into brcmf_fweh_process_event() as packet_len, but this value is not checked. event_packet should be followed by DATALEN bytes of additional event data. Ensure that the received packet actually contains at least DATALEN bytes of additional data, to avoid copying uninitialized memory into event->data. Suggested-by: Mattias Nissler Signed-off-by: Kevin Cernekee Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit ee398aed4817708173721a94998727ee5107a9a6 Author: Chanwoo Choi Date: Wed Oct 18 17:28:36 2017 -0700 Input: stmfts - fix setting ABS_MT_POSITION_* maximum size commit c9bfb2f0031a2de664147ebbfb90f95bb12fdf79 upstream. The commit 78bcac7b2ae1e ("Input: add support for the STMicroelectronics FingerTip touchscreen) used the 'touchscreen_parse_properties()' helper function in order to get the value of common properties. But, commit 78bcac7b2ae1e didn't set the capability of ABS_MT_POSITION_* before calling touchscreen_parse_properties(). In result, the max_x and max_y of 'struct touchscreen_properties' were not set. Fixes: 78bcac7b2ae1e ("Input: add support for the STMicroelectronics FingerTip touchscreen") Signed-off-by: Chanwoo Choi Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 7b5e405b7878bc6ecc338e5bedd0bf2eed43b078 Author: Len Brown Date: Tue Oct 17 16:00:02 2017 -0400 Revert "tools/power turbostat: stop migrating, unless '-m'" commit c97cc7dbce2fe6f46e137f4b040f915a0181ee85 upstream. This reverts commit c91fc8519d87715a3a173475ea3778794c139996. That change caused a C6 and PC6 residency regression on large idle systems. Users also complained about new output indicating jitter: turbostat: cpu6 jitter 3794 9142 Signed-off-by: Len Brown Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 73f8f48c57e37ac9758bfe8f1d605739f6d62757 Author: Guenter Roeck Date: Sat Jul 15 16:51:26 2017 -0700 i2c: piix4: Fix SMBus port selection for AMD Family 17h chips commit 0fe16195f89173652cf111d7b384941b00c5aabd upstream. AMD Family 17h uses the KERNCZ SMBus controller. While its documentation is not publicly available, it is documented in the BIOS and Kernel Developer’s Guide for AMD Family 15h Models 60h-6Fh Processors. On this SMBus controller, the port select register is at PMx register 0x02, bit 4:3 (PMx00 register bit 20:19). Without this patch, the 4 SMBus channels on AMD Family 17h chips are mirrored and report the same chips on all channels. Signed-off-by: Guenter Roeck Reviewed-by: Jean Delvare Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit adb0c133a4479ad477c60b630f16803ded751c64 Author: Pontus Andersson Date: Mon Oct 2 14:45:19 2017 +0200 i2c: ismt: Separate I2C block read from SMBus block read commit c6ebcedbab7ca78984959386012a17b21183e1a3 upstream. Commit b6c159a9cb69 ("i2c: ismt: Don't duplicate the receive length for block reads") broke I2C block reads. It aimed to fix normal SMBus block read, but changed the correct behavior of I2C block read in the process. According to Documentation/i2c/smbus-protocol, one vital difference between normal SMBus block read and I2C block read is that there is no byte count prefixed in the data sent on the wire: SMBus Block Read: i2c_smbus_read_block_data() S Addr Wr [A] Comm [A] S Addr Rd [A] [Count] A [Data] A [Data] A ... A [Data] NA P I2C Block Read: i2c_smbus_read_i2c_block_data() S Addr Wr [A] Comm [A] S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P Therefore the two transaction types need to be processed differently in the driver by copying of the dma_buffer as done previously for the I2C_SMBUS_I2C_BLOCK_DATA case. Fixes: b6c159a9cb69 ("i2c: ismt: Don't duplicate the receive length for block reads") Signed-off-by: Pontus Andersson Tested-by: Stephen Douthit Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 73459c67767df77cab51a040012b595ee6582bcc Author: Takashi Iwai Date: Tue Oct 17 16:38:55 2017 +0200 ALSA: hda: Abort capability probe at invalid register read commit 098a0a62c1554f5a3813ef1b8539563214ada8f6 upstream. The loop in snd_hdac_bus_parse_capabilities() may go to nirvana when it hits an invalid register value read: BUG: unable to handle kernel paging request at ffffad5dc41f3fff IP: pci_azx_readl+0x5/0x10 [snd_hda_intel] Call Trace: snd_hdac_bus_parse_capabilities+0x3c/0x1f0 [snd_hda_core] azx_probe_continue+0x7d5/0x940 [snd_hda_intel] ..... This happened on a new Intel machine, and we need to check the value and abort the loop accordingly. [Note: the fixes tag below indicates only the commit where this patch can be applied; the original problem was introduced even before that commit] Fixes: 6720b38420a0 ("ALSA: hda - move bus_parse_capabilities to core") Acked-by: Vinod Koul Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit dc67aedafecaee986d4c6e4383de7fb3fb1e6609 Author: Takashi Iwai Date: Tue Oct 17 11:58:17 2017 +0200 ALSA: hda: Remove superfluous '-' added by printk conversion commit 6bf88a343db2b3c160edf9b82a74966b31cc80bd upstream. While converting the error messages to the standard macros in the commit 4e76a8833fac ("ALSA: hda - Replace with standard printk"), a superfluous '-' slipped in the code mistakenly. Its influence is almost negligible, merely shows a dB value as negative integer instead of positive integer (or vice versa) in the rare error message. So let's kill this embarrassing byte to show more correct value. Fixes: 4e76a8833fac ("ALSA: hda - Replace with standard printk") Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit da401672310d51c660e10e9f077a0e3ff4a3bbf0 Author: Ben Hutchings Date: Wed Oct 18 00:45:49 2017 +0100 ALSA: seq: Enable 'use' locking in all configurations commit 8009d506a1dd00cf436b0c4cca0dcec130580a21 upstream. The 'use' locking macros are no-ops if neither SMP or SND_DEBUG is enabled. This might once have been OK in non-preemptible configurations, but even in that case snd_seq_read() may sleep while relying on a 'use' lock. So always use the proper implementations. Signed-off-by: Ben Hutchings Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e280f0677fbf5d2a273e1a372d4bfc7fdf5370a4 Author: Steven Rostedt (VMware) Date: Tue Oct 17 14:55:24 2017 -0400 tracing/samples: Fix creation and deletion of simple_thread_fn creation commit 6575257c60e1a26a5319ccf2b5ce5b6449001017 upstream. Commit 7496946a8 ("tracing: Add samples of DECLARE_EVENT_CLASS() and DEFINE_EVENT()") added template examples for all the events. It created a DEFINE_EVENT_FN() example which reused the foo_bar_reg and foo_bar_unreg functions. Enabling both the TRACE_EVENT_FN() and DEFINE_EVENT_FN() example trace events caused the foo_bar_reg to be called twice, creating the test thread twice. The foo_bar_unreg would remove it only once, even if it was called multiple times, leaving a thread existing when the module is unloaded, causing an oops. Add a ref count and allow foo_bar_reg() and foo_bar_unreg() be called by multiple trace events. Fixes: 7496946a8 ("tracing: Add samples of DECLARE_EVENT_CLASS() and DEFINE_EVENT()") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 219db7f1756fd50c1507e175655a3887eca95a63 Author: Sean Young Date: Sat Sep 2 07:42:42 2017 -0400 media: dvb: i2c transfers over usb cannot be done from stack commit b4756707152700c96acdfe149cb1ca4cec306c7a upstream. Since commit 29d2fef8be11 ("usb: catch attempts to submit urbs with a vmalloc'd transfer buffer"), the AverMedia AverTV DVB-T USB 2.0 (a800) fails to probe. Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit c2c3a6a57a9502ea57298a1b4e7d4dd7b73dd57a Author: Jose Abreu Date: Thu Sep 14 11:23:38 2017 -0400 media: cec: Respond to unregistered initiators, when applicable commit 845d6524d69b40bd6abd61dc1264a8657159aa55 upstream. Running CEC 1.4 compliance test we get the following error on test 11.1.6.2: "ERROR: The DUT did not broadcast a message to the unregistered device." Fix this by letting GIVE_PHYSICAL_ADDR message respond to unregistered device. Also, GIVE_DEVICE_VENDOR_ID and GIVE_FEATURES fall in the same category so, respond also to these messages. With this fix we pass CEC 1.4 official compliance. Signed-off-by: Jose Abreu Cc: Joao Pinto Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 3e3705c989aa0c6be6e4a6092aea8fe325b3e2da Author: Hans Verkuil Date: Thu Aug 31 12:56:10 2017 -0400 media: s5p-cec: add NACK detection support commit e949f61461ab83b094cad564c89a8d2b078b4508 upstream. The s5p-cec driver returned CEC_TX_STATUS_ERROR for the NACK condition. Some digging into the datasheet uncovered the S5P_CEC_TX_STAT1 register where bit 0 indicates if the transmit was nacked or not. Use this to return the correct CEC_TX_STATUS_NACK status to userspace. This was the only driver that couldn't tell a NACK from another error, and that was very unusual. And a potential problem for applications as well. Tested with my Odroid-U3. Signed-off-by: Hans Verkuil Acked-by: Sylwester Nawrocki Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 44681a35e10c091a473842bd214ed0e1e8b2935d Author: Ben Skeggs Date: Mon Sep 25 15:05:38 2017 +1000 drm/nouveau/mmu: flush tlbs before deleting page tables commit 77913bbcb43ac9a07a6fe849c2fd3bf85fc8bdd8 upstream. Even though we've zeroed the PDE, the GPU may have cached the PD, so we need to flush when deleting them. Noticed while working on replacement MMU code, but a backport might be a good idea, so let's fix it in the current code too. Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit e62932c347c6353e9938c875ba926f40659cf74c Author: Ilia Mirkin Date: Sun Oct 1 13:52:43 2017 -0400 drm/nouveau/bsp/g92: disable by default commit 194d68dd051c2dd5ac2b522ae16100e774e8d869 upstream. G92's seem to require some additional bit of initialization before the BSP engine can work. It feels like clocks are not set up for the underlying VLD engine, which means that all commands submitted to the xtensa chip end up hanging. VP seems to work fine though. This still allows people to force-enable the bsp engine if they want to play around with it, but makes it harder for the card to hang by default. Signed-off-by: Ilia Mirkin Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 2dfc9e7240eeef4d0880cbcf07591604afcae3b5 Author: Ben Skeggs Date: Tue Oct 3 16:24:28 2017 +1000 drm/nouveau/kms/nv50: fix oops during DP IRQ handling on non-MST boards commit 227f66d2f9954f68375736af62ebcd73c6754d69 upstream. Reported-by: Woody Suwalski Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 7b89d147cb3a26c162a853fcfc5ebc2b7ca07264 Author: Chris Wilson Date: Fri Oct 13 16:47:35 2017 +0100 drm/i915: Use bdw_ddi_translations_fdi for Broadwell commit fbe776cc3a753618877f7ce87a28ae3480743348 upstream. The compiler warns: drivers/gpu/drm/i915/intel_ddi.c:118:35: warning: ‘bdw_ddi_translations_fdi’ defined but not used Lo and behold, if we look at intel_ddi_get_buf_trans_fdi(), it uses hsw_ddi_translations_fdi[] for both Haswell and *Broadwell* Fixes: 7d1c42e679f9 ("drm/i915: Refactor code to select the DDI buf translation table") Signed-off-by: Chris Wilson Cc: Ville Syrjälä Cc: David Weinehall Cc: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20171013154735.27163-1-chris@chris-wilson.co.uk Reviewed-by: Jani Nikula Reviewed-by: Ville Syrjälä (cherry picked from commit 1210d3889077653b90b0bfd2cc54e19f4766e4e6) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit e8194caabdf1c292a07138806f3d9a894cb41a49 Author: Adrian Hunter Date: Mon Oct 9 10:24:01 2017 +0300 mmc: sdhci-pci: Fix default d3_retune for Intel host controllers commit eb701ce16a45ed9880897c48f05ee608d77c72e3 upstream. The default for d3_retune is true, but that was not being set in all cases, which results in eMMC errors because re-tuning has not been done. Fix by initializing d3_retune to true. Signed-off-by: Adrian Hunter Fixes: c959a6b00ff5 ("mmc: sdhci-pci: Don't re-tune with runtime pm for some Intel devices") Reported-and-tested-by: ojab Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 8b1e10789c840109c9dd024c9b52ba23b690b7c4 Author: Eric Biggers Date: Mon Oct 9 12:37:49 2017 -0700 KEYS: encrypted: fix dereference of NULL user_key_payload commit 13923d0865ca96312197962522e88bc0aedccd74 upstream. A key of type "encrypted" references a "master key" which is used to encrypt and decrypt the encrypted key's payload. However, when we accessed the master key's payload, we failed to handle the case where the master key has been revoked, which sets the payload pointer to NULL. Note that request_key() *does* skip revoked keys, but there is still a window where the key can be revoked before we acquire its semaphore. Fix it by checking for a NULL payload, treating it like a key which was already revoked at the time it was requested. This was an issue for master keys of type "user" only. Master keys can also be of type "trusted", but those cannot be revoked. Fixes: 7e70cb497850 ("keys: add new key-type encrypted") Reviewed-by: James Morris Cc: Mimi Zohar Cc: David Safford Signed-off-by: Eric Biggers Signed-off-by: David Howells Signed-off-by: Greg Kroah-Hartman commit 92fbaf970afdda14eed5f8f1c571ac3016fc2523 Author: ZHU Yi (ST-FIR/ENG1-Zhu) Date: Fri Sep 15 07:09:37 2017 +0000 can: flexcan: fix p1010 state transition issue commit fb5b91d61bebc24686ffc379138fd67808b1a1e6 upstream. Enable FLEXCAN_QUIRK_BROKEN_WERR_STATE and FLEXCAN_QUIRK_BROKEN_PERR_STATE for p1010 to report correct state transitions. Signed-off-by: Zhu Yi Signed-off-by: Mark Jonas Acked-by: Wolfgang Grandegger Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 2fec746de7af57f6035cafba9476c61822814d3d Author: ZHU Yi (ST-FIR/ENG1-Zhu) Date: Fri Sep 15 07:08:23 2017 +0000 can: flexcan: fix i.MX28 state transition issue commit 083c5571290a2d4308b75f1a59cf376b6e907808 upstream. Enable FLEXCAN_QUIRK_BROKEN_PERR_STATE for i.MX28 to report correct state transitions, especially to error passive. Signed-off-by: Wolfgang Grandegger Signed-off-by: Zhu Yi Signed-off-by: Mark Jonas Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 6d85c0adccec86a07a5b3960cdbbb3cd6f25d60a Author: ZHU Yi (ST-FIR/ENG1-Zhu) Date: Fri Sep 15 07:05:50 2017 +0000 can: flexcan: fix i.MX6 state transition issue commit cf9c04677f2bf599b44511963039ec6e25583feb upstream. Enable FLEXCAN_QUIRK_BROKEN_PERR_STATE for i.MX6 to report correct state transitions. Signed-off-by: Zhu Yi Signed-off-by: Mark Jonas Acked-by: Wolfgang Grandegger Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit fbd7c47fc62c418f27af467166ad3040589b4a7f Author: ZHU Yi (ST-FIR/ENG1-Zhu) Date: Fri Sep 15 07:03:58 2017 +0000 can: flexcan: implement error passive state quirk commit da49a8075c00b4d98ef069a0ee201177a8b79ead upstream. Add FLEXCAN_QUIRK_BROKEN_PERR_STATE for better description of the missing error passive interrupt quirk. Error interrupt flooding may happen if the broken error state quirk fix is enabled. For example, in case there is singled out node on the bus and the node sends a frame, then error interrupt flooding happens and will not stop because the node cannot go to bus off. The flooding will stop after another node connected to the bus again. If high bitrate configured on the low end system, then the flooding may causes performance issue, hence, this patch mitigates this by: 1. disable error interrupt upon error passive state transition 2. re-enable error interrupt upon error warning state transition 3. disable/enable error interrupt upon error active state transition depends on FLEXCAN_QUIRK_BROKEN_WERR_STATE In this way, the driver is still able to report correct state transitions without additional latency. When there are bus problems, flooding of error interrupts is limited to the number of frames required to change state from error warning to error passive if the core has [TR]WRN_INT connected (FLEXCAN_QUIRK_BROKEN_WERR_STATE is not enabled), otherwise, the flooding is limited to the number of frames required to change state from error active to error passive. Signed-off-by: Zhu Yi Signed-off-by: Mark Jonas Acked-by: Wolfgang Grandegger Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit bf2fc7f191b5744b193991753d871e214c0ba83c Author: ZHU Yi (ST-FIR/ENG1-Zhu) Date: Fri Sep 15 07:01:23 2017 +0000 can: flexcan: rename legacy error state quirk commit 2f8639b24b4f4f9dd6cf7c1f2aea90e2fcbcc451 upstream. Rename FLEXCAN_QUIRK_BROKEN_ERR_STATE to FLEXCAN_QUIRK_BROKEN_WERR_STATE for better description of the missing [TR]WRN_INT quirk. Signed-off-by: Zhu Yi Signed-off-by: Mark Jonas Acked-by: Wolfgang Grandegger Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 201ff91da409a7c77aaed642494075c105d70dcc Author: ZHU Yi (ST-FIR/ENG1-Zhu) Date: Fri Sep 15 06:59:15 2017 +0000 can: flexcan: fix state transition regression commit ad2302345d59d29232cb668baaae9e840925d153 upstream. Update state upon any interrupt to report correct state transitions in case the flexcan core enabled the broken error state quirk fix. Signed-off-by: Zhu Yi Signed-off-by: Mark Jonas Acked-by: Wolfgang Grandegger Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 8f0a7b0262eea5796bc6b9c4c639bf44f395d7ee Author: Marc Kleine-Budde Date: Sat Jul 29 11:51:01 2017 +0200 can: af_can: can_pernet_init(): add missing error handling for kzalloc returning NULL commit 5a606223c6b5b7560da253ed52e62c67fa18e29b upstream. This patch adds the missing check and error handling for out-of-memory situations, when kzalloc cannot allocate memory. Fixes: cb5635a36776 ("can: complete initial namespace support") Acked-by: Oliver Hartkopp Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 5463bc9a46f2484012ab147c6483aa3973f47665 Author: Stefan Mätje Date: Wed Oct 18 13:25:17 2017 +0200 can: esd_usb2: Fix can_dlc value for received RTR, frames commit 72d92e865d1560723e1957ee3f393688c49ca5bf upstream. The dlc member of the struct rx_msg contains also the ESD_RTR flag to mark received RTR frames. Without the fix the can_dlc value for received RTR frames would always be set to 8 by get_can_dlc() instead of the received value. Fixes: 96d8e90382dc ("can: Add driver for esd CAN-USB/2 device") Signed-off-by: Stefan Mätje Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit e47a56cbf51953dc0d96c2e8f9acfd2b724ff313 Author: Mayank Rana Date: Fri Oct 6 17:45:30 2017 +0300 usb: xhci: Handle error condition in xhci_stop_device() commit b3207c65dfafae27e7c492cb9188c0dc0eeaf3fd upstream. xhci_stop_device() calls xhci_queue_stop_endpoint() multiple times without checking the return value. xhci_queue_stop_endpoint() can return error if the HC is already halted or unable to queue commands. This can cause a deadlock condition as xhci_stop_device() would end up waiting indefinitely for a completion for the command that didn't get queued. Fix this by checking the return value and bailing out of xhci_stop_device() in case of error. This patch happens to fix potential memory leaks of the allocated command structures as well. Fixes: c311e391a7ef ("xhci: rework command timeout and cancellation,") Signed-off-by: Mayank Rana Signed-off-by: Jack Pham Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit d53911e63388926487fd835d2f4e6506630972a2 Author: Lu Baolu Date: Fri Oct 6 17:45:29 2017 +0300 usb: xhci: Reset halted endpoint if trb is noop commit 810a624bd1b64b13ddcc2eb5c1880526a750a870 upstream. When a URB is cancled, xhci driver turns the untransferred trbs into no-ops. If an endpoint stalls on a no-op trb that belongs to the cancelled URB, the event handler won't reset the endpoint. Hence, it will stay halted. Link: http://marc.info/?l=linux-usb&m=149582598330127&w=2 Signed-off-by: Lu Baolu Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit d1120fe38b3f19d4c66084c3cca7439a8aa1238d Author: Jeffy Chen Date: Fri Oct 6 17:45:28 2017 +0300 xhci: Cleanup current_cmd in xhci_cleanup_command_queue() commit d1aad52cf8b3f95dfe9b5b64da66343306ddf73b upstream. KASAN reported use-after-free bug when xhci host controller died: [ 176.952537] BUG: KASAN: use-after-free in xhci_handle_command_timeout+0x68/0x224 [ 176.960846] Write of size 4 at addr ffffffc0cbb01608 by task kworker/3:3/1680 ... [ 177.180644] Freed by task 0: [ 177.183882] kasan_slab_free+0x90/0x15c [ 177.188194] kfree+0x114/0x28c [ 177.191630] xhci_cleanup_command_queue+0xc8/0xf8 [ 177.196916] xhci_hc_died+0x84/0x358 Problem here is that when the cmd_timer fired, it would try to access current_cmd while the command queue is already freed by xhci_hc_died(). Cleanup current_cmd in xhci_cleanup_command_queue() to avoid that. Fixes: d9f11ba9f107 ("xhci: Rework how we handle unresponsive or hoptlug removed hosts") Signed-off-by: Jeffy Chen Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 301d332138d2aea68b5ca870a969ba7e38967915 Author: Mathias Nyman Date: Fri Oct 6 17:45:27 2017 +0300 xhci: Identify USB 3.1 capable hosts by their port protocol capability commit ea7d0d69426cab6747ed311c53f4142eb48b9454 upstream. Many USB 3.1 capable hosts never updated the Serial Bus Release Number (SBRN) register to USB 3.1 from USB 3.0 xhci driver identified USB 3.1 capable hosts based on this SBRN register, which according to specs "contains the release of the Universal Serial Bus Specification with which this Universal Serial Bus Host Controller module is compliant." but still in october 2017 gives USB 3.0 as the only possible option. Make an additional check for USB 3.1 support and enable it if the xHCI supported protocol capablity lists USB 3.1 capable ports. Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 180de9e37c6f759e5b041f070b08d4540cb97829 Author: Jonathan Liu Date: Mon Oct 9 22:46:12 2017 -0500 usb: musb: Check for host-mode using is_host_active() on reset interrupt commit 445ef61543da3db5b699f87fb0aa4f227165f6ed upstream. The sunxi musb has a bug where sometimes it will generate a babble error on device disconnect instead of a disconnect IRQ. When this happens the musb controller switches from host mode to device mode (it clears MUSB_DEVCTL_HM/MUSB_DEVCTL_SESSION and sets MUSB_DEVCTL_BDEVICE) and gets stuck in this state. The babble error is misdetected as a bus reset because MUSB_DEVCTL_HM was cleared. To fix this, use is_host_active() rather than (devctl & MUSB_DEVCTL_HM) to detect babble error so that sunxi musb babble recovery can handle it by restoring the mode. This information is provided by the driver logic and does not rely on register contents. Signed-off-by: Jonathan Liu Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman commit 154af043a9902c5055e4253533dc2ee321a4fb11 Author: Alexandre Bailon Date: Mon Oct 9 22:46:11 2017 -0500 usb: musb: musb_cppi41: Configure the number of channels for DA8xx commit 297d7fe9e439473800ab1f2f853b4b5f8c888500 upstream. Currently, the number of channels is set to 15 but in the case of DA8xx, the number of channels is 4. Update the driver to configure the number of channels at runtime. Signed-off-by: Alexandre Bailon Tested-by: Sekhar Nori Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman commit 24f31a23540e9cb88787113e8e005504263bcf2b Author: Alexandre Bailon Date: Mon Oct 9 22:46:10 2017 -0500 usb: musb: musb_cppi41: Fix cppi41_set_dma_mode() for DA8xx commit e10c5b0c773efb8643ee89d387d310584ca30830 upstream. The way to configure the DMA mode on DA8xx is different from DSPS. Add a new function to configure DMA mode on DA8xx and use a callback to call the right function based on the platform. Signed-off-by: Alexandre Bailon Tested-by: Sekhar Nori Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman commit db6e446f73eb5999aa32cad624a9f3afc0057d59 Author: Alexandre Bailon Date: Mon Oct 9 22:46:09 2017 -0500 usb: musb: musb_cppi41: Fix the address of teardown and autoreq registers commit bfa53e0e366b98185fadb03f7916d1538cb90ebd upstream. The DA8xx and DSPS platforms don't use the same address for few registers. On Da8xx, this is causing some issues (e.g. teardown that doesn't work). Configure the address of the register during the init and use them instead of constants. Reported-by: nsekhar@ti.com Signed-off-by: Alexandre Bailon Tested-by: Sekhar Nori Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman commit 6fc8dcbecd6395af39fbe0e595ec9c21b0532db6 Author: Johan Hovold Date: Mon Oct 9 22:46:08 2017 -0500 USB: musb: fix late external abort on suspend commit 0c3aae9bd59978fb8c3557d7883380bef0f2cfa1 upstream. The musb delayed irq work was never flushed on suspend, something which since 4.9 can lead to an external abort if the work is scheduled after the grandparent's clock has been disabled: PM: Suspending system (mem) PM: suspend of devices complete after 125.224 msecs PM: suspend devices took 0.132 seconds PM: late suspend of devices complete after 7.423 msecs PM: noirq suspend of devices complete after 7.083 msecs suspend debug: Waiting for 5 second(s). Unhandled fault: external abort on non-linefetch (0x1008) at 0xd0262c60 ... [] (musb_default_readb) from [] (musb_irq_work+0x48/0x220) [] (musb_irq_work) from [] (process_one_work+0x1f4/0x758) [] (process_one_work) from [] (worker_thread+0x54/0x514) [] (worker_thread) from [] (kthread+0x128/0x158) [] (kthread) from [] (ret_from_fork+0x14/0x24) Commit 2bff3916fda9 ("usb: musb: Fix PM for hub disconnect") started scheduling musb_irq_work with a delay of up to a second and with retries thereby making this easy to trigger, for example, by suspending shortly after a disconnect. Note that we set a flag to prevent the irq work from rescheduling itself during suspend and instead process a disconnect immediately. This takes care of the case where we are disconnected shortly before suspending. However, when in host mode, a disconnect while suspended will still go unnoticed and thus prevent the controller from runtime suspending upon resume as the session bit is always set. This will need to be addressed separately. Fixes: 550a7375fe72 ("USB: Add MUSB and TUSB support") Fixes: 467d5c980709 ("usb: musb: Implement session bit based runtime PM for musb-core") Fixes: 2bff3916fda9 ("usb: musb: Fix PM for hub disconnect") Cc: Felipe Balbi Cc: Tony Lindgren Signed-off-by: Johan Hovold Tested-by: Tony Lindgren Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman commit 9533e3607af86b97deaf54197503780a5f6183cf Author: Johan Hovold Date: Mon Oct 9 22:46:07 2017 -0500 USB: musb: fix session-bit runtime-PM quirk commit 4f190e0b9de89c4c917c3ffb3799e9d00fc534ac upstream. The current session-bit quirk implementation does not prevent the retry counter from underflowing, something which could break runtime PM and keep the device active for a very long time (about 2^32 seconds) after a disconnect. This notably breaks the B-device timeout case, but could potentially cause problems also when the controller is operating as an A-device. Fixes: 2bff3916fda9 ("usb: musb: Fix PM for hub disconnect") Cc: Tony Lindgren Signed-off-by: Johan Hovold Tested-by: Tony Lindgren Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman commit a2259ebaa933331c53904caf792b619ec42f0da5 Author: Jonathan Liu Date: Mon Oct 9 22:46:13 2017 -0500 usb: musb: sunxi: Explicitly release USB PHY on exit commit 6ed05c68cbcae42cd52b8e53b66952bfa9c002ce upstream. This fixes a kernel oops when unloading the driver due to usb_put_phy being called after usb_phy_generic_unregister when the device is detached. Calling usb_phy_generic_unregister causes x->dev->driver to be NULL in usb_put_phy and results in a NULL pointer dereference. Signed-off-by: Jonathan Liu Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman commit 8472cf52c3c01285d99e7ee808f725e8bfcdafd9 Author: Lars-Peter Clausen Date: Fri Sep 29 15:24:05 2017 +0200 iio: dummy: events: Add missing break commit be94a6f6d488b4767662e8949dc62361bd1d6311 upstream. Add missing break in iio_simple_dummy_write_event_config() for the voltage threshold event enable attribute. Without this writing to the in_voltage0_thresh_rising_en always returns -EINVAL even though the change was correctly applied. Fixes: 3e34e650db197 ("iio: dummy: Demonstrate the usage of new channel types") Signed-off-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit d29babf5c2320f1e42fc4d343b3f369788696f23 Author: Helge Deller Date: Wed Oct 18 22:25:00 2017 +0200 parisc: Fix detection of nonsynchronous cr16 cycle counters commit 8642b31ba9eef8a01845146a26682d4869e62513 upstream. For CPUs which have an unknown or invalid CPU location (physical location) assume that their cycle counters aren't syncronized across CPUs. Signed-off-by: Helge Deller Fixes: c8c3735997a3 ("parisc: Enhance detection of synchronous cr16 clocksources") Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit f0889088d5fce357ce8ecfa3a094a94d57c545f0 Author: John David Anglin Date: Sat Sep 30 17:24:23 2017 -0400 parisc: Fix double-word compare and exchange in LWS code on 32-bit kernels commit 374b3bf8e8b519f61eb9775888074c6e46b3bf0c upstream. As discussed on the debian-hppa list, double-wordcompare and exchange operations fail on 32-bit kernels. Looking at the code, I realized that the ",ma" completer does the wrong thing in the "ldw,ma 4(%r26), %r29" instruction. This increments %r26 and causes the following store to write to the wrong location. Note by Helge Deller: The patch applies cleanly to stable kernel series if this upstream commit is merged in advance: f4125cfdb300 ("parisc: Avoid trashing sr2 and sr3 in LWS code"). Signed-off-by: John David Anglin Tested-by: Christoph Biedl Fixes: 89206491201c ("parisc: Implement new LWS CAS supporting 64 bit operations.") Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 62fba6cbbcbfa97ec789daa0b7fb836d94644f28 Author: Christian Borntraeger Date: Wed Oct 4 14:46:17 2017 +0200 s390/cputime: fix guest/irq/softirq times after CPU hotplug commit b7662eef14caf4f582d453d45395825b5a8f594c upstream. On CPU hotplug some cpu stats contain bogus values: $ cat /proc/stat cpu 0 0 49 1280 0 0 0 3 0 0 cpu0 0 0 49 618 0 0 0 3 0 0 cpu1 0 0 0 662 0 0 0 0 0 0 [...] $ echo 0 > /sys/devices/system/cpu/cpu1/online $ echo 1 > /sys/devices/system/cpu/cpu1/online $ cat /proc/stat cpu 0 0 49 3200 0 450359962737 450359962737 3 0 0 cpu0 0 0 49 1956 0 0 0 3 0 0 cpu1 0 0 0 1244 0 450359962737 450359962737 0 0 0 [...] pcpu_attach_task() needs the same assignments as vtime_task_switch. Signed-off-by: Christian Borntraeger Fixes: b7394a5f4ce9 ("sched/cputime, s390: Implement delayed accounting of system time") Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 6948b6c3842668d95150516ac9791e1a4353ddaf Author: Josef Bacik Date: Mon Oct 9 13:12:10 2017 -0400 nbd: don't set the device size until we're connected commit 639812a1ed9bf49ae2c026086fbf975339cd1eef upstream. A user reported a regression with using the normal ioctl interface on newer kernels. This happens because I was setting the device size before the device was actually connected, which caused us to error out and close everything down. This didn't happen on netlink because we hold the device lock the whole time we're setting things up, but we don't do that for the ioctl path. This fixes the problem. Fixes: 29eaadc ("nbd: stop using the bdev everywhere") Signed-off-by: Josef Bacik Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 1ed37ce2533ae03861ae5ee8f5bc4366f5acb64b Author: Quinn Tran Date: Tue Oct 10 12:08:22 2017 -0700 scsi: qla2xxx: Fix uninitialized work element commit a9e170e28636fd577249f39029d59e4e960a42b8 upstream. Fixes following stack trace kernel: Call Trace: kernel: dump_stack+0x63/0x84 kernel: __warn+0xd1/0xf0 kernel: warn_slowpath_null+0x1d/0x20 kernel: __queue_work+0x37a/0x420 kernel: queue_work_on+0x27/0x40 kernel: queue_work+0x14/0x20 [qla2xxx] kernel: schedule_work+0x13/0x20 [qla2xxx] kernel: qla2x00_post_work+0xab/0xb0 [qla2xxx] kernel: qla2x00_post_aen_work+0x3b/0x50 [qla2xxx] kernel: qla2x00_async_event+0x20d/0x15d0 [qla2xxx] kernel: ? lock_timer_base+0x7d/0xa0 kernel: qla24xx_intr_handler+0x1da/0x310 [qla2xxx] kernel: qla2x00_poll+0x36/0x60 [qla2xxx] kernel: qla2x00_mailbox_command+0x659/0xec0 [qla2xxx] kernel: ? proc_create_data+0x7a/0xd0 kernel: qla25xx_init_rsp_que+0x15b/0x240 [qla2xxx] kernel: ? request_irq+0x14/0x20 [qla2xxx] kernel: qla25xx_create_rsp_que+0x256/0x3c0 [qla2xxx] kernel: qla2xxx_create_qpair+0x2af/0x5b0 [qla2xxx] kernel: qla2x00_probe_one+0x1107/0x1c30 [qla2xxx] Fixes: ec7193e26055 ("qla2xxx: Fix delayed response to command for loop mode/direct connect.") Signed-off-by: Quinn Tran Signed-off-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 6d9e8b2dfbe5008647c9c416159d37b26067fc26 Author: Wolfgang Grandegger Date: Thu Sep 14 18:37:14 2017 +0200 can: gs_usb: fix busy loop if no more TX context is available commit 97819f943063b622eca44d3644067c190dc75039 upstream. If sending messages with no cable connected, it quickly happens that there is no more TX context available. Then "gs_can_start_xmit()" returns with "NETDEV_TX_BUSY" and the upper layer does retry immediately keeping the CPU busy. To fix that issue, I moved "atomic_dec(&dev->active_tx_urbs)" from "gs_usb_xmit_callback()" to the TX done handling in "gs_usb_receive_bulk_callback()". Renaming "active_tx_urbs" to "active_tx_contexts" and moving it into "gs_[alloc|free]_tx_context()" would also make sense. Signed-off-by: Wolfgang Grandegger Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 03ca8ea420e4f5dee31c94c0f48957d31adf6aa1 Author: Jussi Laako Date: Sun Oct 15 12:41:32 2017 +0300 ALSA: usb-audio: Add native DSD support for Pro-Ject Pre Box S2 Digital commit 9bb201a5d5acc733943e8af7151cceab9d976a69 upstream. Add native DSD support quirk for Pro-Ject Pre Box S2 Digital USB id 2772:0230. Signed-off-by: Jussi Laako Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 015e94ead900904d18b686311e2da50b92dd58bd Author: Mathias Nyman Date: Tue Oct 17 16:07:33 2017 +0300 usb: hub: Allow reset retry for USB2 devices on connect bounce commit 1ac7db63333db1eeff901bfd6bbcd502b4634fa4 upstream. If the connect status change is set during reset signaling, but the status remains connected just retry port reset. This solves an issue with connecting a 90W HP Thunderbolt 3 dock with a Lenovo Carbon x1 (5th generation) which causes a 30min loop of a high speed device being re-discovererd before usb ports starts working. [...] [ 389.023845] usb 3-1: new high-speed USB device number 55 using xhci_hcd [ 389.491841] usb 3-1: new high-speed USB device number 56 using xhci_hcd [ 389.959928] usb 3-1: new high-speed USB device number 57 using xhci_hcd [...] This is caused by a high speed device that doesn't successfully go to the enabled state after the second port reset. Instead the connection bounces (connected, with connect status change), bailing out completely from enumeration just to restart from scratch. Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1716332 Signed-off-by: Mathias Nyman Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 1916547b28bdad9ff355bd37dcca504015bf398f Author: Felipe Balbi Date: Tue Oct 3 11:16:43 2017 +0300 usb: quirks: add quirk for WORLDE MINI MIDI keyboard commit 2811501e6d8f5747d08f8e25b9ecf472d0dc4c7d upstream. This keyboard doesn't implement Get String descriptors properly even though string indexes are valid. What happens is that when requesting for the String descriptor, the device disconnects and reconnects. Without this quirk, this loop will continue forever. Cc: Alan Stern Reported-by: Владимир Мартьянов Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit e3a038930502bbaafc70e39bbc9d5d8e95356466 Author: Maksim Salau Date: Wed Oct 11 11:10:52 2017 +0300 usb: cdc_acm: Add quirk for Elatec TWN3 commit 765fb2f181cad669f2beb87842a05d8071f2be85 upstream. Elatec TWN3 has the union descriptor on data interface. This results in failure to bind the device to the driver with the following log: usb 1-1.2: new full speed USB device using streamplug-ehci and address 4 usb 1-1.2: New USB device found, idVendor=09d8, idProduct=0320 usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1.2: Product: RFID Device (COM) usb 1-1.2: Manufacturer: OEM cdc_acm 1-1.2:1.0: Zero length descriptor references cdc_acm: probe of 1-1.2:1.0 failed with error -22 Adding the NO_UNION_NORMAL quirk for the device fixes the issue. `lsusb -v` of the device: Bus 001 Device 003: ID 09d8:0320 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 2 Communications bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 32 idVendor 0x09d8 idProduct 0x0320 bcdDevice 3.00 iManufacturer 1 OEM iProduct 2 RFID Device (COM) iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 67 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 250mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25ter) iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 2 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 0 CDC Header: bcdCDC 1.10 CDC Call Management: bmCapabilities 0x03 call management use DataInterface bDataInterface 1 CDC ACM: bmCapabilities 0x06 sends break line coding and serial state CDC Union: bMasterInterface 0 bSlaveInterface 1 Device Status: 0x0000 (Bus Powered) Signed-off-by: Maksim Salau Acked-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit c2110c8dea7a3cd89867cbc057f66d217c7ee34a Author: Johan Hovold Date: Thu Oct 12 14:50:46 2017 +0200 USB: serial: metro-usb: add MS7820 device id commit 31dc3f819bac28a0990b36510197560258ab7421 upstream. Add device-id entry for (Honeywell) Metrologic MS7820 bar code scanner. The device has two interfaces (in this mode?); a vendor-specific interface with two interrupt endpoints and a second HID interface, which we do not bind to. Reported-by: Ladislav Dobrovsky Tested-by: Ladislav Dobrovsky Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 775462fd5c5378957e5165c898e2fa532ebf4234 Author: Alan Stern Date: Wed Oct 18 12:49:38 2017 -0400 USB: core: fix out-of-bounds access bug in usb_get_bos_descriptor() commit 1c0edc3633b56000e18d82fc241e3995ca18a69e upstream. Andrey used the syzkaller fuzzer to find an out-of-bounds memory access in usb_get_bos_descriptor(). The code wasn't checking that the next usb_dev_cap_header structure could fit into the remaining buffer space. This patch fixes the error and also reduces the bNumDeviceCaps field in the header to match the actual number of capabilities found, in cases where there are fewer than expected. Reported-by: Andrey Konovalov Signed-off-by: Alan Stern Tested-by: Andrey Konovalov Signed-off-by: Greg Kroah-Hartman commit a9fdf6354267d92b57bfb96fbcccbe5d5c163d8e Author: Hans de Goede Date: Mon Oct 16 16:21:19 2017 +0200 USB: devio: Revert "USB: devio: Don't corrupt user memory" commit 845d584f41eac3475c21e4a7d5e88d0f6e410cf7 upstream. Taking the uurb->buffer_length userspace passes in as a maximum for the actual urbs transfer_buffer_length causes 2 serious issues: 1) It breaks isochronous support for all userspace apps using libusb, as existing libusb versions pass in 0 for uurb->buffer_length, relying on the kernel using the lenghts of the usbdevfs_iso_packet_desc descriptors passed in added together as buffer length. This for example causes redirection of USB audio and Webcam's into virtual machines using qemu-kvm to no longer work. This is a userspace ABI break and as such must be reverted. Note that the original commit does not protect other users / the kernels memory, it only stops the userspace process making the call from shooting itself in the foot. 2) It may cause the kernel to program host controllers to DMA over random memory. Just as the devio code used to only look at the iso_packet_desc lenghts, the host drivers do the same, relying on the submitter of the urbs to make sure the entire buffer is large enough and not checking transfer_buffer_length. But the "USB: devio: Don't corrupt user memory" commit now takes the userspace provided uurb->buffer_length for the buffer-size while copying over the user-provided iso_packet_desc lengths 1:1, allowing the user to specify a small buffer size while programming the host controller to dma a lot more data. (Atleast the ohci, uhci, xhci and fhci drivers do not check transfer_buffer_length for isoc transfers.) This reverts commit fa1ed74eb1c2 ("USB: devio: Don't corrupt user memory") fixing both these issues. Cc: Dan Carpenter Signed-off-by: Hans de Goede Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit aff794632bfec481281ce0b46cd2b54dff847ec1 Author: Phil Elwell Date: Sun Sep 24 15:20:49 2017 +0100 staging: bcm2835-audio: Fix memory corruption commit c97d96b4e612c7dc1b37d7afc61b598a9a25994d upstream. The previous commit (0adbfd46) fixed a memory leak but also freed a block in the success case, causing a stale pointer to be used with potentially fatal results. Only free the vchi_instance block in the case that vchi_connect fails; once connected, the instance is retained for subsequent connections. Simplifying the code by removing a bunch of gotos and returning errors directly. Signed-off-by: Phil Elwell Fixes: 0adbfd4694c2 ("staging: bcm2835-audio: fix memory leak in bcm2835_audio_open_connection()") Tested-by: Stefan Wahren Signed-off-by: Greg Kroah-Hartman