commit 2a2114a466c3cc828ba9caecfa5b679289ce9793 Author: Alexandre Frade Date: Wed Jul 1 11:56:08 2020 -0300 Linux 5.4.50-xanmod1 Signed-off-by: Alexandre Frade commit 9a717ddea39d286252c2cc4170de50347cf0c558 Merge: 220a93eef6d4 e75220890bf6 Author: Alexandre Frade Date: Wed Jul 1 11:55:21 2020 -0300 Merge tag 'v5.4.50' into 5.4 Linux 5.4.50 commit e75220890bf6b37c5f7b1dbd81d8292ed6d96643 Author: Sasha Levin Date: Tue Jun 30 16:21:55 2020 -0400 Linux 5.4.50 Signed-off-by: Sasha Levin commit a160afebd779bd2fdb0b21dd1680490b1e248d5d Author: Greg Kroah-Hartman Date: Tue May 12 10:22:44 2020 +0200 Revert "tty: hvc: Fix data abort due to race in hvc_open" commit cf9c94456ebafc6d75a834e58dfdc8ae71a3acbc upstream. This reverts commit e2bd1dcbe1aa34ff5570b3427c530e4332ecf0fe. In discussion on the mailing list, it has been determined that this is not the correct type of fix for this issue. Revert it so that we can do this correctly. Reported-by: Jiri Slaby Reported-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20200428032601.22127-1-rananta@codeaurora.org Cc: Raghavendra Rao Ananta Signed-off-by: Greg Kroah-Hartman commit ffd40b7962d463daa531a8110e5b708bcb5c6da7 Author: Zheng Bin Date: Fri Feb 21 07:38:20 2020 -0800 xfs: add agf freeblocks verify in xfs_agf_verify [ Upstream commit d0c7feaf87678371c2c09b3709400be416b2dc62 ] We recently used fuzz(hydra) to test XFS and automatically generate tmp.img(XFS v5 format, but some metadata is wrong) xfs_repair information(just one AG): agf_freeblks 0, counted 3224 in ag 0 agf_longest 536874136, counted 3224 in ag 0 sb_fdblocks 613, counted 3228 Test as follows: mount tmp.img tmpdir cp file1M tmpdir sync In 4.19-stable, sync will stuck, the reason is: xfs_mountfs xfs_check_summary_counts if ((!xfs_sb_version_haslazysbcount(&mp->m_sb) || XFS_LAST_UNMOUNT_WAS_CLEAN(mp)) && !xfs_fs_has_sickness(mp, XFS_SICK_FS_COUNTERS)) return 0; -->just return, incore sb_fdblocks still be 613 xfs_initialize_perag_data cp file1M tmpdir -->ok(write file to pagecache) sync -->stuck(write pagecache to disk) xfs_map_blocks xfs_iomap_write_allocate while (count_fsb != 0) { nimaps = 0; while (nimaps == 0) { --> endless loop nimaps = 1; xfs_bmapi_write(..., &nimaps) --> nimaps becomes 0 again xfs_bmapi_write xfs_bmap_alloc xfs_bmap_btalloc xfs_alloc_vextent xfs_alloc_fix_freelist xfs_alloc_space_available -->fail(agf_freeblks is 0) In linux-next, sync not stuck, cause commit c2b3164320b5 ("xfs: use the latest extent at writeback delalloc conversion time") remove the above while, dmesg is as follows: [ 55.250114] XFS (loop0): page discard on page ffffea0008bc7380, inode 0x1b0c, offset 0. Users do not know why this page is discard, the better soultion is: 1. Like xfs_repair, make sure sb_fdblocks is equal to counted (xfs_initialize_perag_data did this, who is not called at this mount) 2. Add agf verify, if fail, will tell users to repair This patch use the second soultion. Signed-off-by: Zheng Bin Signed-off-by: Ren Xudong Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin commit cc66553004f4589f76804fb56c19331a1c00a043 Author: Mikulas Patocka Date: Fri Jun 19 11:51:34 2020 -0400 dm writecache: add cond_resched to loop in persistent_memory_claim() commit d35bd764e6899a7bea71958f08d16cea5bfa1919 upstream. Add cond_resched() to a loop that fills in the mapper memory area because the loop can be executed many times. Fixes: 48debafe4f2fe ("dm: add writecache target") Cc: stable@vger.kernel.org Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit a51e71cbf6e64b170ef01a78f94df01cb46acb9b Author: Huaisheng Ye Date: Fri Jun 12 23:59:11 2020 +0800 dm writecache: correct uncommitted_block when discarding uncommitted entry commit 39495b12ef1cf602e6abd350dce2ef4199906531 upstream. When uncommitted entry has been discarded, correct wc->uncommitted_block for getting the exact number. Fixes: 48debafe4f2fe ("dm: add writecache target") Cc: stable@vger.kernel.org Signed-off-by: Huaisheng Ye Acked-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit de1d70dad6f22b5d02c04e4d127463b51c727c2c Author: Chuck Lever Date: Mon Jun 15 09:21:13 2020 -0400 xprtrdma: Fix handling of RDMA_ERROR replies commit 7b2182ec381f8ea15c7eb1266d6b5d7da620ad93 upstream. The RPC client currently doesn't handle ERR_CHUNK replies correctly. rpcrdma_complete_rqst() incorrectly passes a negative number to xprt_complete_rqst() as the number of bytes copied. Instead, set task->tk_status to the error value, and return zero bytes copied. In these cases, return -EIO rather than -EREMOTEIO. The RPC client's finite state machine doesn't know what to do with -EREMOTEIO. Additional clean ups: - Don't double-count RDMA_ERROR replies - Remove a stale comment Signed-off-by: Chuck Lever Cc: Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 4d35ca872ac3c7464f062231f6a55444dbbcc106 Author: Olga Kornievskaia Date: Wed Jun 24 13:54:08 2020 -0400 NFSv4 fix CLOSE not waiting for direct IO compeletion commit d03727b248d0dae6199569a8d7b629a681154633 upstream. Figuring out the root case for the REMOVE/CLOSE race and suggesting the solution was done by Neil Brown. Currently what happens is that direct IO calls hold a reference on the open context which is decremented as an asynchronous task in the nfs_direct_complete(). Before reference is decremented, control is returned to the application which is free to close the file. When close is being processed, it decrements its reference on the open_context but since directIO still holds one, it doesn't sent a close on the wire. It returns control to the application which is free to do other operations. For instance, it can delete a file. Direct IO is finally releasing its reference and triggering an asynchronous close. Which races with the REMOVE. On the server, REMOVE can be processed before the CLOSE, failing the REMOVE with EACCES as the file is still opened. Signed-off-by: Olga Kornievskaia Suggested-by: Neil Brown CC: stable@vger.kernel.org Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 02917bef8f1b08cde7027446177c5cb288456f99 Author: Trond Myklebust Date: Mon Jun 22 15:04:15 2020 -0400 pNFS/flexfiles: Fix list corruption if the mirror count changes commit 8b04013737341442ed914b336cde866b902664ae upstream. If the mirror count changes in the new layout we pick up inside ff_layout_pg_init_write(), then we can end up adding the request to the wrong mirror and corrupting the mirror->pg_list. Fixes: d600ad1f2bdb ("NFS41: pop some layoutget errors to application") Cc: stable@vger.kernel.org Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 7b99577ff376d58addf149eebe0ffff46351b3d7 Author: Chuck Lever Date: Thu Jun 25 11:32:34 2020 -0400 SUNRPC: Properly set the @subbuf parameter of xdr_buf_subsegment() commit 89a3c9f5b9f0bcaa9aea3e8b2a616fcaea9aad78 upstream. @subbuf is an output parameter of xdr_buf_subsegment(). A survey of call sites shows that @subbuf is always uninitialized before xdr_buf_segment() is invoked by callers. There are some execution paths through xdr_buf_subsegment() that do not set all of the fields in @subbuf, leaving some pointer fields containing garbage addresses. Subsequent processing of that buffer then results in a page fault. Signed-off-by: Chuck Lever Cc: Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit c27d205baa8255ad152f26064ecf1fddd0258a5f Author: Vasily Averin Date: Mon Jun 1 11:54:57 2020 +0300 sunrpc: fixed rollback in rpc_gssd_dummy_populate() commit b7ade38165ca0001c5a3bd5314a314abbbfbb1b7 upstream. __rpc_depopulate(gssd_dentry) was lost on error path cc: stable@vger.kernel.org Fixes: commit 4b9a445e3eeb ("sunrpc: create a new dummy pipe for gssd to hold open") Signed-off-by: Vasily Averin Reviewed-by: Jeff Layton Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 60bdb51d44faf3723aa037e501eb84d500fb4dfd Author: Dan Carpenter Date: Wed Jun 3 13:19:58 2020 +0300 Staging: rtl8723bs: prevent buffer overflow in update_sta_support_rate() commit b65a2d8c8614386f7e8d38ea150749f8a862f431 upstream. The "ie_len" variable is in the 0-255 range and it comes from the network. If it's over NDIS_802_11_LENGTH_RATES_EX (16) then that will lead to memory corruption. Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Signed-off-by: Dan Carpenter Cc: stable Link: https://lore.kernel.org/r/20200603101958.GA1845750@mwanda Signed-off-by: Greg Kroah-Hartman commit c6f88afa6ae1485f505a860700f52e6a2d32b7dd Author: Wenhui Sheng Date: Thu Jun 18 15:37:04 2020 +0800 drm/amdgpu: add fw release for sdma v5_0 commit edfaf6fa73f15568d4337f208b2333f647c35810 upstream. sdma fw isn't released when module exit Reviewed-by: Hawking Zhang Signed-off-by: Wenhui Sheng Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 05124abe1fb0deb9df35445885f89043eddbba9a Author: Denis Efremov Date: Mon Jun 22 23:31:22 2020 +0300 drm/radeon: fix fb_div check in ni_init_smc_spll_table() commit 35f760b44b1b9cb16a306bdcc7220fbbf78c4789 upstream. clk_s is checked twice in a row in ni_init_smc_spll_table(). fb_div should be checked instead. Fixes: 69e0b57a91ad ("drm/radeon/kms: add dpm support for cayman (v5)") Cc: stable@vger.kernel.org Signed-off-by: Denis Efremov Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 834a3aa2ceb4369f39b8b8b82dd68d278934623f Author: Daniel Gomez Date: Mon May 18 22:16:46 2020 +0200 drm: rcar-du: Fix build error commit 5f9af404eec82981c4345c9943be48422234e7ab upstream. Select DRM_KMS_HELPER dependency. Build error when DRM_KMS_HELPER is not selected: drivers/gpu/drm/rcar-du/rcar_lvds.o:(.rodata+0xd48): undefined reference to `drm_atomic_helper_bridge_duplicate_state' drivers/gpu/drm/rcar-du/rcar_lvds.o:(.rodata+0xd50): undefined reference to `drm_atomic_helper_bridge_destroy_state' drivers/gpu/drm/rcar-du/rcar_lvds.o:(.rodata+0xd70): undefined reference to `drm_atomic_helper_bridge_reset' drivers/gpu/drm/rcar-du/rcar_lvds.o:(.rodata+0xdc8): undefined reference to `drm_atomic_helper_connector_reset' drivers/gpu/drm/rcar-du/rcar_lvds.o:(.rodata+0xde0): undefined reference to `drm_helper_probe_single_connector_modes' drivers/gpu/drm/rcar-du/rcar_lvds.o:(.rodata+0xe08): undefined reference to `drm_atomic_helper_connector_duplicate_state' drivers/gpu/drm/rcar-du/rcar_lvds.o:(.rodata+0xe10): undefined reference to `drm_atomic_helper_connector_destroy_state' Fixes: c6a27fa41fab ("drm: rcar-du: Convert LVDS encoder code to bridge driver") Cc: Signed-off-by: Daniel Gomez Reviewed-by: Emil Velikov Reviewed-by: Kieran Bingham Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart Signed-off-by: Greg Kroah-Hartman commit 176a3c488476d077114d54810e221634aff94659 Author: Bernard Zhao Date: Sat Jun 20 17:11:52 2020 +0800 drm/amd: fix potential memleak in err branch commit b5b78a6c8d8cb9c307bc6b16a754603424459d6e upstream. The function kobject_init_and_add alloc memory like: kobject_init_and_add->kobject_add_varg->kobject_set_name_vargs ->kvasprintf_const->kstrdup_const->kstrdup->kmalloc_track_caller ->kmalloc_slab, in err branch this memory not free. If use kmemleak, this path maybe catched. These changes are to add kobject_put in kobject_init_and_add failed branch, fix potential memleak. Signed-off-by: Bernard Zhao Reviewed-by: Felix Kuehling Signed-off-by: Felix Kuehling Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 0b3cc973f16fab7507297eaec1c0c262020b08c9 Author: Steven Rostedt (VMware) Date: Mon Jun 22 15:18:15 2020 -0400 ring-buffer: Zero out time extend if it is nested and not absolute commit 097350d1c6e1f5808cae142006f18a0bbc57018d upstream. Currently the ring buffer makes events that happen in interrupts that preempt another event have a delta of zero. (Hopefully we can change this soon). But this is to deal with the races of updating a global counter with lockless and nesting functions updating deltas. With the addition of absolute time stamps, the time extend didn't follow this rule. A time extend can happen if two events happen longer than 2^27 nanoseconds appart, as the delta time field in each event is only 27 bits. If that happens, then a time extend is injected with 2^59 bits of nanoseconds to use (18 years). But if the 2^27 nanoseconds happen between two events, and as it is writing the event, an interrupt triggers, it will see the 2^27 difference as well and inject a time extend of its own. But a recent change made the time extend logic not take into account the nesting, and this can cause two time extend deltas to happen moving the time stamp much further ahead than the current time. This gets all reset when the ring buffer moves to the next page, but that can cause time to appear to go backwards. This was observed in a trace-cmd recording, and since the data is saved in a file, with trace-cmd report --debug, it was possible to see that this indeed did happen! bash-52501 110d... 81778.908247: sched_switch: bash:52501 [120] S ==> swapper/110:0 [120] [12770284:0x2e8:64] -0 110d... 81778.908757: sched_switch: swapper/110:0 [120] R ==> bash:52501 [120] [509947:0x32c:64] TIME EXTEND: delta:306454770 length:0 bash-52501 110.... 81779.215212: sched_swap_numa: src_pid=52501 src_tgid=52388 src_ngid=52501 src_cpu=110 src_nid=2 dst_pid=52509 dst_tgid=52388 dst_ngid=52501 dst_cpu=49 dst_nid=1 [0:0x378:48] TIME EXTEND: delta:306458165 length:0 bash-52501 110dNh. 81779.521670: sched_wakeup: migration/110:565 [0] success=1 CPU:110 [0:0x3b4:40] and at the next page, caused the time to go backwards: bash-52504 110d... 81779.685411: sched_switch: bash:52504 [120] S ==> swapper/110:0 [120] [8347057:0xfb4:64] CPU:110 [SUBBUFFER START] [81779379165886:0x1320000] -0 110dN.. 81779.379166: sched_wakeup: bash:52504 [120] success=1 CPU:110 [0:0x10:40] -0 110d... 81779.379167: sched_switch: swapper/110:0 [120] R ==> bash:52504 [120] [1168:0x3c:64] Link: https://lkml.kernel.org/r/20200622151815.345d1bf5@oasis.local.home Cc: Ingo Molnar Cc: Andrew Morton Cc: Tom Zanussi Cc: stable@vger.kernel.org Fixes: dc4e2801d400b ("ring-buffer: Redefine the unimplemented RINGBUF_TYPE_TIME_STAMP") Reported-by: Julia Lawall Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 9a59a88b3d3144136f78f5d83a23b80a47178811 Author: Masami Hiramatsu Date: Sat Jun 20 12:46:03 2020 +0900 tracing: Fix event trigger to accept redundant spaces commit 6784beada631800f2c5afd567e5628c843362cee upstream. Fix the event trigger to accept redundant spaces in the trigger input. For example, these return -EINVAL echo " traceon" > events/ftrace/print/trigger echo "traceon if common_pid == 0" > events/ftrace/print/trigger echo "disable_event:kmem:kmalloc " > events/ftrace/print/trigger But these are hard to find what is wrong. To fix this issue, use skip_spaces() to remove spaces in front of actual tokens, and set NULL if there is no token. Link: http://lkml.kernel.org/r/159262476352.185015.5261566783045364186.stgit@devnote2 Cc: Tom Zanussi Cc: stable@vger.kernel.org Fixes: 85f2b08268c0 ("tracing: Add basic event trigger framework") Reviewed-by: Tom Zanussi Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit c036eb65fdfc1a5d43f7edf3d6e6fb562bde5120 Author: Robin Gong Date: Fri May 22 18:44:51 2020 +0800 arm64: dts: imx8mn-ddr4-evk: correct ldo1/ldo2 voltage range commit cfb12c8952f617df58d73d24161e539a035d82b0 upstream. Correct ldo1 voltage range from wrong high group(3.0V~3.3V) to low group (1.6V~1.9V) because the ldo1 should be 1.8V. Actually, two voltage groups have been supported at bd718x7-regulator driver, hence, just corrrect the voltage range to 1.6V~3.3V. For ldo2@0.8V, correct voltage range too. Otherwise, ldo1 would be kept @3.0V and ldo2@0.9V which violate i.mx8mn datasheet as the below warning log in kernel: [ 0.995524] LDO1: Bringing 1800000uV into 3000000-3000000uV [ 0.999196] LDO2: Bringing 800000uV into 900000-900000uV Fixes: 3e44dd09736d ("arm64: dts: imx8mn-ddr4-evk: Add rohm,bd71847 PMIC support") Cc: stable@vger.kernel.org Signed-off-by: Robin Gong Reviewed-by: Dong Aisheng Reviewed-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 90bd9c611f21b7461d199f2e331cdde1563c72e3 Author: Robin Gong Date: Fri May 22 18:44:50 2020 +0800 arm64: dts: imx8mm-evk: correct ldo1/ldo2 voltage range commit 4fd6b5735c03c0955d93960d31f17d7144f5578f upstream. Correct ldo1 voltage range from wrong high group(3.0V~3.3V) to low group (1.6V~1.9V) because the ldo1 should be 1.8V. Actually, two voltage groups have been supported at bd718x7-regulator driver, hence, just corrrect the voltage range to 1.6V~3.3V. For ldo2@0.8V, correct voltage range too. Otherwise, ldo1 would be kept @3.0V and ldo2@0.9V which violate i.mx8mm datasheet as the below warning log in kernel: [ 0.995524] LDO1: Bringing 1800000uV into 3000000-3000000uV [ 0.999196] LDO2: Bringing 800000uV into 900000-900000uV Fixes: 78cc25fa265d ("arm64: dts: imx8mm-evk: Add BD71847 PMIC") Cc: stable@vger.kernel.org Signed-off-by: Robin Gong Reviewed-by: Dong Aisheng Reviewed-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 73f79b420bd0e2f93ee8896dca07313b8ab3eb0a Author: Jiping Ma Date: Mon May 11 10:52:07 2020 +0800 arm64: perf: Report the PC value in REGS_ABI_32 mode commit 8dfe804a4031ca6ba3a3efb2048534249b64f3a5 upstream. A 32-bit perf querying the registers of a compat task using REGS_ABI_32 will receive zeroes from w15, when it expects to find the PC. Return the PC value for register dwarf register 15 when returning register values for a compat task to perf. Cc: Acked-by: Mark Rutland Signed-off-by: Jiping Ma Link: https://lore.kernel.org/r/1589165527-188401-1-git-send-email-jiping.ma2@windriver.com [will: Shuffled code and added a comment] Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 7a9e3e25a9d25b58d565f79e0da9ed494e9952ea Author: Muchun Song Date: Thu Jun 25 20:30:19 2020 -0700 mm/memcontrol.c: add missed css_put() commit 3a98990ae2150277ed34d3b248c60e68bf2244b2 upstream. We should put the css reference when memory allocation failed. Link: http://lkml.kernel.org/r/20200614122653.98829-1-songmuchun@bytedance.com Fixes: f0a3a24b532d ("mm: memcg/slab: rework non-root kmem_cache lifecycle management") Signed-off-by: Muchun Song Acked-by: Roman Gushchin Acked-by: Michal Hocko Cc: Johannes Weiner Cc: Vladimir Davydov Cc: Qian Cai Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ff6aff13a8cfc421418b902647ac84bf027bedb9 Author: Junxiao Bi Date: Thu Jun 25 20:29:37 2020 -0700 ocfs2: fix panic on nfs server over ocfs2 commit e5a15e17a78d58f933d17cafedfcf7486a29f5b4 upstream. The following kernel panic was captured when running nfs server over ocfs2, at that time ocfs2_test_inode_bit() was checking whether one inode locating at "blkno" 5 was valid, that is ocfs2 root inode, its "suballoc_slot" was OCFS2_INVALID_SLOT(65535) and it was allocted from //global_inode_alloc, but here it wrongly assumed that it was got from per slot inode alloctor which would cause array overflow and trigger kernel panic. BUG: unable to handle kernel paging request at 0000000000001088 IP: [] _raw_spin_lock+0x18/0xf0 PGD 1e06ba067 PUD 1e9e7d067 PMD 0 Oops: 0002 [#1] SMP CPU: 6 PID: 24873 Comm: nfsd Not tainted 4.1.12-124.36.1.el6uek.x86_64 #2 Hardware name: Huawei CH121 V3/IT11SGCA1, BIOS 3.87 02/02/2018 RIP: _raw_spin_lock+0x18/0xf0 RSP: e02b:ffff88005ae97908 EFLAGS: 00010206 RAX: ffff88005ae98000 RBX: 0000000000001088 RCX: 0000000000000000 RDX: 0000000000020000 RSI: 0000000000000009 RDI: 0000000000001088 RBP: ffff88005ae97928 R08: 0000000000000000 R09: ffff880212878e00 R10: 0000000000007ff0 R11: 0000000000000000 R12: 0000000000001088 R13: ffff8800063c0aa8 R14: ffff8800650c27d0 R15: 000000000000ffff FS: 0000000000000000(0000) GS:ffff880218180000(0000) knlGS:ffff880218180000 CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001088 CR3: 00000002033d0000 CR4: 0000000000042660 Call Trace: igrab+0x1e/0x60 ocfs2_get_system_file_inode+0x63/0x3a0 [ocfs2] ocfs2_test_inode_bit+0x328/0xa00 [ocfs2] ocfs2_get_parent+0xba/0x3e0 [ocfs2] reconnect_path+0xb5/0x300 exportfs_decode_fh+0xf6/0x2b0 fh_verify+0x350/0x660 [nfsd] nfsd4_putfh+0x4d/0x60 [nfsd] nfsd4_proc_compound+0x3d3/0x6f0 [nfsd] nfsd_dispatch+0xe0/0x290 [nfsd] svc_process_common+0x412/0x6a0 [sunrpc] svc_process+0x123/0x210 [sunrpc] nfsd+0xff/0x170 [nfsd] kthread+0xcb/0xf0 ret_from_fork+0x61/0x90 Code: 83 c2 02 0f b7 f2 e8 18 dc 91 ff 66 90 eb bf 0f 1f 40 00 55 48 89 e5 41 56 41 55 41 54 53 0f 1f 44 00 00 48 89 fb ba 00 00 02 00 0f c1 17 89 d0 45 31 e4 45 31 ed c1 e8 10 66 39 d0 41 89 c6 RIP _raw_spin_lock+0x18/0xf0 CR2: 0000000000001088 ---[ end trace 7264463cd1aac8f9 ]--- Kernel panic - not syncing: Fatal exception Link: http://lkml.kernel.org/r/20200616183829.87211-4-junxiao.bi@oracle.com Signed-off-by: Junxiao Bi Reviewed-by: Joseph Qi Cc: Changwei Ge Cc: Gang He Cc: Joel Becker Cc: Jun Piao Cc: Mark Fasheh Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a8d82ebaee9747302d6ec9cbed0ced84943ebacc Author: Junxiao Bi Date: Thu Jun 25 20:29:40 2020 -0700 ocfs2: fix value of OCFS2_INVALID_SLOT commit 9277f8334ffc719fe922d776444d6e4e884dbf30 upstream. In the ocfs2 disk layout, slot number is 16 bits, but in ocfs2 implementation, slot number is 32 bits. Usually this will not cause any issue, because slot number is converted from u16 to u32, but OCFS2_INVALID_SLOT was defined as -1, when an invalid slot number from disk was obtained, its value was (u16)-1, and it was converted to u32. Then the following checking in get_local_system_inode will be always skipped: static struct inode **get_local_system_inode(struct ocfs2_super *osb, int type, u32 slot) { BUG_ON(slot == OCFS2_INVALID_SLOT); ... } Link: http://lkml.kernel.org/r/20200616183829.87211-5-junxiao.bi@oracle.com Signed-off-by: Junxiao Bi Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Changwei Ge Cc: Gang He Cc: Jun Piao Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4685df862c8b8fcc16d754f3135e2c7ee4baf5de Author: Junxiao Bi Date: Thu Jun 25 20:29:33 2020 -0700 ocfs2: load global_inode_alloc commit 7569d3c754e452769a5747eeeba488179e38a5da upstream. Set global_inode_alloc as OCFS2_FIRST_ONLINE_SYSTEM_INODE, that will make it load during mount. It can be used to test whether some global/system inodes are valid. One use case is that nfsd will test whether root inode is valid. Link: http://lkml.kernel.org/r/20200616183829.87211-3-junxiao.bi@oracle.com Signed-off-by: Junxiao Bi Reviewed-by: Joseph Qi Cc: Changwei Ge Cc: Gang He Cc: Joel Becker Cc: Jun Piao Cc: Mark Fasheh Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7fa716a594a6ec6830222260f6502b25f3f86ed5 Author: Junxiao Bi Date: Thu Jun 25 20:29:30 2020 -0700 ocfs2: avoid inode removal while nfsd is accessing it commit 4cd9973f9ff69e37dd0ba2bd6e6423f8179c329a upstream. Patch series "ocfs2: fix nfsd over ocfs2 issues", v2. This is a series of patches to fix issues on nfsd over ocfs2. patch 1 is to avoid inode removed while nfsd access it patch 2 & 3 is to fix a panic issue. This patch (of 4): When nfsd is getting file dentry using handle or parent dentry of some dentry, one cluster lock is used to avoid inode removed from other node, but it still could be removed from local node, so use a rw lock to avoid this. Link: http://lkml.kernel.org/r/20200616183829.87211-1-junxiao.bi@oracle.com Link: http://lkml.kernel.org/r/20200616183829.87211-2-junxiao.bi@oracle.com Signed-off-by: Junxiao Bi Reviewed-by: Joseph Qi Cc: Changwei Ge Cc: Gang He Cc: Joel Becker Cc: Jun Piao Cc: Mark Fasheh Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit fbca1aee13974bade598c9d0906ef89d1bdc63c3 Author: Waiman Long Date: Thu Jun 25 20:29:52 2020 -0700 mm/slab: use memzero_explicit() in kzfree() commit 8982ae527fbef170ef298650c15d55a9ccd33973 upstream. The kzfree() function is normally used to clear some sensitive information, like encryption keys, in the buffer before freeing it back to the pool. Memset() is currently used for buffer clearing. However unlikely, there is still a non-zero probability that the compiler may choose to optimize away the memory clearing especially if LTO is being used in the future. To make sure that this optimization will never happen, memzero_explicit(), which is introduced in v3.18, is now used in kzfree() to future-proof it. Link: http://lkml.kernel.org/r/20200616154311.12314-2-longman@redhat.com Fixes: 3ef0e5ba4673 ("slab: introduce kzfree()") Signed-off-by: Waiman Long Acked-by: Michal Hocko Cc: David Howells Cc: Jarkko Sakkinen Cc: James Morris Cc: "Serge E. Hallyn" Cc: Joe Perches Cc: Matthew Wilcox Cc: David Rientjes Cc: Johannes Weiner Cc: Dan Carpenter Cc: "Jason A . Donenfeld" Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a79c3a99ac8187d79ce7cc6be8329454d2321ef5 Author: Filipe Manana Date: Mon Jun 15 18:48:58 2020 +0100 btrfs: fix failure of RWF_NOWAIT write into prealloc extent beyond eof commit 4b1946284dd6641afdb9457101056d9e6ee6204c upstream. If we attempt to write to prealloc extent located after eof using a RWF_NOWAIT write, we always fail with -EAGAIN. We do actually check if we have an allocated extent for the write at the start of btrfs_file_write_iter() through a call to check_can_nocow(), but later when we go into the actual direct IO write path we simply return -EAGAIN if the write starts at or beyond EOF. Trivial to reproduce: $ mkfs.btrfs -f /dev/sdb $ mount /dev/sdb /mnt $ touch /mnt/foo $ chattr +C /mnt/foo $ xfs_io -d -c "pwrite -S 0xab 0 64K" /mnt/foo wrote 65536/65536 bytes at offset 0 64 KiB, 16 ops; 0.0004 sec (135.575 MiB/sec and 34707.1584 ops/sec) $ xfs_io -c "falloc -k 64K 1M" /mnt/foo $ xfs_io -d -c "pwrite -N -V 1 -S 0xfe -b 64K 64K 64K" /mnt/foo pwrite: Resource temporarily unavailable On xfs and ext4 the write succeeds, as expected. Fix this by removing the wrong check at btrfs_direct_IO(). Fixes: edf064e7c6fec3 ("btrfs: nowait aio support") CC: stable@vger.kernel.org # 4.14+ Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 863a197f7f102bfbd42f79b40c50947e9019f011 Author: Filipe Manana Date: Mon Jun 15 10:38:44 2020 +0100 btrfs: check if a log root exists before locking the log_mutex on unlink commit e7a79811d0db136dc2d336b56d54cf1b774ce972 upstream. This brings back an optimization that commit e678934cbe5f02 ("btrfs: Remove unnecessary check from join_running_log_trans") removed, but in a different form. So it's almost equivalent to a revert. That commit removed an optimization where we avoid locking a root's log_mutex when there is no log tree created in the current transaction. The affected code path is triggered through unlink operations. That commit was based on the assumption that the optimization was not necessary because we used to have the following checks when the patch was authored: int btrfs_del_dir_entries_in_log(...) { (...) if (dir->logged_trans < trans->transid) return 0; ret = join_running_log_trans(root); (...) } int btrfs_del_inode_ref_in_log(...) { (...) if (inode->logged_trans < trans->transid) return 0; ret = join_running_log_trans(root); (...) } However before that patch was merged, another patch was merged first which replaced those checks because they were buggy. That other patch corresponds to commit 803f0f64d17769 ("Btrfs: fix fsync not persisting dentry deletions due to inode evictions"). The assumption that if the logged_trans field of an inode had a smaller value then the current transaction's generation (transid) meant that the inode was not logged in the current transaction was only correct if the inode was not evicted and reloaded in the current transaction. So the corresponding bug fix changed those checks and replaced them with the following helper function: static bool inode_logged(struct btrfs_trans_handle *trans, struct btrfs_inode *inode) { if (inode->logged_trans == trans->transid) return true; if (inode->last_trans == trans->transid && test_bit(BTRFS_INODE_NEEDS_FULL_SYNC, &inode->runtime_flags) && !test_bit(BTRFS_FS_LOG_RECOVERING, &trans->fs_info->flags)) return true; return false; } So if we have a subvolume without a log tree in the current transaction (because we had no fsyncs), every time we unlink an inode we can end up trying to lock the log_mutex of the root through join_running_log_trans() twice, once for the inode being unlinked (by btrfs_del_inode_ref_in_log()) and once for the parent directory (with btrfs_del_dir_entries_in_log()). This means if we have several unlink operations happening in parallel for inodes in the same subvolume, and the those inodes and/or their parent inode were changed in the current transaction, we end up having a lot of contention on the log_mutex. The test robots from intel reported a -30.7% performance regression for a REAIM test after commit e678934cbe5f02 ("btrfs: Remove unnecessary check from join_running_log_trans"). So just bring back the optimization to join_running_log_trans() where we check first if a log root exists before trying to lock the log_mutex. This is done by checking for a bit that is set on the root when a log tree is created and removed when a log tree is freed (at transaction commit time). Commit e678934cbe5f02 ("btrfs: Remove unnecessary check from join_running_log_trans") was merged in the 5.4 merge window while commit 803f0f64d17769 ("Btrfs: fix fsync not persisting dentry deletions due to inode evictions") was merged in the 5.3 merge window. But the first commit was actually authored before the second commit (May 23 2019 vs June 19 2019). Reported-by: kernel test robot Link: https://lore.kernel.org/lkml/20200611090233.GL12456@shao2-debian/ Fixes: e678934cbe5f02 ("btrfs: Remove unnecessary check from join_running_log_trans") CC: stable@vger.kernel.org # 5.4+ Reviewed-by: Josef Bacik Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 53a0816610478ef21f72fa3898c96930203255b6 Author: Filipe Manana Date: Mon Jun 8 13:32:55 2020 +0100 btrfs: fix data block group relocation failure due to concurrent scrub commit 432cd2a10f1c10cead91fe706ff5dc52f06d642a upstream. When running relocation of a data block group while scrub is running in parallel, it is possible that the relocation will fail and abort the current transaction with an -EINVAL error: [134243.988595] BTRFS info (device sdc): found 14 extents, stage: move data extents [134243.999871] ------------[ cut here ]------------ [134244.000741] BTRFS: Transaction aborted (error -22) [134244.001692] WARNING: CPU: 0 PID: 26954 at fs/btrfs/ctree.c:1071 __btrfs_cow_block+0x6a7/0x790 [btrfs] [134244.003380] Modules linked in: btrfs blake2b_generic xor raid6_pq (...) [134244.012577] CPU: 0 PID: 26954 Comm: btrfs Tainted: G W 5.6.0-rc7-btrfs-next-58 #5 [134244.014162] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 [134244.016184] RIP: 0010:__btrfs_cow_block+0x6a7/0x790 [btrfs] [134244.017151] Code: 48 c7 c7 (...) [134244.020549] RSP: 0018:ffffa41607863888 EFLAGS: 00010286 [134244.021515] RAX: 0000000000000000 RBX: ffff9614bdfe09c8 RCX: 0000000000000000 [134244.022822] RDX: 0000000000000001 RSI: ffffffffb3d63980 RDI: 0000000000000001 [134244.024124] RBP: ffff961589e8c000 R08: 0000000000000000 R09: 0000000000000001 [134244.025424] R10: ffffffffc0ae5955 R11: 0000000000000000 R12: ffff9614bd530d08 [134244.026725] R13: ffff9614ced41b88 R14: ffff9614bdfe2a48 R15: 0000000000000000 [134244.028024] FS: 00007f29b63c08c0(0000) GS:ffff9615ba600000(0000) knlGS:0000000000000000 [134244.029491] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [134244.030560] CR2: 00007f4eb339b000 CR3: 0000000130d6e006 CR4: 00000000003606f0 [134244.031997] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [134244.033153] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [134244.034484] Call Trace: [134244.034984] btrfs_cow_block+0x12b/0x2b0 [btrfs] [134244.035859] do_relocation+0x30b/0x790 [btrfs] [134244.036681] ? do_raw_spin_unlock+0x49/0xc0 [134244.037460] ? _raw_spin_unlock+0x29/0x40 [134244.038235] relocate_tree_blocks+0x37b/0x730 [btrfs] [134244.039245] relocate_block_group+0x388/0x770 [btrfs] [134244.040228] btrfs_relocate_block_group+0x161/0x2e0 [btrfs] [134244.041323] btrfs_relocate_chunk+0x36/0x110 [btrfs] [134244.041345] btrfs_balance+0xc06/0x1860 [btrfs] [134244.043382] ? btrfs_ioctl_balance+0x27c/0x310 [btrfs] [134244.045586] btrfs_ioctl_balance+0x1ed/0x310 [btrfs] [134244.045611] btrfs_ioctl+0x1880/0x3760 [btrfs] [134244.049043] ? do_raw_spin_unlock+0x49/0xc0 [134244.049838] ? _raw_spin_unlock+0x29/0x40 [134244.050587] ? __handle_mm_fault+0x11b3/0x14b0 [134244.051417] ? ksys_ioctl+0x92/0xb0 [134244.052070] ksys_ioctl+0x92/0xb0 [134244.052701] ? trace_hardirqs_off_thunk+0x1a/0x1c [134244.053511] __x64_sys_ioctl+0x16/0x20 [134244.054206] do_syscall_64+0x5c/0x280 [134244.054891] entry_SYSCALL_64_after_hwframe+0x49/0xbe [134244.055819] RIP: 0033:0x7f29b51c9dd7 [134244.056491] Code: 00 00 00 (...) [134244.059767] RSP: 002b:00007ffcccc1dd08 EFLAGS: 00000202 ORIG_RAX: 0000000000000010 [134244.061168] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f29b51c9dd7 [134244.062474] RDX: 00007ffcccc1dda0 RSI: 00000000c4009420 RDI: 0000000000000003 [134244.063771] RBP: 0000000000000003 R08: 00005565cea4b000 R09: 0000000000000000 [134244.065032] R10: 0000000000000541 R11: 0000000000000202 R12: 00007ffcccc2060a [134244.066327] R13: 00007ffcccc1dda0 R14: 0000000000000002 R15: 00007ffcccc1dec0 [134244.067626] irq event stamp: 0 [134244.068202] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [134244.069351] hardirqs last disabled at (0): [] copy_process+0x74f/0x2020 [134244.070909] softirqs last enabled at (0): [] copy_process+0x74f/0x2020 [134244.072392] softirqs last disabled at (0): [<0000000000000000>] 0x0 [134244.073432] ---[ end trace bd7c03622e0b0a99 ]--- The -EINVAL error comes from the following chain of function calls: __btrfs_cow_block() <-- aborts the transaction btrfs_reloc_cow_block() replace_file_extents() get_new_location() <-- returns -EINVAL When relocating a data block group, for each allocated extent of the block group, we preallocate another extent (at prealloc_file_extent_cluster()), associated with the data relocation inode, and then dirty all its pages. These preallocated extents have, and must have, the same size that extents from the data block group being relocated have. Later before we start the relocation stage that updates pointers (bytenr field of file extent items) to point to the the new extents, we trigger writeback for the data relocation inode. The expectation is that writeback will write the pages to the previously preallocated extents, that it follows the NOCOW path. That is generally the case, however, if a scrub is running it may have turned the block group that contains those extents into RO mode, in which case writeback falls back to the COW path. However in the COW path instead of allocating exactly one extent with the expected size, the allocator may end up allocating several smaller extents due to free space fragmentation - because we tell it at cow_file_range() that the minimum allocation size can match the filesystem's sector size. This later breaks the relocation's expectation that an extent associated to a file extent item in the data relocation inode has the same size as the respective extent pointed by a file extent item in another tree - in this case the extent to which the relocation inode poins to is smaller, causing relocation.c:get_new_location() to return -EINVAL. For example, if we are relocating a data block group X that has a logical address of X and the block group has an extent allocated at the logical address X + 128KiB with a size of 64KiB: 1) At prealloc_file_extent_cluster() we allocate an extent for the data relocation inode with a size of 64KiB and associate it to the file offset 128KiB (X + 128KiB - X) of the data relocation inode. This preallocated extent was allocated at block group Z; 2) A scrub running in parallel turns block group Z into RO mode and starts scrubing its extents; 3) Relocation triggers writeback for the data relocation inode; 4) When running delalloc (btrfs_run_delalloc_range()), we try first the NOCOW path because the data relocation inode has BTRFS_INODE_PREALLOC set in its flags. However, because block group Z is in RO mode, the NOCOW path (run_delalloc_nocow()) falls back into the COW path, by calling cow_file_range(); 5) At cow_file_range(), in the first iteration of the while loop we call btrfs_reserve_extent() to allocate a 64KiB extent and pass it a minimum allocation size of 4KiB (fs_info->sectorsize). Due to free space fragmentation, btrfs_reserve_extent() ends up allocating two extents of 32KiB each, each one on a different iteration of that while loop; 6) Writeback of the data relocation inode completes; 7) Relocation proceeds and ends up at relocation.c:replace_file_extents(), with a leaf which has a file extent item that points to the data extent from block group X, that has a logical address (bytenr) of X + 128KiB and a size of 64KiB. Then it calls get_new_location(), which does a lookup in the data relocation tree for a file extent item starting at offset 128KiB (X + 128KiB - X) and belonging to the data relocation inode. It finds a corresponding file extent item, however that item points to an extent that has a size of 32KiB, which doesn't match the expected size of 64KiB, resuling in -EINVAL being returned from this function and propagated up to __btrfs_cow_block(), which aborts the current transaction. To fix this make sure that at cow_file_range() when we call the allocator we pass it a minimum allocation size corresponding the desired extent size if the inode belongs to the data relocation tree, otherwise pass it the filesystem's sector size as the minimum allocation size. CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Josef Bacik Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 0a4dfc69ea7ebe6ed0f0af9bfa10f2096dfa4c49 Author: Filipe Manana Date: Mon Jun 8 13:33:05 2020 +0100 btrfs: fix bytes_may_use underflow when running balance and scrub in parallel commit 6bd335b469f945f75474c11e3f577f85409f39c3 upstream. When balance and scrub are running in parallel it is possible to end up with an underflow of the bytes_may_use counter of the data space_info object, which triggers a warning like the following: [134243.793196] BTRFS info (device sdc): relocating block group 1104150528 flags data [134243.806891] ------------[ cut here ]------------ [134243.807561] WARNING: CPU: 1 PID: 26884 at fs/btrfs/space-info.h:125 btrfs_add_reserved_bytes+0x1da/0x280 [btrfs] [134243.808819] Modules linked in: btrfs blake2b_generic xor (...) [134243.815779] CPU: 1 PID: 26884 Comm: kworker/u8:8 Tainted: G W 5.6.0-rc7-btrfs-next-58 #5 [134243.816944] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 [134243.818389] Workqueue: writeback wb_workfn (flush-btrfs-108483) [134243.819186] RIP: 0010:btrfs_add_reserved_bytes+0x1da/0x280 [btrfs] [134243.819963] Code: 0b f2 85 (...) [134243.822271] RSP: 0018:ffffa4160aae7510 EFLAGS: 00010287 [134243.822929] RAX: 000000000000c000 RBX: ffff96159a8c1000 RCX: 0000000000000000 [134243.823816] RDX: 0000000000008000 RSI: 0000000000000000 RDI: ffff96158067a810 [134243.824742] RBP: ffff96158067a800 R08: 0000000000000001 R09: 0000000000000000 [134243.825636] R10: ffff961501432a40 R11: 0000000000000000 R12: 000000000000c000 [134243.826532] R13: 0000000000000001 R14: ffffffffffff4000 R15: ffff96158067a810 [134243.827432] FS: 0000000000000000(0000) GS:ffff9615baa00000(0000) knlGS:0000000000000000 [134243.828451] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [134243.829184] CR2: 000055bd7e414000 CR3: 00000001077be004 CR4: 00000000003606e0 [134243.830083] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [134243.830975] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [134243.831867] Call Trace: [134243.832211] find_free_extent+0x4a0/0x16c0 [btrfs] [134243.832846] btrfs_reserve_extent+0x91/0x180 [btrfs] [134243.833487] cow_file_range+0x12d/0x490 [btrfs] [134243.834080] fallback_to_cow+0x82/0x1b0 [btrfs] [134243.834689] ? release_extent_buffer+0x121/0x170 [btrfs] [134243.835370] run_delalloc_nocow+0x33f/0xa30 [btrfs] [134243.836032] btrfs_run_delalloc_range+0x1ea/0x6d0 [btrfs] [134243.836725] ? find_lock_delalloc_range+0x221/0x250 [btrfs] [134243.837450] writepage_delalloc+0xe8/0x150 [btrfs] [134243.838059] __extent_writepage+0xe8/0x4c0 [btrfs] [134243.838674] extent_write_cache_pages+0x237/0x530 [btrfs] [134243.839364] extent_writepages+0x44/0xa0 [btrfs] [134243.839946] do_writepages+0x23/0x80 [134243.840401] __writeback_single_inode+0x59/0x700 [134243.841006] writeback_sb_inodes+0x267/0x5f0 [134243.841548] __writeback_inodes_wb+0x87/0xe0 [134243.842091] wb_writeback+0x382/0x590 [134243.842574] ? wb_workfn+0x4a2/0x6c0 [134243.843030] wb_workfn+0x4a2/0x6c0 [134243.843468] process_one_work+0x26d/0x6a0 [134243.843978] worker_thread+0x4f/0x3e0 [134243.844452] ? process_one_work+0x6a0/0x6a0 [134243.844981] kthread+0x103/0x140 [134243.845400] ? kthread_create_worker_on_cpu+0x70/0x70 [134243.846030] ret_from_fork+0x3a/0x50 [134243.846494] irq event stamp: 0 [134243.846892] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [134243.847682] hardirqs last disabled at (0): [] copy_process+0x74f/0x2020 [134243.848687] softirqs last enabled at (0): [] copy_process+0x74f/0x2020 [134243.849913] softirqs last disabled at (0): [<0000000000000000>] 0x0 [134243.850698] ---[ end trace bd7c03622e0b0a96 ]--- [134243.851335] ------------[ cut here ]------------ When relocating a data block group, for each extent allocated in the block group we preallocate another extent with the same size for the data relocation inode (we do it at prealloc_file_extent_cluster()). We reserve space by calling btrfs_check_data_free_space(), which ends up incrementing the data space_info's bytes_may_use counter, and then call btrfs_prealloc_file_range() to allocate the extent, which always decrements the bytes_may_use counter by the same amount. The expectation is that writeback of the data relocation inode always follows a NOCOW path, by writing into the preallocated extents. However, when starting writeback we might end up falling back into the COW path, because the block group that contains the preallocated extent was turned into RO mode by a scrub running in parallel. The COW path then calls the extent allocator which ends up calling btrfs_add_reserved_bytes(), and this function decrements the bytes_may_use counter of the data space_info object by an amount corresponding to the size of the allocated extent, despite we haven't previously incremented it. When the counter currently has a value smaller then the allocated extent we reset the counter to 0 and emit a warning, otherwise we just decrement it and slowly mess up with this counter which is crucial for space reservation, the end result can be granting reserved space to tasks when there isn't really enough free space, and having the tasks fail later in critical places where error handling consists of a transaction abort or hitting a BUG_ON(). Fix this by making sure that if we fallback to the COW path for a data relocation inode, we increment the bytes_may_use counter of the data space_info object. The COW path will then decrement it at btrfs_add_reserved_bytes() on success or through its error handling part by a call to extent_clear_unlock_delalloc() (which ends up calling btrfs_clear_delalloc_extent() that does the decrement operation) in case of an error. Test case btrfs/061 from fstests could sporadically trigger this. CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Josef Bacik Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit df13086490db6155f43986dda4e006c5644cfe22 Author: Matt Fleming Date: Thu Jun 18 11:20:02 2020 +0100 x86/asm/64: Align start of __clear_user() loop to 16-bytes commit bb5570ad3b54e7930997aec76ab68256d5236d94 upstream. x86 CPUs can suffer severe performance drops if a tight loop, such as the ones in __clear_user(), straddles a 16-byte instruction fetch window, or worse, a 64-byte cacheline. This issues was discovered in the SUSE kernel with the following commit, 1153933703d9 ("x86/asm/64: Micro-optimize __clear_user() - Use immediate constants") which increased the code object size from 10 bytes to 15 bytes and caused the 8-byte copy loop in __clear_user() to be split across a 64-byte cacheline. Aligning the start of the loop to 16-bytes makes this fit neatly inside a single instruction fetch window again and restores the performance of __clear_user() which is used heavily when reading from /dev/zero. Here are some numbers from running libmicro's read_z* and pread_z* microbenchmarks which read from /dev/zero: Zen 1 (Naples) libmicro-file 5.7.0-rc6 5.7.0-rc6 5.7.0-rc6 revert-1153933703d9+ align16+ Time mean95-pread_z100k 9.9195 ( 0.00%) 5.9856 ( 39.66%) 5.9938 ( 39.58%) Time mean95-pread_z10k 1.1378 ( 0.00%) 0.7450 ( 34.52%) 0.7467 ( 34.38%) Time mean95-pread_z1k 0.2623 ( 0.00%) 0.2251 ( 14.18%) 0.2252 ( 14.15%) Time mean95-pread_zw100k 9.9974 ( 0.00%) 6.0648 ( 39.34%) 6.0756 ( 39.23%) Time mean95-read_z100k 9.8940 ( 0.00%) 5.9885 ( 39.47%) 5.9994 ( 39.36%) Time mean95-read_z10k 1.1394 ( 0.00%) 0.7483 ( 34.33%) 0.7482 ( 34.33%) Note that this doesn't affect Haswell or Broadwell microarchitectures which seem to avoid the alignment issue by executing the loop straight out of the Loop Stream Detector (verified using perf events). Fixes: 1153933703d9 ("x86/asm/64: Micro-optimize __clear_user() - Use immediate constants") Signed-off-by: Matt Fleming Signed-off-by: Borislav Petkov Cc: # v4.19+ Link: https://lkml.kernel.org/r/20200618102002.30034-1-matt@codeblueprint.co.uk Signed-off-by: Greg Kroah-Hartman commit 3ceaf206b706c1a81ac48d76ced9028e460b27b0 Author: Kees Cook Date: Mon Jun 8 20:15:09 2020 -0700 x86/cpu: Use pinning mask for CR4 bits needing to be 0 commit a13b9d0b97211579ea63b96c606de79b963c0f47 upstream. The X86_CR4_FSGSBASE bit of CR4 should not change after boot[1]. Older kernels should enforce this bit to zero, and newer kernels need to enforce it depending on boot-time configuration (e.g. "nofsgsbase"). To support a pinned bit being either 1 or 0, use an explicit mask in combination with the expected pinned bit values. [1] https://lore.kernel.org/lkml/20200527103147.GI325280@hirez.programming.kicks-ass.net Signed-off-by: Kees Cook Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/202006082013.71E29A42@keescook Signed-off-by: Greg Kroah-Hartman commit 96a80133559f1585814fccf110c6ca17ef17b9d7 Author: Sean Christopherson Date: Mon Jun 22 17:51:35 2020 -0700 KVM: VMX: Stop context switching MSR_IA32_UMWAIT_CONTROL commit bf09fb6cba4f7099620cc9ed32d94c27c4af992e upstream. Remove support for context switching between the guest's and host's desired UMWAIT_CONTROL. Propagating the guest's value to hardware isn't required for correct functionality, e.g. KVM intercepts reads and writes to the MSR, and the latency effects of the settings controlled by the MSR are not architecturally visible. As a general rule, KVM should not allow the guest to control power management settings unless explicitly enabled by userspace, e.g. see KVM_CAP_X86_DISABLE_EXITS. E.g. Intel's SDM explicitly states that C0.2 can improve the performance of SMT siblings. A devious guest could disable C0.2 so as to improve the performance of their workloads at the detriment to workloads running in the host or on other VMs. Wholesale removal of UMWAIT_CONTROL context switching also fixes a race condition where updates from the host may cause KVM to enter the guest with the incorrect value. Because updates are are propagated to all CPUs via IPI (SMP function callback), the value in hardware may be stale with respect to the cached value and KVM could enter the guest with the wrong value in hardware. As above, the guest can't observe the bad value, but it's a weird and confusing wart in the implementation. Removal also fixes the unnecessary usage of VMX's atomic load/store MSR lists. Using the lists is only necessary for MSRs that are required for correct functionality immediately upon VM-Enter/VM-Exit, e.g. EFER on old hardware, or for MSRs that need to-the-uop precision, e.g. perf related MSRs. For UMWAIT_CONTROL, the effects are only visible in the kernel via TPAUSE/delay(), and KVM doesn't do any form of delay in vcpu_vmx_run(). Using the atomic lists is undesirable as they are more expensive than direct RDMSR/WRMSR. Furthermore, even if giving the guest control of the MSR is legitimate, e.g. in pass-through scenarios, it's not clear that the benefits would outweigh the overhead. E.g. saving and restoring an MSR across a VMX roundtrip costs ~250 cycles, and if the guest diverged from the host that cost would be paid on every run of the guest. In other words, if there is a legitimate use case then it should be enabled by a new per-VM capability. Note, KVM still needs to emulate MSR_IA32_UMWAIT_CONTROL so that it can correctly expose other WAITPKG features to the guest, e.g. TPAUSE, UMWAIT and UMONITOR. Fixes: 6e3ba4abcea56 ("KVM: vmx: Emulate MSR IA32_UMWAIT_CONTROL") Cc: stable@vger.kernel.org Cc: Jingqi Liu Cc: Tao Xu Signed-off-by: Sean Christopherson Message-Id: <20200623005135.10414-1-sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 8ccc6ac51eac8d0735328a54a7bf44ec6d82a18c Author: Sean Christopherson Date: Mon Jun 22 14:58:29 2020 -0700 KVM: nVMX: Plumb L2 GPA through to PML emulation commit 2dbebf7ae1ed9a420d954305e2c9d5ed39ec57c3 upstream. Explicitly pass the L2 GPA to kvm_arch_write_log_dirty(), which for all intents and purposes is vmx_write_pml_buffer(), instead of having the latter pull the GPA from vmcs.GUEST_PHYSICAL_ADDRESS. If the dirty bit update is the result of KVM emulation (rare for L2), then the GPA in the VMCS may be stale and/or hold a completely unrelated GPA. Fixes: c5f983f6e8455 ("nVMX: Implement emulated Page Modification Logging") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20200622215832.22090-2-sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 5774f9fa563bb51294dd3262b4fac1f4dc6f0c3c Author: Xiaoyao Li Date: Tue Jun 16 15:33:07 2020 +0800 KVM: X86: Fix MSR range of APIC registers in X2APIC mode commit bf10bd0be53282183f374af23577b18b5fbf7801 upstream. Only MSR address range 0x800 through 0x8ff is architecturally reserved and dedicated for accessing APIC registers in x2APIC mode. Fixes: 0105d1a52640 ("KVM: x2apic interface to lapic") Signed-off-by: Xiaoyao Li Message-Id: <20200616073307.16440-1-xiaoyao.li@intel.com> Cc: stable@vger.kernel.org Reviewed-by: Sean Christopherson Reviewed-by: Jim Mattson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 0236040fcf97d7d9e807d61e08f745678885271d Author: Gao Xiang Date: Fri Jun 19 07:43:49 2020 +0800 erofs: fix partially uninitialized misuse in z_erofs_onlinepage_fixup commit 3c597282887fd55181578996dca52ce697d985a5 upstream. Hongyu reported "id != index" in z_erofs_onlinepage_fixup() with specific aarch64 environment easily, which wasn't shown before. After digging into that, I found that high 32 bits of page->private was set to 0xaaaaaaaa rather than 0 (due to z_erofs_onlinepage_init behavior with specific compiler options). Actually we only use low 32 bits to keep the page information since page->private is only 4 bytes on most 32-bit platforms. However z_erofs_onlinepage_fixup() uses the upper 32 bits by mistake. Let's fix it now. Reported-and-tested-by: Hongyu Jin Fixes: 3883a79abd02 ("staging: erofs: introduce VLE decompression support") Cc: # 4.19+ Reviewed-by: Chao Yu Link: https://lore.kernel.org/r/20200618234349.22553-1-hsiangkao@aol.com Signed-off-by: Gao Xiang Signed-off-by: Greg Kroah-Hartman commit 824d0b6225f3fa2992704478a8df520537cfcb56 Author: Jason A. Donenfeld Date: Mon Jun 15 04:43:32 2020 -0600 ACPI: configfs: Disallow loading ACPI tables when locked down commit 75b0cea7bf307f362057cc778efe89af4c615354 upstream. Like other vectors already patched, this one here allows the root user to load ACPI tables, which enables arbitrary physical address writes, which in turn makes it possible to disable lockdown. Prevents this by checking the lockdown status before allowing a new ACPI table to be installed. The link in the trailer shows a PoC of how this might be used. Link: https://git.zx2c4.com/american-unsigned-language/tree/american-unsigned-language-2.sh Cc: 5.4+ # 5.4+ Signed-off-by: Jason A. Donenfeld Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 3c4f9a5541bb481b11904fc4c9b1c755fc3cd8f9 Author: Nathan Chancellor Date: Thu Jun 11 21:51:50 2020 -0700 ACPI: sysfs: Fix pm_profile_attr type commit e6d701dca9893990d999fd145e3e07223c002b06 upstream. When running a kernel with Clang's Control Flow Integrity implemented, there is a violation that happens when accessing /sys/firmware/acpi/pm_profile: $ cat /sys/firmware/acpi/pm_profile 0 $ dmesg ... [ 17.352564] ------------[ cut here ]------------ [ 17.352568] CFI failure (target: acpi_show_profile+0x0/0x8): [ 17.352572] WARNING: CPU: 3 PID: 497 at kernel/cfi.c:29 __cfi_check_fail+0x33/0x40 [ 17.352573] Modules linked in: [ 17.352575] CPU: 3 PID: 497 Comm: cat Tainted: G W 5.7.0-microsoft-standard+ #1 [ 17.352576] RIP: 0010:__cfi_check_fail+0x33/0x40 [ 17.352577] Code: 48 c7 c7 50 b3 85 84 48 c7 c6 50 0a 4e 84 e8 a4 d8 60 00 85 c0 75 02 5b c3 48 c7 c7 dc 5e 49 84 48 89 de 31 c0 e8 7d 06 eb ff <0f> 0b 5b c3 00 00 cc cc 00 00 cc cc 00 85 f6 74 25 41 b9 ea ff ff [ 17.352577] RSP: 0018:ffffaa6dc3c53d30 EFLAGS: 00010246 [ 17.352578] RAX: 331267e0c06cee00 RBX: ffffffff83d85890 RCX: ffffffff8483a6f8 [ 17.352579] RDX: ffff9cceabbb37c0 RSI: 0000000000000082 RDI: ffffffff84bb9e1c [ 17.352579] RBP: ffffffff845b2bc8 R08: 0000000000000001 R09: ffff9cceabbba200 [ 17.352579] R10: 000000000000019d R11: 0000000000000000 R12: ffff9cc947766f00 [ 17.352580] R13: ffffffff83d6bd50 R14: ffff9ccc6fa80000 R15: ffffffff845bd328 [ 17.352582] FS: 00007fdbc8d13580(0000) GS:ffff9cce91ac0000(0000) knlGS:0000000000000000 [ 17.352582] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 17.352583] CR2: 00007fdbc858e000 CR3: 00000005174d0000 CR4: 0000000000340ea0 [ 17.352584] Call Trace: [ 17.352586] ? rev_id_show+0x8/0x8 [ 17.352587] ? __cfi_check+0x45bac/0x4b640 [ 17.352589] ? kobj_attr_show+0x73/0x80 [ 17.352590] ? sysfs_kf_seq_show+0xc1/0x140 [ 17.352592] ? ext4_seq_options_show.cfi_jt+0x8/0x8 [ 17.352593] ? seq_read+0x180/0x600 [ 17.352595] ? sysfs_create_file_ns.cfi_jt+0x10/0x10 [ 17.352596] ? tlbflush_read_file+0x8/0x8 [ 17.352597] ? __vfs_read+0x6b/0x220 [ 17.352598] ? handle_mm_fault+0xa23/0x11b0 [ 17.352599] ? vfs_read+0xa2/0x130 [ 17.352599] ? ksys_read+0x6a/0xd0 [ 17.352601] ? __do_sys_getpgrp+0x8/0x8 [ 17.352602] ? do_syscall_64+0x72/0x120 [ 17.352603] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 17.352604] ---[ end trace 7b1fa81dc897e419 ]--- When /sys/firmware/acpi/pm_profile is read, sysfs_kf_seq_show is called, which in turn calls kobj_attr_show, which gets the ->show callback member by calling container_of on attr (casting it to struct kobj_attribute) then calls it. There is a CFI violation because pm_profile_attr is of type struct device_attribute but kobj_attr_show calls ->show expecting it to be from struct kobj_attribute. CFI checking ensures that function pointer types match when doing indirect calls. Fix pm_profile_attr to be defined in terms of kobj_attribute so there is no violation or mismatch. Fixes: 362b646062b2 ("ACPI: Export FADT pm_profile integer value to userspace") Link: https://github.com/ClangBuiltLinux/linux/issues/1051 Reported-by: yuu ichii Signed-off-by: Nathan Chancellor Cc: 3.10+ # 3.10+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 6ee4d61403d25e2f34f9428acfa99537a6b45639 Author: Kai-Heng Feng Date: Wed Jun 17 18:29:02 2020 +0800 ALSA: hda/realtek: Add mute LED and micmute LED support for HP systems commit b2c22910fe5aae10b7e17b0721e63a3edf0c9553 upstream. There are two more HP systems control mute LED from HDA codec and need to expose micmute led class so SoF can control micmute LED. Add quirks to support them. Signed-off-by: Kai-Heng Feng Cc: Link: https://lore.kernel.org/r/20200617102906.16156-2-kai.heng.feng@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1a1bc3ae6935bfda9bf2c37a71f0712225b89b3f Author: Takashi Iwai Date: Tue Jun 16 15:21:50 2020 +0200 ALSA: hda/realtek - Add quirk for MSI GE63 laptop commit a0b03952a797591d4b6d6fa7b9b7872e27783729 upstream. MSI GE63 laptop with ALC1220 codec requires the very same quirk (ALC1220_FIXUP_CLEVO_P950) as other MSI devices for the proper sound output. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208057 Cc: Link: https://lore.kernel.org/r/20200616132150.8778-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 0211e0d7f185b4ff51960196b035654f1a2c068a Author: Aaron Plattner Date: Thu Jun 11 11:08:45 2020 -0700 ALSA: hda: Add NVIDIA codec IDs 9a & 9d through a0 to patch table commit adb36a8203831e40494a92095dacd566b2ad4a69 upstream. These IDs are for upcoming NVIDIA chips with audio functions that are largely similar to the existing ones. Signed-off-by: Aaron Plattner Cc: Link: https://lore.kernel.org/r/20200611180845.39942-1-aplattner@nvidia.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f06a6294e113e7f530c0942a886a10243a762b77 Author: Yash Shah Date: Tue Jun 16 19:33:06 2020 +0530 RISC-V: Don't allow write+exec only page mapping request in mmap [ Upstream commit e0d17c842c0f824fd4df9f4688709fc6907201e1 ] As per the table 4.4 of version "20190608-Priv-MSU-Ratified" of the RISC-V instruction set manual[0], the PTE permission bit combination of "write+exec only" is reserved for future use. Hence, don't allow such mapping request in mmap call. An issue is been reported by David Abdurachmanov, that while running stress-ng with "sysbadaddr" argument, RCU stalls are observed on RISC-V specific kernel. This issue arises when the stress-sysbadaddr request for pages with "write+exec only" permission bits and then passes the address obtain from this mmap call to various system call. For the riscv kernel, the mmap call should fail for this particular combination of permission bits since it's not valid. [0]: http://dabbelt.com/~palmer/keep/riscv-isa-manual/riscv-privileged-20190608-1.pdf Signed-off-by: Yash Shah Reported-by: David Abdurachmanov [Palmer: Refer to the latest ISA specification at the only link I could find, and update the terminology.] Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 26b0956cb374171832b730996a59411649d7047d Author: Weiping Zhang Date: Wed Jun 17 14:18:37 2020 +0800 block: update hctx map when use multiple maps [ Upstream commit fe35ec58f0d339221643287bbb7cee15c93a5389 ] There is an issue when tune the number for read and write queues, if the total queue count was not changed. The hctx->type cannot be updated, since __blk_mq_update_nr_hw_queues will return directly if the total queue count has not been changed. Reproduce: dmesg | grep "default/read/poll" [ 2.607459] nvme nvme0: 48/0/0 default/read/poll queues cat /sys/kernel/debug/block/nvme0n1/hctx*/type | sort | uniq -c 48 default tune the write queues to 24: echo 24 > /sys/module/nvme/parameters/write_queues echo 1 > /sys/block/nvme0n1/device/reset_controller dmesg | grep "default/read/poll" [ 433.547235] nvme nvme0: 24/24/0 default/read/poll queues cat /sys/kernel/debug/block/nvme0n1/hctx*/type | sort | uniq -c 48 default The driver's hardware queue mapping is not same as block layer. Signed-off-by: Weiping Zhang Reviewed-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 72647ea37700b7baefbc4df15371e3e75cb8c301 Author: Luis Chamberlain Date: Fri Jun 5 16:58:36 2020 +0200 blktrace: break out of blktrace setup on concurrent calls [ Upstream commit 1b0b283648163dae2a214ca28ed5a99f62a77319 ] We use one blktrace per request_queue, that means one per the entire disk. So we cannot run one blktrace on say /dev/vda and then /dev/vda1, or just two calls on /dev/vda. We check for concurrent setup only at the very end of the blktrace setup though. If we try to run two concurrent blktraces on the same block device the second one will fail, and the first one seems to go on. However when one tries to kill the first one one will see things like this: The kernel will show these: ``` debugfs: File 'dropped' in directory 'nvme1n1' already present! debugfs: File 'msg' in directory 'nvme1n1' already present! debugfs: File 'trace0' in directory 'nvme1n1' already present! `` And userspace just sees this error message for the second call: ``` blktrace /dev/nvme1n1 BLKTRACESETUP(2) /dev/nvme1n1 failed: 5/Input/output error ``` The first userspace process #1 will also claim that the files were taken underneath their nose as well. The files are taken away form the first process given that when the second blktrace fails, it will follow up with a BLKTRACESTOP and BLKTRACETEARDOWN. This means that even if go-happy process #1 is waiting for blktrace data, we *have* been asked to take teardown the blktrace. This can easily be reproduced with break-blktrace [0] run_0005.sh test. Just break out early if we know we're already going to fail, this will prevent trying to create the files all over again, which we know still exist. [0] https://github.com/mcgrof/break-blktrace Signed-off-by: Luis Chamberlain Signed-off-by: Jan Kara Reviewed-by: Bart Van Assche Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit d14eb5d8f0f4a2783e2125e0ba8a6732b345cc35 Author: Masami Hiramatsu Date: Tue May 12 17:02:33 2020 +0900 kprobes: Suppress the suspicious RCU warning on kprobes [ Upstream commit 6743ad432ec92e680cd0d9db86cb17b949cf5a43 ] Anders reported that the lockdep warns that suspicious RCU list usage in register_kprobe() (detected by CONFIG_PROVE_RCU_LIST.) This is because get_kprobe() access kprobe_table[] by hlist_for_each_entry_rcu() without rcu_read_lock. If we call get_kprobe() from the breakpoint handler context, it is run with preempt disabled, so this is not a problem. But in other cases, instead of rcu_read_lock(), we locks kprobe_mutex so that the kprobe_table[] is not updated. So, current code is safe, but still not good from the view point of RCU. Joel suggested that we can silent that warning by passing lockdep_is_held() to the last argument of hlist_for_each_entry_rcu(). Add lockdep_is_held(&kprobe_mutex) at the end of the hlist_for_each_entry_rcu() to suppress the warning. Link: http://lkml.kernel.org/r/158927055350.27680.10261450713467997503.stgit@devnote2 Reported-by: Anders Roxell Suggested-by: Joel Fernandes Reviewed-by: Joel Fernandes (Google) Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 8ed391a3dbc497f83a5fc6eabdd86784a3172b3c Author: Sami Tolvanen Date: Fri Apr 24 12:30:46 2020 -0700 recordmcount: support >64k sections [ Upstream commit 4ef57b21d6fb49d2b25c47e4cff467a0c2c8b6b7 ] When compiling a kernel with Clang and LTO, we need to run recordmcount on vmlinux.o with a large number of sections, which currently fails as the program doesn't understand extended section indexes. This change adds support for processing binaries with >64k sections. Link: https://lkml.kernel.org/r/20200424193046.160744-1-samitolvanen@google.com Link: https://lore.kernel.org/lkml/CAK7LNARbZhoaA=Nnuw0=gBrkuKbr_4Ng_Ei57uafujZf7Xazgw@mail.gmail.com/ Cc: Kees Cook Reviewed-by: Matt Helsley Signed-off-by: Sami Tolvanen Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 803d114e8f19cb5e9e40b5c26d8ea33829916d09 Author: Masahiro Yamada Date: Sun Jun 14 23:43:40 2020 +0900 kbuild: improve cc-option to clean up all temporary files [ Upstream commit f2f02ebd8f3833626642688b2d2c6a7b3c141fa9 ] When cc-option and friends evaluate compiler flags, the temporary file $$TMP is created as an output object, and automatically cleaned up. The actual file path of $$TMP is ..tmp, here is the process ID of $(shell ...) invoked from cc-option. (Please note $$$$ is the escape sequence of $$). Such garbage files are cleaned up in most cases, but some compiler flags create additional output files. For example, -gsplit-dwarf creates a .dwo file. When CONFIG_DEBUG_INFO_SPLIT=y, you will see a bunch of ..dwo files left in the top of build directories. You may not notice them unless you do 'ls -a', but the garbage files will increase every time you run 'make'. This commit changes the temporary object path to .tmp_/tmp, and removes .tmp_ directory when exiting. Separate build artifacts such as *.dwo will be cleaned up all together because their file paths are usually determined based on the base name of the object. Another example is -ftest-coverage, which outputs the coverage data into .gcno Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit cbed4eb0a92fa990b83f9b106c69e905d5c80ece Author: Will Deacon Date: Tue Jun 16 18:29:11 2020 +0100 arm64: sve: Fix build failure when ARM64_SVE=y and SYSCTL=n [ Upstream commit e575fb9e76c8e33440fb859572a8b7d430f053d6 ] When I squashed the 'allnoconfig' compiler warning about the set_sve_default_vl() function being defined but not used in commit 1e570f512cbd ("arm64/sve: Eliminate data races on sve_default_vl"), I accidentally broke the build for configs where ARM64_SVE is enabled, but SYSCTL is not. Fix this by only compiling the SVE sysctl support if both CONFIG_SVE=y and CONFIG_SYSCTL=y. Cc: Dave Martin Reported-by: Qian Cai Link: https://lore.kernel.org/r/20200616131808.GA1040@lca.pw Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit a9a3b33b20aac7308e72cb886d08128c75689883 Author: Vincenzo Frascino Date: Tue Mar 24 12:10:27 2020 +0000 s390/vdso: fix vDSO clock_getres() [ Upstream commit 478237a595120a18e9b52fd2c57a6e8b7a01e411 ] clock_getres in the vDSO library has to preserve the same behaviour of posix_get_hrtimer_res(). In particular, posix_get_hrtimer_res() does: sec = 0; ns = hrtimer_resolution; and hrtimer_resolution depends on the enablement of the high resolution timers that can happen either at compile or at run time. Fix the s390 vdso implementation of clock_getres keeping a copy of hrtimer_resolution in vdso data and using that directly. Link: https://lkml.kernel.org/r/20200324121027.21665-1-vincenzo.frascino@arm.com Signed-off-by: Vincenzo Frascino Acked-by: Martin Schwidefsky [heiko.carstens@de.ibm.com: use llgf for proper zero extension] Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 68a3cbc4466058eb61752a494606e2d192dae7cc Author: Nathan Chancellor Date: Tue Jun 2 12:25:24 2020 -0700 s390/vdso: Use $(LD) instead of $(CC) to link vDSO [ Upstream commit 2b2a25845d534ac6d55086e35c033961fdd83a26 ] Currently, the VDSO is being linked through $(CC). This does not match how the rest of the kernel links objects, which is through the $(LD) variable. When clang is built in a default configuration, it first attempts to use the target triple's default linker, which is just ld. However, the user can override this through the CLANG_DEFAULT_LINKER cmake define so that clang uses another linker by default, such as LLVM's own linker, ld.lld. This can be useful to get more optimized links across various different projects. However, this is problematic for the s390 vDSO because ld.lld does not have any s390 emulatiom support: https://github.com/llvm/llvm-project/blob/llvmorg-10.0.1-rc1/lld/ELF/Driver.cpp#L132-L150 Thus, if a user is using a toolchain with ld.lld as the default, they will see an error, even if they have specified ld.bfd through the LD make variable: $ make -j"$(nproc)" -s ARCH=s390 CROSS_COMPILE=s390x-linux-gnu- LLVM=1 \ LD=s390x-linux-gnu-ld \ defconfig arch/s390/kernel/vdso64/ ld.lld: error: unknown emulation: elf64_s390 clang-11: error: linker command failed with exit code 1 (use -v to see invocation) Normally, '-fuse-ld=bfd' could be used to get around this; however, this can be fragile, depending on paths and variable naming. The cleaner solution for the kernel is to take advantage of the fact that $(LD) can be invoked directly, which bypasses the heuristics of $(CC) and respects the user's choice. Similar changes have been done for ARM, ARM64, and MIPS. Link: https://lkml.kernel.org/r/20200602192523.32758-1-natechancellor@gmail.com Link: https://github.com/ClangBuiltLinux/linux/issues/1041 Signed-off-by: Nathan Chancellor Reviewed-by: Nick Desaulniers [heiko.carstens@de.ibm.com: add --build-id flag] Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 7c17909a889d05abf3401a13823834d076651dd5 Author: Sven Schnelle Date: Mon Mar 9 16:44:50 2020 +0100 s390/ptrace: fix setting syscall number [ Upstream commit 873e5a763d604c32988c4a78913a8dab3862d2f9 ] When strace wants to update the syscall number, it sets GPR2 to the desired number and updates the GPR via PTRACE_SETREGSET. It doesn't update regs->int_code which would cause the old syscall executed on syscall restart. As we cannot change the ptrace ABI and don't have a field for the interruption code, check whether the tracee is in a syscall and the last instruction was svc. In that case assume that the tracer wants to update the syscall number and copy the GPR2 value to regs->int_code. Signed-off-by: Sven Schnelle Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 64f7b10a91a4177e7d620b545a00c7c86d209770 Author: Sven Schnelle Date: Fri Mar 6 13:19:34 2020 +0100 s390/ptrace: pass invalid syscall numbers to tracing [ Upstream commit 00332c16b1604242a56289ff2b26e283dbad0812 ] tracing expects to see invalid syscalls, so pass it through. The syscall path in entry.S checks the syscall number before looking up the handler, so it is still safe. Signed-off-by: Sven Schnelle Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 453cfe187723d5e63003d213742df2d6797e937d Author: Vidya Sagar Date: Thu Jun 4 23:19:35 2020 +0530 pinctrl: tegra: Use noirq suspend/resume callbacks [ Upstream commit 782b6b69847f34dda330530493ea62b7de3fd06a ] Use noirq suspend/resume callbacks as other drivers which implement noirq suspend/resume callbacks (Ex:- PCIe) depend on pinctrl driver to configure the signals used by their respective devices in the noirq phase. Signed-off-by: Vidya Sagar Reviewed-by: Dmitry Osipenko Link: https://lore.kernel.org/r/20200604174935.26560-1-vidyas@nvidia.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 7851257375ae77ab0a2a779f6bed5becd2f0c4d6 Author: Dmitry Baryshkov Date: Thu Jun 4 03:28:17 2020 +0300 pinctrl: qcom: spmi-gpio: fix warning about irq chip reusage [ Upstream commit 5e50311556c9f409a85740e3cb4c4511e7e27da0 ] Fix the following warnings caused by reusage of the same irq_chip instance for all spmi-gpio gpio_irq_chip instances. Instead embed irq_chip into pmic_gpio_state struct. gpio gpiochip2: (c440000.qcom,spmi:pmic@2:gpio@c000): detected irqchip that is shared with multiple gpiochips: please fix the driver. gpio gpiochip3: (c440000.qcom,spmi:pmic@4:gpio@c000): detected irqchip that is shared with multiple gpiochips: please fix the driver. gpio gpiochip4: (c440000.qcom,spmi:pmic@a:gpio@c000): detected irqchip that is shared with multiple gpiochips: please fix the driver. Signed-off-by: Dmitry Baryshkov Acked-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20200604002817.667160-1-dmitry.baryshkov@linaro.org Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 8dba9173a37a53197971c39f752d07e6bc1a50d0 Author: Aditya Pakki Date: Fri Jun 12 15:01:54 2020 -0500 test_objagg: Fix potential memory leak in error handling [ Upstream commit a6379f0ad6375a707e915518ecd5c2270afcd395 ] In case of failure of check_expect_hints_stats(), the resources allocated by objagg_hints_get should be freed. The patch fixes this issue. Signed-off-by: Aditya Pakki Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6fd916e249357a65a4924795613eb1bf69514209 Author: Zekun Shen Date: Mon Jun 15 11:50:29 2020 -0400 net: alx: fix race condition in alx_remove [ Upstream commit e89df5c4322c1bf495f62d74745895b5fd2a4393 ] There is a race condition exist during termination. The path is alx_stop and then alx_remove. An alx_schedule_link_check could be called before alx_stop by interrupt handler and invoke alx_link_check later. Alx_stop frees the napis, and alx_remove cancels any pending works. If any of the work is scheduled before termination and invoked before alx_remove, a null-ptr-deref occurs because both expect alx->napis[i]. This patch fix the race condition by moving cancel_work_sync functions before alx_free_napis inside alx_stop. Because interrupt handler can call alx_schedule_link_check again, alx_free_irq is moved before cancel_work_sync calls too. Signed-off-by: Zekun Shen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 855dbf10c9a7eec8ee37f304a7704c19003c24fc Author: Thomas Falcon Date: Mon Jun 15 10:29:23 2020 -0500 ibmvnic: Harden device login requests [ Upstream commit dff515a3e71dc8ab3b9dcc2e23a9b5fca88b3c18 ] The VNIC driver's "login" command sequence is the final step in the driver's initialization process with device firmware, confirming the available device queue resources to be utilized by the driver. Under high system load, firmware may not respond to the request in a timely manner or may abort the request. In such cases, the driver should reattempt the login command sequence. In case of a device error, the number of retries is bounded. Signed-off-by: Thomas Falcon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 07b8b2d463710afa9b9d275177d8801b8de60606 Author: Dinghao Liu Date: Thu May 28 15:21:04 2020 +0800 hwrng: ks-sa - Fix runtime PM imbalance on error [ Upstream commit 95459261c99f1621d90bc628c2a48e60b7cf9a88 ] pm_runtime_get_sync() increments the runtime PM usage counter even the call returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Signed-off-by: Dinghao Liu Reviewed-by: Alexander Sverdlin Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit b8403f7e45e57ee705bcc2fe99d34ea44703ec3a Author: Nathan Huckleberry Date: Thu Jun 11 18:32:35 2020 +0000 riscv/atomic: Fix sign extension for RV64I [ Upstream commit 6c58f25e6938c073198af8b1e1832f83f8f0df33 ] The argument passed to cmpxchg is not guaranteed to be sign extended, but lr.w sign extends on RV64I. This makes cmpxchg fail on clang built kernels when __old is negative. To fix this, we just cast __old to long which sign extends on RV64I. With this fix, clang built RISC-V kernels now boot. Link: https://github.com/ClangBuiltLinux/linux/issues/867 Signed-off-by: Nathan Huckleberry Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 81616542adcc777d82e1679c429c87bb44251dd1 Author: Denis Efremov Date: Fri Jun 5 20:37:44 2020 +0300 drm/amd/display: Use kfree() to free rgb_user in calculate_user_regamma_ramp() [ Upstream commit 43a562774fceba867e8eebba977d7d42f8a2eac7 ] Use kfree() instead of kvfree() to free rgb_user in calculate_user_regamma_ramp() because the memory is allocated with kcalloc(). Signed-off-by: Denis Efremov Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f7f181582f1b863c2f49e78205c65059819948f6 Author: Ye Bin Date: Fri Jun 5 09:41:49 2020 +0800 ata/libata: Fix usage of page address by page_address in ata_scsi_mode_select_xlat function [ Upstream commit f650ef61e040bcb175dd8762164b00a5d627f20e ] BUG: KASAN: use-after-free in ata_scsi_mode_select_xlat+0x10bd/0x10f0 drivers/ata/libata-scsi.c:4045 Read of size 1 at addr ffff88803b8cd003 by task syz-executor.6/12621 CPU: 1 PID: 12621 Comm: syz-executor.6 Not tainted 4.19.95 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xac/0xee lib/dump_stack.c:118 print_address_description+0x60/0x223 mm/kasan/report.c:253 kasan_report_error mm/kasan/report.c:351 [inline] kasan_report mm/kasan/report.c:409 [inline] kasan_report.cold+0xae/0x2d8 mm/kasan/report.c:393 ata_scsi_mode_select_xlat+0x10bd/0x10f0 drivers/ata/libata-scsi.c:4045 ata_scsi_translate+0x2da/0x680 drivers/ata/libata-scsi.c:2035 __ata_scsi_queuecmd drivers/ata/libata-scsi.c:4360 [inline] ata_scsi_queuecmd+0x2e4/0x790 drivers/ata/libata-scsi.c:4409 scsi_dispatch_cmd+0x2ee/0x6c0 drivers/scsi/scsi_lib.c:1867 scsi_queue_rq+0xfd7/0x1990 drivers/scsi/scsi_lib.c:2170 blk_mq_dispatch_rq_list+0x1e1/0x19a0 block/blk-mq.c:1186 blk_mq_do_dispatch_sched+0x147/0x3d0 block/blk-mq-sched.c:108 blk_mq_sched_dispatch_requests+0x427/0x680 block/blk-mq-sched.c:204 __blk_mq_run_hw_queue+0xbc/0x200 block/blk-mq.c:1308 __blk_mq_delay_run_hw_queue+0x3c0/0x460 block/blk-mq.c:1376 blk_mq_run_hw_queue+0x152/0x310 block/blk-mq.c:1413 blk_mq_sched_insert_request+0x337/0x6c0 block/blk-mq-sched.c:397 blk_execute_rq_nowait+0x124/0x320 block/blk-exec.c:64 blk_execute_rq+0xc5/0x112 block/blk-exec.c:101 sg_scsi_ioctl+0x3b0/0x6a0 block/scsi_ioctl.c:507 sg_ioctl+0xd37/0x23f0 drivers/scsi/sg.c:1106 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:501 [inline] do_vfs_ioctl+0xae6/0x1030 fs/ioctl.c:688 ksys_ioctl+0x76/0xa0 fs/ioctl.c:705 __do_sys_ioctl fs/ioctl.c:712 [inline] __se_sys_ioctl fs/ioctl.c:710 [inline] __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:710 do_syscall_64+0xa0/0x2e0 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x45c479 Code: ad b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007fb0e9602c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fb0e96036d4 RCX: 000000000045c479 RDX: 0000000020000040 RSI: 0000000000000001 RDI: 0000000000000003 RBP: 000000000076bfc0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff R13: 000000000000046d R14: 00000000004c6e1a R15: 000000000076bfcc Allocated by task 12577: set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc mm/kasan/kasan.c:553 [inline] kasan_kmalloc+0xbf/0xe0 mm/kasan/kasan.c:531 __kmalloc+0xf3/0x1e0 mm/slub.c:3749 kmalloc include/linux/slab.h:520 [inline] load_elf_phdrs+0x118/0x1b0 fs/binfmt_elf.c:441 load_elf_binary+0x2de/0x4610 fs/binfmt_elf.c:737 search_binary_handler fs/exec.c:1654 [inline] search_binary_handler+0x15c/0x4e0 fs/exec.c:1632 exec_binprm fs/exec.c:1696 [inline] __do_execve_file.isra.0+0xf52/0x1a90 fs/exec.c:1820 do_execveat_common fs/exec.c:1866 [inline] do_execve fs/exec.c:1883 [inline] __do_sys_execve fs/exec.c:1964 [inline] __se_sys_execve fs/exec.c:1959 [inline] __x64_sys_execve+0x8a/0xb0 fs/exec.c:1959 do_syscall_64+0xa0/0x2e0 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Freed by task 12577: set_track mm/kasan/kasan.c:460 [inline] __kasan_slab_free+0x129/0x170 mm/kasan/kasan.c:521 slab_free_hook mm/slub.c:1370 [inline] slab_free_freelist_hook mm/slub.c:1397 [inline] slab_free mm/slub.c:2952 [inline] kfree+0x8b/0x1a0 mm/slub.c:3904 load_elf_binary+0x1be7/0x4610 fs/binfmt_elf.c:1118 search_binary_handler fs/exec.c:1654 [inline] search_binary_handler+0x15c/0x4e0 fs/exec.c:1632 exec_binprm fs/exec.c:1696 [inline] __do_execve_file.isra.0+0xf52/0x1a90 fs/exec.c:1820 do_execveat_common fs/exec.c:1866 [inline] do_execve fs/exec.c:1883 [inline] __do_sys_execve fs/exec.c:1964 [inline] __se_sys_execve fs/exec.c:1959 [inline] __x64_sys_execve+0x8a/0xb0 fs/exec.c:1959 do_syscall_64+0xa0/0x2e0 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The buggy address belongs to the object at ffff88803b8ccf00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 259 bytes inside of 512-byte region [ffff88803b8ccf00, ffff88803b8cd100) The buggy address belongs to the page: page:ffffea0000ee3300 count:1 mapcount:0 mapping:ffff88806cc03080 index:0xffff88803b8cc780 compound_mapcount: 0 flags: 0x100000000008100(slab|head) raw: 0100000000008100 ffffea0001104080 0000000200000002 ffff88806cc03080 raw: ffff88803b8cc780 00000000800c000b 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88803b8ccf00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88803b8ccf80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff88803b8cd000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88803b8cd080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88803b8cd100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc You can refer to "https://www.lkml.org/lkml/2019/1/17/474" reproduce this error. The exception code is "bd_len = p[3];", "p" value is ffff88803b8cd000 which belongs to the cache kmalloc-512 of size 512. The "page_address(sg_page(scsi_sglist(scmd)))" maybe from sg_scsi_ioctl function "buffer" which allocated by kzalloc, so "buffer" may not page aligned. This also looks completely buggy on highmem systems and really needs to use a kmap_atomic. --Christoph Hellwig To address above bugs, Paolo Bonzini advise to simpler to just make a char array of size CACHE_MPAGE_LEN+8+8+4-2(or just 64 to make it easy), use sg_copy_to_buffer to copy from the sglist into the buffer, and workthere. Signed-off-by: Ye Bin Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 4dfc238a2441668703081d5ca60d98d531efa5e4 Author: Navid Emamdoost Date: Thu Jun 4 22:06:43 2020 -0500 sata_rcar: handle pm_runtime_get_sync failure cases [ Upstream commit eea1238867205b9e48a67c1a63219529a73c46fd ] Calling pm_runtime_get_sync increments the counter even in case of failure, causing incorrect ref count. Call pm_runtime_put if pm_runtime_get_sync fails. Signed-off-by: Navid Emamdoost Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 83bdf7f8b7127f3e52960ca1c690a8cd1252b9ca Author: Juri Lelli Date: Mon Nov 19 16:32:01 2018 +0100 sched/core: Fix PI boosting between RT and DEADLINE tasks [ Upstream commit 740797ce3a124b7dd22b7fb832d87bc8fba1cf6f ] syzbot reported the following warning: WARNING: CPU: 1 PID: 6351 at kernel/sched/deadline.c:628 enqueue_task_dl+0x22da/0x38a0 kernel/sched/deadline.c:1504 At deadline.c:628 we have: 623 static inline void setup_new_dl_entity(struct sched_dl_entity *dl_se) 624 { 625 struct dl_rq *dl_rq = dl_rq_of_se(dl_se); 626 struct rq *rq = rq_of_dl_rq(dl_rq); 627 628 WARN_ON(dl_se->dl_boosted); 629 WARN_ON(dl_time_before(rq_clock(rq), dl_se->deadline)); [...] } Which means that setup_new_dl_entity() has been called on a task currently boosted. This shouldn't happen though, as setup_new_dl_entity() is only called when the 'dynamic' deadline of the new entity is in the past w.r.t. rq_clock and boosted tasks shouldn't verify this condition. Digging through the PI code I noticed that what above might in fact happen if an RT tasks blocks on an rt_mutex hold by a DEADLINE task. In the first branch of boosting conditions we check only if a pi_task 'dynamic' deadline is earlier than mutex holder's and in this case we set mutex holder to be dl_boosted. However, since RT 'dynamic' deadlines are only initialized if such tasks get boosted at some point (or if they become DEADLINE of course), in general RT 'dynamic' deadlines are usually equal to 0 and this verifies the aforementioned condition. Fix it by checking that the potential donor task is actually (even if temporary because in turn boosted) running at DEADLINE priority before using its 'dynamic' deadline value. Fixes: 2d3d891d3344 ("sched/deadline: Add SCHED_DEADLINE inheritance logic") Reported-by: syzbot+119ba87189432ead09b4@syzkaller.appspotmail.com Signed-off-by: Juri Lelli Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Reviewed-by: Daniel Bristot de Oliveira Tested-by: Daniel Wagner Link: https://lkml.kernel.org/r/20181119153201.GB2119@localhost.localdomain Signed-off-by: Sasha Levin commit 3dc7138943b1af6e9bf0bcabec623e5cc1041306 Author: Juri Lelli Date: Wed Jun 17 09:29:19 2020 +0200 sched/deadline: Initialize ->dl_boosted [ Upstream commit ce9bc3b27f2a21a7969b41ffb04df8cf61bd1592 ] syzbot reported the following warning triggered via SYSC_sched_setattr(): WARNING: CPU: 0 PID: 6973 at kernel/sched/deadline.c:593 setup_new_dl_entity /kernel/sched/deadline.c:594 [inline] WARNING: CPU: 0 PID: 6973 at kernel/sched/deadline.c:593 enqueue_dl_entity /kernel/sched/deadline.c:1370 [inline] WARNING: CPU: 0 PID: 6973 at kernel/sched/deadline.c:593 enqueue_task_dl+0x1c17/0x2ba0 /kernel/sched/deadline.c:1441 This happens because the ->dl_boosted flag is currently not initialized by __dl_clear_params() (unlike the other flags) and setup_new_dl_entity() rightfully complains about it. Initialize dl_boosted to 0. Fixes: 2d3d891d3344 ("sched/deadline: Add SCHED_DEADLINE inheritance logic") Reported-by: syzbot+5ac8bac25f95e8b221e7@syzkaller.appspotmail.com Signed-off-by: Juri Lelli Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Tested-by: Daniel Wagner Link: https://lkml.kernel.org/r/20200617072919.818409-1-juri.lelli@redhat.com Signed-off-by: Sasha Levin commit bfd4981fe3d64b49662920925fead26cf37c4834 Author: David Howells Date: Wed Jun 24 17:00:24 2020 +0100 afs: Fix storage of cell names [ Upstream commit 719fdd32921fb7e3208db8832d32ae1c2d68900f ] The cell name stored in the afs_cell struct is a 64-char + NUL buffer - when it needs to be able to handle up to AFS_MAXCELLNAME (256 chars) + NUL. Fix this by changing the array to a pointer and allocating the string. Found using Coverity. Fixes: 989782dcdc91 ("afs: Overhaul cell database management") Reported-by: Colin Ian King Signed-off-by: David Howells Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 5cee9e67596f7d694e94d7def7cd9d65a7599f66 Author: Mans Rullgard Date: Sat Jun 13 11:41:09 2020 +0100 i2c: core: check returned size of emulated smbus block read [ Upstream commit 40e05200593af06633f64ab0effff052eee6f076 ] If the i2c bus driver ignores the I2C_M_RECV_LEN flag (as some of them do), it is possible for an I2C_SMBUS_BLOCK_DATA read issued on some random device to return an arbitrary value in the first byte (and nothing else). When this happens, i2c_smbus_xfer_emulated() will happily write past the end of the supplied data buffer, thus causing Bad Things to happen. To prevent this, check the size before copying the data block and return an error if it is too large. Fixes: 209d27c3b167 ("i2c: Emulate SMBus block read over I2C") Signed-off-by: Mans Rullgard [wsa: use better errno] Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 4a6e6413059e8cbacb99ce797ec447612f407e43 Author: Eddie James Date: Tue Jun 9 15:15:54 2020 -0500 i2c: fsi: Fix the port number field in status register [ Upstream commit 502035e284cc7e9efef22b01771d822d49698ab9 ] The port number field in the status register was not correct, so fix it. Fixes: d6ffb6300116 ("i2c: Add FSI-attached I2C master algorithm") Signed-off-by: Eddie James Signed-off-by: Joel Stanley Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 0935afc39797b1305ae8fce4161c77bd94f068ff Author: Vincent Chen Date: Tue Jun 23 09:24:17 2020 +0800 clk: sifive: allocate sufficient memory for struct __prci_data [ Upstream commit d0a5fdf4cc83dabcdea668f971b8a2e916437711 ] The (struct __prci_data).hw_clks.hws is an array with dynamic elements. Using struct_size(pd, hw_clks.hws, ARRAY_SIZE(__prci_init_clocks)) instead of sizeof(*pd) to get the correct memory size of struct __prci_data for sifive/fu540-prci. After applying this modifications, the kernel runs smoothly with CONFIG_SLAB_FREELIST_RANDOM enabled on the HiFive unleashed board. Fixes: 30b8e27e3b58 ("clk: sifive: add a driver for the SiFive FU540 PRCI IP block") Signed-off-by: Vincent Chen Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit b78bae5ab399b2e73705dcacc85ef2b613e439b3 Author: Doug Berger Date: Wed Jun 24 18:14:55 2020 -0700 net: bcmgenet: use hardware padding of runt frames [ Upstream commit 20d1f2d1b024f6be199a3bedf1578a1d21592bc5 ] When commit 474ea9cafc45 ("net: bcmgenet: correctly pad short packets") added the call to skb_padto() it should have been located before the nr_frags parameter was read since that value could be changed when padding packets with lengths between 55 and 59 bytes (inclusive). The use of a stale nr_frags value can cause corruption of the pad data when tx-scatter-gather is enabled. This corruption of the pad can cause invalid checksum computation when hardware offload of tx-checksum is also enabled. Since the original reason for the padding was corrected by commit 7dd399130efb ("net: bcmgenet: fix skb_len in bcmgenet_xmit_single()") we can remove the software padding all together and make use of hardware padding of short frames as long as the hardware also always appends the FCS value to the frame. Fixes: 474ea9cafc45 ("net: bcmgenet: correctly pad short packets") Signed-off-by: Doug Berger Acked-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ae6d80f62c739d1b0a9a3f3cfd17c45293bb3a33 Author: Russell King Date: Wed Jun 10 21:51:11 2020 +0100 netfilter: ipset: fix unaligned atomic access [ Upstream commit 715028460082d07a7ec6fcd87b14b46784346a72 ] When using ip_set with counters and comment, traffic causes the kernel to panic on 32-bit ARM: Alignment trap: not handling instruction e1b82f9f at [] Unhandled fault: alignment exception (0x221) at 0xea08133c PC is at ip_set_match_extensions+0xe0/0x224 [ip_set] The problem occurs when we try to update the 64-bit counters - the faulting address above is not 64-bit aligned. The problem occurs due to the way elements are allocated, for example: set->dsize = ip_set_elem_len(set, tb, 0, 0); map = ip_set_alloc(sizeof(*map) + elements * set->dsize); If the element has a requirement for a member to be 64-bit aligned, and set->dsize is not a multiple of 8, but is a multiple of four, then every odd numbered elements will be misaligned - and hitting an atomic64_add() on that element will cause the kernel to panic. ip_set_elem_len() must return a size that is rounded to the maximum alignment of any extension field stored in the element. This change ensures that is the case. Fixes: 95ad1f4a9358 ("netfilter: ipset: Fix extension alignment") Signed-off-by: Russell King Acked-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 8d93603bf60c7a6760ec79d24aa3987b22a68411 Author: Sagi Grimberg Date: Wed Jun 24 01:53:10 2020 -0700 nvme: don't protect ns mutation with ns->head->lock [ Upstream commit e164471dcf19308d154adb69e7760d8ba426a77f ] Right now ns->head->lock is protecting namespace mutation which is wrong and unneeded. Move it to only protect against head mutations. While we're at it, remove unnecessary ns->head reference as we already have head pointer. The problem with this is that the head->lock spans mpath disk node I/O that may block under some conditions (if for example the controller is disconnecting or the path became inaccessible), The locking scheme does not allow any other path to enable itself, preventing blocked I/O to complete and forward-progress from there. This is a preparation patch for the fix in a subsequent patch where the disk I/O will also be done outside the head->lock. Fixes: 0d0b660f214d ("nvme: add ANA support") Signed-off-by: Anton Eidelman Signed-off-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit f9dc5e708ab8a6e0593d9064308939d8a34e3f91 Author: Yoshihiro Shimoda Date: Thu Jun 18 21:11:17 2020 +0900 usb: renesas_usbhs: getting residue from callback_result [ Upstream commit ea0efd687b01355cd799c8643d0c636ba4859ffc ] This driver assumed that dmaengine_tx_status() could return the residue even if the transfer was completed. However, this was not correct usage [1] and this caused to break getting the residue after the commit 24461d9792c2 ("dmaengine: virt-dma: Fix access after free in vchan_complete()") actually. So, this is possible to get wrong received size if the usb controller gets a short packet. For example, g_zero driver causes "bad OUT byte" errors. The usb-dmac driver will support the callback_result, so this driver can use it to get residue correctly. Note that even if the usb-dmac driver has not supported the callback_result yet, this patch doesn't cause any side-effects. [1] https://lore.kernel.org/dmaengine/20200616165550.GP2324254@vkoul-mobl/ Reported-by: Hien Dang Fixes: 24461d9792c2 ("dmaengine: virt-dma: Fix access after free in vchan_complete()") Signed-off-by: Yoshihiro Shimoda Link: https://lore.kernel.org/r/1592482277-19563-1-git-send-email-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 56ee0ed97df5cace405e86a9632ad648b5b8f00b Author: Dan Carpenter Date: Mon Jun 15 14:27:19 2020 +0300 usb: gadget: udc: Potential Oops in error handling code [ Upstream commit e55f3c37cb8d31c7e301f46396b2ac6a19eb3a7c ] If this is in "transceiver" mode the the ->qwork isn't required and is a NULL pointer. This can lead to a NULL dereference when we call destroy_workqueue(udc->qwork). Fixes: 3517c31a8ece ("usb: gadget: mv_udc: use devm_xxx for probe") Signed-off-by: Dan Carpenter Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit a3a86515d017081673dcb1ec42a5f38f5024a6f4 Author: SeongJae Park Date: Tue Jun 23 10:41:22 2020 +0200 scsi: lpfc: Avoid another null dereference in lpfc_sli4_hba_unset() [ Upstream commit 46da547e21d6cefceec3fb3dba5ebbca056627fc ] Commit cdb42becdd40 ("scsi: lpfc: Replace io_channels for nvme and fcp with general hdw_queues per cpu") has introduced static checker warnings for potential null dereferences in 'lpfc_sli4_hba_unset()' and commit 1ffdd2c0440d ("scsi: lpfc: resolve static checker warning in lpfc_sli4_hba_unset") has tried to fix it. However, yet another potential null dereference is remaining. This commit fixes it. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. Link: https://lore.kernel.org/r/20200623084122.30633-1-sjpark@amazon.com Fixes: 1ffdd2c0440d ("scsi: lpfc: resolve static checker warning inlpfc_sli4_hba_unset") Fixes: cdb42becdd40 ("scsi: lpfc: Replace io_channels for nvme and fcp with general hdw_queues per cpu") Reviewed-by: James Smart Signed-off-by: SeongJae Park Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1e812023f47884be63a4db24ff2e25001280d1c1 Author: yu kuai Date: Thu Jun 4 20:42:06 2020 +0800 ARM: imx5: add missing put_device() call in imx_suspend_alloc_ocram() [ Upstream commit 586745f1598ccf71b0a5a6df2222dee0a865954e ] if of_find_device_by_node() succeed, imx_suspend_alloc_ocram() doesn't have a corresponding put_device(). Thus add a jump target to fix the exception handling for this function implementation. Fixes: 1579c7b9fe01 ("ARM: imx53: Set DDR pins to high impedance when in suspend to RAM.") Signed-off-by: yu kuai Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 61f488765dffabd91087072c21bd424299e17125 Author: Rahul Lakkireddy Date: Wed Jun 24 01:51:31 2020 +0530 cxgb4: move handling L2T ARP failures to caller [ Upstream commit 11d8cd5c9f3b46f397f889cefdb66795518aaebd ] Move code handling L2T ARP failures to the only caller. Fixes following sparse warning: skbuff.h:2091:29: warning: context imbalance in 'handle_failed_resolution' - unexpected unlock Fixes: 749cb5fe48bb ("cxgb4: Replace arpq_head/arpq_tail with SKB double link-list code") Signed-off-by: Rahul Lakkireddy Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 065f225ef975513e5ba0edaaa7c7d0b74bbc0b75 Author: Alexander Lobakin Date: Tue Jun 23 16:51:35 2020 +0300 net: qede: fix use-after-free on recovery and AER handling [ Upstream commit ec6c80590bde6b5dfa4970fffa3572f1acd313ca ] Set edev->cdev pointer to NULL after calling remove() callback to avoid using of already freed object. Fixes: ccc67ef50b90 ("qede: Error recovery process") Signed-off-by: Alexander Lobakin Signed-off-by: Igor Russkikh Signed-off-by: Michal Kalderon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f490e70fa7eb9a237ff112d2ffe100f107e41bb2 Author: Alexander Lobakin Date: Tue Jun 23 16:51:34 2020 +0300 net: qede: fix PTP initialization on recovery [ Upstream commit 1c85f394c2206ea3835f43534d5675f0574e1b70 ] Currently PTP cyclecounter and timecounter are initialized only on the first probing and are cleaned up during removal. This means that PTP becomes non-functional after device recovery. Fix this by unconditional PTP initialization on probing and clearing Tx pending bit on exiting. Fixes: ccc67ef50b90 ("qede: Error recovery process") Signed-off-by: Alexander Lobakin Signed-off-by: Igor Russkikh Signed-off-by: Michal Kalderon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7180c8fc4a03f8120f8ece1c165b797f1f752ec6 Author: Alexander Lobakin Date: Tue Jun 23 16:51:33 2020 +0300 net: qed: fix excessive QM ILT lines consumption [ Upstream commit d434d02f7e7c24c721365fd594ed781acb18e0da ] This is likely a copy'n'paste mistake. The amount of ILT lines to reserve for a single VF was being multiplied by the total VFs count. This led to a huge redundancy in reservation and potential lines drainouts. Fixes: 1408cc1fa48c ("qed: Introduce VFs") Signed-off-by: Alexander Lobakin Signed-off-by: Igor Russkikh Signed-off-by: Michal Kalderon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 32cf4ff4ec523a4551155978498512b186c47943 Author: Alexander Lobakin Date: Tue Jun 23 16:51:32 2020 +0300 net: qed: fix NVMe login fails over VFs [ Upstream commit ccd7c7ce167a21dbf2b698ffcf00f11d96d44f9b ] 25ms sleep cycles in waiting for PF response are excessive and may lead to different timeout failures. Start to wait with short udelays, and in most cases polling will end here. If the time was not sufficient, switch to msleeps. usleep_range() may go far beyond 100us depending on platform and tick configuration, hence atomic udelays for consistency. Also add explicit DMA barriers since 'done' always comes from a shared request-response DMA pool, and note that in the comment nearby. Fixes: 1408cc1fa48c ("qed: Introduce VFs") Signed-off-by: Alexander Lobakin Signed-off-by: Igor Russkikh Signed-off-by: Michal Kalderon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d0717a95a06b5671551c70aacc5d784992f70c8b Author: Alexander Lobakin Date: Tue Jun 23 16:51:31 2020 +0300 net: qede: stop adding events on an already destroyed workqueue [ Upstream commit 4079c7f7a2a00ab403c177ce723b560de59139c3 ] Set rdma_wq pointer to NULL after destroying the workqueue and check for it when adding new events to fix crashes on driver unload. Fixes: cee9fbd8e2e9 ("qede: Add qedr framework") Signed-off-by: Alexander Lobakin Signed-off-by: Igor Russkikh Signed-off-by: Michal Kalderon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 164d9a15652f2f03aad22091709756b4b9fea8d8 Author: Alexander Lobakin Date: Tue Jun 23 16:51:30 2020 +0300 net: qed: fix async event callbacks unregistering [ Upstream commit 31333c1a2521ff4b4ceb0c29de492549cd4a8de3 ] qed_spq_unregister_async_cb() should be called before qed_rdma_info_free() to avoid crash-spawning uses-after-free. Instead of calling it from each subsystem exit code, do it in one place on PF down. Fixes: 291d57f67d24 ("qed: Fix rdma_info structure allocation") Signed-off-by: Alexander Lobakin Signed-off-by: Igor Russkikh Signed-off-by: Michal Kalderon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5cf7f0c68405ec6d08b9e45eb9cb072876537793 Author: Alexander Lobakin Date: Tue Jun 23 16:51:29 2020 +0300 net: qed: fix left elements count calculation [ Upstream commit 97dd1abd026ae4e6a82fa68645928404ad483409 ] qed_chain_get_element_left{,_u32} returned 0 when the difference between producer and consumer page count was equal to the total page count. Fix this by conditional expanding of producer value (vs unconditional). This allowed to eliminate normalizaton against total page count, which was the cause of this bug. Misc: replace open-coded constants with common defines. Fixes: a91eb52abb50 ("qed: Revisit chain implementation") Signed-off-by: Alexander Lobakin Signed-off-by: Igor Russkikh Signed-off-by: Michal Kalderon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 33104571648b400ec211025f57c2d10b5ccc04a5 Author: Lu Baolu Date: Tue Jun 23 07:13:44 2020 +0800 iommu/vt-d: Update scalable mode paging structure coherency [ Upstream commit 04c00956ee3cd138fd38560a91452a804a8c5550 ] The Scalable-mode Page-walk Coherency (SMPWC) field in the VT-d extended capability register indicates the hardware coherency behavior on paging structures accessed through the pasid table entry. This is ignored in current code and using ECAP.C instead which is only valid in legacy mode. Fix this so that paging structure updates could be manually flushed from the cache line if hardware page walking is not snooped. Fixes: 765b6a98c1de3 ("iommu/vt-d: Enumerate the scalable mode capability") Signed-off-by: Lu Baolu Cc: Ashok Raj Cc: Kevin Tian Cc: Jacob Pan Link: https://lore.kernel.org/r/20200622231345.29722-6-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit ede796e5ac870aa0badb474678eb7752d3208d7f Author: Lu Baolu Date: Tue Jun 23 07:13:43 2020 +0800 iommu/vt-d: Enable PCI ACS for platform opt in hint [ Upstream commit 50310600ebda74b9988467e2e6128711c7ba56fc ] PCI ACS is disabled if Intel IOMMU is off by default or intel_iommu=off is used in command line. Unfortunately, Intel IOMMU will be forced on if there're devices sitting on an external facing PCI port that is marked as untrusted (for example, thunderbolt peripherals). That means, PCI ACS is disabled while Intel IOMMU is forced on to isolate those devices. As the result, the devices of an MFD will be grouped by a single group even the ACS is supported on device. [ 0.691263] pci 0000:00:07.1: Adding to iommu group 3 [ 0.691277] pci 0000:00:07.2: Adding to iommu group 3 [ 0.691292] pci 0000:00:07.3: Adding to iommu group 3 Fix it by requesting PCI ACS when Intel IOMMU is detected with platform opt in hint. Fixes: 89a6079df791a ("iommu/vt-d: Force IOMMU on for platform opt in hint") Co-developed-by: Lalithambika Krishnakumar Signed-off-by: Lalithambika Krishnakumar Signed-off-by: Lu Baolu Reviewed-by: Mika Westerberg Cc: Mika Westerberg Cc: Ashok Raj Link: https://lore.kernel.org/r/20200622231345.29722-5-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 67db9e032b6e5db640e643375c43c82af34a02a6 Author: Willem de Bruijn Date: Thu Jun 18 12:40:43 2020 -0400 selftests/net: report etf errors correctly [ Upstream commit ca8826095e4d4afc0ccaead27bba6e4b623a12ae ] The ETF qdisc can queue skbs that it could not pace on the errqueue. Address a few issues in the selftest - recv buffer size was too small, and incorrectly calculated - compared errno to ee_code instead of ee_errno - missed invalid request error type v2: - fix a few checkpatch --strict indentation warnings Fixes: ea6a547669b3 ("selftests/net: make so_txtime more robust to timer variance") Signed-off-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 34f45567462d07f697e9a4ec6a0c8c374f432b83 Author: Fan Guo Date: Fri Jun 12 14:38:24 2020 +0800 RDMA/mad: Fix possible memory leak in ib_mad_post_receive_mads() [ Upstream commit a17f4bed811c60712d8131883cdba11a105d0161 ] If ib_dma_mapping_error() returns non-zero value, ib_mad_post_receive_mads() will jump out of loops and return -ENOMEM without freeing mad_priv. Fix this memory-leak problem by freeing mad_priv in this case. Fixes: 2c34e68f4261 ("IB/mad: Check and handle potential DMA mapping errors") Link: https://lore.kernel.org/r/20200612063824.180611-1-guofan5@huawei.com Signed-off-by: Fan Guo Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit d3edf648f39833a31c8b584c64a6d7f05cad6a6f Author: Julian Wiedmann Date: Wed Jun 17 16:54:52 2020 +0200 s390/qeth: fix error handling for isolation mode cmds [ Upstream commit e2dfcfba00ba4a414617ef4c5a8501fe21567eb3 ] Current(?) OSA devices also store their cmd-specific return codes for SET_ACCESS_CONTROL cmds into the top-level cmd->hdr.return_code. So once we added stricter checking for the top-level field a while ago, none of the error logic that rolls back the user's configuration to its old state is applied any longer. For this specific cmd, go back to the old model where we peek into the cmd structure even though the top-level field indicated an error. Fixes: 686c97ee29c8 ("s390/qeth: fix error handling in adapter command callbacks") Signed-off-by: Julian Wiedmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9e89c2d5da87017f15f9be3c411023f917cd4e58 Author: Qiushi Wu Date: Sat Jun 13 15:51:58 2020 -0500 ASoC: rockchip: Fix a reference count leak. [ Upstream commit f141a422159a199f4c8dedb7e0df55b3b2cf16cd ] Calling pm_runtime_get_sync increments the counter even in case of failure, causing incorrect ref count if pm_runtime_put is not called in error handling paths. Call pm_runtime_put if pm_runtime_get_sync fails. Fixes: fc05a5b22253 ("ASoC: rockchip: add support for pdm controller") Signed-off-by: Qiushi Wu Reviewed-by: Heiko Stuebner Link: https://lore.kernel.org/r/20200613205158.27296-1-wu000273@umn.edu Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4aeb21584e550f20bc829c812f24764b9a0dbb09 Author: Mark Zhang Date: Tue Jun 16 13:43:04 2020 +0300 RDMA/cma: Protect bind_list and listen_list while finding matching cm id [ Upstream commit 730c8912484186d4623d0c76509066d285c3a755 ] The bind_list and listen_list must be accessed under a lock, add the missing locking around the access in cm_ib_id_from_event() In addition add lockdep asserts to make it clearer what the locking semantic is here. general protection fault: 0000 [#1] SMP NOPTI CPU: 226 PID: 126135 Comm: kworker/226:1 Tainted: G OE 4.12.14-150.47-default #1 SLE15 Hardware name: Cray Inc. Windom/Windom, BIOS 0.8.7 01-10-2020 Workqueue: ib_cm cm_work_handler [ib_cm] task: ffff9c5a60a1d2c0 task.stack: ffffc1d91f554000 RIP: 0010:cma_ib_req_handler+0x3f1/0x11b0 [rdma_cm] RSP: 0018:ffffc1d91f557b40 EFLAGS: 00010286 RAX: deacffffffffff30 RBX: 0000000000000001 RCX: ffff9c2af5bb6000 RDX: 00000000000000a9 RSI: ffff9c5aa4ed2f10 RDI: ffffc1d91f557b08 RBP: ffffc1d91f557d90 R08: ffff9c340cc80000 R09: ffff9c2c0f901900 R10: 0000000000000000 R11: 0000000000000001 R12: deacffffffffff30 R13: ffff9c5a48aeec00 R14: ffffc1d91f557c30 R15: ffff9c5c2eea3688 FS: 0000000000000000(0000) GS:ffff9c5c2fa80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00002b5cc03fa320 CR3: 0000003f8500a000 CR4: 00000000003406e0 Call Trace: ? rdma_addr_cancel+0xa0/0xa0 [ib_core] ? cm_process_work+0x28/0x140 [ib_cm] cm_process_work+0x28/0x140 [ib_cm] ? cm_get_bth_pkey.isra.44+0x34/0xa0 [ib_cm] cm_work_handler+0xa06/0x1a6f [ib_cm] ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x40/0x70 ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x40/0x70 ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x40/0x70 ? __switch_to+0x7c/0x4b0 ? __switch_to_asm+0x40/0x70 ? __switch_to_asm+0x34/0x70 process_one_work+0x1da/0x400 worker_thread+0x2b/0x3f0 ? process_one_work+0x400/0x400 kthread+0x118/0x140 ? kthread_create_on_node+0x40/0x40 ret_from_fork+0x22/0x40 Code: 00 66 83 f8 02 0f 84 ca 05 00 00 49 8b 84 24 d0 01 00 00 48 85 c0 0f 84 68 07 00 00 48 2d d0 01 00 00 49 89 c4 0f 84 59 07 00 00 <41> 0f b7 44 24 20 49 8b 77 50 66 83 f8 0a 75 9e 49 8b 7c 24 28 Fixes: 4c21b5bcef73 ("IB/cma: Add net_dev and private data checks to RDMA CM") Link: https://lore.kernel.org/r/20200616104304.2426081-1-leon@kernel.org Signed-off-by: Mark Zhang Reviewed-by: Maor Gottlieb Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit f0078dc6750fe46c7955de081b05cbf7d00d9093 Author: Michal Kalderon Date: Tue Jun 16 12:34:08 2020 +0300 RDMA/qedr: Fix KASAN: use-after-free in ucma_event_handler+0x532 [ Upstream commit 0dfbd5ecf28cbcb81674c49d34ee97366db1be44 ] Private data passed to iwarp_cm_handler is copied for connection request / response, but ignored otherwise. If junk is passed, it is stored in the event and used later in the event processing. The driver passes an old junk pointer during connection close which leads to a use-after-free on event processing. Set private data to NULL for events that don 't have private data. BUG: KASAN: use-after-free in ucma_event_handler+0x532/0x560 [rdma_ucm] kernel: Read of size 4 at addr ffff8886caa71200 by task kworker/u128:1/5250 kernel: kernel: Workqueue: iw_cm_wq cm_work_handler [iw_cm] kernel: Call Trace: kernel: dump_stack+0x8c/0xc0 kernel: print_address_description.constprop.0+0x1b/0x210 kernel: ? ucma_event_handler+0x532/0x560 [rdma_ucm] kernel: ? ucma_event_handler+0x532/0x560 [rdma_ucm] kernel: __kasan_report.cold+0x1a/0x33 kernel: ? ucma_event_handler+0x532/0x560 [rdma_ucm] kernel: kasan_report+0xe/0x20 kernel: check_memory_region+0x130/0x1a0 kernel: memcpy+0x20/0x50 kernel: ucma_event_handler+0x532/0x560 [rdma_ucm] kernel: ? __rpc_execute+0x608/0x620 [sunrpc] kernel: cma_iw_handler+0x212/0x330 [rdma_cm] kernel: ? iw_conn_req_handler+0x6e0/0x6e0 [rdma_cm] kernel: ? enqueue_timer+0x86/0x140 kernel: ? _raw_write_lock_irq+0xd0/0xd0 kernel: cm_work_handler+0xd3d/0x1070 [iw_cm] Fixes: e411e0587e0d ("RDMA/qedr: Add iWARP connection management functions") Link: https://lore.kernel.org/r/20200616093408.17827-1-michal.kalderon@marvell.com Signed-off-by: Ariel Elior Signed-off-by: Michal Kalderon Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 66143ecb9e3cfb1428b1b82feec35178e6ece844 Author: Aditya Pakki Date: Sat Jun 13 23:11:48 2020 -0500 RDMA/rvt: Fix potential memory leak caused by rvt_alloc_rq [ Upstream commit 90a239ee25fa3a483facec3de7c144361a3d3a51 ] In case of failure of alloc_ud_wq_attr(), the memory allocated by rvt_alloc_rq() is not freed. Fix it by calling rvt_free_rq() using the existing clean-up code. Fixes: d310c4bf8aea ("IB/{rdmavt, hfi1, qib}: Remove AH refcount for UD QPs") Link: https://lore.kernel.org/r/20200614041148.131983-1-pakki001@umn.edu Signed-off-by: Aditya Pakki Acked-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit d6fb7f457456b528804b4c21fd8e781b18519cde Author: David Howells Date: Wed Jun 17 23:01:23 2020 +0100 rxrpc: Fix handling of rwind from an ACK packet [ Upstream commit a2ad7c21ad8cf1ce4ad65e13df1c2a1c29b38ac5 ] The handling of the receive window size (rwind) from a received ACK packet is not correct. The rxrpc_input_ackinfo() function currently checks the current Tx window size against the rwind from the ACK to see if it has changed, but then limits the rwind size before storing it in the tx_winsize member and, if it increased, wake up the transmitting process. This means that if rwind > RXRPC_RXTX_BUFF_SIZE - 1, this path will always be followed. Fix this by limiting rwind before we compare it to tx_winsize. The effect of this can be seen by enabling the rxrpc_rx_rwind_change tracepoint. Fixes: 702f2ac87a9a ("rxrpc: Wake up the transmitter if Rx window size increases on the peer") Signed-off-by: David Howells Signed-off-by: Sasha Levin commit 73cff44e66e3552ace8f985a4f0e021f0e1278e3 Author: Matthew Hagan Date: Sun Jun 14 15:19:00 2020 -0700 ARM: dts: NSP: Correct FA2 mailbox node [ Upstream commit ac4e106d8934a5894811fc263f4b03fc8ed0fb7a ] The FA2 mailbox is specified at 0x18025000 but should actually be 0x18025c00, length 0x400 according to socregs_nsp.h and board_bu.c. Also the interrupt was off by one and should be GIC SPI 151 instead of 150. Fixes: 17d517172300 ("ARM: dts: NSP: Add mailbox (PDC) to NSP") Signed-off-by: Matthew Hagan Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit f1ee7d3a2c1ab17802321879c9a62ca690e71ab9 Author: Stanislav Fomichev Date: Tue Jun 16 18:04:14 2020 -0700 bpf: Don't return EINVAL from {get,set}sockopt when optlen > PAGE_SIZE [ Upstream commit d8fe449a9c51a37d844ab607e14e2f5c657d3cf2 ] Attaching to these hooks can break iptables because its optval is usually quite big, or at least bigger than the current PAGE_SIZE limit. David also mentioned some SCTP options can be big (around 256k). For such optvals we expose only the first PAGE_SIZE bytes to the BPF program. BPF program has two options: 1. Set ctx->optlen to 0 to indicate that the BPF's optval should be ignored and the kernel should use original userspace value. 2. Set ctx->optlen to something that's smaller than the PAGE_SIZE. v5: * use ctx->optlen == 0 with trimmed buffer (Alexei Starovoitov) * update the docs accordingly v4: * use temporary buffer to avoid optval == optval_end == NULL; this removes the corner case in the verifier that might assume non-zero PTR_TO_PACKET/PTR_TO_PACKET_END. v3: * don't increase the limit, bypass the argument v2: * proper comments formatting (Jakub Kicinski) Fixes: 0d01da6afc54 ("bpf: implement getsockopt and setsockopt hooks") Signed-off-by: Stanislav Fomichev Signed-off-by: Alexei Starovoitov Cc: David Laight Link: https://lore.kernel.org/bpf/20200617010416.93086-1-sdf@google.com Signed-off-by: Sasha Levin commit 0f3aa6c6d6adf4578164e9c5b164dd6e4d6b4800 Author: Toke Høiland-Jørgensen Date: Tue Jun 16 16:28:29 2020 +0200 devmap: Use bpf_map_area_alloc() for allocating hash buckets [ Upstream commit 99c51064fb06146b3d494b745c947e438a10aaa7 ] Syzkaller discovered that creating a hash of type devmap_hash with a large number of entries can hit the memory allocator limit for allocating contiguous memory regions. There's really no reason to use kmalloc_array() directly in the devmap code, so just switch it to the existing bpf_map_area_alloc() function that is used elsewhere. Fixes: 6f9d451ab1a3 ("xdp: Add devmap_hash map type for looking up devices by hashed index") Reported-by: Xiumei Mu Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200616142829.114173-1-toke@redhat.com Signed-off-by: Sasha Levin commit b93df0f6d7cdabe69d91720e5b799001f2667dcc Author: Charles Keepax Date: Wed Jun 17 16:21:29 2020 +0100 regmap: Fix memory leak from regmap_register_patch [ Upstream commit 95b2c3ec4cb1689db2389c251d39f64490ba641c ] When a register patch is registered the reg_sequence is copied but the memory allocated is never freed. Add a kfree in regmap_exit to clean it up. Fixes: 22f0d90a3482 ("regmap: Support register patch sets") Signed-off-by: Charles Keepax Link: https://lore.kernel.org/r/20200617152129.19655-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5f6b834e110bc44171acdb8f9258d42813ff548f Author: Dan Carpenter Date: Tue Jun 2 22:36:11 2020 +0300 x86/resctrl: Fix a NULL vs IS_ERR() static checker warning in rdt_cdp_peer_get() [ Upstream commit cc5277fe66cf3ad68f41f1c539b2ef0d5e432974 ] The callers don't expect *d_cdp to be set to an error pointer, they only check for NULL. This leads to a static checker warning: arch/x86/kernel/cpu/resctrl/rdtgroup.c:2648 __init_one_rdt_domain() warn: 'd_cdp' could be an error pointer This would not trigger a bug in this specific case because __init_one_rdt_domain() calls it with a valid domain that would not have a negative id and thus not trigger the return of the ERR_PTR(). If this was a negative domain id then the call to rdt_find_domain() in domain_add_cpu() would have returned the ERR_PTR() much earlier and the creation of the domain with an invalid id would have been prevented. Even though a bug is not triggered currently the right and safe thing to do is to set the pointer to NULL because that is what can be checked for when the caller is handling the CDP and non-CDP cases. Fixes: 52eb74339a62 ("x86/resctrl: Fix rdt_find_domain() return value and checks") Signed-off-by: Dan Carpenter Signed-off-by: Borislav Petkov Acked-by: Reinette Chatre Acked-by: Fenghua Yu Link: https://lkml.kernel.org/r/20200602193611.GA190851@mwanda Signed-off-by: Sasha Levin commit 99ab61cc8b75566899bd61864f0ff9b7f6eef41e Author: Tony Lindgren Date: Fri Jun 12 10:19:50 2020 -0700 ARM: dts: Fix duovero smsc interrupt for suspend [ Upstream commit 9cf28e41f9f768791f54ee18333239fda6927ed8 ] While testing the recent suspend and resume regressions I noticed that duovero can still end up losing edge gpio interrupts on runtime suspend. This causes NFSroot easily stopping working after resume on duovero. Let's fix the issue by using gpio level interrupts for smsc as then the gpio interrupt state is seen by the gpio controller on resume. Fixes: 731b409878a3 ("ARM: dts: Configure duovero for to allow core retention during idle") Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 07f7c547698b1590288af8b33e4c9a19c341bdb8 Author: Drew Fustini Date: Tue Jun 9 23:45:21 2020 +0200 ARM: dts: am335x-pocketbeagle: Fix mmc0 Write Protect [ Upstream commit d7af722344e6dc52d87649100516515263e15c75 ] AM3358 pin mcasp0_aclkr (ZCZ ball B13) [0] is routed to P1.31 header [1] Mode 4 of this pin is mmc0_sdwp (SD Write Protect). A signal connected to P1.31 may accidentally trigger mmc0 write protection. To avoid this situation, do not put mcasp0_aclkr in mode 4 (mmc0_sdwp) by default. [0] http://www.ti.com/lit/ds/symlink/am3358.pdf [1] https://github.com/beagleboard/pocketbeagle/wiki/System-Reference-Manual#531_Expansion_Headers Fixes: 047905376a16 (ARM: dts: Add am335x-pocketbeagle) Signed-off-by: Robert Nelson Signed-off-by: Drew Fustini Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit d909f9db0caa2e7a582cc47f8366743e0873efcc Author: Gaurav Singh Date: Fri Jun 12 14:53:27 2020 -0400 bpf, xdp, samples: Fix null pointer dereference in *_user code [ Upstream commit 6903cdae9f9f08d61e49c16cbef11c293e33a615 ] Memset on the pointer right after malloc can cause a NULL pointer deference if it failed to allocate memory. A simple fix is to replace malloc()/memset() pair with a simple call to calloc(). Fixes: 0fca931a6f21 ("samples/bpf: program demonstrating access to xdp_rxq_info") Signed-off-by: Gaurav Singh Signed-off-by: Daniel Borkmann Acked-by: Jesper Dangaard Brouer Acked-by: John Fastabend Signed-off-by: Sasha Levin commit 0608288c6caab98e7819dd017b4a8818819ddfed Author: Lorenzo Bianconi Date: Tue May 12 18:30:40 2020 +0200 samples/bpf: xdp_redirect_cpu: Set MAX_CPUS according to NR_CPUS [ Upstream commit 6a09815428547657f3ffd2f5c31ac2a191e7fdf3 ] xdp_redirect_cpu is currently failing in bpf_prog_load_xattr() allocating cpu_map map if CONFIG_NR_CPUS is less than 64 since cpu_map_alloc() requires max_entries to be less than NR_CPUS. Set cpu_map max_entries according to NR_CPUS in xdp_redirect_cpu_kern.c and get currently running cpus in xdp_redirect_cpu_user.c Signed-off-by: Lorenzo Bianconi Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/374472755001c260158c4e4b22f193bdd3c56fb7.1589300442.git.lorenzo@kernel.org Signed-off-by: Sasha Levin commit b59ed5668c4ef162c9357317e889c8cfc96f3477 Author: Shengjiu Wang Date: Tue Jun 16 10:53:48 2020 +0800 ASoC: fsl_ssi: Fix bclk calculation for mono channel [ Upstream commit ed1220df6e666500ebf58c4f2fccc681941646fb ] For mono channel, SSI will switch to Normal mode. In Normal mode and Network mode, the Word Length Control bits control the word length divider in clock generator, which is different with I2S Master mode (the word length is fixed to 32bit), it should be the value of params_width(hw_params). The condition "slots == 2" is not good for I2S Master mode, because for Network mode and Normal mode, the slots can also be 2. Then we need to use (ssi->i2s_net & SSI_SCR_I2S_MODE_MASK) to check if it is I2S Master mode. So we refine the formula for mono channel, otherwise there will be sound issue for S24_LE. Fixes: b0a7043d5c2c ("ASoC: fsl_ssi: Caculate bit clock rate using slot number and width") Signed-off-by: Shengjiu Wang Reviewed-by: Nicolin Chen Link: https://lore.kernel.org/r/034eff1435ff6ce300b6c781130cefd9db22ab9a.1592276147.git.shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3947dd237ef56dc303f379f4127f321c043124bf Author: Tom Seewald Date: Wed Jun 10 12:47:17 2020 -0500 RDMA/siw: Fix pointer-to-int-cast warning in siw_rx_pbl() [ Upstream commit 6769b275a313c76ddcd7d94c632032326db5f759 ] The variable buf_addr is type dma_addr_t, which may not be the same size as a pointer. To ensure it is the correct size, cast to a uintptr_t. Fixes: c536277e0db1 ("RDMA/siw: Fix 64/32bit pointer inconsistency") Link: https://lore.kernel.org/r/20200610174717.15932-1-tseewald@gmail.com Signed-off-by: Tom Seewald Reviewed-by: Bernard Metzler Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 34f105349369095b1f75e4cc422b674456d171ca Author: Robin Gong Date: Mon Jun 15 05:54:08 2020 +0800 regualtor: pfuze100: correct sw1a/sw2 on pfuze3000 [ Upstream commit 6f1cf5257acc6e6242ddf2f52bc7912aed77b79f ] PFUZE100_SWB_REG is not proper for sw1a/sw2, because enable_mask/enable_reg is not correct. On PFUZE3000, sw1a/sw2 should be the same as sw1a/sw2 on pfuze100 except that voltages are not linear, so add new PFUZE3000_SW_REG and pfuze3000_sw_regulator_ops which like the non-linear PFUZE100_SW_REG and pfuze100_sw_regulator_ops. Fixes: 1dced996ee70 ("regulator: pfuze100: update voltage setting for pfuze3000 sw1a") Reported-by: Christophe Meynard Signed-off-by: Robin Gong Link: https://lore.kernel.org/r/1592171648-8752-1-git-send-email-yibin.gong@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1fa27418054f74b428035ed228af18865be6df0b Author: Srinivas Kandagatla Date: Fri Jun 12 13:37:11 2020 +0100 ASoC: qcom: common: set correct directions for dailinks [ Upstream commit a2120089251f1fe221305e88df99af16f940e236 ] Currently both FE and BE dai-links are configured bi-directional, However the DSP BE dais are only single directional, so set the directions as supported by the BE dais. Fixes: c25e295cd77b (ASoC: qcom: Add support to parse common audio device nodes) Reported-by: John Stultz Signed-off-by: Srinivas Kandagatla Tested-by: John Stultz Reviewed-by: Vinod Koul Link: https://lore.kernel.org/r/20200612123711.29130-2-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 47c7ae0ca9d7f96a53abbffdc4f00103253f82cb Author: Srinivas Kandagatla Date: Fri Jun 12 13:37:10 2020 +0100 ASoc: q6afe: add support to get port direction [ Upstream commit 4a95737440d426e93441d49d11abf4c6526d4666 ] This patch adds support to q6afe_is_rx_port() to get direction of DSP BE dai port, this is useful for setting dailink directions correctly. Fixes: c25e295cd77b (ASoC: qcom: Add support to parse common audio device nodes) Reported-by: John Stultz Signed-off-by: Srinivas Kandagatla Reviewed-by: Vinod Koul Link: https://lore.kernel.org/r/20200612123711.29130-1-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 92444a57e3656ac0c11972f2ace4b356ecb15795 Author: Qiushi Wu Date: Thu May 28 13:38:04 2020 -0500 efi/esrt: Fix reference count leak in esre_create_sysfs_entry. [ Upstream commit 4ddf4739be6e375116c375f0a68bf3893ffcee21 ] kobject_init_and_add() takes reference even when it fails. If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Previous commit "b8eb718348b8" fixed a similar problem. Fixes: 0bb549052d33 ("efi: Add esrt support") Signed-off-by: Qiushi Wu Link: https://lore.kernel.org/r/20200528183804.4497-1-wu000273@umn.edu Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit 8c236ac4376aa838f62fb86d21f73ffe1852b551 Author: Fabian Vogt Date: Mon Jun 15 09:16:36 2020 +0200 efi/tpm: Verify event log header before parsing [ Upstream commit 7dfc06a0f25b593a9f51992f540c0f80a57f3629 ] It is possible that the first event in the event log is not actually a log header at all, but rather a normal event. This leads to the cast in __calc_tpm2_event_size being an invalid conversion, which means that the values read are effectively garbage. Depending on the first event's contents, this leads either to apparently normal behaviour, a crash or a freeze. While this behaviour of the firmware is not in accordance with the TCG Client EFI Specification, this happens on a Dell Precision 5510 with the TPM enabled but hidden from the OS ("TPM On" disabled, state otherwise untouched). The EFI firmware claims that the TPM is present and active and that it supports the TCG 2.0 event log format. Fortunately, this can be worked around by simply checking the header of the first event and the event log header signature itself. Commit b4f1874c6216 ("tpm: check event log version before reading final events") addressed a similar issue also found on Dell models. Fixes: 6b0326190205 ("efi: Attempt to get the TCG2 event log in the boot stub") Signed-off-by: Fabian Vogt Link: https://lore.kernel.org/r/1927248.evlx2EsYKh@linux-e202.suse.de Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1165773 Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit e50cf858d118eb2c792b206ac26a2f9845321b20 Author: Srinivas Kandagatla Date: Thu Jun 11 13:41:53 2020 +0100 ASoC: q6asm: handle EOS correctly [ Upstream commit 6476b60f32866be49d05e2e0163f337374c55b06 ] Successful send of EOS command does not indicate that EOS is actually finished, correct event to wait EOS is finished is EOS_RENDERED event. EOS_RENDERED means that the DSP has finished processing all the buffers for that particular session and stream. This patch fixes EOS handling! Fixes: 68fd8480bb7b ("ASoC: qdsp6: q6asm: Add support to audio stream apis") Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20200611124159.20742-3-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 41b2debf35ef5bc5719971d2470b1b7ed876a3c2 Author: Huy Nguyen Date: Mon Jun 1 16:39:37 2020 -0500 xfrm: Fix double ESP trailer insertion in IPsec crypto offload. [ Upstream commit 94579ac3f6d0820adc83b5dc5358ead0158101e9 ] During IPsec performance testing, we see bad ICMP checksum. The error packet has duplicated ESP trailer due to double validate_xmit_xfrm calls. The first call is from ip_output, but the packet cannot be sent because netif_xmit_frozen_or_stopped is true and the packet gets dev_requeue_skb. The second call is from NET_TX softirq. However after the first call, the packet already has the ESP trailer. Fix by marking the skb with XFRM_XMIT bit after the packet is handled by validate_xmit_xfrm to avoid duplicate ESP trailer insertion. Fixes: f6e27114a60a ("net: Add a xfrm validate function to validate_xmit_skb") Signed-off-by: Huy Nguyen Reviewed-by: Boris Pismenny Reviewed-by: Raed Salem Reviewed-by: Saeed Mahameed Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 475a7b09b4bbc9a3801c60c3ac8375d142ed3def Author: Tony Lindgren Date: Wed May 27 16:32:06 2020 -0700 ARM: OMAP2+: Fix legacy mode dss_reset [ Upstream commit 77cad9dbc957f23a73169e8a8971186744296614 ] We must check for "dss_core" instead of "dss" to avoid also matching also "dss_dispc". This only matters for the mixed case of data configured in device tree but with legacy booting ti,hwmods property still enabled. Fixes: 8b30919a4e3c ("ARM: OMAP2+: Handle reset quirks for dynamically allocated modules") Cc: Laurent Pinchart Cc: Tomi Valkeinen Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 527ddb339d6b8770b87a962cbc61e96932f32a9c Author: Tony Lindgren Date: Sun May 31 12:37:54 2020 -0700 bus: ti-sysc: Ignore clockactivity unless specified as a quirk [ Upstream commit 08b91dd6e547467fad61a7c201ff71080d7ad65a ] We must ignore the clockactivity bit for most modules and not set it unless specified for the module with SYSC_QUIRK_USE_CLOCKACT. Otherwise the interface clock can be automatically gated constantly causing unexpected performance issues. Fixes: ae9ae12e9daa ("bus: ti-sysc: Handle clockactivity for enable and disable") Cc: Laurent Pinchart Cc: Tomi Valkeinen Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 1f5197a5ad973c9a5511c1d4f27c9dea4ec5dcad Author: Tony Lindgren Date: Wed May 27 06:49:29 2020 -0700 bus: ti-sysc: Flush posted write on enable and disable [ Upstream commit 5ce8aee81be6c8bc19051d7c7b0d3cbb7ac5fc3f ] Looks like we're missing flush of posted write after module enable and disable. I've seen occasional errors accessing various modules, and it is suspected that the lack of posted writes can also cause random reboots. The errors we can see are similar to the one below from spi for example: 44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4CFG (Read): Data Access in User mode during Functional access ... mcspi_wait_for_reg_bit omap2_mcspi_transfer_one spi_transfer_one_message ... We also want to also flush posted write for disable. The clkctrl clock disable happens after module disable, and we don't want to have the module potentially stay active while we're trying to disable the clock. Fixes: d59b60564cbf ("bus: ti-sysc: Add generic enable/disable functions") Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 21d511c6c9c25bd45acfafd9768027394a0fddb3 Author: Dennis Dalessandro Date: Tue Jun 23 16:32:30 2020 -0400 IB/hfi1: Fix module use count flaw due to leftover module put calls commit 822fbd37410639acdae368ea55477ddd3498651d upstream. When the try_module_get calls were removed from opening and closing of the i2c debugfs file, the corresponding module_put calls were missed. This results in an inaccurate module use count that requires a power cycle to fix. Fixes: 09fbca8e6240 ("IB/hfi1: No need to use try_module_get for debugfs") Link: https://lore.kernel.org/r/20200623203230.106975.76240.stgit@awfm-01.aw.intel.com Cc: Reviewed-by: Kaike Wan Reviewed-by: Mike Marciniszyn Signed-off-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 2a4c0bf5c70eabd2b1f6f730a32bcad53e860085 Author: Shay Drory Date: Sun Jun 21 13:47:35 2020 +0300 IB/mad: Fix use after free when destroying MAD agent commit 116a1b9f1cb769b83e5adff323f977a62b1dcb2e upstream. Currently, when RMPP MADs are processed while the MAD agent is destroyed, it could result in use after free of rmpp_recv, as decribed below: cpu-0 cpu-1 ----- ----- ib_mad_recv_done() ib_mad_complete_recv() ib_process_rmpp_recv_wc() unregister_mad_agent() ib_cancel_rmpp_recvs() cancel_delayed_work() process_rmpp_data() start_rmpp() queue_delayed_work(rmpp_recv->cleanup_work) destroy_rmpp_recv() free_rmpp_recv() cleanup_work()[1] spin_lock_irqsave(&rmpp_recv->agent->lock) <-- use after free [1] cleanup_work() == recv_cleanup_handler Fix it by waiting for the MAD agent reference count becoming zero before calling to ib_cancel_rmpp_recvs(). Fixes: 9a41e38a467c ("IB/mad: Use IDR for agent IDs") Link: https://lore.kernel.org/r/20200621104738.54850-2-leon@kernel.org Signed-off-by: Shay Drory Reviewed-by: Maor Gottlieb Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 588ad2b29ea3d4fe95da5ae161b370b539e16382 Author: Zheng Bin Date: Thu Jun 18 12:21:37 2020 +0800 loop: replace kill_bdev with invalidate_bdev commit f4bd34b139a3fa2808c4205f12714c65e1548c6c upstream. When a filesystem is mounted on a loop device and on a loop ioctl LOOP_SET_STATUS64, because of kill_bdev, buffer_head mappings are getting destroyed. kill_bdev truncate_inode_pages truncate_inode_pages_range do_invalidatepage block_invalidatepage discard_buffer -->clear BH_Mapped flag sb_bread __bread_gfp bh = __getblk_gfp -->discard_buffer clear BH_Mapped flag __bread_slow submit_bh submit_bh_wbc BUG_ON(!buffer_mapped(bh)) --> hit this BUG_ON Fixes: 5db470e229e2 ("loop: drop caches if offset or block_size are changed") Signed-off-by: Zheng Bin Reviewed-by: Christoph Hellwig Reviewed-by: Bart Van Assche Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit d9a74e455070cf95a845cd153f44d915fa110da5 Author: Joakim Tjernlund Date: Fri Jun 5 12:54:18 2020 +0200 cdc-acm: Add DISABLE_ECHO quirk for Microchip/SMSC chip commit 03894573f2913181ee5aae0089f333b2131f2d4b upstream. USB_DEVICE(0x0424, 0x274e) can send data before cdc_acm is ready, causing garbage chars on the TTY causing stray input to the shell and/or login prompt. Signed-off-by: Joakim Tjernlund Cc: stable@vger.kernel.org Acked-by: Oliver Neukum Link: https://lore.kernel.org/r/20200605105418.22263-1-joakim.tjernlund@infinera.com Signed-off-by: Greg Kroah-Hartman commit d6522bc320d7968a7977c30b6f2f3c6d79f1448f Author: Kai-Heng Feng Date: Wed Jun 24 16:59:48 2020 +0300 xhci: Return if xHCI doesn't support LPM commit f0c472a6da51f9fac15e80fe2fd9c83b68754cff upstream. Just return if xHCI is quirked to disable LPM. We can save some time from reading registers and doing spinlocks. Add stable tag as we want this patch together with the next one, "Poll for U0 after disabling USB2 LPM" which fixes a suspend issue for some USB2 LPM devices Cc: stable@vger.kernel.org Signed-off-by: Kai-Heng Feng Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20200624135949.22611-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 14d46386226e102e43ee535ac74306b7489180b0 Author: Al Cooper Date: Wed Jun 24 16:59:46 2020 +0300 xhci: Fix enumeration issue when setting max packet size for FS devices. commit a73d9d9cfc3cfceabd91fb0b0c13e4062b6dbcd7 upstream. Unable to complete the enumeration of a USB TV Tuner device. Per XHCI spec (4.6.5), the EP state field of the input context shall be cleared for a set address command. In the special case of an FS device that has "MaxPacketSize0 = 8", the Linux XHCI driver does not do this before evaluating the context. With an XHCI controller that checks the EP state field for parameter context error this causes a problem in cases such as the device getting reset again after enumeration. When that field is cleared, the problem does not occur. This was found and fixed by Sasi Kumar. Cc: stable@vger.kernel.org Signed-off-by: Al Cooper Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20200624135949.22611-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit c09be4f57956deae7b9dbee3a35811a2a9c45d99 Author: Mathias Nyman Date: Wed Jun 24 16:59:45 2020 +0300 xhci: Fix incorrect EP_STATE_MASK commit dceea67058fe22075db3aed62d5cb62092be5053 upstream. EP_STATE_MASK should be 0x7 instead of 0xf xhci spec 6.2.3 shows that the EP state field in the endpoint context data structure consist of bits [2:0]. The old value included a bit from the next field which fortunately is a RsvdZ region. So hopefully this hasn't caused too much harm Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20200624135949.22611-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit e615f58fa86c3aa4a6f7f56df77c654bc92323de Author: Zhang Xiaoxu Date: Tue Jun 23 07:31:54 2020 -0400 cifs/smb3: Fix data inconsistent when zero file range commit 6b69040247e14b43419a520f841f2b3052833df9 upstream. CIFS implements the fallocate(FALLOC_FL_ZERO_RANGE) with send SMB ioctl(FSCTL_SET_ZERO_DATA) to server. It just set the range of the remote file to zero, but local page cache not update, then the data inconsistent with server, which leads the xfstest generic/008 failed. So we need to remove the local page caches before send SMB ioctl(FSCTL_SET_ZERO_DATA) to server. After next read, it will re-cache it. Fixes: 30175628bf7f5 ("[SMB3] Enable fallocate -z support for SMB3 mounts") Reported-by: Hulk Robot Signed-off-by: Zhang Xiaoxu Reviewed-by: Pavel Shilovsky Cc: stable@vger.kernel.org # v3.17 Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit bd2f2ac0ab96327a62a790f99116e7544a3fe0cf Author: Zhang Xiaoxu Date: Tue Jun 23 07:31:53 2020 -0400 cifs/smb3: Fix data inconsistent when punch hole commit acc91c2d8de4ef46ed751c5f9df99ed9a109b100 upstream. When punch hole success, we also can read old data from file: # strace -e trace=pread64,fallocate xfs_io -f -c "pread 20 40" \ -c "fpunch 20 40" -c"pread 20 40" file pread64(3, " version 5.8.0-rc1+"..., 40, 20) = 40 fallocate(3, FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE, 20, 40) = 0 pread64(3, " version 5.8.0-rc1+"..., 40, 20) = 40 CIFS implements the fallocate(FALLOCATE_FL_PUNCH_HOLE) with send SMB ioctl(FSCTL_SET_ZERO_DATA) to server. It just set the range of the remote file to zero, but local page caches not updated, then the local page caches inconsistent with server. Also can be found by xfstests generic/316. So, we need to remove the page caches before send the SMB ioctl(FSCTL_SET_ZERO_DATA) to server. Fixes: 31742c5a33176 ("enable fallocate punch hole ("fallocate -p") for SMB3") Suggested-by: Pavel Shilovsky Reviewed-by: Pavel Shilovsky Signed-off-by: Zhang Xiaoxu Cc: stable@vger.kernel.org # v3.17 Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 572a11131ad3ec7737dbf68828618025160bbd57 Author: Xiyu Yang Date: Sat Jun 13 20:27:09 2020 +0800 cifs: Fix cached_fid refcnt leak in open_shroot commit 77577de64167aa0643d47ffbaacf3642632b321b upstream. open_shroot() invokes kref_get(), which increases the refcount of the "tcon->crfid" object. When open_shroot() returns not zero, it means the open operation failed and close_shroot() will not be called to decrement the refcount of the "tcon->crfid". The reference counting issue happens in one normal path of open_shroot(). When the cached root have been opened successfully in a concurrent process, the function increases the refcount and jump to "oshr_free" to return. However the current return value "rc" may not equal to 0, thus the increased refcount will not be balanced outside the function, causing a refcnt leak. Fix this issue by setting the value of "rc" to 0 before jumping to "oshr_free" label. Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Signed-off-by: Steve French CC: Stable Signed-off-by: Greg Kroah-Hartman commit 1f551a056b30b898df6690078d0632e41fad6174 Author: Steffen Maier Date: Tue Jun 23 16:02:42 2020 +0200 scsi: zfcp: Fix panic on ERP timeout for previously dismissed ERP action commit 936e6b85da0476dd2edac7c51c68072da9fb4ba2 upstream. Suppose that, for unrelated reasons, FSF requests on behalf of recovery are very slow and can run into the ERP timeout. In the case at hand, we did adapter recovery to a large degree. However due to the slowness a LUN open is pending so the corresponding fc_rport remains blocked. After fast_io_fail_tmo we trigger close physical port recovery for the port under which the LUN should have been opened. The new higher order port recovery dismisses the pending LUN open ERP action and dismisses the pending LUN open FSF request. Such dismissal decouples the ERP action from the pending corresponding FSF request by setting zfcp_fsf_req->erp_action to NULL (among other things) [zfcp_erp_strategy_check_fsfreq()]. If now the ERP timeout for the pending open LUN request runs out, we must not use zfcp_fsf_req->erp_action in the ERP timeout handler. This is a problem since v4.15 commit 75492a51568b ("s390/scsi: Convert timers to use timer_setup()"). Before that we intentionally only passed zfcp_erp_action as context argument to zfcp_erp_timeout_handler(). Note: The lifetime of the corresponding zfcp_fsf_req object continues until a (late) response or an (unrelated) adapter recovery. Just like the regular response path ignores dismissed requests [zfcp_fsf_req_complete() => zfcp_fsf_protstatus_eval() => return early] the ERP timeout handler now needs to ignore dismissed requests. So simply return early in the ERP timeout handler if the FSF request is marked as dismissed in its status flags. To protect against the race where zfcp_erp_strategy_check_fsfreq() dismisses and sets zfcp_fsf_req->erp_action to NULL after our previous status flag check, return early if zfcp_fsf_req->erp_action is NULL. After all, the former ERP action does not need to be woken up as that was already done as part of the dismissal above [zfcp_erp_action_dismiss()]. This fixes the following panic due to kernel page fault in IRQ context: Unable to handle kernel pointer dereference in virtual kernel address space Failing address: 0000000000000000 TEID: 0000000000000483 Fault in home space mode while using kernel ASCE. AS:000009859238c00b R2:00000e3e7ffd000b R3:00000e3e7ffcc007 S:00000e3e7ffd7000 P:000000000000013d Oops: 0004 ilc:2 [#1] SMP Modules linked in: ... CPU: 82 PID: 311273 Comm: stress Kdump: loaded Tainted: G E X ... Hardware name: IBM 8561 T01 701 (LPAR) Krnl PSW : 0404c00180000000 001fffff80549be0 (zfcp_erp_notify+0x40/0xc0 [zfcp]) R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 Krnl GPRS: 0000000000000080 00000e3d00000000 00000000000000f0 0000000000030000 000000010028e700 000000000400a39c 000000010028e700 00000e3e7cf87e02 0000000010000000 0700098591cb67f0 0000000000000000 0000000000000000 0000033840e9a000 0000000000000000 001fffe008d6bc18 001fffe008d6bbc8 Krnl Code: 001fffff80549bd4: a7180000 lhi %r1,0 001fffff80549bd8: 4120a0f0 la %r2,240(%r10) #001fffff80549bdc: a53e0003 llilh %r3,3 >001fffff80549be0: ba132000 cs %r1,%r3,0(%r2) 001fffff80549be4: a7740037 brc 7,1fffff80549c52 001fffff80549be8: e320b0180004 lg %r2,24(%r11) 001fffff80549bee: e31020e00004 lg %r1,224(%r2) 001fffff80549bf4: 412020e0 la %r2,224(%r2) Call Trace: [<001fffff80549be0>] zfcp_erp_notify+0x40/0xc0 [zfcp] [<00000985915e26f0>] call_timer_fn+0x38/0x190 [<00000985915e2944>] expire_timers+0xfc/0x190 [<00000985915e2ac4>] run_timer_softirq+0xec/0x218 [<0000098591ca7c4c>] __do_softirq+0x144/0x398 [<00000985915110aa>] do_softirq_own_stack+0x72/0x88 [<0000098591551b58>] irq_exit+0xb0/0xb8 [<0000098591510c6a>] do_IRQ+0x82/0xb0 [<0000098591ca7140>] ext_int_handler+0x128/0x12c [<0000098591722d98>] clear_subpage.constprop.13+0x38/0x60 ([<000009859172ae4c>] clear_huge_page+0xec/0x250) [<000009859177e7a2>] do_huge_pmd_anonymous_page+0x32a/0x768 [<000009859172a712>] __handle_mm_fault+0x88a/0x900 [<000009859172a860>] handle_mm_fault+0xd8/0x1b0 [<0000098591529ef6>] do_dat_exception+0x136/0x3e8 [<0000098591ca6d34>] pgm_check_handler+0x1c8/0x220 Last Breaking-Event-Address: [<001fffff80549c88>] zfcp_erp_timeout_handler+0x10/0x18 [zfcp] Kernel panic - not syncing: Fatal exception in interrupt Link: https://lore.kernel.org/r/20200623140242.98864-1-maier@linux.ibm.com Fixes: 75492a51568b ("s390/scsi: Convert timers to use timer_setup()") Cc: #4.15+ Reviewed-by: Julian Wiedmann Signed-off-by: Steffen Maier Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit d3a251b8479767a396f89c360ae8ca92cd614cdf Author: Roman Bolshakov Date: Fri Jun 5 17:44:37 2020 +0300 scsi: qla2xxx: Keep initiator ports after RSCN commit 632f24f09d5b7c8a2f94932c3391ca957ae76cc4 upstream. The driver performs SCR (state change registration) in all modes including pure target mode. For each RSCN, scan_needed flag is set in qla2x00_handle_rscn() for the port mentioned in the RSCN and fabric rescan is scheduled. During the rescan, GNN_FT handler, qla24xx_async_gnnft_done() deletes session of the port that caused the RSCN. In target mode, the session deletion has an impact on ATIO handler, qlt_24xx_atio_pkt(). Target responds with SAM STATUS BUSY to I/O incoming from the deleted session. qlt_handle_cmd_for_atio() and qlt_handle_task_mgmt() return -EFAULT if they are not able to find session of the command/TMF, and that results in invocation of qlt_send_busy(): qlt_24xx_atio_pkt_all_vps: qla_target(0): type 6 ox_id 0014 qla_target(0): Unable to send command to target, sending BUSY status Such response causes command timeout on the initiator. Error handler thread on the initiator will be spawned to abort the commands: scsi 23:0:0:0: tag#0 abort scheduled scsi 23:0:0:0: tag#0 aborting command qla2xxx [0000:af:00.0]-188c:23: Entered qla24xx_abort_command. qla2xxx [0000:af:00.0]-801c:23: Abort command issued nexus=23:0:0 -- 0 2003. Command abort is rejected by target and fails (2003), error handler then tries to perform DEVICE RESET and TARGET RESET but they're also doomed to fail because TMFs are ignored for the deleted sessions. Then initiator makes BUS RESET that resets the link via qla2x00_full_login_lip(). BUS RESET succeeds and brings initiator port up, SAN switch detects that and sends RSCN to the target port and it fails again the same way as described above. It never goes out of the loop. The change breaks the RSCN loop by keeping initiator sessions mentioned in RSCN payload in all modes, including dual and pure target mode. Link: https://lore.kernel.org/r/20200605144435.27023-1-r.bolshakov@yadro.com Fixes: 2037ce49d30a ("scsi: qla2xxx: Fix stale session") Cc: Quinn Tran Cc: Arun Easi Cc: Nilesh Javali Cc: Bart Van Assche Cc: Daniel Wagner Cc: Himanshu Madhani Cc: Martin Wilck Cc: stable@vger.kernel.org # v5.4+ Reviewed-by: Daniel Wagner Reviewed-by: Shyam Sundar Reviewed-by: Himanshu Madhani Signed-off-by: Roman Bolshakov Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit be8df027079b856a89e85778330394cea2b0b290 Author: Peter Chen Date: Tue Jun 23 11:09:18 2020 +0800 usb: cdns3: ep0: add spinlock for cdns3_check_new_setup commit 2587a029fa2a877d0a8dda955ef1b24c94b4bd0e upstream. The other thread may access other endpoints when the cdns3_check_new_setup is handling, add spinlock to protect it. Cc: Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") Reviewed-by: Pawel Laszczak Signed-off-by: Peter Chen Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit a0668653be26acdf16272c7eb79017dbdbf69298 Author: Peter Chen Date: Tue Jun 23 11:09:16 2020 +0800 usb: cdns3: ep0: fix the test mode set incorrectly commit b51e1cf64f93acebb6d8afbacd648a6ecefc39b4 upstream. The 'tmode' is ctrl->wIndex, changing it as the real test mode value for register assignment. Cc: Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") Reviewed-by: Jun Li Signed-off-by: Peter Chen Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 79175ae5f9968863f41fb20063bd5840f478686f Author: Peter Chen Date: Tue Jun 23 11:09:17 2020 +0800 usb: cdns3: trace: using correct dir value commit ba3a80fe0fb67d8790f62b7bc60df97406d89871 upstream. It should use the correct direction value from register, not depends on previous software setting. It fixed the EP number wrong issue at trace when the TRBERR interrupt occurs for EP0IN. When the EP0IN IOC has finished, software prepares the setup packet request, the expected direction is OUT, but at that time, the TRBERR for EP0IN may occur since it is DMULT mode, the DMA does not stop until TRBERR has met. Cc: Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") Reviewed-by: Pawel Laszczak Signed-off-by: Peter Chen Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 25e1bb1e6c368d09da13007b60f0c92b1c4101b4 Author: Takashi Iwai Date: Wed Jun 24 14:23:40 2020 +0200 ALSA: usb-audio: Fix OOB access of mixer element list commit 220345e98f1cdc768eeb6e3364a0fa7ab9647fe7 upstream. The USB-audio mixer code holds a linked list of usb_mixer_elem_list, and several operations are performed for each mixer element. A few of them (snd_usb_mixer_notify_id() and snd_usb_mixer_interrupt_v2()) assume each mixer element being a usb_mixer_elem_info object that is a subclass of usb_mixer_elem_list, cast via container_of() and access it members. This may result in an out-of-bound access when a non-standard list element has been added, as spotted by syzkaller recently. This patch adds a new field, is_std_info, in usb_mixer_elem_list to indicate that the element is the usb_mixer_elem_info type or not, and skip the access to such an element if needed. Reported-by: syzbot+fb14314433463ad51625@syzkaller.appspotmail.com Reported-by: syzbot+2405ca3401e943c538b5@syzkaller.appspotmail.com Cc: Link: https://lore.kernel.org/r/20200624122340.9615-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1cc2d29710c2e9c96b6d026f71b5cfc09d96ea8c Author: Macpaul Lin Date: Tue Jun 23 19:03:23 2020 +0800 ALSA: usb-audio: add quirk for Samsung USBC Headset (AKG) commit a32a1fc99807244d920d274adc46ba04b538cc8a upstream. We've found Samsung USBC Headset (AKG) (VID: 0x04e8, PID: 0xa051) need a tiny delay after each class compliant request. Otherwise the device might not be able to be recognized each times. Signed-off-by: Chihhao Chen Signed-off-by: Macpaul Lin Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/1592910203-24035-1-git-send-email-macpaul.lin@mediatek.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 0c4ff206043eb43a57888801cae30750a7e4b7db Author: Yick W. Tse Date: Sat Jun 13 11:40:06 2020 +0000 ALSA: usb-audio: add quirk for Denon DCD-1500RE commit c9808bbfed3cfc911ecb60fe8e80c0c27876c657 upstream. fix error "clock source 41 is not valid, cannot use" [] New USB device found, idVendor=154e, idProduct=1002, bcdDevice= 1.00 [] New USB device strings: Mfr=1, Product=2, SerialNumber=0 [] Product: DCD-1500RE [] Manufacturer: D & M Holdings Inc. [] [] clock source 41 is not valid, cannot use [] usbcore: registered new interface driver snd-usb-audio Signed-off-by: Yick W. Tse Cc: Link: https://lore.kernel.org/r/1373857985.210365.1592048406997@mail.yahoo.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 74a7ad9d975c214a74e1ceddb4d349fd72e04eb7 Author: Laurence Tratt Date: Fri Jun 12 12:18:07 2020 +0100 ALSA: usb-audio: Add implicit feedback quirk for SSL2+. commit e7585db1b0b5b4e4eb1967bb1472df308f7ffcbf upstream. This uses the same quirk as the Motu M2 and M4 to ensure the driver uses the audio interface's clock. Tested on an SSL2+. Signed-off-by: Laurence Tratt Cc: Link: https://lore.kernel.org/r/20200612111807.dgnig6rwhmsl2bod@overdrive.tratt.net Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 895ec8c86e13f85b119c71d5f95491b48867955e Author: Li Jun Date: Thu Jun 4 19:21:18 2020 +0800 usb: typec: tcpci_rt1711h: avoid screaming irq causing boot hangs commit 302c570bf36e997d55ad0d60628a2feec76954a4 upstream. John reported screaming irq caused by rt1711h when system boot[1], this is because irq request is done before tcpci_register_port(), so the chip->tcpci has not been setup, irq handler is entered but can't do anything, this patch is to address this by moving the irq request after tcpci_register_port(). [1] https://lore.kernel.org/linux-usb/20200530040157.31038-1-john.stultz@linaro.org Fixes: ce08eaeb6388 ("staging: typec: rt1711h typec chip driver") Cc: stable # v4.18+ Cc: John Stultz Reported-and-tested-by: John Stultz Reviewed-by: Guenter Roeck Reviewed-by: Heikki Krogerus Signed-off-by: Li Jun Link: https://lore.kernel.org/r/20200604112118.38062-1-jun.li@nxp.com Signed-off-by: Greg Kroah-Hartman commit fe2daefad98a274eb6962e73d5b4dff7ade994dc Author: Tang Bin Date: Tue Jun 2 19:47:08 2020 +0800 usb: host: ehci-exynos: Fix error check in exynos_ehci_probe() commit 44ed240d62736ad29943ec01e41e194b96f7c5e9 upstream. If the function platform_get_irq() failed, the negative value returned will not be detected here. So fix error handling in exynos_ehci_probe(). And when get irq failed, the function platform_get_irq() logs an error message, so remove redundant message here. Fixes: 1bcc5aa87f04 ("USB: Add initial S5P EHCI driver") Cc: stable Signed-off-by: Zhang Shengju Signed-off-by: Tang Bin Link: https://lore.kernel.org/r/20200602114708.28620-1-tangbin@cmss.chinamobile.com Signed-off-by: Greg Kroah-Hartman commit c1e71a51c2f522ebabcc289ea3366a47e48c4a3e Author: Kai-Heng Feng Date: Wed Jun 24 16:59:49 2020 +0300 xhci: Poll for U0 after disabling USB2 LPM commit b3d71abd135e6919ca0b6cab463738472653ddfb upstream. USB2 devices with LPM enabled may interrupt the system suspend: [ 932.510475] usb 1-7: usb suspend, wakeup 0 [ 932.510549] hub 1-0:1.0: hub_suspend [ 932.510581] usb usb1: bus suspend, wakeup 0 [ 932.510590] xhci_hcd 0000:00:14.0: port 9 not suspended [ 932.510593] xhci_hcd 0000:00:14.0: port 8 not suspended .. [ 932.520323] xhci_hcd 0000:00:14.0: Port change event, 1-7, id 7, portsc: 0x400e03 .. [ 932.591405] PM: pci_pm_suspend(): hcd_pci_suspend+0x0/0x30 returns -16 [ 932.591414] PM: dpm_run_callback(): pci_pm_suspend+0x0/0x160 returns -16 [ 932.591418] PM: Device 0000:00:14.0 failed to suspend async: error -16 During system suspend, USB core will let HC suspends the device if it doesn't have remote wakeup enabled and doesn't have any children. However, from the log above we can see that the usb 1-7 doesn't get bus suspended due to not in U0. After a while the port finished U2 -> U0 transition, interrupts the suspend process. The observation is that after disabling LPM, port doesn't transit to U0 immediately and can linger in U2. xHCI spec 4.23.5.2 states that the maximum exit latency for USB2 LPM should be BESL + 10us. The BESL for the affected device is advertised as 400us, which is still not enough based on my testing result. So let's use the maximum permitted latency, 10000, to poll for U0 status to solve the issue. Cc: stable@vger.kernel.org Signed-off-by: Kai-Heng Feng Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20200624135949.22611-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 9d814bd14cffb51e418983faa1d899da2a3a55fc Author: Macpaul Lin Date: Wed Jun 24 16:59:47 2020 +0300 usb: host: xhci-mtk: avoid runtime suspend when removing hcd commit a24d5072e87457a14023ee1dd3fc8b1e76f899ef upstream. When runtime suspend was enabled, runtime suspend might happen when xhci is removing hcd. This might cause kernel panic when hcd has been freed but runtime pm suspend related handle need to reference it. Signed-off-by: Macpaul Lin Reviewed-by: Chunfeng Yun Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20200624135949.22611-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 9200037a6ab6cdd76b0d04240d5f61d4d076a8b4 Author: Longfang Liu Date: Mon Jun 8 11:46:59 2020 +0800 USB: ehci: reopen solution for Synopsys HC bug commit 1ddcb71a3edf0e1682b6e056158e4c4b00325f66 upstream. A Synopsys USB2.0 core used in Huawei Kunpeng920 SoC has a bug which might cause the host controller not issuing ping. Bug description: After indicating an Interrupt on Async Advance, the software uses the doorbell mechanism to delete the Next Link queue head of the last executed queue head. At this time, the host controller still references the removed queue head(the queue head is NULL). NULL reference causes the host controller to lose the USB device. Solution: After deleting the Next Link queue head, when has_synopsys_hc_bug set to 1，the software can write one of the valid queue head addresses to the ASYNCLISTADDR register to allow the host controller to get the valid queue head. in order to solve that problem, this patch set the flag for Huawei Kunpeng920 There are detailed instructions and solutions in this patch: commit 2f7ac6c19997 ("USB: ehci: add workaround for Synopsys HC bug") Signed-off-by: Longfang Liu Cc: stable Acked-by: Alan Stern Link: https://lore.kernel.org/r/1591588019-44284-1-git-send-email-liulongfang@huawei.com Signed-off-by: Greg Kroah-Hartman commit ffeb58a0daf07ef0d5508a7ba6845bc9aa3713fe Author: Tomasz Meresiński Date: Wed Jun 3 22:33:46 2020 +0200 usb: add USB_QUIRK_DELAY_INIT for Logitech C922 commit 5d8021923e8a8cc37a421a64e27c7221f0fee33c upstream. The Logitech C922, just like other Logitech webcams, needs the USB_QUIRK_DELAY_INIT or it will randomly not respond after device connection Signed-off-by: Tomasz Meresiński Cc: stable Link: https://lore.kernel.org/r/20200603203347.7792-1-tomasz@meresinski.eu Signed-off-by: Greg Kroah-Hartman commit 6b3eb8af48cb6af7ebaca7cfb95d0698c778cc41 Author: Minas Harutyunyan Date: Tue Jun 9 12:28:11 2020 +0400 usb: dwc2: Postponed gadget registration to the udc class driver commit 207324a321a866401b098cadf19e4a2dd6584622 upstream. During dwc2 driver probe, after gadget registration to the udc class driver, if exist any builtin function driver it immediately bound to dwc2 and after init host side (dwc2_hcd_init()) stucked in host mode. Patch postpone gadget registration after host side initialization done. Fixes: 117777b2c3bb9 ("usb: dwc2: Move gadget probe function into platform code") Reported-by: kbuild test robot Tested-by: Marek Vasut Cc: stable Signed-off-by: Minas Harutyunyan Link: https://lore.kernel.org/r/f21cb38fecc72a230b86155d94c7e60c9cb66f58.1591690938.git.hminas@synopsys.com Signed-off-by: Greg Kroah-Hartman commit 195c1d1dd8cf957a2bbec5cfbb331539760032ea Author: Chuhong Yuan Date: Wed Jun 10 10:48:44 2020 +0800 USB: ohci-sm501: Add missed iounmap() in remove commit 07c112fb09c86c0231f6ff0061a000ffe91c8eb9 upstream. This driver misses calling iounmap() in remove to undo the ioremap() called in probe. Add the missed call to fix it. Fixes: f54aab6ebcec ("usb: ohci-sm501 driver") Cc: stable Signed-off-by: Chuhong Yuan Acked-by: Alan Stern Link: https://lore.kernel.org/r/20200610024844.3628408-1-hslester96@gmail.com Signed-off-by: Greg Kroah-Hartman commit 2274a7421e732b9be095029537062cc00a54c19a Author: Todd Kjos Date: Mon Jun 22 13:07:15 2020 -0700 binder: fix null deref of proc->context commit d35d3660e065b69fdb8bf512f3d899f350afce52 upstream. The binder driver makes the assumption proc->context pointer is invariant after initialization (as documented in the kerneldoc header for struct proc). However, in commit f0fe2c0f050d ("binder: prevent UAF for binderfs devices II") proc->context is set to NULL during binder_deferred_release(). Another proc was in the middle of setting up a transaction to the dying process and crashed on a NULL pointer deref on "context" which is a local set to &proc->context: new_ref->data.desc = (node == context->binder_context_mgr_node) ? 0 : 1; Here's the stack: [ 5237.855435] Call trace: [ 5237.855441] binder_get_ref_for_node_olocked+0x100/0x2ec [ 5237.855446] binder_inc_ref_for_node+0x140/0x280 [ 5237.855451] binder_translate_binder+0x1d0/0x388 [ 5237.855456] binder_transaction+0x2228/0x3730 [ 5237.855461] binder_thread_write+0x640/0x25bc [ 5237.855466] binder_ioctl_write_read+0xb0/0x464 [ 5237.855471] binder_ioctl+0x30c/0x96c [ 5237.855477] do_vfs_ioctl+0x3e0/0x700 [ 5237.855482] __arm64_sys_ioctl+0x78/0xa4 [ 5237.855488] el0_svc_common+0xb4/0x194 [ 5237.855493] el0_svc_handler+0x74/0x98 [ 5237.855497] el0_svc+0x8/0xc The fix is to move the kfree of the binder_device to binder_free_proc() so the binder_device is freed when we know there are no references remaining on the binder_proc. Fixes: f0fe2c0f050d ("binder: prevent UAF for binderfs devices II") Acked-by: Christian Brauner Signed-off-by: Todd Kjos Cc: stable Link: https://lore.kernel.org/r/20200622200715.114382-1-tkjos@google.com Signed-off-by: Greg Kroah-Hartman commit 3621616af99bac4cf55728265ce886f36e6a3fed Author: Takashi Iwai Date: Tue Jun 16 14:09:21 2020 +0200 ALSA: usb-audio: Fix potential use-after-free of streams [ Upstream commit ff58bbc7b9704a5869204176f804eff57307fef0 ] With the recent full-duplex support of implicit feedback streams, an endpoint can be still running after closing the capture stream as long as the playback stream with the sync-endpoint is running. In such a state, the URBs are still be handled and they may call retire_data_urb callback, which tries to transfer the data from the PCM buffer. Since the PCM stream gets closed, this may lead to use-after-free. This patch adds the proper clearance of the callback at stopping the capture stream for addressing the possible UAF above. Fixes: 10ce77e4817f ("ALSA: usb-audio: Add duplex sound support for USB devices using implicit feedback") Link: https://lore.kernel.org/r/20200616120921.12249-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 335add4ac891c3c5094e5b30cce004322f284ca4 Author: Al Viro Date: Sat Jun 6 23:44:24 2020 -0400 fix a braino in "sparc32: fix register window handling in genregs32_[gs]et()" [ Upstream commit 9d964e1b82d8182184153b70174f445ea616f053 ] lost npc in PTRACE_SETREGSET, breaking PTRACE_SETREGS as well Fixes: cf51e129b968 "sparc32: fix register window handling in genregs32_[gs]et()" Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 32e5a15f10847905eb7932f2a837a9e664dba665 Author: Valentin Longchamp Date: Tue Jun 9 22:11:54 2020 +0200 net: sched: export __netdev_watchdog_up() [ Upstream commit 1a3db27ad9a72d033235b9673653962c02e3486e ] Since the quiesce/activate rework, __netdev_watchdog_up() is directly called in the ucc_geth driver. Unfortunately, this function is not available for modules and thus ucc_geth cannot be built as a module anymore. Fix it by exporting __netdev_watchdog_up(). Since the commit introducing the regression was backported to stable branches, this one should ideally be as well. Fixes: 79dde73cf9bc ("net/ethernet/freescale: rework quiesce/activate for ucc_geth") Signed-off-by: Valentin Longchamp Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9d3d40ec7dee70838cf5c48773dcbcddced2485a Author: Sasha Levin Date: Thu Jun 25 17:03:10 2020 -0400 btrfs: fix a block group ref counter leak after failure to remove block group [ Upstream commit 9fecd13202f520f3f25d5b1c313adb740fe19773 ] When removing a block group, if we fail to delete the block group's item from the extent tree, we jump to the 'out' label and end up decrementing the block group's reference count once only (by 1), resulting in a counter leak because the block group at that point was already removed from the block group cache rbtree - so we have to decrement the reference count twice, once for the rbtree and once for our lookup at the start of the function. There is a second bug where if removing the free space tree entries (the call to remove_block_group_free_space()) fails we end up jumping to the 'out_put_group' label but end up decrementing the reference count only once, when we should have done it twice, since we have already removed the block group from the block group cache rbtree. This happens because the reference count decrement for the rbtree reference happens after attempting to remove the free space tree entries, which is far away from the place where we remove the block group from the rbtree. To make things less error prone, decrement the reference count for the rbtree immediately after removing the block group from it. This also eleminates the need for two different exit labels on error, renaming 'out_put_label' to just 'out' and removing the old 'out'. Fixes: f6033c5e333238 ("btrfs: fix block group leak when removing fails") CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Nikolay Borisov Reviewed-by: Anand Jain Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 8ae850cddf27b7b354b6abe207c5b7c05d615a53 Author: Thierry Reding Date: Thu Apr 30 13:31:58 2020 +0200 Revert "i2c: tegra: Fix suspending in active runtime PM state" [ Upstream commit 78ad73421831247e46c31899a7bead02740e4bef ] This reverts commit 9f42de8d4ec2304f10bbc51dc0484f3503d61196. It's not safe to use pm_runtime_force_{suspend,resume}(), especially during the noirq phase of suspend. See also the guidance provided in commit 1e2ef05bb8cf ("PM: Limit race conditions between runtime PM and system sleep (v2)"). Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 052a7fdd86fba7820618717571df6bb23018a5c1 Author: Neal Cardwell Date: Wed Jun 24 12:42:02 2020 -0400 tcp_cubic: fix spurious HYSTART_DELAY exit upon drop in min RTT [ Upstream commit b344579ca8478598937215f7005d6c7b84d28aee ] Mirja Kuehlewind reported a bug in Linux TCP CUBIC Hystart, where Hystart HYSTART_DELAY mechanism can exit Slow Start spuriously on an ACK when the minimum rtt of a connection goes down. From inspection it is clear from the existing code that this could happen in an example like the following: o The first 8 RTT samples in a round trip are 150ms, resulting in a curr_rtt of 150ms and a delay_min of 150ms. o The 9th RTT sample is 100ms. The curr_rtt does not change after the first 8 samples, so curr_rtt remains 150ms. But delay_min can be lowered at any time, so delay_min falls to 100ms. The code executes the HYSTART_DELAY comparison between curr_rtt of 150ms and delay_min of 100ms, and the curr_rtt is declared far enough above delay_min to force a (spurious) exit of Slow start. The fix here is simple: allow every RTT sample in a round trip to lower the curr_rtt. Fixes: ae27e98a5152 ("[TCP] CUBIC v2.3") Reported-by: Mirja Kuehlewind Signed-off-by: Neal Cardwell Signed-off-by: Eric Dumazet Acked-by: Soheil Hassas Yeganeh Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 942315134313e6bf33e03039e1e4eb64fec91647 Author: Toke Høiland-Jørgensen Date: Thu Jun 25 22:12:09 2020 +0200 sch_cake: fix a few style nits [ Upstream commit 3f608f0c41360b11b04c763f348b712f651c8bac ] I spotted a few nits when comparing the in-tree version of sch_cake with the out-of-tree one: A redundant error variable declaration shadowing an outer declaration, and an indentation alignment issue. Fix both of these. Fixes: 046f6fd5daef ("sched: Add Common Applications Kept Enhanced (cake) qdisc") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b1aa7e5fa163f491546a536e29643b1d04f8287c Author: Toke Høiland-Jørgensen Date: Thu Jun 25 22:12:08 2020 +0200 sch_cake: don't call diffserv parsing code when it is not needed [ Upstream commit 8c95eca0bb8c4bd2231a0d581f1ad0d50c90488c ] As a further optimisation of the diffserv parsing codepath, we can skip it entirely if CAKE is configured to neither use diffserv-based classification, nor to zero out the diffserv bits. Fixes: c87b4ecdbe8d ("sch_cake: Make sure we can write the IP header before changing DSCP bits") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ea2628dd586d23e1412baced76b519a2f1c66d1c Author: Ilya Ponetayev Date: Thu Jun 25 22:12:07 2020 +0200 sch_cake: don't try to reallocate or unshare skb unconditionally [ Upstream commit 9208d2863ac689a563b92f2161d8d1e7127d0add ] cake_handle_diffserv() tries to linearize mac and network header parts of skb and to make it writable unconditionally. In some cases it leads to full skb reallocation, which reduces throughput and increases CPU load. Some measurements of IPv4 forward + NAPT on MIPS router with 580 MHz single-core CPU was conducted. It appears that on kernel 4.9 skb_try_make_writable() reallocates skb, if skb was allocated in ethernet driver via so-called 'build skb' method from page cache (it was discovered by strange increase of kmalloc-2048 slab at first). Obtain DSCP value via read-only skb_header_pointer() call, and leave linearization only for DSCP bleaching or ECN CE setting. And, as an additional optimisation, skip diffserv parsing entirely if it is not needed by the current configuration. Fixes: c87b4ecdbe8d ("sch_cake: Make sure we can write the IP header before changing DSCP bits") Signed-off-by: Ilya Ponetayev [ fix a few style issues, reflow commit message ] Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3c6208267218d4e04692c9af2501570eaec28e2a Author: Taehee Yoo Date: Tue Jun 16 16:51:51 2020 +0000 ip_tunnel: fix use-after-free in ip_tunnel_lookup() [ Upstream commit ba61539c6ae57f4146284a5cb4f7b7ed8d42bf45 ] In the datapath, the ip_tunnel_lookup() is used and it internally uses fallback tunnel device pointer, which is fb_tunnel_dev. This pointer variable should be set to NULL when a fb interface is deleted. But there is no routine to set fb_tunnel_dev pointer to NULL. So, this pointer will be still used after interface is deleted and it eventually results in the use-after-free problem. Test commands: ip netns add A ip netns add B ip link add eth0 type veth peer name eth1 ip link set eth0 netns A ip link set eth1 netns B ip netns exec A ip link set lo up ip netns exec A ip link set eth0 up ip netns exec A ip link add gre1 type gre local 10.0.0.1 \ remote 10.0.0.2 ip netns exec A ip link set gre1 up ip netns exec A ip a a 10.0.100.1/24 dev gre1 ip netns exec A ip a a 10.0.0.1/24 dev eth0 ip netns exec B ip link set lo up ip netns exec B ip link set eth1 up ip netns exec B ip link add gre1 type gre local 10.0.0.2 \ remote 10.0.0.1 ip netns exec B ip link set gre1 up ip netns exec B ip a a 10.0.100.2/24 dev gre1 ip netns exec B ip a a 10.0.0.2/24 dev eth1 ip netns exec A hping3 10.0.100.2 -2 --flood -d 60000 & ip netns del B Splat looks like: [ 77.793450][ C3] ================================================================== [ 77.794702][ C3] BUG: KASAN: use-after-free in ip_tunnel_lookup+0xcc4/0xf30 [ 77.795573][ C3] Read of size 4 at addr ffff888060bd9c84 by task hping3/2905 [ 77.796398][ C3] [ 77.796664][ C3] CPU: 3 PID: 2905 Comm: hping3 Not tainted 5.8.0-rc1+ #616 [ 77.797474][ C3] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 77.798453][ C3] Call Trace: [ 77.798815][ C3] [ 77.799142][ C3] dump_stack+0x9d/0xdb [ 77.799605][ C3] print_address_description.constprop.7+0x2cc/0x450 [ 77.800365][ C3] ? ip_tunnel_lookup+0xcc4/0xf30 [ 77.800908][ C3] ? ip_tunnel_lookup+0xcc4/0xf30 [ 77.801517][ C3] ? ip_tunnel_lookup+0xcc4/0xf30 [ 77.802145][ C3] kasan_report+0x154/0x190 [ 77.802821][ C3] ? ip_tunnel_lookup+0xcc4/0xf30 [ 77.803503][ C3] ip_tunnel_lookup+0xcc4/0xf30 [ 77.804165][ C3] __ipgre_rcv+0x1ab/0xaa0 [ip_gre] [ 77.804862][ C3] ? rcu_read_lock_sched_held+0xc0/0xc0 [ 77.805621][ C3] gre_rcv+0x304/0x1910 [ip_gre] [ 77.806293][ C3] ? lock_acquire+0x1a9/0x870 [ 77.806925][ C3] ? gre_rcv+0xfe/0x354 [gre] [ 77.807559][ C3] ? erspan_xmit+0x2e60/0x2e60 [ip_gre] [ 77.808305][ C3] ? rcu_read_lock_sched_held+0xc0/0xc0 [ 77.809032][ C3] ? rcu_read_lock_held+0x90/0xa0 [ 77.809713][ C3] gre_rcv+0x1b8/0x354 [gre] [ ... ] Suggested-by: Eric Dumazet Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.") Signed-off-by: Taehee Yoo Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9baf076d797f8b593b0f912677407de48a82dad4 Author: Florian Fainelli Date: Fri Jun 19 11:47:47 2020 -0700 net: phy: Check harder for errors in get_phy_id() [ Upstream commit b2ffc75e2e990b09903f9d15ccd53bc5f3a4217c ] Commit 02a6efcab675 ("net: phy: allow scanning busses with missing phys") added a special condition to return -ENODEV in case -ENODEV or -EIO was returned from the first read of the MII_PHYSID1 register. In case the MDIO bus data line pull-up is not strong enough, the MDIO bus controller will not flag this as a read error. This can happen when a pluggable daughter card is not connected and weak internal pull-ups are used (since that is the only option, otherwise the pins are floating). The second read of MII_PHYSID2 will be correctly flagged an error though, but now we will return -EIO which will be treated as a hard error, thus preventing MDIO bus scanning loops to continue succesfully. Apply the same logic to both register reads, thus allowing the scanning logic to proceed. Fixes: 02a6efcab675 ("net: phy: allow scanning busses with missing phys") Reviewed-by: Andrew Lunn Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 568c5aaf6c2d922f44a7431a4155646f5d7253d2 Author: Taehee Yoo Date: Tue Jun 16 16:04:00 2020 +0000 ip6_gre: fix use-after-free in ip6gre_tunnel_lookup() [ Upstream commit dafabb6590cb15f300b77c095d50312e2c7c8e0f ] In the datapath, the ip6gre_tunnel_lookup() is used and it internally uses fallback tunnel device pointer, which is fb_tunnel_dev. This pointer variable should be set to NULL when a fb interface is deleted. But there is no routine to set fb_tunnel_dev pointer to NULL. So, this pointer will be still used after interface is deleted and it eventually results in the use-after-free problem. Test commands: ip netns add A ip netns add B ip link add eth0 type veth peer name eth1 ip link set eth0 netns A ip link set eth1 netns B ip netns exec A ip link set lo up ip netns exec A ip link set eth0 up ip netns exec A ip link add ip6gre1 type ip6gre local fc:0::1 \ remote fc:0::2 ip netns exec A ip -6 a a fc:100::1/64 dev ip6gre1 ip netns exec A ip link set ip6gre1 up ip netns exec A ip -6 a a fc:0::1/64 dev eth0 ip netns exec A ip link set ip6gre0 up ip netns exec B ip link set lo up ip netns exec B ip link set eth1 up ip netns exec B ip link add ip6gre1 type ip6gre local fc:0::2 \ remote fc:0::1 ip netns exec B ip -6 a a fc:100::2/64 dev ip6gre1 ip netns exec B ip link set ip6gre1 up ip netns exec B ip -6 a a fc:0::2/64 dev eth1 ip netns exec B ip link set ip6gre0 up ip netns exec A ping fc:100::2 -s 60000 & ip netns del B Splat looks like: [ 73.087285][ C1] BUG: KASAN: use-after-free in ip6gre_tunnel_lookup+0x1064/0x13f0 [ip6_gre] [ 73.088361][ C1] Read of size 4 at addr ffff888040559218 by task ping/1429 [ 73.089317][ C1] [ 73.089638][ C1] CPU: 1 PID: 1429 Comm: ping Not tainted 5.7.0+ #602 [ 73.090531][ C1] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 73.091725][ C1] Call Trace: [ 73.092160][ C1] [ 73.092556][ C1] dump_stack+0x96/0xdb [ 73.093122][ C1] print_address_description.constprop.6+0x2cc/0x450 [ 73.094016][ C1] ? ip6gre_tunnel_lookup+0x1064/0x13f0 [ip6_gre] [ 73.094894][ C1] ? ip6gre_tunnel_lookup+0x1064/0x13f0 [ip6_gre] [ 73.095767][ C1] ? ip6gre_tunnel_lookup+0x1064/0x13f0 [ip6_gre] [ 73.096619][ C1] kasan_report+0x154/0x190 [ 73.097209][ C1] ? ip6gre_tunnel_lookup+0x1064/0x13f0 [ip6_gre] [ 73.097989][ C1] ip6gre_tunnel_lookup+0x1064/0x13f0 [ip6_gre] [ 73.098750][ C1] ? gre_del_protocol+0x60/0x60 [gre] [ 73.099500][ C1] gre_rcv+0x1c5/0x1450 [ip6_gre] [ 73.100199][ C1] ? ip6gre_header+0xf00/0xf00 [ip6_gre] [ 73.100985][ C1] ? rcu_read_lock_sched_held+0xc0/0xc0 [ 73.101830][ C1] ? ip6_input_finish+0x5/0xf0 [ 73.102483][ C1] ip6_protocol_deliver_rcu+0xcbb/0x1510 [ 73.103296][ C1] ip6_input_finish+0x5b/0xf0 [ 73.103920][ C1] ip6_input+0xcd/0x2c0 [ 73.104473][ C1] ? ip6_input_finish+0xf0/0xf0 [ 73.105115][ C1] ? rcu_read_lock_held+0x90/0xa0 [ 73.105783][ C1] ? rcu_read_lock_sched_held+0xc0/0xc0 [ 73.106548][ C1] ipv6_rcv+0x1f1/0x300 [ ... ] Suggested-by: Eric Dumazet Fixes: c12b395a4664 ("gre: Support GRE over IPv6") Signed-off-by: Taehee Yoo Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 35db638692db1e696855b78897e363ef150306d0 Author: David Christensen Date: Wed Jun 17 11:51:17 2020 -0700 tg3: driver sleeps indefinitely when EEH errors exceed eeh_max_freezes [ Upstream commit 3a2656a211caf35e56afc9425e6e518fa52f7fbc ] The driver function tg3_io_error_detected() calls napi_disable twice, without an intervening napi_enable, when the number of EEH errors exceeds eeh_max_freezes, resulting in an indefinite sleep while holding rtnl_lock. Add check for pcierr_recovery which skips code already executed for the "Frozen" state. Signed-off-by: David Christensen Reviewed-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fe3a5d8fc372285a292af315ea1ea75a7cafc8ce Author: Eric Dumazet Date: Mon Jun 15 20:37:07 2020 -0700 tcp: grow window for OOO packets only for SACK flows [ Upstream commit 662051215c758ae8545451628816204ed6cd372d ] Back in 2013, we made a change that broke fast retransmit for non SACK flows. Indeed, for these flows, a sender needs to receive three duplicate ACK before starting fast retransmit. Sending ACK with different receive window do not count. Even if enabling SACK is strongly recommended these days, there still are some cases where it has to be disabled. Not increasing the window seems better than having to rely on RTO. After the fix, following packetdrill test gives : // Initialize connection 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 bind(3, ..., ...) = 0 +0 listen(3, 1) = 0 +0 < S 0:0(0) win 32792 +0 > S. 0:0(0) ack 1 +0 < . 1:1(0) ack 1 win 514 +0 accept(3, ..., ...) = 4 +0 < . 1:1001(1000) ack 1 win 514 // Quick ack +0 > . 1:1(0) ack 1001 win 264 +0 < . 2001:3001(1000) ack 1 win 514 // DUPACK : Normally we should not change the window +0 > . 1:1(0) ack 1001 win 264 +0 < . 3001:4001(1000) ack 1 win 514 // DUPACK : Normally we should not change the window +0 > . 1:1(0) ack 1001 win 264 +0 < . 4001:5001(1000) ack 1 win 514 // DUPACK : Normally we should not change the window +0 > . 1:1(0) ack 1001 win 264 +0 < . 1001:2001(1000) ack 1 win 514 // Hole is repaired. +0 > . 1:1(0) ack 5001 win 272 Fixes: 4e4f1fc22681 ("tcp: properly increase rcv_ssthresh for ofo packets") Signed-off-by: Eric Dumazet Reported-by: Venkat Venkatsubra Acked-by: Neal Cardwell Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit cb22ce3346f2167b532f113df959d466e288aa3c Author: Denis Kirjanov Date: Thu Jun 25 14:51:06 2020 +0300 tcp: don't ignore ECN CWR on pure ACK [ Upstream commit 2570284060b48f3f79d8f1a2698792f36c385e9a ] there is a problem with the CWR flag set in an incoming ACK segment and it leads to the situation when the ECE flag is latched forever the following packetdrill script shows what happens: // Stack receives incoming segments with CE set +0.1 <[ect0] . 11001:12001(1000) ack 1001 win 65535 +0.0 <[ce] . 12001:13001(1000) ack 1001 win 65535 +0.0 <[ect0] P. 13001:14001(1000) ack 1001 win 65535 // Stack repsonds with ECN ECHO +0.0 >[noecn] . 1001:1001(0) ack 12001 +0.0 >[noecn] E. 1001:1001(0) ack 13001 +0.0 >[noecn] E. 1001:1001(0) ack 14001 // Write a packet +0.1 write(3, ..., 1000) = 1000 +0.0 >[ect0] PE. 1001:2001(1000) ack 14001 // Pure ACK received +0.01 <[noecn] W. 14001:14001(0) ack 2001 win 65535 // Since CWR was sent, this packet should NOT have ECE set +0.1 write(3, ..., 1000) = 1000 +0.0 >[ect0] P. 2001:3001(1000) ack 14001 // but Linux will still keep ECE latched here, with packetdrill // flagging a missing ECE flag, expecting // >[ect0] PE. 2001:3001(1000) ack 14001 // in the script In the situation above we will continue to send ECN ECHO packets and trigger the peer to reduce the congestion window. To avoid that we can check CWR on pure ACKs received. v3: - Add a sequence check to avoid sending an ACK to an ACK v2: - Adjusted the comment - move CWR check before checking for unacknowledged packets Signed-off-by: Denis Kirjanov Acked-by: Neal Cardwell Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit dc43f7e807a8bd9cc7deecf1980fcb3349477646 Author: Marcelo Ricardo Leitner Date: Wed Jun 24 17:34:18 2020 -0300 sctp: Don't advertise IPv4 addresses if ipv6only is set on the socket [ Upstream commit 471e39df96b9a4c4ba88a2da9e25a126624d7a9c ] If a socket is set ipv6only, it will still send IPv4 addresses in the INIT and INIT_ACK packets. This potentially misleads the peer into using them, which then would cause association termination. The fix is to not add IPv4 addresses to ipv6only sockets. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Corey Minyard Signed-off-by: Marcelo Ricardo Leitner Tested-by: Corey Minyard Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fea864489c90a07e7e84f8f6f5c531b313ad6593 Author: David Howells Date: Fri Jun 19 23:38:16 2020 +0100 rxrpc: Fix notification call on completion of discarded calls [ Upstream commit 0041cd5a50442db6e456b145892a0eaf2dff061f ] When preallocated service calls are being discarded, they're passed to ->discard_new_call() to have the caller clean up any attached higher-layer preallocated pieces before being marked completed. However, the act of marking them completed now invokes the call's notification function - which causes a problem because that function might assume that the previously freed pieces of memory are still there. Fix this by setting a dummy notification function on the socket after calling ->discard_new_call(). This results in the following kasan message when the kafs module is removed. ================================================================== BUG: KASAN: use-after-free in afs_wake_up_async_call+0x6aa/0x770 fs/afs/rxrpc.c:707 Write of size 1 at addr ffff8880946c39e4 by task kworker/u4:1/21 CPU: 0 PID: 21 Comm: kworker/u4:1 Not tainted 5.8.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: netns cleanup_net Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x18f/0x20d lib/dump_stack.c:118 print_address_description.constprop.0.cold+0xd3/0x413 mm/kasan/report.c:383 __kasan_report mm/kasan/report.c:513 [inline] kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530 afs_wake_up_async_call+0x6aa/0x770 fs/afs/rxrpc.c:707 rxrpc_notify_socket+0x1db/0x5d0 net/rxrpc/recvmsg.c:40 __rxrpc_set_call_completion.part.0+0x172/0x410 net/rxrpc/recvmsg.c:76 __rxrpc_call_completed net/rxrpc/recvmsg.c:112 [inline] rxrpc_call_completed+0xca/0xf0 net/rxrpc/recvmsg.c:111 rxrpc_discard_prealloc+0x781/0xab0 net/rxrpc/call_accept.c:233 rxrpc_listen+0x147/0x360 net/rxrpc/af_rxrpc.c:245 afs_close_socket+0x95/0x320 fs/afs/rxrpc.c:110 afs_net_exit+0x1bc/0x310 fs/afs/main.c:155 ops_exit_list.isra.0+0xa8/0x150 net/core/net_namespace.c:186 cleanup_net+0x511/0xa50 net/core/net_namespace.c:603 process_one_work+0x965/0x1690 kernel/workqueue.c:2269 worker_thread+0x96/0xe10 kernel/workqueue.c:2415 kthread+0x3b5/0x4a0 kernel/kthread.c:291 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 Allocated by task 6820: save_stack+0x1b/0x40 mm/kasan/common.c:48 set_track mm/kasan/common.c:56 [inline] __kasan_kmalloc mm/kasan/common.c:494 [inline] __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:467 kmem_cache_alloc_trace+0x153/0x7d0 mm/slab.c:3551 kmalloc include/linux/slab.h:555 [inline] kzalloc include/linux/slab.h:669 [inline] afs_alloc_call+0x55/0x630 fs/afs/rxrpc.c:141 afs_charge_preallocation+0xe9/0x2d0 fs/afs/rxrpc.c:757 afs_open_socket+0x292/0x360 fs/afs/rxrpc.c:92 afs_net_init+0xa6c/0xe30 fs/afs/main.c:125 ops_init+0xaf/0x420 net/core/net_namespace.c:151 setup_net+0x2de/0x860 net/core/net_namespace.c:341 copy_net_ns+0x293/0x590 net/core/net_namespace.c:482 create_new_namespaces+0x3fb/0xb30 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xbd/0x1f0 kernel/nsproxy.c:231 ksys_unshare+0x43d/0x8e0 kernel/fork.c:2983 __do_sys_unshare kernel/fork.c:3051 [inline] __se_sys_unshare kernel/fork.c:3049 [inline] __x64_sys_unshare+0x2d/0x40 kernel/fork.c:3049 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:359 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Freed by task 21: save_stack+0x1b/0x40 mm/kasan/common.c:48 set_track mm/kasan/common.c:56 [inline] kasan_set_free_info mm/kasan/common.c:316 [inline] __kasan_slab_free+0xf7/0x140 mm/kasan/common.c:455 __cache_free mm/slab.c:3426 [inline] kfree+0x109/0x2b0 mm/slab.c:3757 afs_put_call+0x585/0xa40 fs/afs/rxrpc.c:190 rxrpc_discard_prealloc+0x764/0xab0 net/rxrpc/call_accept.c:230 rxrpc_listen+0x147/0x360 net/rxrpc/af_rxrpc.c:245 afs_close_socket+0x95/0x320 fs/afs/rxrpc.c:110 afs_net_exit+0x1bc/0x310 fs/afs/main.c:155 ops_exit_list.isra.0+0xa8/0x150 net/core/net_namespace.c:186 cleanup_net+0x511/0xa50 net/core/net_namespace.c:603 process_one_work+0x965/0x1690 kernel/workqueue.c:2269 worker_thread+0x96/0xe10 kernel/workqueue.c:2415 kthread+0x3b5/0x4a0 kernel/kthread.c:291 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 The buggy address belongs to the object at ffff8880946c3800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 484 bytes inside of 1024-byte region [ffff8880946c3800, ffff8880946c3c00) The buggy address belongs to the page: page:ffffea000251b0c0 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 flags: 0xfffe0000000200(slab) raw: 00fffe0000000200 ffffea0002546508 ffffea00024fa248 ffff8880aa000c40 raw: 0000000000000000 ffff8880946c3000 0000000100000002 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880946c3880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880946c3900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8880946c3980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880946c3a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880946c3a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Reported-by: syzbot+d3eccef36ddbd02713e9@syzkaller.appspotmail.com Fixes: 5ac0d62226a0 ("rxrpc: Fix missing notification") Signed-off-by: David Howells Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6956830cf9817f934fefa5df8bd6b1a18b83d5e7 Author: Aditya Pakki Date: Fri Jun 12 15:27:55 2020 -0500 rocker: fix incorrect error handling in dma_rings_init [ Upstream commit 58d0c864e1a759a15c9df78f50ea5a5c32b3989e ] In rocker_dma_rings_init, the goto blocks in case of errors caused by the functions rocker_dma_cmd_ring_waits_alloc() and rocker_dma_ring_create() are incorrect. The patch fixes the order consistent with cleanup in rocker_dma_rings_fini(). Signed-off-by: Aditya Pakki Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a908f986ddf7d989fda232c5e7cecbf9f6e5165b Author: Lorenzo Bianconi Date: Tue Jun 23 18:33:15 2020 +0200 openvswitch: take into account de-fragmentation/gso_size in execute_check_pkt_len [ Upstream commit 17843655708e1941c0653af3cd61be6948e36f43 ] ovs connection tracking module performs de-fragmentation on incoming fragmented traffic. Take info account if traffic has been de-fragmented in execute_check_pkt_len action otherwise we will perform the wrong nested action considering the original packet size. This issue typically occurs if ovs-vswitchd adds a rule in the pipeline that requires connection tracking (e.g. OVN stateful ACLs) before execute_check_pkt_len action. Moreover take into account GSO fragment size for GSO packet in execute_check_pkt_len routine Fixes: 4d5ec89fc8d14 ("net: openvswitch: Add a new action check_pkt_len") Signed-off-by: Lorenzo Bianconi Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 27b70214fc6995087c76a24cc3ff2742a23aff5d Author: Jeremy Kerr Date: Mon Jun 15 10:54:56 2020 +0800 net: usb: ax88179_178a: fix packet alignment padding [ Upstream commit e869e7a17798d85829fa7d4f9bbe1eebd4b2d3f6 ] Using a AX88179 device (0b95:1790), I see two bytes of appended data on every RX packet. For example, this 48-byte ping, using 0xff as a payload byte: 04:20:22.528472 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 2447, seq 1, length 64 0x0000: 000a cd35 ea50 000a cd35 ea4f 0800 4500 0x0010: 0054 c116 4000 4001 f63e c0a8 0101 c0a8 0x0020: 0102 0800 b633 098f 0001 87ea cd5e 0000 0x0030: 0000 dcf2 0600 0000 0000 ffff ffff ffff 0x0040: ffff ffff ffff ffff ffff ffff ffff ffff 0x0050: ffff ffff ffff ffff ffff ffff ffff ffff 0x0060: ffff 961f Those last two bytes - 96 1f - aren't part of the original packet. In the ax88179 RX path, the usbnet rx_fixup function trims a 2-byte 'alignment pseudo header' from the start of the packet, and sets the length from a per-packet field populated by hardware. It looks like that length field *includes* the 2-byte header; the current driver assumes that it's excluded. This change trims the 2-byte alignment header after we've set the packet length, so the resulting packet length is correct. While we're moving the comment around, this also fixes the spelling of 'pseudo'. Signed-off-by: Jeremy Kerr Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 67571b1ab2963dca6a031a08b785a1bc7c214433 Author: Eric Dumazet Date: Wed Jun 17 22:23:25 2020 -0700 net: increment xmit_recursion level in dev_direct_xmit() [ Upstream commit 0ad6f6e767ec2f613418cbc7ebe5ec4c35af540c ] Back in commit f60e5990d9c1 ("ipv6: protect skb->sk accesses from recursive dereference inside the stack") Hannes added code so that IPv6 stack would not trust skb->sk for typical cases where packet goes through 'standard' xmit path (__dev_queue_xmit()) Alas af_packet had a dev_direct_xmit() path that was not dealing yet with xmit_recursion level. Also change sk_mc_loop() to dump a stack once only. Without this patch, syzbot was able to trigger : [1] [ 153.567378] WARNING: CPU: 7 PID: 11273 at net/core/sock.c:721 sk_mc_loop+0x51/0x70 [ 153.567378] Modules linked in: nfnetlink ip6table_raw ip6table_filter iptable_raw iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 nf_defrag_ipv6 iptable_filter macsec macvtap tap macvlan 8021q hsr wireguard libblake2s blake2s_x86_64 libblake2s_generic udp_tunnel ip6_udp_tunnel libchacha20poly1305 poly1305_x86_64 chacha_x86_64 libchacha curve25519_x86_64 libcurve25519_generic netdevsim batman_adv dummy team bridge stp llc w1_therm wire i2c_mux_pca954x i2c_mux cdc_acm ehci_pci ehci_hcd mlx4_en mlx4_ib ib_uverbs ib_core mlx4_core [ 153.567386] CPU: 7 PID: 11273 Comm: b159172088 Not tainted 5.8.0-smp-DEV #273 [ 153.567387] RIP: 0010:sk_mc_loop+0x51/0x70 [ 153.567388] Code: 66 83 f8 0a 75 24 0f b6 4f 12 b8 01 00 00 00 31 d2 d3 e0 a9 bf ef ff ff 74 07 48 8b 97 f0 02 00 00 0f b6 42 3a 83 e0 01 5d c3 <0f> 0b b8 01 00 00 00 5d c3 0f b6 87 18 03 00 00 5d c0 e8 04 83 e0 [ 153.567388] RSP: 0018:ffff95c69bb93990 EFLAGS: 00010212 [ 153.567388] RAX: 0000000000000011 RBX: ffff95c6e0ee3e00 RCX: 0000000000000007 [ 153.567389] RDX: ffff95c69ae50000 RSI: ffff95c6c30c3000 RDI: ffff95c6c30c3000 [ 153.567389] RBP: ffff95c69bb93990 R08: ffff95c69a77f000 R09: 0000000000000008 [ 153.567389] R10: 0000000000000040 R11: 00003e0e00026128 R12: ffff95c6c30c3000 [ 153.567390] R13: ffff95c6cc4fd500 R14: ffff95c6f84500c0 R15: ffff95c69aa13c00 [ 153.567390] FS: 00007fdc3a283700(0000) GS:ffff95c6ff9c0000(0000) knlGS:0000000000000000 [ 153.567390] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 153.567391] CR2: 00007ffee758e890 CR3: 0000001f9ba20003 CR4: 00000000001606e0 [ 153.567391] Call Trace: [ 153.567391] ip6_finish_output2+0x34e/0x550 [ 153.567391] __ip6_finish_output+0xe7/0x110 [ 153.567391] ip6_finish_output+0x2d/0xb0 [ 153.567392] ip6_output+0x77/0x120 [ 153.567392] ? __ip6_finish_output+0x110/0x110 [ 153.567392] ip6_local_out+0x3d/0x50 [ 153.567392] ipvlan_queue_xmit+0x56c/0x5e0 [ 153.567393] ? ksize+0x19/0x30 [ 153.567393] ipvlan_start_xmit+0x18/0x50 [ 153.567393] dev_direct_xmit+0xf3/0x1c0 [ 153.567393] packet_direct_xmit+0x69/0xa0 [ 153.567394] packet_sendmsg+0xbf0/0x19b0 [ 153.567394] ? plist_del+0x62/0xb0 [ 153.567394] sock_sendmsg+0x65/0x70 [ 153.567394] sock_write_iter+0x93/0xf0 [ 153.567394] new_sync_write+0x18e/0x1a0 [ 153.567395] __vfs_write+0x29/0x40 [ 153.567395] vfs_write+0xb9/0x1b0 [ 153.567395] ksys_write+0xb1/0xe0 [ 153.567395] __x64_sys_write+0x1a/0x20 [ 153.567395] do_syscall_64+0x43/0x70 [ 153.567396] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 153.567396] RIP: 0033:0x453549 [ 153.567396] Code: Bad RIP value. [ 153.567396] RSP: 002b:00007fdc3a282cc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 153.567397] RAX: ffffffffffffffda RBX: 00000000004d32d0 RCX: 0000000000453549 [ 153.567397] RDX: 0000000000000020 RSI: 0000000020000300 RDI: 0000000000000003 [ 153.567398] RBP: 00000000004d32d8 R08: 0000000000000000 R09: 0000000000000000 [ 153.567398] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004d32dc [ 153.567398] R13: 00007ffee742260f R14: 00007fdc3a282dc0 R15: 00007fdc3a283700 [ 153.567399] ---[ end trace c1d5ae2b1059ec62 ]--- f60e5990d9c1 ("ipv6: protect skb->sk accesses from recursive dereference inside the stack") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 97a1d2aa6cdd2a1e9bda8b25be09baf8f70de2ed Author: guodeqing Date: Wed Jun 17 10:07:16 2020 +0800 net: Fix the arp error in some cases [ Upstream commit 5eea3a63ff4aba6a26002e657a6d21934b7e2b96 ] ie., $ ifconfig eth0 6.6.6.6 netmask 255.255.255.0 $ ip rule add from 6.6.6.6 table 6666 $ ip route add 9.9.9.9 via 6.6.6.6 $ ping -I 6.6.6.6 9.9.9.9 PING 9.9.9.9 (9.9.9.9) from 6.6.6.6 : 56(84) bytes of data. 3 packets transmitted, 0 received, 100% packet loss, time 2079ms $ arp Address HWtype HWaddress Flags Mask Iface 6.6.6.6 (incomplete) eth0 The arp request address is error, this is because fib_table_lookup in fib_check_nh lookup the destnation 9.9.9.9 nexthop, the scope of the fib result is RT_SCOPE_LINK,the correct scope is RT_SCOPE_HOST. Here I add a check of whether this is RT_TABLE_MAIN to solve this problem. Fixes: 3bfd847203c6 ("net: Use passed in table for nexthop lookups") Signed-off-by: guodeqing Reviewed-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 742f2358b3248832bf46745e5bd7a06dfa3aae53 Author: Yang Yingliang Date: Tue Jun 16 09:39:21 2020 +0000 net: fix memleak in register_netdevice() [ Upstream commit 814152a89ed52c722ab92e9fbabcac3cb8a39245 ] I got a memleak report when doing some fuzz test: unreferenced object 0xffff888112584000 (size 13599): comm "ip", pid 3048, jiffies 4294911734 (age 343.491s) hex dump (first 32 bytes): 74 61 70 30 00 00 00 00 00 00 00 00 00 00 00 00 tap0............ 00 ee d9 19 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<000000002f60ba65>] __kmalloc_node+0x309/0x3a0 [<0000000075b211ec>] kvmalloc_node+0x7f/0xc0 [<00000000d3a97396>] alloc_netdev_mqs+0x76/0xfc0 [<00000000609c3655>] __tun_chr_ioctl+0x1456/0x3d70 [<000000001127ca24>] ksys_ioctl+0xe5/0x130 [<00000000b7d5e66a>] __x64_sys_ioctl+0x6f/0xb0 [<00000000e1023498>] do_syscall_64+0x56/0xa0 [<000000009ec0eb12>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 unreferenced object 0xffff888111845cc0 (size 8): comm "ip", pid 3048, jiffies 4294911734 (age 343.491s) hex dump (first 8 bytes): 74 61 70 30 00 88 ff ff tap0.... backtrace: [<000000004c159777>] kstrdup+0x35/0x70 [<00000000d8b496ad>] kstrdup_const+0x3d/0x50 [<00000000494e884a>] kvasprintf_const+0xf1/0x180 [<0000000097880a2b>] kobject_set_name_vargs+0x56/0x140 [<000000008fbdfc7b>] dev_set_name+0xab/0xe0 [<000000005b99e3b4>] netdev_register_kobject+0xc0/0x390 [<00000000602704fe>] register_netdevice+0xb61/0x1250 [<000000002b7ca244>] __tun_chr_ioctl+0x1cd1/0x3d70 [<000000001127ca24>] ksys_ioctl+0xe5/0x130 [<00000000b7d5e66a>] __x64_sys_ioctl+0x6f/0xb0 [<00000000e1023498>] do_syscall_64+0x56/0xa0 [<000000009ec0eb12>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 unreferenced object 0xffff88811886d800 (size 512): comm "ip", pid 3048, jiffies 4294911734 (age 343.491s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff c0 66 3d a3 ff ff ff ff .........f=..... backtrace: [<0000000050315800>] device_add+0x61e/0x1950 [<0000000021008dfb>] netdev_register_kobject+0x17e/0x390 [<00000000602704fe>] register_netdevice+0xb61/0x1250 [<000000002b7ca244>] __tun_chr_ioctl+0x1cd1/0x3d70 [<000000001127ca24>] ksys_ioctl+0xe5/0x130 [<00000000b7d5e66a>] __x64_sys_ioctl+0x6f/0xb0 [<00000000e1023498>] do_syscall_64+0x56/0xa0 [<000000009ec0eb12>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 If call_netdevice_notifiers() failed, then rollback_registered() calls netdev_unregister_kobject() which holds the kobject. The reference cannot be put because the netdev won't be add to todo list, so it will leads a memleak, we need put the reference to avoid memleak. Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9e693934cd59b67ba10014ae7a72cec9c0ea659c Author: Tariq Toukan Date: Mon Jun 22 23:26:04 2020 +0300 net: Do not clear the sock TX queue in sk_set_socket() [ Upstream commit 41b14fb8724d5a4b382a63cb4a1a61880347ccb8 ] Clearing the sock TX queue in sk_set_socket() might cause unexpected out-of-order transmit when called from sock_orphan(), as outstanding packets can pick a different TX queue and bypass the ones already queued. This is undesired in general. More specifically, it breaks the in-order scheduling property guarantee for device-offloaded TLS sockets. Remove the call to sk_tx_queue_clear() in sk_set_socket(), and add it explicitly only where needed. Fixes: e022f0b4a03f ("net: Introduce sk_tx_queue_mapping") Signed-off-by: Tariq Toukan Reviewed-by: Boris Pismenny Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9f217d6dd79663efeb89d307ec3edf77116c6577 Author: Taehee Yoo Date: Tue Jun 16 15:52:05 2020 +0000 net: core: reduce recursion limit value [ Upstream commit fb7861d14c8d7edac65b2fcb6e8031cb138457b2 ] In the current code, ->ndo_start_xmit() can be executed recursively only 10 times because of stack memory. But, in the case of the vxlan, 10 recursion limit value results in a stack overflow. In the current code, the nested interface is limited by 8 depth. There is no critical reason that the recursion limitation value should be 10. So, it would be good to be the same value with the limitation value of nesting interface depth. Test commands: ip link add vxlan10 type vxlan vni 10 dstport 4789 srcport 4789 4789 ip link set vxlan10 up ip a a 192.168.10.1/24 dev vxlan10 ip n a 192.168.10.2 dev vxlan10 lladdr fc:22:33:44:55:66 nud permanent for i in {9..0} do let A=$i+1 ip link add vxlan$i type vxlan vni $i dstport 4789 srcport 4789 4789 ip link set vxlan$i up ip a a 192.168.$i.1/24 dev vxlan$i ip n a 192.168.$i.2 dev vxlan$i lladdr fc:22:33:44:55:66 nud permanent bridge fdb add fc:22:33:44:55:66 dev vxlan$A dst 192.168.$i.2 self done hping3 192.168.10.2 -2 -d 60000 Splat looks like: [ 103.814237][ T1127] ============================================================================= [ 103.871955][ T1127] BUG kmalloc-2k (Tainted: G B ): Padding overwritten. 0x00000000897a2e4f-0x000 [ 103.873187][ T1127] ----------------------------------------------------------------------------- [ 103.873187][ T1127] [ 103.874252][ T1127] INFO: Slab 0x000000005cccc724 objects=5 used=5 fp=0x0000000000000000 flags=0x10000000001020 [ 103.881323][ T1127] CPU: 3 PID: 1127 Comm: hping3 Tainted: G B 5.7.0+ #575 [ 103.882131][ T1127] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 103.883006][ T1127] Call Trace: [ 103.883324][ T1127] dump_stack+0x96/0xdb [ 103.883716][ T1127] slab_err+0xad/0xd0 [ 103.884106][ T1127] ? _raw_spin_unlock+0x1f/0x30 [ 103.884620][ T1127] ? get_partial_node.isra.78+0x140/0x360 [ 103.885214][ T1127] slab_pad_check.part.53+0xf7/0x160 [ 103.885769][ T1127] ? pskb_expand_head+0x110/0xe10 [ 103.886316][ T1127] check_slab+0x97/0xb0 [ 103.886763][ T1127] alloc_debug_processing+0x84/0x1a0 [ 103.887308][ T1127] ___slab_alloc+0x5a5/0x630 [ 103.887765][ T1127] ? pskb_expand_head+0x110/0xe10 [ 103.888265][ T1127] ? lock_downgrade+0x730/0x730 [ 103.888762][ T1127] ? pskb_expand_head+0x110/0xe10 [ 103.889244][ T1127] ? __slab_alloc+0x3e/0x80 [ 103.889675][ T1127] __slab_alloc+0x3e/0x80 [ 103.890108][ T1127] __kmalloc_node_track_caller+0xc7/0x420 [ ... ] Fixes: 11a766ce915f ("net: Increase xmit RECURSION_LIMIT to 10.") Signed-off-by: Taehee Yoo Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f32325b100eaf9d13063b193ca326ba4adf8310f Author: Thomas Martitz Date: Thu Jun 25 14:26:03 2020 +0200 net: bridge: enfore alignment for ethernet address [ Upstream commit db7202dec92e6caa2706c21d6fc359af318bde2e ] The eth_addr member is passed to ether_addr functions that require 2-byte alignment, therefore the member must be properly aligned to avoid unaligned accesses. The problem is in place since the initial merge of multicast to unicast: commit 6db6f0eae6052b70885562e1733896647ec1d807 bridge: multicast to unicast Fixes: 6db6f0eae605 ("bridge: multicast to unicast") Cc: Roopa Prabhu Cc: Nikolay Aleksandrov Cc: David S. Miller Cc: Jakub Kicinski Cc: Felix Fietkau Cc: stable@vger.kernel.org Signed-off-by: Thomas Martitz Acked-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 57a976e676e1caff0614089fd9a61b3c111bd3c6 Author: Sven Auhagen Date: Sun Jun 14 09:19:17 2020 +0200 mvpp2: ethtool rxtx stats fix [ Upstream commit cc970925feb9a38c2f0d34305518e00a3084ce85 ] The ethtool rx and tx queue statistics are reporting wrong values. Fix reading out the correct ones. Signed-off-by: Sven Auhagen Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fa0d7e09da1df4aa14555e9d79ff14e331c6a9ea Author: Wang Hai Date: Thu Jun 11 15:57:50 2020 +0800 mld: fix memory leak in ipv6_mc_destroy_dev() [ Upstream commit ea2fce88d2fd678ed9d45354ff49b73f1d5615dd ] Commit a84d01647989 ("mld: fix memory leak in mld_del_delrec()") fixed the memory leak of MLD, but missing the ipv6_mc_destroy_dev() path, in which mca_sources are leaked after ma_put(). Using ip6_mc_clear_src() to take care of the missing free. BUG: memory leak unreferenced object 0xffff8881113d3180 (size 64): comm "syz-executor071", pid 389, jiffies 4294887985 (age 17.943s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 ff 02 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 ................ backtrace: [<000000002cbc483c>] kmalloc include/linux/slab.h:555 [inline] [<000000002cbc483c>] kzalloc include/linux/slab.h:669 [inline] [<000000002cbc483c>] ip6_mc_add1_src net/ipv6/mcast.c:2237 [inline] [<000000002cbc483c>] ip6_mc_add_src+0x7f5/0xbb0 net/ipv6/mcast.c:2357 [<0000000058b8b1ff>] ip6_mc_source+0xe0c/0x1530 net/ipv6/mcast.c:449 [<000000000bfc4fb5>] do_ipv6_setsockopt.isra.12+0x1b2c/0x3b30 net/ipv6/ipv6_sockglue.c:754 [<00000000e4e7a722>] ipv6_setsockopt+0xda/0x150 net/ipv6/ipv6_sockglue.c:950 [<0000000029260d9a>] rawv6_setsockopt+0x45/0x100 net/ipv6/raw.c:1081 [<000000005c1b46f9>] __sys_setsockopt+0x131/0x210 net/socket.c:2132 [<000000008491f7db>] __do_sys_setsockopt net/socket.c:2148 [inline] [<000000008491f7db>] __se_sys_setsockopt net/socket.c:2145 [inline] [<000000008491f7db>] __x64_sys_setsockopt+0xba/0x150 net/socket.c:2145 [<00000000c7bc11c5>] do_syscall_64+0xa1/0x530 arch/x86/entry/common.c:295 [<000000005fb7a3f3>] entry_SYSCALL_64_after_hwframe+0x49/0xb3 Fixes: 1666d49e1d41 ("mld: do not remove mld souce list info when set link down") Reported-by: Hulk Robot Signed-off-by: Wang Hai Acked-by: Hangbin Liu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 009b3e294a901cb0286ecda179d6e6f0d0ffaa65 Author: Thomas Falcon Date: Thu Jun 18 10:43:46 2020 -0500 ibmveth: Fix max MTU limit [ Upstream commit 5948378b26d89f8aa5eac37629dbd0616ce8d7a7 ] The max MTU limit defined for ibmveth is not accounting for virtual ethernet buffer overhead, which is twenty-two additional bytes set aside for the ethernet header and eight additional bytes of an opaque handle reserved for use by the hypervisor. Update the max MTU to reflect this overhead. Fixes: d894be57ca92 ("ethernet: use net core MTU range checking in more drivers") Fixes: 110447f8269a ("ethernet: fix min/max MTU typos") Signed-off-by: Thomas Falcon Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f060107ccc97619074faa6ee4cfe43664abcbd82 Author: Sabrina Dubroca Date: Thu Jun 18 12:13:22 2020 +0200 geneve: allow changing DF behavior after creation [ Upstream commit 56c09de347e40804fc8dad155272fb9609e0a97b ] Currently, trying to change the DF parameter of a geneve device does nothing: # ip -d link show geneve1 14: geneve1: link/ether geneve id 1 remote 10.0.0.1 ttl auto df set dstport 6081 # ip link set geneve1 type geneve id 1 df unset # ip -d link show geneve1 14: geneve1: link/ether geneve id 1 remote 10.0.0.1 ttl auto df set dstport 6081 We just need to update the value in geneve_changelink. Fixes: a025fb5f49ad ("geneve: Allow configuration of DF behaviour") Signed-off-by: Sabrina Dubroca Reviewed-by: Stefano Brivio Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ce06fcb6a66d22b080385768113ee28bf3593984 Author: Claudiu Manoil Date: Fri Jun 26 19:17:29 2020 +0300 enetc: Fix tx rings bitmap iteration range, irq handling [ Upstream commit 0574e2000fc3103cbc69ba82ec1175ce171fdf5e ] The rings bitmap of an interrupt vector encodes which of the device's rings were assigned to that interrupt vector. Hence the iteration range of the tx rings bitmap (for_each_set_bit()) should be the total number of Tx rings of that netdevice instead of the number of rings assigned to the interrupt vector. Since there are 2 cores, and one interrupt vector for each core, the number of rings asigned to an interrupt vector is half the number of available rings. The impact of this error is that the upper half of the tx rings could still generate interrupts during napi polling. Fixes: d4fd0404c1c9 ("enetc: Introduce basic PF and VF ENETC ethernet drivers") Signed-off-by: Claudiu Manoil Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b90ca32531bf913845a5104689345f9f461f97bb Author: yu kuai Date: Mon Jun 1 20:38:56 2020 +0800 block/bio-integrity: don't free 'buf' if bio_integrity_add_page() failed commit a75ca9303175d36af93c0937dd9b1a6422908b8d upstream. commit e7bf90e5afe3 ("block/bio-integrity: fix a memory leak bug") added a kfree() for 'buf' if bio_integrity_add_page() returns '0'. However, the object will be freed in bio_integrity_free() since 'bio->bi_opf' and 'bio->bi_integrity' were set previousy in bio_integrity_alloc(). Fixes: commit e7bf90e5afe3 ("block/bio-integrity: fix a memory leak bug") Signed-off-by: yu kuai Reviewed-by: Ming Lei Reviewed-by: Bob Liu Acked-by: Martin K. Petersen Signed-off-by: Jens Axboe Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 4e9688ad3d36e8f73c73e435f53da5ae1cd91a70 Author: Greg Kroah-Hartman Date: Wed Jun 24 17:50:53 2020 +0200 Linux 5.4.49 commit 99705220b22ca116457edeae51ae817d056a6622 Author: Ahmed S. Darwish Date: Wed Jun 3 16:49:44 2020 +0200 net: core: device_rename: Use rwsem instead of a seqcount [ Upstream commit 11d6011c2cf29f7c8181ebde6c8bc0c4d83adcd7 ] Sequence counters write paths are critical sections that must never be preempted, and blocking, even for CONFIG_PREEMPTION=n, is not allowed. Commit 5dbe7c178d3f ("net: fix kernel deadlock with interface rename and netdev name retrieval.") handled a deadlock, observed with CONFIG_PREEMPTION=n, where the devnet_rename seqcount read side was infinitely spinning: it got scheduled after the seqcount write side blocked inside its own critical section. To fix that deadlock, among other issues, the commit added a cond_resched() inside the read side section. While this will get the non-preemptible kernel eventually unstuck, the seqcount reader is fully exhausting its slice just spinning -- until TIF_NEED_RESCHED is set. The fix is also still broken: if the seqcount reader belongs to a real-time scheduling policy, it can spin forever and the kernel will livelock. Disabling preemption over the seqcount write side critical section will not work: inside it are a number of GFP_KERNEL allocations and mutex locking through the drivers/base/ :: device_rename() call chain. >From all the above, replace the seqcount with a rwsem. Fixes: 5dbe7c178d3f (net: fix kernel deadlock with interface rename and netdev name retrieval.) Fixes: 30e6c9fa93cf (net: devnet_rename_seq should be a seqcount) Fixes: c91f6df2db49 (sockopt: Change getsockopt() of SO_BINDTODEVICE to return an interface name) Cc: Reported-by: kbuild test robot [ v1 missing up_read() on error exit ] Reported-by: Dan Carpenter [ v1 missing up_read() on error exit ] Signed-off-by: Ahmed S. Darwish Reviewed-by: Sebastian Andrzej Siewior Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e33765201db763d8650c5af99c78875130e9c174 Author: Thomas Gleixner Date: Tue Oct 15 21:18:08 2019 +0200 sched/rt, net: Use CONFIG_PREEMPTION.patch [ Upstream commit 2da2b32fd9346009e9acdb68c570ca8d3966aba7 ] CONFIG_PREEMPTION is selected by CONFIG_PREEMPT and by CONFIG_PREEMPT_RT. Both PREEMPT and PREEMPT_RT require the same functionality which today depends on CONFIG_PREEMPT. Update the comment to use CONFIG_PREEMPTION. Signed-off-by: Thomas Gleixner Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Acked-by: David S. Miller Cc: Linus Torvalds Cc: Peter Zijlstra Cc: netdev@vger.kernel.org Link: https://lore.kernel.org/r/20191015191821.11479-22-bigeasy@linutronix.de Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit a6030d71e62d3e0e270bf3b7fb48d32a636732db Author: Paul Cercueil Date: Wed May 27 13:52:23 2020 +0200 pwm: jz4740: Enhance precision in calculation of duty cycle commit 9017dc4fbd59c09463019ce494cfe36d654495a8 upstream. Calculating the hardware value for the duty from the hardware value of the period resulted in a precision loss versus calculating it from the clock rate directly. (Also remove a cast that doesn't really need to be here) Fixes: f6b8a5700057 ("pwm: Add Ingenic JZ4740 support") Cc: Suggested-by: Uwe Kleine-König Reviewed-by: Uwe Kleine-König Signed-off-by: Paul Cercueil Signed-off-by: Thierry Reding [ukl: backport to v5.4.y and adapt commit log accordingly] Signed-off-by: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman commit d0da4be602882214109dd4444d777c8277e1e048 Author: Alexander Sverdlin Date: Fri May 29 14:17:10 2020 +0200 net: octeon: mgmt: Repair filling of RX ring commit 0c34bb598c510e070160029f34efeeb217000f8d upstream. The removal of mips_swiotlb_ops exposed a problem in octeon_mgmt Ethernet driver. mips_swiotlb_ops had an mb() after most of the operations and the removal of the ops had broken the receive functionality of the driver. My code inspection has shown no other places except octeon_mgmt_rx_fill_ring() where an explicit barrier would be obviously missing. The latter function however has to make sure that "ringing the bell" doesn't happen before RX ring entry is really written. The patch has been successfully tested on Octeon II. Fixes: a999933db9ed ("MIPS: remove mips_swiotlb_ops") Cc: stable@vger.kernel.org Signed-off-by: Alexander Sverdlin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 96d98372b53a98b9769f16cd2c44e9f59ec43be9 Author: Chen Yu Date: Fri May 22 01:59:00 2020 +0800 e1000e: Do not wake up the system via WOL if device wakeup is disabled commit 6bf6be1127f7e6d4bf39f84d56854e944d045d74 upstream. Currently the system will be woken up via WOL(Wake On LAN) even if the device wakeup ability has been disabled via sysfs: cat /sys/devices/pci0000:00/0000:00:1f.6/power/wakeup disabled The system should not be woken up if the user has explicitly disabled the wake up ability for this device. This patch clears the WOL ability of this network device if the user has disabled the wake up ability in sysfs. Fixes: bc7f75fa9788 ("[E1000E]: New pci-express e1000 driver") Reported-by: "Rafael J. Wysocki" Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Chen Yu Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman commit 3d390370d78c4ea967a7f8ce5d0ab0136199eb21 Author: Jiri Olsa Date: Tue May 12 17:03:18 2020 +0900 kretprobe: Prevent triggering kretprobe from within kprobe_flush_task commit 9b38cc704e844e41d9cf74e647bff1d249512cb3 upstream. Ziqian reported lockup when adding retprobe on _raw_spin_lock_irqsave. My test was also able to trigger lockdep output: ============================================ WARNING: possible recursive locking detected 5.6.0-rc6+ #6 Not tainted -------------------------------------------- sched-messaging/2767 is trying to acquire lock: ffffffff9a492798 (&(kretprobe_table_locks[i].lock)){-.-.}, at: kretprobe_hash_lock+0x52/0xa0 but task is already holding lock: ffffffff9a491a18 (&(kretprobe_table_locks[i].lock)){-.-.}, at: kretprobe_trampoline+0x0/0x50 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(kretprobe_table_locks[i].lock)); lock(&(kretprobe_table_locks[i].lock)); *** DEADLOCK *** May be due to missing lock nesting notation 1 lock held by sched-messaging/2767: #0: ffffffff9a491a18 (&(kretprobe_table_locks[i].lock)){-.-.}, at: kretprobe_trampoline+0x0/0x50 stack backtrace: CPU: 3 PID: 2767 Comm: sched-messaging Not tainted 5.6.0-rc6+ #6 Call Trace: dump_stack+0x96/0xe0 __lock_acquire.cold.57+0x173/0x2b7 ? native_queued_spin_lock_slowpath+0x42b/0x9e0 ? lockdep_hardirqs_on+0x590/0x590 ? __lock_acquire+0xf63/0x4030 lock_acquire+0x15a/0x3d0 ? kretprobe_hash_lock+0x52/0xa0 _raw_spin_lock_irqsave+0x36/0x70 ? kretprobe_hash_lock+0x52/0xa0 kretprobe_hash_lock+0x52/0xa0 trampoline_handler+0xf8/0x940 ? kprobe_fault_handler+0x380/0x380 ? find_held_lock+0x3a/0x1c0 kretprobe_trampoline+0x25/0x50 ? lock_acquired+0x392/0xbc0 ? _raw_spin_lock_irqsave+0x50/0x70 ? __get_valid_kprobe+0x1f0/0x1f0 ? _raw_spin_unlock_irqrestore+0x3b/0x40 ? finish_task_switch+0x4b9/0x6d0 ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x40/0x70 The code within the kretprobe handler checks for probe reentrancy, so we won't trigger any _raw_spin_lock_irqsave probe in there. The problem is in outside kprobe_flush_task, where we call: kprobe_flush_task kretprobe_table_lock raw_spin_lock_irqsave _raw_spin_lock_irqsave where _raw_spin_lock_irqsave triggers the kretprobe and installs kretprobe_trampoline handler on _raw_spin_lock_irqsave return. The kretprobe_trampoline handler is then executed with already locked kretprobe_table_locks, and first thing it does is to lock kretprobe_table_locks ;-) the whole lockup path like: kprobe_flush_task kretprobe_table_lock raw_spin_lock_irqsave _raw_spin_lock_irqsave ---> probe triggered, kretprobe_trampoline installed ---> kretprobe_table_locks locked kretprobe_trampoline trampoline_handler kretprobe_hash_lock(current, &head, &flags); <--- deadlock Adding kprobe_busy_begin/end helpers that mark code with fake probe installed to prevent triggering of another kprobe within this code. Using these helpers in kprobe_flush_task, so the probe recursion protection check is hit and the probe is never set to prevent above lockup. Link: http://lkml.kernel.org/r/158927059835.27680.7011202830041561604.stgit@devnote2 Fixes: ef53d9c5e4da ("kprobes: improve kretprobe scalability with hashed locking") Cc: Ingo Molnar Cc: "Gustavo A . R . Silva" Cc: Anders Roxell Cc: "Naveen N . Rao" Cc: Anil S Keshavamurthy Cc: David Miller Cc: Ingo Molnar Cc: Peter Zijlstra Cc: stable@vger.kernel.org Reported-by: "Ziqian SUN (Zamir)" Acked-by: Masami Hiramatsu Signed-off-by: Jiri Olsa Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit c19f0c3c9a8ae6f60d69db33a1d363a97de599d3 Author: Masami Hiramatsu Date: Tue May 12 17:02:56 2020 +0900 kprobes: Fix to protect kick_kprobe_optimizer() by kprobe_mutex commit 1a0aa991a6274161c95a844c58cfb801d681eb59 upstream. In kprobe_optimizer() kick_kprobe_optimizer() is called without kprobe_mutex, but this can race with other caller which is protected by kprobe_mutex. To fix that, expand kprobe_mutex protected area to protect kick_kprobe_optimizer() call. Link: http://lkml.kernel.org/r/158927057586.27680.5036330063955940456.stgit@devnote2 Fixes: cd7ebe2298ff ("kprobes: Use text_poke_smp_batch for optimizing") Cc: Ingo Molnar Cc: "Gustavo A . R . Silva" Cc: Anders Roxell Cc: "Naveen N . Rao" Cc: Anil S Keshavamurthy Cc: David Miller Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Ziqian SUN Cc: stable@vger.kernel.org Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit f4748ee4fa15749f5baa3f387e7b7b6a1fbc6954 Author: Vamshi K Sthambamkadi Date: Mon Jun 15 20:00:38 2020 +0530 tracing/probe: Fix memleak in fetch_op_data operations commit 3aa8fdc37d16735e8891035becf25b3857d3efe0 upstream. kmemleak report: [<57dcc2ca>] __kmalloc_track_caller+0x139/0x2b0 [] kstrndup+0x37/0x80 [] parse_probe_arg.isra.7+0x3cc/0x630 [<055bf2ba>] traceprobe_parse_probe_arg+0x2f5/0x810 [<655a7766>] trace_kprobe_create+0x2ca/0x950 [<4fc6a02a>] create_or_delete_trace_kprobe+0xf/0x30 [<6d1c8a52>] trace_run_command+0x67/0x80 [] trace_parse_run_command+0xa7/0x140 [] probes_write+0x10/0x20 [<2027641c>] __vfs_write+0x30/0x1e0 [<6a4aeee1>] vfs_write+0x96/0x1b0 [<3517fb7d>] ksys_write+0x53/0xc0 [] __ia32_sys_write+0x15/0x20 [] do_syscall_32_irqs_on+0x3d/0x260 [] do_fast_syscall_32+0x39/0xb0 [] entry_SYSENTER_32+0xaf/0x102 Post parse_probe_arg(), the FETCH_OP_DATA operation type is overwritten to FETCH_OP_ST_STRING, as a result memory is never freed since traceprobe_free_probe_arg() iterates only over SYMBOL and DATA op types Setup fetch string operation correctly after fetch_op_data operation. Link: https://lkml.kernel.org/r/20200615143034.GA1734@cosmos Cc: stable@vger.kernel.org Fixes: a42e3c4de964 ("tracing/probe: Add immediate string parameter support") Acked-by: Masami Hiramatsu Signed-off-by: Vamshi K Sthambamkadi Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 7bb62d0cd8ac709dc07cc0b7e84889d4ec09dd66 Author: Eric Biggers Date: Thu Jun 4 11:52:53 2020 -0700 crypto: algboss - don't wait during notifier callback commit 77251e41f89a813b4090f5199442f217bbf11297 upstream. When a crypto template needs to be instantiated, CRYPTO_MSG_ALG_REQUEST is sent to crypto_chain. cryptomgr_schedule_probe() handles this by starting a thread to instantiate the template, then waiting for this thread to complete via crypto_larval::completion. This can deadlock because instantiating the template may require loading modules, and this (apparently depending on userspace) may need to wait for the crc-t10dif module (lib/crc-t10dif.c) to be loaded. But crc-t10dif's module_init function uses crypto_register_notifier() and therefore takes crypto_chain.rwsem for write. That can't proceed until the notifier callback has finished, as it holds this semaphore for read. Fix this by removing the wait on crypto_larval::completion from within cryptomgr_schedule_probe(). It's actually unnecessary because crypto_alg_mod_lookup() calls crypto_larval_wait() itself after sending CRYPTO_MSG_ALG_REQUEST. This only actually became a problem in v4.20 due to commit b76377543b73 ("crc-t10dif: Pick better transform if one becomes available"), but the unnecessary wait was much older. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207159 Reported-by: Mike Gerow Fixes: 398710379f51 ("crypto: algapi - Move larval completion into algboss") Cc: # v3.6+ Cc: Martin K. Petersen Signed-off-by: Eric Biggers Reported-by: Kai Lüke Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 993e0d12f2261e6b4bf2d10c1d6ea14e97d70329 Author: Herbert Xu Date: Fri May 29 14:54:43 2020 +1000 crypto: algif_skcipher - Cap recv SG list at ctx->used commit 7cf81954705b7e5b057f7dc39a7ded54422ab6e1 upstream. Somewhere along the line the cap on the SG list length for receive was lost. This patch restores it and removes the subsequent test which is now redundant. Fixes: 2d97591ef43d ("crypto: af_alg - consolidation of...") Cc: Signed-off-by: Herbert Xu Reviewed-by: Stephan Mueller Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 972f961c5930ffa5de5472f7ced6e9b12bfbbf07 Author: Harry Wentland Date: Thu May 28 09:44:44 2020 -0400 Revert "drm/amd/display: disable dcn20 abm feature for bring up" commit 14ed1c908a7a623cc0cbf0203f8201d1b7d31d16 upstream. This reverts commit 96cb7cf13d8530099c256c053648ad576588c387. This change was used for DCN2 bringup and is no longer desired. In fact it breaks backlight on DCN2 systems. Cc: Alexander Monakov Cc: Hersen Wu Cc: Anthony Koo Cc: Michael Chiu Signed-off-by: Harry Wentland Acked-by: Alex Deucher Reviewed-by: Nicholas Kazlauskas Reported-and-tested-by: Alexander Monakov Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 021935185e2a5e5a65449137ac939754d97f94b0 Author: Imre Deak Date: Fri Jun 12 15:17:31 2020 +0300 drm/i915/icl+: Fix hotplug interrupt disabling after storm detection commit a3005c2edf7e8c3478880db1ca84028a2b6819bb upstream. Atm, hotplug interrupts on TypeC ports are left enabled after detecting an interrupt storm, fix this. Reported-by: Kunal Joshi References: https://gitlab.freedesktop.org/drm/intel/-/issues/351 Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/1964 Cc: Kunal Joshi Cc: stable@vger.kernel.org Signed-off-by: Imre Deak Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20200612121731.19596-1-imre.deak@intel.com (cherry picked from commit 587a87b9d7e94927edcdea018565bc1939381eb1) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit d814e4732cbecfa9b7a40ff0f117876f0dec3c3c Author: Denis Efremov Date: Fri Jun 5 20:37:43 2020 +0300 drm/amd/display: Use kvfree() to free coeff in build_regamma() commit 81921a828b94ce2816932c19a5ec74d302972833 upstream. Use kvfree() instead of kfree() to free coeff in build_regamma() because the memory is allocated with kvzalloc(). Fixes: e752058b8671 ("drm/amd/display: Optimize gamma calculations") Cc: stable@vger.kernel.org Signed-off-by: Denis Efremov Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 50df31ea31cc657e5abf2bf589bdf96ade5eaa55 Author: Jeykumar Sankaran Date: Tue Jun 2 20:37:31 2020 -0700 drm/connector: notify userspace on hotplug after register complete commit 968d81a64a883af2d16dd3f8a6ad6b67db2fde58 upstream. drm connector notifies userspace on hotplug event prematurely before late_register and mode_object register completes. This leads to a race between userspace and kernel on updating the IDR list. So, move the notification to end of connector register. Signed-off-by: Jeykumar Sankaran Signed-off-by: Steve Cohen Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/1591155451-10393-1-git-send-email-jsanka@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit 35bd59b8b68ca471d8890de3bb16def04a8b1d66 Author: Chris Wilson Date: Mon Jun 1 17:19:42 2020 +0100 drm/i915: Whitelist context-local timestamp in the gen9 cmdparser commit 273500ae71711c040d258a7b3f4b6f44c368fff2 upstream. Allow batch buffers to read their own _local_ cumulative HW runtime of their logical context. Fixes: 0f2f39758341 ("drm/i915: Add gen9 BCS cmdparsing") Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: # v5.4+ Reviewed-by: Mika Kuoppala Link: https://patchwork.freedesktop.org/patch/msgid/20200601161942.30854-1-chris@chris-wilson.co.uk (cherry picked from commit f9496520df11de00fbafc3cbd693b9570d600ab3) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit 962d0e0c091cb7c77a9a46fb010617c69f401667 Author: Chris Wilson Date: Fri May 22 14:27:06 2020 +0100 drm/i915/gem: Avoid iterating an empty list commit 757a9395f33c51c4e6eff2c7c0fbd50226a58224 upstream. Our __sgt_iter assumes that the scattergather list has at least one element. But during construction we may fail in allocating the first page, and so mark the first element as the terminator. This is unexpected! [22555.524752] RIP: 0010:shmem_get_pages+0x506/0x710 [i915] [22555.524759] Code: 49 8b 2c 24 31 c0 66 89 44 24 40 48 85 ed 0f 84 62 01 00 00 4c 8b 75 00 8b 5d 08 44 8b 7d 0c 48 8b 0d 7e 34 07 e2 49 83 e6 fc <49> 8b 16 41 01 df 48 89 cf 48 89 d0 48 c1 e8 2d 48 85 c9 0f 84 c8 [22555.524765] RSP: 0018:ffffc9000053f9d0 EFLAGS: 00010246 [22555.524770] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff8881ffffa000 [22555.524774] RDX: fffffffffffffff4 RSI: ffffffffffffffff RDI: ffffffff821efe00 [22555.524778] RBP: ffff8881b099ab00 R08: 0000000000000000 R09: 00000000fffffff4 [22555.524782] R10: 0000000000000002 R11: 00000000ffec0a02 R12: ffff8881cd3c8d60 [22555.524786] R13: 00000000fffffff4 R14: 0000000000000000 R15: 0000000000000000 [22555.524790] FS: 00007f4fbeb9b9c0(0000) GS:ffff8881f8580000(0000) knlGS:0000000000000000 [22555.524795] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [22555.524799] CR2: 0000000000000000 CR3: 00000001ec7f0004 CR4: 00000000001606e0 [22555.524803] Call Trace: [22555.524919] __i915_gem_object_get_pages+0x4f/0x60 [i915] Fixes: 85d1225ec066 ("drm/i915: Introduce & use new lightweight SGL iterators") Signed-off-by: Chris Wilson Cc: Matthew Auld Cc: Tvrtko Ursulin Cc: # v4.8+ Reviewed-by: Matthew Auld Reviewed-by: Maciej Patelczyk Link: https://patchwork.freedesktop.org/patch/msgid/20200522132706.5133-1-chris@chris-wilson.co.uk (cherry picked from commit 957ad9a02be6faa87594c58ac09460cd3d190d0e) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit a09489576fe56ca5535ab425bef63f4f69437613 Author: Jordan Crouse Date: Fri May 1 13:43:26 2020 -0600 drm/msm: Check for powered down HW in the devfreq callbacks commit eadf79286a4badebc95af7061530bdb50a7e6f38 upstream. Writing to the devfreq sysfs nodes while the GPU is powered down can result in a system crash (on a5xx) or a nasty GMU error (on a6xx): $ /sys/class/devfreq/5000000.gpu# echo 500000000 > min_freq [ 104.841625] platform 506a000.gmu: [drm:a6xx_gmu_set_oob] *ERROR* Timeout waiting for GMU OOB set GPU_DCVS: 0x0 Despite the fact that we carefully try to suspend the devfreq device when the hardware is powered down there are lots of holes in the governors that don't check for the suspend state and blindly call into the devfreq callbacks that end up triggering hardware reads in the GPU driver. Call pm_runtime_get_if_in_use() in the gpu_busy() and gpu_set_freq() callbacks to skip the hardware access if it isn't active. v3: Only check pm_runtime_get_if_in_use() for == 0 per Eric Anholt v2: Use pm_runtime_get_if_in_use() per Eric Anholt Cc: stable@vger.kernel.org Reviewed-by: Eric Anholt Signed-off-by: Jordan Crouse Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit 536ffde7df46ad66ac70c3a96c7792a7db9889df Author: Imre Deak Date: Thu May 14 23:45:53 2020 +0300 drm/i915: Fix AUX power domain toggling across TypeC mode resets commit d96536f0fe699729a0974eb5b65eb0d87cc747e1 upstream. Make sure to select the port's AUX power domain while holding the TC port lock. The domain depends on the port's current TC mode, which may get changed under us if we're not holding the lock. This was left out from commit 8c10e2262663 ("drm/i915: Keep the TypeC port mode fixed for detect/AUX transfers") Cc: # v5.4+ Signed-off-by: Imre Deak Reviewed-by: José Roberto de Souza Link: https://patchwork.freedesktop.org/patch/msgid/20200514204553.27193-1-imre.deak@intel.com (cherry picked from commit ae9b6cfe1352da25931bce3ea4acfd4dc1ac8a85) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit 190f6c2d6e388fd07aab5cacfbb552a0315c2cfe Author: Dmitry V. Levin Date: Tue Jun 2 21:00:51 2020 +0300 s390: fix syscall_get_error for compat processes commit b3583fca5fb654af2cfc1c08259abb9728272538 upstream. If both the tracer and the tracee are compat processes, and gprs[2] is assigned a value by __poke_user_compat, then the higher 32 bits of gprs[2] are cleared, IS_ERR_VALUE() always returns false, and syscall_get_error() always returns 0. Fix the implementation by sign-extending the value for compat processes the same way as x86 implementation does. The bug was exposed to user space by commit 201766a20e30f ("ptrace: add PTRACE_GET_SYSCALL_INFO request") and detected by strace test suite. This change fixes strace syscall tampering on s390. Link: https://lkml.kernel.org/r/20200602180051.GA2427@altlinux.org Fixes: 753c4dd6a2fa2 ("[S390] ptrace changes") Cc: Elvira Khabirova Cc: stable@vger.kernel.org # v2.6.28+ Signed-off-by: Dmitry V. Levin Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 2173a7ed6358eb6898b4f8b282855466872ffb9e Author: Eric Biggers Date: Mon Jun 1 13:08:05 2020 -0700 f2fs: avoid utf8_strncasecmp() with unstable name [ Upstream commit fc3bb095ab02b9e7d89a069ade2cead15c64c504 ] If the dentry name passed to ->d_compare() fits in dentry::d_iname, then it may be concurrently modified by a rename. This can cause undefined behavior (possibly out-of-bounds memory accesses or crashes) in utf8_strncasecmp(), since fs/unicode/ isn't written to handle strings that may be concurrently modified. Fix this by first copying the filename to a stack buffer if needed. This way we get a stable snapshot of the filename. Fixes: 2c2eb7a300cd ("f2fs: Support case-insensitive file name lookups") Cc: # v5.4+ Cc: Al Viro Cc: Daniel Rosenberg Cc: Gabriel Krisman Bertazi Signed-off-by: Eric Biggers Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit de3feefa3bfd4276da53aa87a88e4970825320f1 Author: Eric Biggers Date: Thu May 7 00:59:03 2020 -0700 f2fs: split f2fs_d_compare() from f2fs_match_name() [ Upstream commit f874fa1c7c7905c1744a2037a11516558ed00a81 ] Sharing f2fs_ci_compare() between comparing cached dentries (f2fs_d_compare()) and comparing on-disk dentries (f2fs_match_name()) doesn't work as well as intended, as these actions fundamentally differ in several ways (e.g. whether the task may sleep, whether the directory is stable, whether the casefolded name was precomputed, whether the dentry will need to be decrypted once we allow casefold+encrypt, etc.) Just make f2fs_d_compare() implement what it needs directly, and rework f2fs_ci_compare() to be specialized for f2fs_match_name(). Signed-off-by: Eric Biggers Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 9fec865dde6e19309db8f87b0fb220cf110cdd4b Author: Denis Efremov Date: Mon Jun 1 19:45:26 2020 +0300 net/mlx5: DR, Fix freeing in dr_create_rc_qp() [ Upstream commit 47a357de2b6b706af3c9471d5042f9ba8907031e ] Variable "in" in dr_create_rc_qp() is allocated with kvzalloc() and should be freed with kvfree(). Fixes: 297cccebdc5a ("net/mlx5: DR, Expose an internal API to issue RDMA operations") Cc: stable@vger.kernel.org Signed-off-by: Denis Efremov Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 859a0a9afee3159aeebdefa5febc0c96cf919f6b Author: Ahmed S. Darwish Date: Wed Jun 3 16:49:48 2020 +0200 block: nr_sects_write(): Disable preemption on seqcount write [ Upstream commit 15b81ce5abdc4b502aa31dff2d415b79d2349d2f ] For optimized block readers not holding a mutex, the "number of sectors" 64-bit value is protected from tearing on 32-bit architectures by a sequence counter. Disable preemption before entering that sequence counter's write side critical section. Otherwise, the read side can preempt the write side section and spin for the entire scheduler tick. If the reader belongs to a real-time scheduling class, it can spin forever and the kernel will livelock. Fixes: c83f6bf98dc1 ("block: add partition resize function to blkpg ioctl") Cc: Signed-off-by: Ahmed S. Darwish Reviewed-by: Sebastian Andrzej Siewior Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 12030774699056b81f032b421da27e7c746a5950 Author: Ard Biesheuvel Date: Mon Jun 22 19:56:39 2020 +0000 x86/boot/compressed: Relax sed symbol type regex for LLVM ld.lld commit bc310baf2ba381c648983c7f4748327f17324562 upstream. The final build stage of the x86 kernel captures some symbol addresses from the decompressor binary and copies them into zoffset.h. It uses sed with a regular expression that matches the address, symbol type and symbol name, and mangles the captured addresses and the names of symbols of interest into #define directives that are added to zoffset.h The symbol type is indicated by a single letter, which we match strictly: only letters in the set 'ABCDGRSTVW' are matched, even though the actual symbol type is relevant and therefore ignored. Commit bc7c9d620 ("efi/libstub/x86: Force 'hidden' visibility for extern declarations") made a change to the way external symbol references are classified, resulting in 'startup_32' now being emitted as a hidden symbol. This prevents the use of GOT entries to refer to this symbol via its absolute address, which recent toolchains (including Clang based ones) already avoid by default, making this change a no-op in the majority of cases. However, as it turns out, the LLVM linker classifies such hidden symbols as symbols with static linkage in fully linked ELF binaries, causing tools such as NM to output a lowercase 't' rather than an upper case 'T' for the type of such symbols. Since our sed expression only matches upper case letters for the symbol type, the line describing startup_32 is disregarded, resulting in a build error like the following arch/x86/boot/header.S:568:18: error: symbol 'ZO_startup_32' can not be undefined in a subtraction expression init_size: .long (0x00000000008fd000 - ZO_startup_32 + (((0x0000000001f6361c + ((0x0000000001f6361c >> 8) + 65536) - 0x00000000008c32e5) + 4095) & ~4095)) # kernel initialization size Given that we are only interested in the value of the symbol, let's match any character in the set 'a-zA-Z' instead. Signed-off-by: Ard Biesheuvel Signed-off-by: Ingo Molnar Tested-by: Nathan Chancellor Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin commit bba1f4ac037c9841811757c37660aaf711f0207f Author: Ville Syrjälä Date: Thu Oct 10 16:11:57 2019 +0300 drm/amd/display: Use swap() where appropriate [ Upstream commit 34b86b75dfc90ab3d996c224314ce51772a3b351 ] Mostly a cocci-job, but it flat out refused to remove the declaration in drivers/gpu/drm/amd/display/dc/core/dc.c so had to do that part manually. @swap@ identifier TEMP; expression A,B; @@ - TEMP = A; - A = B; - B = TEMP; + swap(A, B); @@ type T; identifier swap.TEMP; @@ ( - T TEMP; | - T TEMP = {...}; ) ... when != TEMP Cc: Harry Wentland Cc: Leo Li Cc: Alex Deucher Cc: "Christian König" Cc: "David (ChunMing) Zhou" Cc: amd-gfx@lists.freedesktop.org Reviewed-by: Nicholas Kazlauskas Signed-off-by: Ville Syrjälä Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 8f16bebbb17124044f73401a4bffa5ad8f7845d4 Author: Lyude Paul Date: Fri Apr 3 15:47:15 2020 -0400 drm/dp_mst: Increase ACT retry timeout to 3s [ Upstream commit 873a95e0d59ac06901ae261dda0b7165ffd002b8 ] Currently we only poll for an ACT up to 30 times, with a busy-wait delay of 100µs between each attempt - giving us a timeout of 2900µs. While this might seem sensible, it would appear that in certain scenarios it can take dramatically longer then that for us to receive an ACT. On one of the EVGA MST hubs that I have available, I observed said hub sometimes taking longer then a second before signalling the ACT. These delays mostly seem to occur when previous sideband messages we've sent are NAKd by the hub, however it wouldn't be particularly surprising if it's possible to reproduce times like this simply by introducing branch devices with large LCTs since payload allocations have to take effect on every downstream device up to the payload's target. So, instead of just retrying 30 times we poll for the ACT for up to 3ms, and additionally use usleep_range() to avoid a very long and rude busy-wait. Note that the previous retry count of 30 appears to have been arbitrarily chosen, as I can't find any mention of a recommended timeout or retry count for ACTs in the DisplayPort 2.0 specification. This also goes for the range we were previously using for udelay(), although I suspect that was just copied from the recommended delay for link training on SST devices. Changes since v1: * Use readx_poll_timeout() instead of open-coding timeout loop - Sean Paul Changes since v2: * Increase poll interval to 200us - Sean Paul * Print status in hex when we timeout waiting for ACT - Sean Paul Signed-off-by: Lyude Paul Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)") Cc: Sean Paul Cc: # v3.17+ Reviewed-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20200406221253.1307209-4-lyude@redhat.com Signed-off-by: Sasha Levin commit ffa9206a62d3894d2a8580bf106db55a85cfb013 Author: Theodore Ts'o Date: Wed Jun 10 11:16:37 2020 -0400 ext4: avoid race conditions when remounting with options that change dax [ Upstream commit 829b37b8cddb1db75c1b7905505b90e593b15db1 ] Trying to change dax mount options when remounting could allow mount options to be enabled for a small amount of time, and then the mount option change would be reverted. In the case of "mount -o remount,dax", this can cause a race where files would temporarily treated as DAX --- and then not. Cc: stable@kernel.org Reported-by: syzbot+bca9799bf129256190da@syzkaller.appspotmail.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 0804b23d2ff15f6656d70291d5e07677ca897881 Author: zhangyi (F) Date: Wed Dec 4 20:46:14 2019 +0800 jbd2: clean __jbd2_journal_abort_hard() and __journal_abort_soft() [ Upstream commit 7f6225e446cc8dfa4c3c7959a4de3dd03ec277bf ] __jbd2_journal_abort_hard() is no longer used, so now we can merge __jbd2_journal_abort_hard() and __journal_abort_soft() these two functions into jbd2_journal_abort() and remove them. Signed-off-by: zhangyi (F) Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20191204124614.45424-5-yi.zhang@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit ae3c09e346bdaf194e6cf5f2b74e29678937b038 Author: Tom Rix Date: Wed Jun 10 14:57:13 2020 -0700 selinux: fix double free commit 65de50969a77509452ae590e9449b70a22b923bb upstream. Clang's static analysis tool reports these double free memory errors. security/selinux/ss/services.c:2987:4: warning: Attempt to free released memory [unix.Malloc] kfree(bnames[i]); ^~~~~~~~~~~~~~~~ security/selinux/ss/services.c:2990:2: warning: Attempt to free released memory [unix.Malloc] kfree(bvalues); ^~~~~~~~~~~~~~ So improve the security_get_bools error handling by freeing these variables and setting their return pointers to NULL and the return len to 0 Cc: stable@vger.kernel.org Signed-off-by: Tom Rix Acked-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 5471b5287cc78905c7a4334cfcc9cd5525c01129 Author: Sandeep Raghuraman Date: Thu Jun 11 01:36:26 2020 +0530 drm/amdgpu: Replace invalid device ID with a valid device ID commit 790243d3bf78f9830a3b2ffbca1ed0f528295d48 upstream. Initializes Powertune data for a specific Hawaii card by fixing what looks like a typo in the code. The device ID 66B1 is not a supported device ID for this driver, and is not mentioned elsewhere. 67B1 is a valid device ID, and is a Hawaii Pro GPU. I have tested on my R9 390 which has device ID 67B1, and it works fine without problems. Signed-off-by: Sandeep Raghuraman Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 3031fb61096ca5cf29cd3d756dc56217f655da2a Author: Huacai Chen Date: Tue Mar 31 14:18:08 2020 +0800 drm/qxl: Use correct notify port address when creating cursor ring commit 80e5f89da3ab949fbbf1cae01dfaea29f5483a75 upstream. The command ring and cursor ring use different notify port addresses definition: QXL_IO_NOTIFY_CMD and QXL_IO_NOTIFY_CURSOR. However, in qxl_device_init() we use QXL_IO_NOTIFY_CMD to create both command ring and cursor ring. This doesn't cause any problems now, because QEMU's behaviors on QXL_IO_NOTIFY_CMD and QXL_IO_NOTIFY_CURSOR are the same. However, QEMU's behavior may be change in future, so let's fix it. P.S.: In the X.org QXL driver, the notify port address of cursor ring is correct. Signed-off-by: Huacai Chen Cc: Link: http://patchwork.freedesktop.org/patch/msgid/1585635488-17507-1-git-send-email-chenhc@lemote.com Signed-off-by: Gerd Hoffmann Signed-off-by: Greg Kroah-Hartman commit 1f3f21d53fa873721783b4e8bb7a9a07fb5c8625 Author: Lyude Paul Date: Fri Apr 3 14:08:32 2020 -0400 drm/dp_mst: Reformat drm_dp_check_act_status() a bit commit a5cb5fa6c3a5c2cf492db667b8670ee7b044b79f upstream. Just add a bit more line wrapping, get rid of some extraneous whitespace, remove an unneeded goto label, and move around some variable declarations. No functional changes here. Signed-off-by: Lyude Paul [this isn't a fix, but it's needed for the fix that comes after this] Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)") Cc: Sean Paul Cc: # v3.17+ Reviewed-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20200406221253.1307209-3-lyude@redhat.com Signed-off-by: Greg Kroah-Hartman commit 8c315a2209307408cd9f68c91603b796dbd5af9f Author: Eric Biggers Date: Mon Jun 1 13:05:43 2020 -0700 ext4: avoid utf8_strncasecmp() with unstable name commit 2ce3ee931a097e9720310db3f09c01c825a4580c upstream. If the dentry name passed to ->d_compare() fits in dentry::d_iname, then it may be concurrently modified by a rename. This can cause undefined behavior (possibly out-of-bounds memory accesses or crashes) in utf8_strncasecmp(), since fs/unicode/ isn't written to handle strings that may be concurrently modified. Fix this by first copying the filename to a stack buffer if needed. This way we get a stable snapshot of the filename. Fixes: b886ee3e778e ("ext4: Support case-insensitive file name lookups") Cc: # v5.2+ Cc: Al Viro Cc: Daniel Rosenberg Cc: Gabriel Krisman Bertazi Signed-off-by: Eric Biggers Reviewed-by: Andreas Dilger Link: https://lore.kernel.org/r/20200601200543.59417-1-ebiggers@kernel.org Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 779286d9babfda4c319e28310653452bc806fb3b Author: Jeffle Xu Date: Fri May 22 12:18:44 2020 +0800 ext4: fix partial cluster initialization when splitting extent commit cfb3c85a600c6aa25a2581b3c1c4db3460f14e46 upstream. Fix the bug when calculating the physical block number of the first block in the split extent. This bug will cause xfstests shared/298 failure on ext4 with bigalloc enabled occasionally. Ext4 error messages indicate that previously freed blocks are being freed again, and the following fsck will fail due to the inconsistency of block bitmap and bg descriptor. The following is an example case: 1. First, Initialize a ext4 filesystem with cluster size '16K', block size '4K', in which case, one cluster contains four blocks. 2. Create one file (e.g., xxx.img) on this ext4 filesystem. Now the extent tree of this file is like: ... 36864:[0]4:220160 36868:[0]14332:145408 51200:[0]2:231424 ... 3. Then execute PUNCH_HOLE fallocate on this file. The hole range is like: .. ext4_ext_remove_space: dev 254,16 ino 12 since 49506 end 49506 depth 1 ext4_ext_remove_space: dev 254,16 ino 12 since 49544 end 49546 depth 1 ext4_ext_remove_space: dev 254,16 ino 12 since 49605 end 49607 depth 1 ... 4. Then the extent tree of this file after punching is like ... 49507:[0]37:158047 49547:[0]58:158087 ... 5. Detailed procedure of punching hole [49544, 49546] 5.1. The block address space: ``` lblk ~49505 49506 49507~49543 49544~49546 49547~ ---------+------+-------------+----------------+-------- extent | hole | extent | hole | extent ---------+------+-------------+----------------+-------- pblk ~158045 158046 158047~158083 158084~158086 158087~ ``` 5.2. The detailed layout of cluster 39521: ``` cluster 39521 <-------------------------------> hole extent <----------------------><-------- lblk 49544 49545 49546 49547 +-------+-------+-------+-------+ | | | | | +-------+-------+-------+-------+ pblk 158084 1580845 158086 158087 ``` 5.3. The ftrace output when punching hole [49544, 49546]: - ext4_ext_remove_space (start 49544, end 49546) - ext4_ext_rm_leaf (start 49544, end 49546, last_extent [49507(158047), 40], partial [pclu 39522 lblk 0 state 2]) - ext4_remove_blocks (extent [49507(158047), 40], from 49544 to 49546, partial [pclu 39522 lblk 0 state 2] - ext4_free_blocks: (block 158084 count 4) - ext4_mballoc_free (extent 1/6753/1) 5.4. Ext4 error message in dmesg: EXT4-fs error (device vdb): mb_free_blocks:1457: group 1, block 158084:freeing already freed block (bit 6753); block bitmap corrupt. EXT4-fs error (device vdb): ext4_mb_generate_buddy:747: group 1, block bitmap and bg descriptor inconsistent: 19550 vs 19551 free clusters In this case, the whole cluster 39521 is freed mistakenly when freeing pblock 158084~158086 (i.e., the first three blocks of this cluster), although pblock 158087 (the last remaining block of this cluster) has not been freed yet. The root cause of this isuue is that, the pclu of the partial cluster is calculated mistakenly in ext4_ext_remove_space(). The correct partial_cluster.pclu (i.e., the cluster number of the first block in the next extent, that is, lblock 49597 (pblock 158086)) should be 39521 rather than 39522. Fixes: f4226d9ea400 ("ext4: fix partial cluster initialization") Signed-off-by: Jeffle Xu Reviewed-by: Eric Whitney Cc: stable@kernel.org # v3.19+ Link: https://lore.kernel.org/r/1590121124-37096-1-git-send-email-jefflexu@linux.alibaba.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit bc615a290faf194b04a54006ad94eec6cb254973 Author: Wolfram Sang Date: Mon Jun 15 09:58:10 2020 +0200 drm: encoder_slave: fix refcouting error for modules [ Upstream commit f78d4032de60f50fd4afaa0fb68ea03b985f820a ] module_put() balances try_module_get(), not request_module(). Fix the error path to match that. Fixes: 2066facca4c7 ("drm/kms: slave encoder interface.") Signed-off-by: Wolfram Sang Reviewed-by: Emil Velikov Acked-by: Daniel Vetter Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit ef4f3b65d5a97fc8385dd8bdd54cc13c7df75b61 Author: Kai-Heng Feng Date: Wed Jun 3 15:48:19 2020 +0800 libata: Use per port sync for detach [ Upstream commit b5292111de9bb70cba3489075970889765302136 ] Commit 130f4caf145c ("libata: Ensure ata_port probe has completed before detach") may cause system freeze during suspend. Using async_synchronize_full() in PM callbacks is wrong, since async callbacks that are already scheduled may wait for not-yet-scheduled callbacks, causes a circular dependency. Instead of using big hammer like async_synchronize_full(), use async cookie to make sure port probe are synced, without affecting other scheduled PM callbacks. Fixes: 130f4caf145c ("libata: Ensure ata_port probe has completed before detach") Suggested-by: John Garry Signed-off-by: Kai-Heng Feng Tested-by: John Garry BugLink: https://bugs.launchpad.net/bugs/1867983 Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 81344ae52c77211c2567db2937dca0de9e0a54a9 Author: Will Deacon Date: Fri May 29 14:12:18 2020 +0100 arm64: hw_breakpoint: Don't invoke overflow handler on uaccess watchpoints [ Upstream commit 24ebec25fb270100e252b19c288e21bd7d8cc7f7 ] Unprivileged memory accesses generated by the so-called "translated" instructions (e.g. STTR) at EL1 can cause EL0 watchpoints to fire unexpectedly if kernel debugging is enabled. In such cases, the hw_breakpoint logic will invoke the user overflow handler which will typically raise a SIGTRAP back to the current task. This is futile when returning back to the kernel because (a) the signal won't have been delivered and (b) userspace can't handle the thing anyway. Avoid invoking the user overflow handler for watchpoints triggered by kernel uaccess routines, and instead single-step over the faulting instruction as we would if no overflow handler had been installed. (Fixes tag identifies the introduction of unprivileged memory accesses, which exposed this latent bug in the hw_breakpoint code) Cc: Catalin Marinas Cc: James Morse Fixes: 57f4959bad0a ("arm64: kernel: Add support for User Access Override") Reported-by: Luis Machado Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 64183b4596247b61c1b8acc37d0564c84924a6e9 Author: Sven Auhagen Date: Tue Jun 16 06:35:29 2020 +0200 mvpp2: remove module bugfix [ Upstream commit 807eaf99688ce162a98a7501477644782d4af098 ] The remove function does not destroy all BM Pools when per cpu pool is active. When reloading the mvpp2 as a module the BM Pools are still active in hardware and due to the bug have twice the size now old + new. This eventually leads to a kernel crash. v2: * add Fixes tag Fixes: 7d04b0b13b11 ("mvpp2: percpu buffers") Signed-off-by: Sven Auhagen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b3dc33946a742256ad9d2ccac848c9e3c2aaafef Author: Jason Yan Date: Tue Jun 16 20:16:55 2020 +0800 block: Fix use-after-free in blkdev_get() [ Upstream commit 2d3a8e2deddea6c89961c422ec0c5b851e648c14 ] In blkdev_get() we call __blkdev_get() to do some internal jobs and if there is some errors in __blkdev_get(), the bdput() is called which means we have released the refcount of the bdev (actually the refcount of the bdev inode). This means we cannot access bdev after that point. But acctually bdev is still accessed in blkdev_get() after calling __blkdev_get(). This results in use-after-free if the refcount is the last one we released in __blkdev_get(). Let's take a look at the following scenerio: CPU0 CPU1 CPU2 blkdev_open blkdev_open Remove disk bd_acquire blkdev_get __blkdev_get del_gendisk bdev_unhash_inode bd_acquire bdev_get_gendisk bd_forget failed because of unhashed bdput bdput (the last one) bdev_evict_inode access bdev => use after free [ 459.350216] BUG: KASAN: use-after-free in __lock_acquire+0x24c1/0x31b0 [ 459.351190] Read of size 8 at addr ffff88806c815a80 by task syz-executor.0/20132 [ 459.352347] [ 459.352594] CPU: 0 PID: 20132 Comm: syz-executor.0 Not tainted 4.19.90 #2 [ 459.353628] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 [ 459.354947] Call Trace: [ 459.355337] dump_stack+0x111/0x19e [ 459.355879] ? __lock_acquire+0x24c1/0x31b0 [ 459.356523] print_address_description+0x60/0x223 [ 459.357248] ? __lock_acquire+0x24c1/0x31b0 [ 459.357887] kasan_report.cold+0xae/0x2d8 [ 459.358503] __lock_acquire+0x24c1/0x31b0 [ 459.359120] ? _raw_spin_unlock_irq+0x24/0x40 [ 459.359784] ? lockdep_hardirqs_on+0x37b/0x580 [ 459.360465] ? _raw_spin_unlock_irq+0x24/0x40 [ 459.361123] ? finish_task_switch+0x125/0x600 [ 459.361812] ? finish_task_switch+0xee/0x600 [ 459.362471] ? mark_held_locks+0xf0/0xf0 [ 459.363108] ? __schedule+0x96f/0x21d0 [ 459.363716] lock_acquire+0x111/0x320 [ 459.364285] ? blkdev_get+0xce/0xbe0 [ 459.364846] ? blkdev_get+0xce/0xbe0 [ 459.365390] __mutex_lock+0xf9/0x12a0 [ 459.365948] ? blkdev_get+0xce/0xbe0 [ 459.366493] ? bdev_evict_inode+0x1f0/0x1f0 [ 459.367130] ? blkdev_get+0xce/0xbe0 [ 459.367678] ? destroy_inode+0xbc/0x110 [ 459.368261] ? mutex_trylock+0x1a0/0x1a0 [ 459.368867] ? __blkdev_get+0x3e6/0x1280 [ 459.369463] ? bdev_disk_changed+0x1d0/0x1d0 [ 459.370114] ? blkdev_get+0xce/0xbe0 [ 459.370656] blkdev_get+0xce/0xbe0 [ 459.371178] ? find_held_lock+0x2c/0x110 [ 459.371774] ? __blkdev_get+0x1280/0x1280 [ 459.372383] ? lock_downgrade+0x680/0x680 [ 459.373002] ? lock_acquire+0x111/0x320 [ 459.373587] ? bd_acquire+0x21/0x2c0 [ 459.374134] ? do_raw_spin_unlock+0x4f/0x250 [ 459.374780] blkdev_open+0x202/0x290 [ 459.375325] do_dentry_open+0x49e/0x1050 [ 459.375924] ? blkdev_get_by_dev+0x70/0x70 [ 459.376543] ? __x64_sys_fchdir+0x1f0/0x1f0 [ 459.377192] ? inode_permission+0xbe/0x3a0 [ 459.377818] path_openat+0x148c/0x3f50 [ 459.378392] ? kmem_cache_alloc+0xd5/0x280 [ 459.379016] ? entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 459.379802] ? path_lookupat.isra.0+0x900/0x900 [ 459.380489] ? __lock_is_held+0xad/0x140 [ 459.381093] do_filp_open+0x1a1/0x280 [ 459.381654] ? may_open_dev+0xf0/0xf0 [ 459.382214] ? find_held_lock+0x2c/0x110 [ 459.382816] ? lock_downgrade+0x680/0x680 [ 459.383425] ? __lock_is_held+0xad/0x140 [ 459.384024] ? do_raw_spin_unlock+0x4f/0x250 [ 459.384668] ? _raw_spin_unlock+0x1f/0x30 [ 459.385280] ? __alloc_fd+0x448/0x560 [ 459.385841] do_sys_open+0x3c3/0x500 [ 459.386386] ? filp_open+0x70/0x70 [ 459.386911] ? trace_hardirqs_on_thunk+0x1a/0x1c [ 459.387610] ? trace_hardirqs_off_caller+0x55/0x1c0 [ 459.388342] ? do_syscall_64+0x1a/0x520 [ 459.388930] do_syscall_64+0xc3/0x520 [ 459.389490] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 459.390248] RIP: 0033:0x416211 [ 459.390720] Code: 75 14 b8 02 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 04 19 00 00 c3 48 83 ec 08 e8 0a fa ff ff 48 89 04 24 b8 02 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2 e8 53 fa ff ff 48 89 d0 48 83 c4 08 48 3d 01 [ 459.393483] RSP: 002b:00007fe45dfe9a60 EFLAGS: 00000293 ORIG_RAX: 0000000000000002 [ 459.394610] RAX: ffffffffffffffda RBX: 00007fe45dfea6d4 RCX: 0000000000416211 [ 459.395678] RDX: 00007fe45dfe9b0a RSI: 0000000000000002 RDI: 00007fe45dfe9b00 [ 459.396758] RBP: 000000000076bf20 R08: 0000000000000000 R09: 000000000000000a [ 459.397930] R10: 0000000000000075 R11: 0000000000000293 R12: 00000000ffffffff [ 459.399022] R13: 0000000000000bd9 R14: 00000000004cdb80 R15: 000000000076bf2c [ 459.400168] [ 459.400430] Allocated by task 20132: [ 459.401038] kasan_kmalloc+0xbf/0xe0 [ 459.401652] kmem_cache_alloc+0xd5/0x280 [ 459.402330] bdev_alloc_inode+0x18/0x40 [ 459.402970] alloc_inode+0x5f/0x180 [ 459.403510] iget5_locked+0x57/0xd0 [ 459.404095] bdget+0x94/0x4e0 [ 459.404607] bd_acquire+0xfa/0x2c0 [ 459.405113] blkdev_open+0x110/0x290 [ 459.405702] do_dentry_open+0x49e/0x1050 [ 459.406340] path_openat+0x148c/0x3f50 [ 459.406926] do_filp_open+0x1a1/0x280 [ 459.407471] do_sys_open+0x3c3/0x500 [ 459.408010] do_syscall_64+0xc3/0x520 [ 459.408572] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 459.409415] [ 459.409679] Freed by task 1262: [ 459.410212] __kasan_slab_free+0x129/0x170 [ 459.410919] kmem_cache_free+0xb2/0x2a0 [ 459.411564] rcu_process_callbacks+0xbb2/0x2320 [ 459.412318] __do_softirq+0x225/0x8ac Fix this by delaying bdput() to the end of blkdev_get() which means we have finished accessing bdev. Fixes: 77ea887e433a ("implement in-kernel gendisk events handling") Reported-by: Hulk Robot Signed-off-by: Jason Yan Tested-by: Sedat Dilek Reviewed-by: Jan Kara Reviewed-by: Christoph Hellwig Reviewed-by: Dan Carpenter Cc: Christoph Hellwig Cc: Jens Axboe Cc: Ming Lei Cc: Jan Kara Cc: Dan Carpenter Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit cb5fe511b11eb785749fbe4a45416318cc1553db Author: Dinghao Liu Date: Fri May 22 12:59:29 2020 +0800 scsi: ufs-bsg: Fix runtime PM imbalance on error [ Upstream commit a1e17eb03e69bb61bd1b1a14610436b7b9be12d9 ] When ufs_bsg_alloc_desc_buffer() returns an error code, a pairing runtime PM usage counter decrement is needed to keep the counter balanced. Link: https://lore.kernel.org/r/20200522045932.31795-1-dinghao.liu@zju.edu.cn Fixes: 74e5e468b664 (scsi: ufs-bsg: Wake the device before sending raw upiu commands) Reviewed-by: Avri Altman Signed-off-by: Dinghao Liu Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 7c7dd0507842bbecbf79c37b2e053be6075e3449 Author: Vasundhara Volam Date: Sun Jun 14 19:57:10 2020 -0400 bnxt_en: Return from timer if interface is not in open state. [ Upstream commit e000940473d1423a42ef9c823fb23ccffe3f07ea ] This will avoid many uneccessary error logs when driver or firmware is in reset. Fixes: 230d1f0de754 ("bnxt_en: Handle firmware reset.") Signed-off-by: Vasundhara Volam Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 13e6e75e68f31164c5ab4407e42afdf80127e328 Author: David Howells Date: Sun Jun 14 22:12:05 2020 +0100 afs: Fix the mapping of the UAEOVERFLOW abort code [ Upstream commit 4ec89596d06bd481ba827f3b409b938d63914157 ] Abort code UAEOVERFLOW is returned when we try and set a time that's out of range, but it's currently mapped to EREMOTEIO by the default case. Fix UAEOVERFLOW to map instead to EOVERFLOW. Found with the generic/258 xfstest. Note that the test is wrong as it assumes that the filesystem will support a pre-UNIX-epoch date. Fixes: 1eda8bab70ca ("afs: Add support for the UAE error table") Signed-off-by: David Howells Signed-off-by: Sasha Levin commit b7420726bc8a7883b52ec1475788ecea305dfbcf Author: David Howells Date: Wed Apr 8 16:13:20 2020 +0100 afs: Set error flag rather than return error from file status decode [ Upstream commit 38355eec6a7d2b8f2f313f9174736dc877744e59 ] Set a flag in the call struct to indicate an unmarshalling error rather than return and handle an error from the decoding of file statuses. This flag is checked on a successful return from the delivery function. Signed-off-by: David Howells Signed-off-by: Sasha Levin commit 66f38da13198e9abb1b42804aad03d5c5326cdb3 Author: David Howells Date: Thu Apr 16 14:20:32 2020 +0100 afs: Always include dir in bulk status fetch from afs_do_lookup() [ Upstream commit 13fcc6356a94558a0a4857dc00cd26b3834a1b3e ] When a lookup is done in an AFS directory, the filesystem will speculate and fetch up to 49 other statuses for files in the same directory and fetch those as well, turning them into inodes or updating inodes that already exist. However, occasionally, a callback break might go missing due to NAT timing out, but the afs filesystem doesn't then realise that the directory is not up to date. Alleviate this by using one of the status slots to check the directory in which the lookup is being done. Reported-by: Dave Botsch Suggested-by: Jeffrey Altman Signed-off-by: David Howells Signed-off-by: Sasha Levin commit 4fd68a35f62d51380ca5d9d568851261b84fc551 Author: David Howells Date: Sat Jun 13 00:03:48 2020 +0100 afs: Fix EOF corruption [ Upstream commit 3f4aa981816368fe6b1d13c2bfbe76df9687e787 ] When doing a partial writeback, afs_write_back_from_locked_page() may generate an FS.StoreData RPC request that writes out part of a file when a file has been constructed from pieces by doing seek, write, seek, write, ... as is done by ld. The FS.StoreData RPC is given the current i_size as the file length, but the server basically ignores it unless the data length is 0 (in which case it's just a truncate operation). The revised file length returned in the result of the RPC may then not reflect what we suggested - and this leads to i_size getting moved backwards - which causes issues later. Fix the client to take account of this by ignoring the returned file size unless the data version number jumped unexpectedly - in which case we're going to have to clear the pagecache and reload anyway. This can be observed when doing a kernel build on an AFS mount. The following pair of commands produce the issue: ld -m elf_x86_64 -z max-page-size=0x200000 --emit-relocs \ -T arch/x86/realmode/rm/realmode.lds \ arch/x86/realmode/rm/header.o \ arch/x86/realmode/rm/trampoline_64.o \ arch/x86/realmode/rm/stack.o \ arch/x86/realmode/rm/reboot.o \ -o arch/x86/realmode/rm/realmode.elf arch/x86/tools/relocs --realmode \ arch/x86/realmode/rm/realmode.elf \ >arch/x86/realmode/rm/realmode.relocs This results in the latter giving: Cannot read ELF section headers 0/18: Success as the realmode.elf file got corrupted. The sequence of events can also be driven with: xfs_io -t -f \ -c "pwrite -S 0x58 0 0x58" \ -c "pwrite -S 0x59 10000 1000" \ -c "close" \ /afs/example.com/scratch/a Fixes: 31143d5d515e ("AFS: implement basic file write support") Signed-off-by: David Howells Signed-off-by: Sasha Levin commit c8c19fcdabdbcc923564cc9258b01db3c0e0ed22 Author: David Howells Date: Fri Jun 12 23:58:51 2020 +0100 afs: afs_write_end() should change i_size under the right lock [ Upstream commit 1f32ef79897052ef7d3d154610d8d6af95abde83 ] Fix afs_write_end() to change i_size under vnode->cb_lock rather than ->wb_lock so that it doesn't race with afs_vnode_commit_status() and afs_getattr(). The ->wb_lock is only meant to guard access to ->wb_keys which isn't accessed by that piece of code. Fixes: 4343d00872e1 ("afs: Get rid of the afs_writeback record") Signed-off-by: David Howells Signed-off-by: Sasha Levin commit 6a9fd8046fbd32248b5f18c023c2689834e5ff95 Author: David Howells Date: Fri Jun 12 00:15:13 2020 +0100 afs: Fix non-setting of mtime when writing into mmap [ Upstream commit bb413489288e4e457353bac513fddb6330d245ca ] The mtime on an inode needs to be updated when a write is made into an mmap'ed section. There are three ways in which this could be done: update it when page_mkwrite is called, update it when a page is changed from dirty to writeback or leave it to the server and fix the mtime up from the reply to the StoreData RPC. Found with the generic/215 xfstest. Fixes: 1cf7a1518aef ("afs: Implement shared-writeable mmap") Signed-off-by: David Howells Signed-off-by: Sasha Levin commit 7b307d292ab26ef6a9b85754a608aa2b5b607318 Author: Aneesh Kumar K.V Date: Sun May 24 15:08:19 2020 +0530 powerpc: Fix kernel crash in show_instructions() w/DEBUG_VIRTUAL [ Upstream commit a6e2c226c3d51fd93636320e47cabc8a8f0824c5 ] With CONFIG_DEBUG_VIRTUAL=y, we can hit a BUG() if we take a hard lockup watchdog interrupt when in OPAL mode. This happens in show_instructions() if the kernel takes the watchdog NMI IPI, or any other interrupt, with MSR_IR == 0. show_instructions() updates the variable pc in the loop and the second iteration will result in BUG(). We hit the BUG_ON due the below check in __va() #define __va(x) ({ VIRTUAL_BUG_ON((unsigned long)(x) >= PAGE_OFFSET); (void *)(unsigned long)((phys_addr_t)(x) | PAGE_OFFSET); }) Fix it by moving the check out of the loop. Also update nip so that the nip == pc check still matches. Fixes: 4dd7554a6456 ("powerpc/64: Add VIRTUAL_BUG_ON checks for __va and __pa addresses") Signed-off-by: Aneesh Kumar K.V [mpe: Use IS_ENABLED(), massage change log] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200524093822.423487-1-aneesh.kumar@linux.ibm.com Signed-off-by: Sasha Levin commit f651e94899ed08b1766bda30f410d33fdd3970ff Author: Zhiqiang Liu Date: Mon Jun 15 00:53:30 2020 +0800 bcache: fix potential deadlock problem in btree_gc_coalesce [ Upstream commit be23e837333a914df3f24bf0b32e87b0331ab8d1 ] coccicheck reports: drivers/md//bcache/btree.c:1538:1-7: preceding lock on line 1417 In btree_gc_coalesce func, if the coalescing process fails, we will goto to out_nocoalesce tag directly without releasing new_nodes[i]->write_lock. Then, it will cause a deadlock when trying to acquire new_nodes[i]-> write_lock for freeing new_nodes[i] before return. btree_gc_coalesce func details as follows: if alloc new_nodes[i] fails: goto out_nocoalesce; // obtain new_nodes[i]->write_lock mutex_lock(&new_nodes[i]->write_lock) // main coalescing process for (i = nodes - 1; i > 0; --i) [snipped] if coalescing process fails: // Here, directly goto out_nocoalesce // tag will cause a deadlock goto out_nocoalesce; [snipped] // release new_nodes[i]->write_lock mutex_unlock(&new_nodes[i]->write_lock) // coalesing succ, return return; out_nocoalesce: btree_node_free(new_nodes[i]) // free new_nodes[i] // obtain new_nodes[i]->write_lock mutex_lock(&new_nodes[i]->write_lock); // set flag for reuse clear_bit(BTREE_NODE_dirty, &ew_nodes[i]->flags); // release new_nodes[i]->write_lock mutex_unlock(&new_nodes[i]->write_lock); To fix the problem, we add a new tag 'out_unlock_nocoalesce' for releasing new_nodes[i]->write_lock before out_nocoalesce tag. If coalescing process fails, we will go to out_unlock_nocoalesce tag for releasing new_nodes[i]->write_lock before free new_nodes[i] in out_nocoalesce tag. (Coly Li helps to clean up commit log format.) Fixes: 2a285686c109816 ("bcache: btree locking rework") Signed-off-by: Zhiqiang Liu Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 889b69a9982b6b9db212af307a1c50c2462a1d16 Author: yangerkun Date: Mon Jun 1 15:34:04 2020 +0800 ext4: stop overwrite the errcode in ext4_setup_super [ Upstream commit 5adaccac46ea79008d7b75f47913f1a00f91d0ce ] Now the errcode from ext4_commit_super will overwrite EROFS exists in ext4_setup_super. Actually, no need to call ext4_commit_super since we will return EROFS. Fix it by goto done directly. Fixes: c89128a00838 ("ext4: handle errors on ext4_commit_super") Signed-off-by: yangerkun Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20200601073404.3712492-1-yangerkun@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit aa7baef53057780bf7b47fb3256c4452eb228b32 Author: Hongbo Yao Date: Fri Jun 5 17:17:40 2020 +0800 perf stat: Fix NULL pointer dereference [ Upstream commit c0c652fc705de75f4ba52e93053acc1ed3933e74 ] If config->aggr_map is NULL and config->aggr_get_id is not NULL, the function print_aggr() will still calling arrg_update_shadow(), which can result in accessing the invalid pointer. Fixes: 088519f318be ("perf stat: Move the display functions to stat-display.c") Signed-off-by: Hongbo Yao Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Wei Li Link: https://lore.kernel.org/lkml/20200608163625.GC3073@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 676634f1a831194649b867e43b4cd1d75ecf9372 Author: Gaurav Singh Date: Mon Jun 8 13:18:17 2020 -0300 perf report: Fix NULL pointer dereference in hists__fprintf_nr_sample_events() [ Upstream commit 11b6e5482e178055ec1f2444b55f2518713809d1 ] The 'evname' variable can be NULL, as it is checked a few lines back, check it before using. Fixes: 9e207ddfa207 ("perf report: Show call graph from reference events") Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/ Signed-off-by: Gaurav Singh Signed-off-by: Sasha Levin commit 335d720bb4bd9d2808cae5af6f3c636c87f19596 Author: Qais Yousef Date: Mon May 18 16:49:31 2020 +0100 usb/ehci-platform: Set PM runtime as active on resume [ Upstream commit 16bdc04cc98ab0c74392ceef2475ecc5e73fcf49 ] Follow suit of ohci-platform.c and perform pm_runtime_set_active() on resume. ohci-platform.c had a warning reported due to the missing pm_runtime_set_active() [1]. [1] https://lore.kernel.org/lkml/20200323143857.db5zphxhq4hz3hmd@e107158-lin.cambridge.arm.com/ Acked-by: Alan Stern Signed-off-by: Qais Yousef CC: Tony Prisk CC: Greg Kroah-Hartman CC: Mathias Nyman CC: Oliver Neukum CC: linux-arm-kernel@lists.infradead.org CC: linux-usb@vger.kernel.org CC: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/r/20200518154931.6144-3-qais.yousef@arm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 21a45a1427dd16c7a07da2d53df190688f9f716c Author: Yoshihiro Shimoda Date: Mon Jan 27 17:37:42 2020 +0900 usb: host: ehci-platform: add a quirk to avoid stuck [ Upstream commit cc7eac1e4afdd151085be4d0341a155760388653 ] Since EHCI/OHCI controllers on R-Car Gen3 SoCs are possible to be getting stuck very rarely after a full/low usb device was disconnected. To detect/recover from such a situation, the controllers require a special way which poll the EHCI PORTSC register and changes the OHCI functional state. So, this patch adds a polling timer into the ehci-platform driver, and if the ehci driver detects the issue by the EHCI PORTSC register, the ehci driver removes a companion device (= the OHCI controller) to change the OHCI functional state to USB Reset once. And then, the ehci driver adds the companion device again. Signed-off-by: Yoshihiro Shimoda Acked-by: Alan Stern Link: https://lore.kernel.org/r/1580114262-25029-1-git-send-email-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 57a1cd87efb9279ab58aae2e5c41920150e31873 Author: Qais Yousef Date: Mon May 18 16:49:30 2020 +0100 usb/xhci-plat: Set PM runtime as active on resume [ Upstream commit 79112cc3c29f4a8c73a21428fbcbcb0afb005e3e ] Follow suit of ohci-platform.c and perform pm_runtime_set_active() on resume. ohci-platform.c had a warning reported due to the missing pm_runtime_set_active() [1]. [1] https://lore.kernel.org/lkml/20200323143857.db5zphxhq4hz3hmd@e107158-lin.cambridge.arm.com/ Signed-off-by: Qais Yousef CC: Tony Prisk CC: Greg Kroah-Hartman CC: Mathias Nyman CC: Oliver Neukum CC: linux-arm-kernel@lists.infradead.org CC: linux-usb@vger.kernel.org CC: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/r/20200518154931.6144-2-qais.yousef@arm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 33a76c15c7c2d374d4524865dbb1c2b73794c860 Author: Andrey Ignatov Date: Thu Jun 11 17:08:57 2020 -0700 bpf: Fix memlock accounting for sock_hash [ Upstream commit 60e5ca8a64bad8f3e2e20a1e57846e497361c700 ] Add missed bpf_map_charge_init() in sock_hash_alloc() and correspondingly bpf_map_charge_finish() on ENOMEM. It was found accidentally while working on unrelated selftest that checks "map->memory.pages > 0" is true for all map types. Before: # bpftool m l ... 3692: sockhash name m_sockhash flags 0x0 key 4B value 4B max_entries 8 memlock 0B After: # bpftool m l ... 84: sockmap name m_sockmap flags 0x0 key 4B value 4B max_entries 8 memlock 4096B Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by: Andrey Ignatov Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200612000857.2881453-1-rdna@fb.com Signed-off-by: Sasha Levin commit 93b67573654200ce430b3e6c5bc77a81ed7c371d Author: Brett Creeley Date: Fri Jun 5 10:09:43 2020 -0700 iavf: fix speed reporting over virtchnl [ Upstream commit e0ef26fbe2b0c62f42ba7667076dc38b693b6fb8 ] Link speeds are communicated over virtchnl using an enum virtchnl_link_speed. Currently, the highest link speed is 40Gbps which leaves us unable to reflect some speeds that an ice VF is capable of. This causes link speed to be misreported on the iavf driver. Allow for communicating link speeds using Mbps so that the proper speed can be reported for an ice VF. Moving away from the enum allows us to communicate future speed changes without requiring a new enum to be added. In order to support communicating link speeds over virtchnl in Mbps the following functionality was added: - Added u32 link_speed_mbps in the iavf_adapter structure. - Added the macro ADV_LINK_SUPPORT(_a) to determine if the VF driver supports communicating link speeds in Mbps. - Added the function iavf_get_vpe_link_status() to fill the correct link_status in the event_data union based on the ADV_LINK_SUPPORT(_a) macro. - Added the function iavf_set_adapter_link_speed_from_vpe() to determine whether or not to fill the u32 link_speed_mbps or enum virtchnl_link_speed link_speed field in the iavf_adapter structure based on the ADV_LINK_SUPPORT(_a) macro. - Do not free vf_res in iavf_init_get_resources() as vf_res will be accessed in iavf_get_link_ksettings(); memset to 0 instead. This memory is subsequently freed in iavf_remove(). Fixes: 7c710869d64e ("ice: Add handlers for VF netdevice operations") Signed-off-by: Brett Creeley Signed-off-by: Sergey Nemov Signed-off-by: Paul Greenwalt Signed-off-by: Tony Nguyen Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit e7847db7aa6d3c44f87286f779d1b956a38e5b4d Author: Li RongQing Date: Thu Jun 11 13:11:06 2020 +0800 xdp: Fix xsk_generic_xmit errno [ Upstream commit aa2cad0600ed2ca6a0ab39948d4db1666b6c962b ] Propagate sock_alloc_send_skb error code, not set it to EAGAIN unconditionally, when fail to allocate skb, which might cause that user space unnecessary loops. Fixes: 35fcde7f8deb ("xsk: support for Tx") Signed-off-by: Li RongQing Signed-off-by: Daniel Borkmann Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/1591852266-24017-1-git-send-email-lirongqing@baidu.com Signed-off-by: Sasha Levin commit 57f71bb57f7c74ab06855dba30dd68935168fb7c Author: Zheng Bin Date: Thu May 21 17:17:21 2020 +0800 nfs: set invalid blocks after NFSv4 writes [ Upstream commit 3a39e778690500066b31fe982d18e2e394d3bce2 ] Use the following command to test nfsv4(size of file1M is 1MB): mount -t nfs -o vers=4.0,actimeo=60 127.0.0.1/dir1 /mnt cp file1M /mnt du -h /mnt/file1M -->0 within 60s, then 1M When write is done(cp file1M /mnt), will call this: nfs_writeback_done nfs4_write_done nfs4_write_done_cb nfs_writeback_update_inode nfs_post_op_update_inode_force_wcc_locked(change, ctime, mtime nfs_post_op_update_inode_force_wcc_locked nfs_set_cache_invalid nfs_refresh_inode_locked nfs_update_inode nfsd write response contains change, ctime, mtime, the flag will be clear after nfs_update_inode. Howerver, write response does not contain space_used, previous open response contains space_used whose value is 0, so inode->i_blocks is still 0. nfs_getattr -->called by "du -h" do_update |= force_sync || nfs_attribute_cache_expired -->false in 60s cache_validity = READ_ONCE(NFS_I(inode)->cache_validity) do_update |= cache_validity & (NFS_INO_INVALID_ATTR -->false if (do_update) { __nfs_revalidate_inode } Within 60s, does not send getattr request to nfsd, thus "du -h /mnt/file1M" is 0. Add a NFS_INO_INVALID_BLOCKS flag, set it when nfsv4 write is done. Fixes: 16e143751727 ("NFS: More fine grained attribute tracking") Signed-off-by: Zheng Bin Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit d3caf0e49492943927b4a831f88df3cb09de68eb Author: Christoph Hellwig Date: Wed Jun 3 08:24:17 2020 +0200 nvme-pci: use simple suspend when a HMB is enabled [ Upstream commit b97120b15ebd3de51325084136d3b9c3cce656d6 ] While the NVMe specification allows the device to access the host memory buffer in host DRAM from all power states, hosts will fail access to DRAM during S3 and similar power states. Fixes: d916b1be94b6 ("nvme-pci: use host managed power state for suspend") Signed-off-by: Christoph Hellwig Reviewed-by: Keith Busch Reviewed-by: Sagi Grimberg Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 9777d12a8b232b8134401cd56c9027caa9fe59c6 Author: YiFei Zhu Date: Wed Jun 10 13:41:39 2020 -0500 net/filter: Permit reading NET in load_bytes_relative when MAC not set [ Upstream commit 0f5d82f187e1beda3fe7295dfc500af266a5bd80 ] Added a check in the switch case on start_header that checks for the existence of the header, and in the case that MAC is not set and the caller requests for MAC, -EFAULT. If the caller requests for NET then MAC's existence is completely ignored. There is no function to check NET header's existence and as far as cgroup_skb/egress is concerned it should always be set. Removed for ptr >= the start of header, considering offset is bounded unsigned and should always be true. len <= end - mac is redundant to ptr + len <= end. Fixes: 3eee1f75f2b9 ("bpf: fix bpf_skb_load_bytes_relative pkt length check") Signed-off-by: YiFei Zhu Signed-off-by: Daniel Borkmann Reviewed-by: Stanislav Fomichev Link: https://lore.kernel.org/bpf/76bb820ddb6a95f59a772ecbd8c8a336f646b362.1591812755.git.zhuyifei@google.com Signed-off-by: Sasha Levin commit 0eb4e1573ffd0721421a70727622c5a242643ea6 Author: Vitaly Kuznetsov Date: Tue Apr 28 11:38:24 2020 +0200 x86/idt: Keep spurious entries unset in system_vectors [ Upstream commit 1f1fbc70c10e81f70e9fbe2102d439c883269811 ] With commit dc20b2d52653 ("x86/idt: Move interrupt gate initialization to IDT code") non assigned system vectors are also marked as used in 'used_vectors' (now 'system_vectors') bitmap. This makes checks in arch_show_interrupts() whether a particular system vector is allocated to always pass and e.g. 'Hyper-V reenlightenment interrupts' entry always shows up in /proc/interrupts. Another side effect of having all unassigned system vectors marked as used is that irq_matrix_debug_show() will wrongly count them among 'System' vectors. As it is now ensured that alloc_intr_gate() is not called after init, it is possible to leave unused entries in 'system_vectors' unset to fix these issues. Signed-off-by: Vitaly Kuznetsov Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/20200428093824.1451532-4-vkuznets@redhat.com Signed-off-by: Sasha Levin commit 04ce5f6f0d3cd290fdf8e65d422e135abaf21e85 Author: Christophe JAILLET Date: Sat May 30 10:16:22 2020 +0200 scsi: acornscsi: Fix an error handling path in acornscsi_probe() [ Upstream commit 42c76c9848e13dbe0538d7ae0147a269dfa859cb ] 'ret' is known to be 0 at this point. Explicitly return -ENOMEM if one of the 'ecardm_iomap()' calls fail. Link: https://lore.kernel.org/r/20200530081622.577888-1-christophe.jaillet@wanadoo.fr Fixes: e95a1b656a98 ("[ARM] rpc: acornscsi: update to new style ecard driver") Signed-off-by: Christophe JAILLET Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f3f9ee422842586f8fe0e807f303137c07e994ca Author: Andrii Nakryiko Date: Tue Jun 9 22:23:35 2020 -0700 libbpf: Handle GCC noreturn-turned-volatile quirk [ Upstream commit 32022fd97ed34f6812802bf1288db27c313576f4 ] Handle a GCC quirk of emitting extra volatile modifier in DWARF (and subsequently preserved in BTF by pahole) for function pointers marked as __attribute__((noreturn)). This was the way to mark such functions before GCC 2.5 added noreturn attribute. Drop such func_proto modifiers, similarly to how it's done for array (also to handle GCC quirk/bug). Such volatile attribute is emitted by GCC only, so existing selftests can't express such test. Simple repro is like this (compiled with GCC + BTF generated by pahole): struct my_struct { void __attribute__((noreturn)) (*fn)(int); }; struct my_struct a; Without this fix, output will be: struct my_struct { voidvolatile (*fn)(int); }; With the fix: struct my_struct { void (*fn)(int); }; Fixes: 351131b51c7a ("libbpf: add btf_dump API for BTF-to-C conversion") Reported-by: Jean-Philippe Brucker Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Tested-by: Jean-Philippe Brucker Link: https://lore.kernel.org/bpf/20200610052335.2862559-1-andriin@fb.com Signed-off-by: Sasha Levin commit ab482b587207b1c39ca5cc23342937eb284291eb Author: Jernej Skrabec Date: Mon Apr 13 11:54:57 2020 +0200 drm/sun4i: hdmi ddc clk: Fix size of m divider [ Upstream commit 54e1e06bcf1cf6e7ac3f86daa5f7454add24b494 ] m divider in DDC clock register is 4 bits wide. Fix that. Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support") Signed-off-by: Jernej Skrabec Reviewed-by: Chen-Yu Tsai Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20200413095457.1176754-1-jernej.skrabec@siol.net Signed-off-by: Sasha Levin commit c7c658ef5159fb1e2dd9e4ec0f868b27490855c4 Author: Jean-Philippe Brucker Date: Mon Jun 8 14:45:32 2020 +0200 tracing/probe: Fix bpf_task_fd_query() for kprobes and uprobes [ Upstream commit 22d5bd6867364b41576a712755271a7d6161abd6 ] Commit 60d53e2c3b75 ("tracing/probe: Split trace_event related data from trace_probe") removed the trace_[ku]probe structure from the trace_event_call->data pointer. As bpf_get_[ku]probe_info() were forgotten in that change, fix them now. These functions are currently only used by the bpf_task_fd_query() syscall handler to collect information about a perf event. Fixes: 60d53e2c3b75 ("tracing/probe: Split trace_event related data from trace_probe") Signed-off-by: Jean-Philippe Brucker Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Acked-by: Masami Hiramatsu Link: https://lore.kernel.org/bpf/20200608124531.819838-1-jean-philippe@linaro.org Signed-off-by: Sasha Levin commit 5bed77b0a2a0e6b6bc0ae8e851cafb38ef0374df Author: Jakub Sitnicki Date: Sun Jun 7 22:52:29 2020 +0200 bpf, sockhash: Synchronize delete from bucket list on map free [ Upstream commit 75e68e5bf2c7fa9d3e874099139df03d5952a3e1 ] We can end up modifying the sockhash bucket list from two CPUs when a sockhash is being destroyed (sock_hash_free) on one CPU, while a socket that is in the sockhash is unlinking itself from it on another CPU it (sock_hash_delete_from_link). This results in accessing a list element that is in an undefined state as reported by KASAN: | ================================================================== | BUG: KASAN: wild-memory-access in sock_hash_free+0x13c/0x280 | Write of size 8 at addr dead000000000122 by task kworker/2:1/95 | | CPU: 2 PID: 95 Comm: kworker/2:1 Not tainted 5.7.0-rc7-02961-ge22c35ab0038-dirty #691 | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 | Workqueue: events bpf_map_free_deferred | Call Trace: | dump_stack+0x97/0xe0 | ? sock_hash_free+0x13c/0x280 | __kasan_report.cold+0x5/0x40 | ? mark_lock+0xbc1/0xc00 | ? sock_hash_free+0x13c/0x280 | kasan_report+0x38/0x50 | ? sock_hash_free+0x152/0x280 | sock_hash_free+0x13c/0x280 | bpf_map_free_deferred+0xb2/0xd0 | ? bpf_map_charge_finish+0x50/0x50 | ? rcu_read_lock_sched_held+0x81/0xb0 | ? rcu_read_lock_bh_held+0x90/0x90 | process_one_work+0x59a/0xac0 | ? lock_release+0x3b0/0x3b0 | ? pwq_dec_nr_in_flight+0x110/0x110 | ? rwlock_bug.part.0+0x60/0x60 | worker_thread+0x7a/0x680 | ? _raw_spin_unlock_irqrestore+0x4c/0x60 | kthread+0x1cc/0x220 | ? process_one_work+0xac0/0xac0 | ? kthread_create_on_node+0xa0/0xa0 | ret_from_fork+0x24/0x30 | ================================================================== Fix it by reintroducing spin-lock protected critical section around the code that removes the elements from the bucket on sockhash free. To do that we also need to defer processing of removed elements, until out of atomic context so that we can unlink the socket from the map when holding the sock lock. Fixes: 90db6d772f74 ("bpf, sockmap: Remove bucket->lock from sock_{hash|map}_free") Reported-by: Eric Dumazet Signed-off-by: Jakub Sitnicki Signed-off-by: Alexei Starovoitov Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200607205229.2389672-3-jakub@cloudflare.com Signed-off-by: Sasha Levin commit 0f97842057c7da92ee6964e0f4190b1b579f51de Author: dihu Date: Fri Jun 5 16:46:25 2020 +0800 bpf/sockmap: Fix kernel panic at __tcp_bpf_recvmsg [ Upstream commit 487082fb7bd2a32b66927d2b22e3a81b072b44f0 ] When user application calls read() with MSG_PEEK flag to read data of bpf sockmap socket, kernel panic happens at __tcp_bpf_recvmsg+0x12c/0x350. sk_msg is not removed from ingress_msg queue after read out under MSG_PEEK flag is set. Because it's not judged whether sk_msg is the last msg of ingress_msg queue, the next sk_msg may be the head of ingress_msg queue, whose memory address of sg page is invalid. So it's necessary to add check codes to prevent this problem. [20759.125457] BUG: kernel NULL pointer dereference, address: 0000000000000008 [20759.132118] CPU: 53 PID: 51378 Comm: envoy Tainted: G E 5.4.32 #1 [20759.140890] Hardware name: Inspur SA5212M4/YZMB-00370-109, BIOS 4.1.12 06/18/2017 [20759.149734] RIP: 0010:copy_page_to_iter+0xad/0x300 [20759.270877] __tcp_bpf_recvmsg+0x12c/0x350 [20759.276099] tcp_bpf_recvmsg+0x113/0x370 [20759.281137] inet_recvmsg+0x55/0xc0 [20759.285734] __sys_recvfrom+0xc8/0x130 [20759.290566] ? __audit_syscall_entry+0x103/0x130 [20759.296227] ? syscall_trace_enter+0x1d2/0x2d0 [20759.301700] ? __audit_syscall_exit+0x1e4/0x290 [20759.307235] __x64_sys_recvfrom+0x24/0x30 [20759.312226] do_syscall_64+0x55/0x1b0 [20759.316852] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by: dihu Signed-off-by: Alexei Starovoitov Acked-by: John Fastabend Acked-by: Jakub Sitnicki Link: https://lore.kernel.org/bpf/20200605084625.9783-1-anny.hu@linux.alibaba.com Signed-off-by: Sasha Levin commit ea8837b9435ef6e6ee43b80687fd24dd93cf7bcb Author: Hans de Goede Date: Mon Jun 8 22:46:34 2020 +0200 ASoC: rt5645: Add platform-data for Asus T101HA [ Upstream commit 79d4f823a06796656289f97b922493da5690e46c ] The Asus T101HA uses the default jack-detect mode 3, but instead of using an analog microphone it is using a DMIC on dmic-data-pin 1, like the Asus T100HA. Note unlike the T100HA its jack-detect is not inverted. Add a DMI quirk with the correct settings for this model. Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200608204634.93407-2-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ebc448eb2de50cbd61e39c832a52585bccc403a4 Author: Hans de Goede Date: Mon Jun 8 22:46:33 2020 +0200 ASoC: Intel: bytcr_rt5640: Add quirk for Toshiba Encore WT10-A tablet [ Upstream commit 199a5e8fda54ab3c8c6f6bf980c004e97ebf5ccb ] The Toshiba Encore WT10-A tablet almost fully works with the default settings for Bay Trail CR devices. The only issue is that it uses a digital mic. connected the the DMIC1 input instead of an analog mic. Add a quirk for this model using the default settings with the input-map replaced with BYT_RT5640_DMIC1_MAP. Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200608204634.93407-1-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 69367d9f1f0ef8cb1d85a437d04bd2dd9b5d13ff Author: Pierre-Louis Bossart Date: Mon Jun 8 14:44:15 2020 -0500 ASoC: SOF: nocodec: conditionally set dpcm_capture/dpcm_playback flags [ Upstream commit ba4e5abc6c4e173af7c941c03c067263b686665d ] With additional checks on dailinks, we see errors such as [ 3.000418] sof-nocodec sof-nocodec: CPU DAI DMIC01 Pin for rtd NoCodec-6 does not support playback It's not clear why we set the dpcm_playback and dpcm_capture flags unconditionally, add a check on number of channels for each direction to avoid invalid configurations. Fixes: 8017b8fd37bf5e ('ASoC: SOF: Add Nocodec machine driver support') Signed-off-by: Pierre-Louis Bossart Reviewed-by: Guennadi Liakhovetski Reviewed-by: Daniel Baluta Reviewed-by: Bard Liao Link: https://lore.kernel.org/r/20200608194415.4663-5-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7b31ec2a011feeecd2e3147c32156c4468f4bef9 Author: Bard Liao Date: Mon Jun 8 14:44:13 2020 -0500 ASoC: core: only convert non DPCM link to DPCM link [ Upstream commit 607fa205a7e4dfad28b8a67ab1c985756ddbccb0 ] Additional checks for valid DAIs expose a corner case, where existing BE dailinks get modified, e.g. HDMI links are tagged with dpcm_capture=1 even if the DAIs are for playback. This patch makes those changes conditional and flags configuration issues when a BE dailink is has no_pcm=0 but dpcm_playback or dpcm_capture=1 (which makes no sense). As discussed on the alsa-devel mailing list, there are redundant flags for dpcm_playback, dpcm_capture, playback_only, capture_only. This will have to be cleaned-up in a future update. For now only correct and flag problematic configurations. Fixes: 218fe9b7ec7f3 ("ASoC: soc-core: Set dpcm_playback / dpcm_capture") Suggested-by: Daniel Baluta Signed-off-by: Bard Liao Signed-off-by: Pierre-Louis Bossart Reviewed-by: Guennadi Liakhovetski Reviewed-by: Daniel Baluta Reviewed-by: Bard Liao Link: https://lore.kernel.org/r/20200608194415.4663-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 445a847a5507b6c98dac5af072fbef40ba1ba73d Author: Zhihao Cheng Date: Tue Jun 2 09:30:45 2020 +0800 afs: Fix memory leak in afs_put_sysnames() [ Upstream commit 2ca068be09bf8e285036603823696140026dcbe7 ] Fix afs_put_sysnames() to actually free the specified afs_sysnames object after its reference count has been decreased to zero and its contents have been released. Fixes: 6f8880d8e681557 ("afs: Implement @sys substitution handling") Signed-off-by: Zhihao Cheng Signed-off-by: David Howells Signed-off-by: Sasha Levin commit 3b50b29a2056a2e96972a8940bf79aaa03b4dd7f Author: Eric Biggers Date: Thu Jun 4 21:57:48 2020 -0700 f2fs: don't return vmalloc() memory from f2fs_kmalloc() [ Upstream commit 0b6d4ca04a86b9dababbb76e58d33c437e127b77 ] kmalloc() returns kmalloc'ed memory, and kvmalloc() returns either kmalloc'ed or vmalloc'ed memory. But the f2fs wrappers, f2fs_kmalloc() and f2fs_kvmalloc(), both return both kinds of memory. It's redundant to have two functions that do the same thing, and also breaking the standard naming convention is causing bugs since people assume it's safe to kfree() memory allocated by f2fs_kmalloc(). See e.g. the various allocations in fs/f2fs/compress.c. Fix this by making f2fs_kmalloc() just use kmalloc(). And to avoid re-introducing the allocation failures that the vmalloc fallback was intended to fix, convert the largest allocations to use f2fs_kvmalloc(). Signed-off-by: Eric Biggers Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 37be9b71b748a03c70c6beda9068e6899c15abb9 Author: tannerlove Date: Mon Jun 8 15:37:15 2020 -0400 selftests/net: in timestamping, strncpy needs to preserve null byte [ Upstream commit 8027bc0307ce59759b90679fa5d8b22949586d20 ] If user passed an interface option longer than 15 characters, then device.ifr_name and hwtstamp.ifr_name became non-null-terminated strings. The compiler warned about this: timestamping.c:353:2: warning: ‘strncpy’ specified bound 16 equals \ destination size [-Wstringop-truncation] 353 | strncpy(device.ifr_name, interface, sizeof(device.ifr_name)); Fixes: cb9eff097831 ("net: new user space API for time stamping of incoming and outgoing packets") Signed-off-by: Tanner Love Acked-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a98132826820dec082bb57d5d733aa57bbcae6fc Author: Shaokun Zhang Date: Fri Jun 5 17:43:41 2020 +0800 drivers/perf: hisi: Fix wrong value for all counters enable [ Upstream commit 961abd78adcb4c72c343fcd9f9dc5e2ebbe9b448 ] In L3C uncore PMU drivers, bit16 is used to control all counters enable & disable. Wrong value is given in the driver and its default value is 1'b1, it can work because each PMU counter has its own control bits too. Let's fix the wrong value. Fixes: 2940bc433370 ("perf: hisi: Add support for HiSilicon SoC L3C PMU driver") Signed-off-by: Shaokun Zhang Cc: Will Deacon Cc: Mark Rutland Link: https://lore.kernel.org/r/1591350221-32275-1-git-send-email-zhangshaokun@hisilicon.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit e1ee6238534e514268bc373f03fb398ac0c8a9d0 Author: Max Staudt Date: Sun Jun 7 20:28:12 2020 +0200 i2c: icy: Fix build with CONFIG_AMIGA_PCMCIA=n [ Upstream commit cdb555397f438592bab00599037c347b700cf397 ] This has been found by the Kernel Test Robot: http://lkml.iu.edu/hypermail/linux/kernel/2006.0/06862.html With CONFIG_AMIGA_PCMCIA=n, io_mm.h does not pull in amigahw.h and ZTWO_VADDR is undefined. Add forgotten include to i2c-icy.c Fixes: 4768e90ecaec ("i2c: Add i2c-icy for I2C on m68k/Amiga") Reported-by: kernel test robot Signed-off-by: Max Staudt Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit ad67536d48ba516406d1a04d0e9025c527b68c3b Author: Logan Gunthorpe Date: Wed Jan 9 12:22:33 2019 -0700 NTB: ntb_test: Fix bug when counting remote files [ Upstream commit 2130c0ba69d69bb21f5c52787f2587db00d13d8a ] When remote files are counted in get_files_count, without using SSH, the code returns 0 because there is a colon prepended to $LOC. $VPATH should have been used instead of $LOC. Fixes: 06bd0407d06c ("NTB: ntb_test: Update ntb_tool Scratchpad tests") Signed-off-by: Logan Gunthorpe Acked-by: Allen Hubbe Tested-by: Alexander Fomichev Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit abf918236a79ced6e2d635b1c622a97d8108ce75 Author: Logan Gunthorpe Date: Wed Jan 9 12:22:32 2019 -0700 NTB: perf: Fix race condition when run with ntb_test [ Upstream commit 34d8673a01b053b6231a995a4eec9341163d63be ] When running ntb_test, the script tries to run the ntb_perf test immediately after probing the modules. Since adding multi-port support, this fails seeing the new initialization procedure in ntb_perf can not complete instantly. To fix this we add a completion which is waited on when a test is started. In this way, run can be written any time after the module is loaded and it will wait for the initialization to complete instead of sending an error. Fixes: 5648e56d03fa ("NTB: ntb_perf: Add full multi-port NTB API support") Signed-off-by: Logan Gunthorpe Acked-by: Allen Hubbe Tested-by: Alexander Fomichev Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit 50a79b96b951833172bf0d87349f2e3a6a2fae29 Author: Logan Gunthorpe Date: Wed Jan 9 12:22:31 2019 -0700 NTB: perf: Fix support for hardware that doesn't have port numbers [ Upstream commit b54369a248c2e033bfcf5d6917e08cf9d73d54a6 ] Legacy drivers do not have port numbers (but is reliably only two ports) and was broken by the recent commit that added mult-port support to ntb_perf. This is especially important to support the cross link topology which is perfectly symmetric and cannot assign unique port numbers easily. Hardware that returns zero for both the local port and the peer should just always use gidx=0 for the only peer. Fixes: 5648e56d03fa ("NTB: ntb_perf: Add full multi-port NTB API support") Signed-off-by: Logan Gunthorpe Acked-by: Allen Hubbe Tested-by: Alexander Fomichev Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit ec84901316702cf94a0be530beddbffaae447a42 Author: Logan Gunthorpe Date: Wed Jan 9 12:22:30 2019 -0700 NTB: perf: Don't require one more memory window than number of peers [ Upstream commit a9c4211ac918ade1522aced6b5acfbe824722f7d ] ntb_perf should not require more than one memory window per peer. This was probably an off-by-one error. Fixes: 5648e56d03fa ("NTB: ntb_perf: Add full multi-port NTB API support") Signed-off-by: Logan Gunthorpe Acked-by: Allen Hubbe Tested-by: Alexander Fomichev Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit 2b97e354e5868e8365e8fb5577d534ee2cf2288e Author: Logan Gunthorpe Date: Wed Jan 9 12:22:27 2019 -0700 NTB: Revert the change to use the NTB device dev for DMA allocations [ Upstream commit 40da7d9a93c8941737ef4a1208d32c13ce017fe1 ] Commit 417cf39cfea9 ("NTB: Set dma mask and dma coherent mask to NTB devices") started using the NTB device for DMA allocations which was turns out was wrong. If the IOMMU is enabled, such alloctanions will always fail with messages such as: DMAR: Allocating domain for 0000:02:00.1 failed This is because the IOMMU has not setup the device for such use. Change the tools back to using the PCI device for allocations seeing it doesn't make sense to add an IOMMU group for the non-physical NTB device. Also remove the code that sets the DMA mask as it no longer makes sense to do this. Fixes: 7f46c8b3a552 ("NTB: ntb_tool: Add full multi-port NTB API support") Signed-off-by: Logan Gunthorpe Tested-by: Alexander Fomichev Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit e5cd9e1df0c978613fa7efeb158d5e155f168d1f Author: Logan Gunthorpe Date: Wed Jan 9 12:22:26 2019 -0700 NTB: ntb_tool: reading the link file should not end in a NULL byte [ Upstream commit 912e12813dd03c602e4922fc34709ec4d4380cf0 ] When running ntb_test this warning is issued: ./ntb_test.sh: line 200: warning: command substitution: ignored null byte in input This is caused by the kernel returning one more byte than is necessary when reading the link file. Reduce the number of bytes read back to 2 as it was before the commit that regressed this. Fixes: 7f46c8b3a552 ("NTB: ntb_tool: Add full multi-port NTB API support") Signed-off-by: Logan Gunthorpe Acked-by: Allen Hubbe Tested-by: Alexander Fomichev Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit 25abac5c9ff7bc7e7ff3f19e13ad340e075ec354 Author: Sanjay R Mehta Date: Tue May 5 23:21:50 2020 -0500 ntb_tool: pass correct struct device to dma_alloc_coherent [ Upstream commit 433efe720674efd9fdbcef78be75793393cf05db ] Currently, ntb->dev is passed to dma_alloc_coherent and dma_free_coherent calls. The returned dma_addr_t is the CPU physical address. This works fine as long as IOMMU is disabled. But when IOMMU is enabled, we need to make sure that IOVA is returned for dma_addr_t. So the correct way to achieve this is by changing the first parameter of dma_alloc_coherent() as ntb->pdev->dev instead. Fixes: 5648e56d03fa ("NTB: ntb_perf: Add full multi-port NTB API support") Signed-off-by: Sanjay R Mehta Signed-off-by: Arindam Nath Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit f167d8f7b34195bcaba034ee0640beeb5310d4f8 Author: Sanjay R Mehta Date: Tue May 5 23:21:49 2020 -0500 ntb_perf: pass correct struct device to dma_alloc_coherent [ Upstream commit 98f4e140264eeb52f22ff05be6b6dd48237255ac ] Currently, ntb->dev is passed to dma_alloc_coherent and dma_free_coherent calls. The returned dma_addr_t is the CPU physical address. This works fine as long as IOMMU is disabled. But when IOMMU is enabled, we need to make sure that IOVA is returned for dma_addr_t. So the correct way to achieve this is by changing the first parameter of dma_alloc_coherent() as ntb->pdev->dev instead. Fixes: 5648e56d03fa ("NTB: ntb_perf: Add full multi-port NTB API support") Signed-off-by: Logan Gunthorpe Signed-off-by: Sanjay R Mehta Signed-off-by: Arindam Nath Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit 08cc0ec9ba86058879e896a5fa4c2bd26b1e1514 Author: Dan Murphy Date: Fri Jun 5 09:01:06 2020 -0500 net: marvell: Fix OF_MDIO config check [ Upstream commit 5cd119d9a05f1c1a08778a7305b4ca0f16bc1e20 ] When CONFIG_OF_MDIO is set to be a module the code block is not compiled. Use the IS_ENABLED macro that checks for both built in as well as module. Fixes: cf41a51db8985 ("of/phylib: Use device tree properties to initialize Marvell PHYs.") Signed-off-by: Dan Murphy Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit fbaf0137df1e24dd4287d55321dfb73e110a7e54 Author: Bob Peterson Date: Thu Jun 4 14:28:58 2020 -0500 gfs2: fix use-after-free on transaction ail lists [ Upstream commit 83d060ca8d90fa1e3feac227f995c013100862d3 ] Before this patch, transactions could be merged into the system transaction by function gfs2_merge_trans(), but the transaction ail lists were never merged. Because the ail flushing mechanism can run separately, bd elements can be attached to the transaction's buffer list during the transaction (trans_add_meta, etc) but quickly moved to its ail lists. Later, in function gfs2_trans_end, the transaction can be freed (by gfs2_trans_end) while it still has bd elements queued to its ail lists, which can cause it to either lose track of the bd elements altogether (memory leak) or worse, reference the bd elements after the parent transaction has been freed. Although I've not seen any serious consequences, the problem becomes apparent with the previous patch's addition of: gfs2_assert_warn(sdp, list_empty(&tr->tr_ail1_list)); to function gfs2_trans_free(). This patch adds logic into gfs2_merge_trans() to move the merged transaction's ail lists to the sdp transaction. This prevents the use-after-free. To do this properly, we need to hold the ail lock, so we pass sdp into the function instead of the transaction itself. Signed-off-by: Bob Peterson Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit e782a45789f865e7eaa4ad321fd0c589a978907b Author: Chaitanya Kulkarni Date: Thu Jun 4 00:13:30 2020 -0700 blktrace: fix endianness for blk_log_remap() [ Upstream commit 5aec598c456fe3c1b71a1202cbb42bdc2a643277 ] The function blk_log_remap() can be simplified by removing the call to get_pdu_remap() that copies the values into extra variable to print the data, which also fixes the endiannness warning reported by sparse. Signed-off-by: Chaitanya Kulkarni Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 545bafecc0f21671cfcf5126b610fd293ce657db Author: Chaitanya Kulkarni Date: Thu Jun 4 00:13:29 2020 -0700 blktrace: fix endianness in get_pdu_int() [ Upstream commit 71df3fd82e7cccec7b749a8607a4662d9f7febdd ] In function get_pdu_len() replace variable type from __u64 to __be64. This fixes sparse warning. Signed-off-by: Chaitanya Kulkarni Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit d578f98fa7b30416437ce2e81ccab298d17cdf34 Author: Chaitanya Kulkarni Date: Thu Jun 4 00:13:28 2020 -0700 blktrace: use errno instead of bi_status [ Upstream commit 48bc3cd3e07a1486f45d9971c75d6090976c3b1b ] In blk_add_trace_spliti() blk_add_trace_bio_remap() use blk_status_to_errno() to pass the error instead of pasing the bi_status. This fixes the sparse warning. Signed-off-by: Chaitanya Kulkarni Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 718d9a863eb303343b81f6a1129e35d7508b4152 Author: Ram Pai Date: Thu Jun 4 16:52:05 2020 -0700 selftests/vm/pkeys: fix alloc_random_pkey() to make it really random [ Upstream commit 6e373263ce07eeaa6410843179535fbdf561fc31 ] alloc_random_pkey() was allocating the same pkey every time. Not all pkeys were geting tested. This fixes it. Signed-off-by: Ram Pai Signed-off-by: Sandipan Das Signed-off-by: Andrew Morton Acked-by: Dave Hansen Cc: Dave Hansen Cc: Florian Weimer Cc: "Desnes A. Nunes do Rosario" Cc: Ingo Molnar Cc: Thiago Jung Bauermann Cc: "Aneesh Kumar K.V" Cc: Michael Ellerman Cc: Michal Hocko Cc: Michal Suchanek Cc: Shuah Khan Link: http://lkml.kernel.org/r/0162f55816d4e783a0d6e49e554d0ab9a3c9a23b.1585646528.git.sandipan@linux.ibm.com Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 7fd59952282392e66cd92f33a7831a903a750254 Author: Arnd Bergmann Date: Thu Jun 4 16:50:30 2020 -0700 include/linux/bitops.h: avoid clang shift-count-overflow warnings [ Upstream commit bd93f003b7462ae39a43c531abca37fe7073b866 ] Clang normally does not warn about certain issues in inline functions when it only happens in an eliminated code path. However if something else goes wrong, it does tend to complain about the definition of hweight_long() on 32-bit targets: include/linux/bitops.h:75:41: error: shift count >= width of type [-Werror,-Wshift-count-overflow] return sizeof(w) == 4 ? hweight32(w) : hweight64(w); ^~~~~~~~~~~~ include/asm-generic/bitops/const_hweight.h:29:49: note: expanded from macro 'hweight64' define hweight64(w) (__builtin_constant_p(w) ? __const_hweight64(w) : __arch_hweight64(w)) ^~~~~~~~~~~~~~~~~~~~ include/asm-generic/bitops/const_hweight.h:21:76: note: expanded from macro '__const_hweight64' define __const_hweight64(w) (__const_hweight32(w) + __const_hweight32((w) >> 32)) ^ ~~ include/asm-generic/bitops/const_hweight.h:20:49: note: expanded from macro '__const_hweight32' define __const_hweight32(w) (__const_hweight16(w) + __const_hweight16((w) >> 16)) ^ include/asm-generic/bitops/const_hweight.h:19:72: note: expanded from macro '__const_hweight16' define __const_hweight16(w) (__const_hweight8(w) + __const_hweight8((w) >> 8 )) ^ include/asm-generic/bitops/const_hweight.h:12:9: note: expanded from macro '__const_hweight8' (!!((w) & (1ULL << 2))) + \ Adding an explicit cast to __u64 avoids that warning and makes it easier to read other output. Signed-off-by: Arnd Bergmann Signed-off-by: Andrew Morton Acked-by: Christian Brauner Cc: Andy Shevchenko Cc: Rasmus Villemoes Cc: Josh Poimboeuf Cc: Nick Desaulniers Link: http://lkml.kernel.org/r/20200505135513.65265-1-arnd@arndb.de Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit b7ce2e4538f67439095c169113a2d600cebc66d3 Author: Jann Horn Date: Thu Jun 4 16:50:17 2020 -0700 lib/zlib: remove outdated and incorrect pre-increment optimization [ Upstream commit acaab7335bd6f0c0b54ce3a00bd7f18222ce0f5f ] The zlib inflate code has an old micro-optimization based on the assumption that for pre-increment memory accesses, the compiler will generate code that fits better into the processor's pipeline than what would be generated for post-increment memory accesses. This optimization was already removed in upstream zlib in 2016: https://github.com/madler/zlib/commit/9aaec95e8211 This optimization causes UB according to C99, which says in section 6.5.6 "Additive operators": "If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overflow; otherwise, the behavior is undefined". This UB is not only a theoretical concern, but can also cause trouble for future work on compiler-based sanitizers. According to the zlib commit, this optimization also is not optimal anymore with modern compilers. Replace uses of OFF, PUP and UP_UNALIGNED with their definitions in the POSTINC case, and remove the macro definitions, just like in the upstream patch. Signed-off-by: Jann Horn Signed-off-by: Andrew Morton Cc: Mikhail Zaslonko Link: http://lkml.kernel.org/r/20200507123112.252723-1-jannh@google.com Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 62378b65237eff0d7ef5fec4a3a111724180ab70 Author: Jiri Benc Date: Wed Jun 3 11:12:14 2020 +0200 geneve: change from tx_error to tx_dropped on missing metadata [ Upstream commit 9d149045b3c0e44c049cdbce8a64e19415290017 ] If the geneve interface is in collect_md (external) mode, it can't send any packets submitted directly to its net interface, as such packets won't have metadata attached. This is expected. However, the kernel itself sends some packets to the interface, most notably, IPv6 DAD, IPv6 multicast listener reports, etc. This is not wrong, as tunnel metadata can be specified in routing table (although technically, that has never worked for IPv6, but hopefully will be fixed eventually) and then the interface must correctly participate in IPv6 housekeeping. The problem is that any such attempt increases the tx_error counter. Just bringing up a geneve interface with IPv6 enabled is enough to see a number of tx_errors. That causes confusion among users, prompting them to find a network error where there is none. Change the counter used to tx_dropped. That better conveys the meaning (there's nothing wrong going on, just some packets are getting dropped) and hopefully will make admins panic less. Signed-off-by: Jiri Benc Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7791ab20b8ebeadcf8e4ad520f786aa020b99a81 Author: Tero Kristo Date: Wed May 27 15:24:29 2020 +0300 crypto: omap-sham - add proper load balancing support for multicore [ Upstream commit 281c377872ff5d15d80df25fc4df02d2676c7cde ] The current implementation of the multiple accelerator core support for OMAP SHA does not work properly. It always picks up the first probed accelerator core if this is available, and rest of the book keeping also gets confused if there are two cores available. Add proper load balancing support for SHA, and also fix any bugs related to the multicore support while doing it. Signed-off-by: Tero Kristo Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit b73df5915d13906d10abc22f747a214d699930f6 Author: Nicholas Kazlauskas Date: Tue Jun 2 20:42:33 2020 -0400 drm/amd/display: Revalidate bandwidth before commiting DC updates [ Upstream commit a24eaa5c51255b344d5a321f1eeb3205f2775498 ] [Why] Whenever we switch between tiled formats without also switching pixel formats or doing anything else that recreates the DC plane state we can run into underflow or hangs since we're not updating the DML parameters before committing to the hardware. [How] If the update type is FULL then call validate_bandwidth again to update the DML parmeters before committing the state. This is basically just a workaround and protective measure against update types being added DC where we could run into this issue in the future. We can only fully validate the state in advance before applying it to the hardware if we recreate all the plane and stream states since we can't modify what's currently in use. The next step is to update DM to ensure that we're creating the plane and stream states for whatever could potentially be a full update in DC to pre-emptively recreate the state for DC global validation. The workaround can stay until this has been fixed in DM. Signed-off-by: Nicholas Kazlauskas Reviewed-by: Hersen Wu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ca0cac3373fa7190906b21d4b1ff9a311c546aae Author: J. Bruce Fields Date: Wed Jun 3 11:12:32 2020 -0400 nfsd: safer handling of corrupted c_type [ Upstream commit c25bf185e57213b54ea0d632ac04907310993433 ] This can only happen if there's a bug somewhere, so let's make it a WARN not a printk. Also, I think it's safest to ignore the corruption rather than trying to fix it by removing a cache entry. Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit e585a8b54046b98f862d45e075ca6d117ee78cc9 Author: Christophe JAILLET Date: Sat May 30 22:49:55 2020 +0200 pinctrl: freescale: imx: Fix an error handling path in 'imx_pinctrl_probe()' [ Upstream commit 11d8da5cabf7c6c3263ba2cd9c00260395867048 ] 'pinctrl_unregister()' should not be called to undo 'devm_pinctrl_register_and_init()', it is already handled by the framework. This simplifies the error handling paths of the probe function. The 'imx_free_resources()' can be removed as well. Fixes: a51c158bf0f7 ("pinctrl: imx: use radix trees for groups and functions") Signed-off-by: Christophe JAILLET Reviewed-by: Dong Aisheng Link: https://lore.kernel.org/r/20200530204955.588962-1-christophe.jaillet@wanadoo.fr Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit d184d62ceb197f7f0e23fb399735f9a3b2241d82 Author: Christophe JAILLET Date: Sat May 30 22:19:52 2020 +0200 pinctrl: imxl: Fix an error handling path in 'imx1_pinctrl_core_probe()' [ Upstream commit 9eb728321286c4b31e964d2377fca2368526d408 ] When 'pinctrl_register()' has been turned into 'devm_pinctrl_register()', an error handling path has not been updated. Axe a now unneeded 'pinctrl_unregister()'. Fixes: e55e025d1687 ("pinctrl: imxl: Use devm_pinctrl_register() for pinctrl registration") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/20200530201952.585798-1-christophe.jaillet@wanadoo.fr Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit bd410e6600b4ff4e3ec0972b296796f93fd2f407 Author: Can Guo Date: Wed May 27 19:24:42 2020 -0700 scsi: ufs: Don't update urgent bkops level when toggling auto bkops [ Upstream commit be32acff43800c87dc5c707f5d47cc607b76b653 ] Urgent bkops level is used to compare against actual bkops status read from UFS device. Urgent bkops level is set during initialization and might be updated in exception event handler during runtime. But it should not be updated to the actual bkops status every time when auto bkops is toggled. Otherwise, if urgent bkops level is updated to 0, auto bkops shall always be kept enabled. Link: https://lore.kernel.org/r/1590632686-17866-1-git-send-email-cang@codeaurora.org Fixes: 24366c2afbb0 ("scsi: ufs: Recheck bkops level if bkops is disabled") Reviewed-by: Stanley Chu Signed-off-by: Can Guo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 88d67834843019721d94cd63e077e2499c480d0b Author: Qiushi Wu Date: Thu May 28 15:13:53 2020 -0500 scsi: iscsi: Fix reference count leak in iscsi_boot_create_kobj [ Upstream commit 0267ffce562c8bbf9b57ebe0e38445ad04972890 ] kobject_init_and_add() takes reference even when it fails. If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Link: https://lore.kernel.org/r/20200528201353.14849-1-wu000273@umn.edu Reviewed-by: Lee Duncan Signed-off-by: Qiushi Wu Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 08904df10d3a2ea34b1b3b77f8ad9bbebd96507e Author: Bob Peterson Date: Wed Apr 29 08:45:54 2020 -0500 gfs2: Allow lock_nolock mount to specify jid=X [ Upstream commit ea22eee4e6027d8927099de344f7fff43c507ef9 ] Before this patch, a simple typo accidentally added \n to the jid= string for lock_nolock mounts. This made it impossible to mount a gfs2 file system with a journal other than journal0. Thus: mount -tgfs2 -o hostdata="jid=1" Resulted in: mount: wrong fs type, bad option, bad superblock on In most cases this is not a problem. However, for debugging and testing purposes we sometimes want to test the integrity of other journals. This patch removes the unnecessary \n and thus allows lock_nolock users to specify an alternate journal. Signed-off-by: Bob Peterson Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 9adcc852d55268ea1c87dd2d44e435366fbb658d Author: J. Bruce Fields Date: Mon Jun 1 17:44:45 2020 -0400 nfsd4: make drc_slab global, not per-net [ Upstream commit 027690c75e8fd91b60a634d31c4891a6e39d45bd ] I made every global per-network-namespace instead. But perhaps doing that to this slab was a step too far. The kmem_cache_create call in our net init method also seems to be responsible for this lockdep warning: [ 45.163710] Unable to find swap-space signature [ 45.375718] trinity-c1 (855): attempted to duplicate a private mapping with mremap. This is not supported. [ 46.055744] futex_wake_op: trinity-c1 tries to shift op by -209; fix this program [ 51.011723] [ 51.013378] ====================================================== [ 51.013875] WARNING: possible circular locking dependency detected [ 51.014378] 5.2.0-rc2 #1 Not tainted [ 51.014672] ------------------------------------------------------ [ 51.015182] trinity-c2/886 is trying to acquire lock: [ 51.015593] 000000005405f099 (slab_mutex){+.+.}, at: slab_attr_store+0xa2/0x130 [ 51.016190] [ 51.016190] but task is already holding lock: [ 51.016652] 00000000ac662005 (kn->count#43){++++}, at: kernfs_fop_write+0x286/0x500 [ 51.017266] [ 51.017266] which lock already depends on the new lock. [ 51.017266] [ 51.017909] [ 51.017909] the existing dependency chain (in reverse order) is: [ 51.018497] [ 51.018497] -> #1 (kn->count#43){++++}: [ 51.018956] __lock_acquire+0x7cf/0x1a20 [ 51.019317] lock_acquire+0x17d/0x390 [ 51.019658] __kernfs_remove+0x892/0xae0 [ 51.020020] kernfs_remove_by_name_ns+0x78/0x110 [ 51.020435] sysfs_remove_link+0x55/0xb0 [ 51.020832] sysfs_slab_add+0xc1/0x3e0 [ 51.021332] __kmem_cache_create+0x155/0x200 [ 51.021720] create_cache+0xf5/0x320 [ 51.022054] kmem_cache_create_usercopy+0x179/0x320 [ 51.022486] kmem_cache_create+0x1a/0x30 [ 51.022867] nfsd_reply_cache_init+0x278/0x560 [ 51.023266] nfsd_init_net+0x20f/0x5e0 [ 51.023623] ops_init+0xcb/0x4b0 [ 51.023928] setup_net+0x2fe/0x670 [ 51.024315] copy_net_ns+0x30a/0x3f0 [ 51.024653] create_new_namespaces+0x3c5/0x820 [ 51.025257] unshare_nsproxy_namespaces+0xd1/0x240 [ 51.025881] ksys_unshare+0x506/0x9c0 [ 51.026381] __x64_sys_unshare+0x3a/0x50 [ 51.026937] do_syscall_64+0x110/0x10b0 [ 51.027509] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 51.028175] [ 51.028175] -> #0 (slab_mutex){+.+.}: [ 51.028817] validate_chain+0x1c51/0x2cc0 [ 51.029422] __lock_acquire+0x7cf/0x1a20 [ 51.029947] lock_acquire+0x17d/0x390 [ 51.030438] __mutex_lock+0x100/0xfa0 [ 51.030995] mutex_lock_nested+0x27/0x30 [ 51.031516] slab_attr_store+0xa2/0x130 [ 51.032020] sysfs_kf_write+0x11d/0x180 [ 51.032529] kernfs_fop_write+0x32a/0x500 [ 51.033056] do_loop_readv_writev+0x21d/0x310 [ 51.033627] do_iter_write+0x2e5/0x380 [ 51.034148] vfs_writev+0x170/0x310 [ 51.034616] do_pwritev+0x13e/0x160 [ 51.035100] __x64_sys_pwritev+0xa3/0x110 [ 51.035633] do_syscall_64+0x110/0x10b0 [ 51.036200] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 51.036924] [ 51.036924] other info that might help us debug this: [ 51.036924] [ 51.037876] Possible unsafe locking scenario: [ 51.037876] [ 51.038556] CPU0 CPU1 [ 51.039130] ---- ---- [ 51.039676] lock(kn->count#43); [ 51.040084] lock(slab_mutex); [ 51.040597] lock(kn->count#43); [ 51.041062] lock(slab_mutex); [ 51.041320] [ 51.041320] *** DEADLOCK *** [ 51.041320] [ 51.041793] 3 locks held by trinity-c2/886: [ 51.042128] #0: 000000001f55e152 (sb_writers#5){.+.+}, at: vfs_writev+0x2b9/0x310 [ 51.042739] #1: 00000000c7d6c034 (&of->mutex){+.+.}, at: kernfs_fop_write+0x25b/0x500 [ 51.043400] #2: 00000000ac662005 (kn->count#43){++++}, at: kernfs_fop_write+0x286/0x500 Reported-by: kernel test robot Fixes: 3ba75830ce17 "drc containerization" Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit 807460787179dee5f74906965eeb5f3ca2353992 Author: Luis Henriques Date: Mon May 18 18:47:26 2020 +0100 ceph: don't return -ESTALE if there's still an open file [ Upstream commit 878dabb64117406abd40977b87544d05bb3031fc ] Similarly to commit 03f219041fdb ("ceph: check i_nlink while converting a file handle to dentry"), this fixes another corner case with name_to_handle_at/open_by_handle_at. The issue has been detected by xfstest generic/467, when doing: - name_to_handle_at("/cephfs/myfile") - open("/cephfs/myfile") - unlink("/cephfs/myfile") - sync; sync; - drop caches - open_by_handle_at() The call to open_by_handle_at should not fail because the file hasn't been deleted yet (only unlinked) and we do have a valid handle to it. -ESTALE shall be returned only if i_nlink is 0 *and* i_count is 1. This patch also makes sure we have LINK caps before checking i_nlink. Signed-off-by: Luis Henriques Reviewed-by: Jeff Layton Acked-by: Amir Goldstein Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 145565f722c9c8ad6e99ea3f5907a72a78f7882a Author: Ben Skeggs Date: Fri May 29 15:18:47 2020 +1000 drm/nouveau/disp/gm200-: fix NV_PDISP_SOR_HDMI2_CTRL(n) selection [ Upstream commit a1ef8bad506e4ffa0c57ac5f8cb99ab5cbc3b1fc ] This is a SOR register, and not indexed by the bound head. Fixes display not coming up on high-bandwidth HDMI displays under a number of configurations. Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit 43ba1b177a494a68d0278dade4d507683ddd58b7 Author: Stafford Horne Date: Wed Apr 22 20:24:11 2020 +0900 openrisc: Fix issue with argument clobbering for clone/fork [ Upstream commit 6bd140e14d9aaa734ec37985b8b20a96c0ece948 ] Working on the OpenRISC glibc port I found that sometimes clone was working strange. That the tls data argument sent in r7 was always wrong. Further investigation revealed that the arguments were getting clobbered in the entry code. This patch removes the code that writes to the argument registers. This was likely due to some old code hanging around. This patch fixes this up for clone and fork. This fork clobber is harmless but also useless so remove. Signed-off-by: Stafford Horne Signed-off-by: Sasha Levin commit 6de31dc168f08e55f41cc5040a9f608f09342435 Author: David Howells Date: Sat May 2 13:38:23 2020 +0100 rxrpc: Adjust /proc/net/rxrpc/calls to display call->debug_id not user_ID [ Upstream commit 32f71aa497cfb23d37149c2ef16ad71fce2e45e2 ] The user ID value isn't actually much use - and leaks a kernel pointer or a userspace value - so replace it with the call debug ID, which appears in trace points. Signed-off-by: David Howells Signed-off-by: Sasha Levin commit 2e48a738dc15aeb9bd451654a7f3b6cdc3a74b70 Author: Wei Yongjun Date: Wed Apr 29 09:35:03 2020 +0000 mailbox: zynqmp-ipi: Fix NULL vs IS_ERR() check in zynqmp_ipi_mbox_probe() [ Upstream commit 445aeeb569f8d7904f8cf80b7c6826bb651ef80e ] In case of error, the function devm_ioremap() returns NULL pointer not ERR_PTR(). So we should check whether the return value of devm_ioremap() is NULL instead of IS_ERR. Fixes: 4981b82ba2ff ("mailbox: ZynqMP IPI mailbox controller") Signed-off-by: Wei Yongjun Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 2d9c7e0ff9f427f4e1bfdbfecb91d3e6e3fcce43 Author: Chuhong Yuan Date: Thu May 28 18:39:50 2020 +0800 rtc: rv3028: Add missed check for devm_regmap_init_i2c() [ Upstream commit c3b29bf6f166f6ed5f04f9c125477358e0e25df8 ] rv3028_probe() misses a check for devm_regmap_init_i2c(). Add the missed check to fix it. Fixes: e6e7376cfd7b ("rtc: rv3028: add new driver") Signed-off-by: Chuhong Yuan Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20200528103950.912353-1-hslester96@gmail.com Signed-off-by: Sasha Levin commit f4fbb592d9d72d85bc6a62b0a18a09d3d9a7c4e6 Author: Qiushi Wu Date: Wed May 27 21:01:09 2020 -0500 vfio/mdev: Fix reference count leak in add_mdev_supported_type [ Upstream commit aa8ba13cae3134b8ef1c1b6879f66372531da738 ] kobject_init_and_add() takes reference even when it fails. If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Thus, replace kfree() by kobject_put() to fix this issue. Previous commit "b8eb718348b8" fixed a similar problem. Fixes: 7b96953bc640 ("vfio: Mediated device Core driver") Signed-off-by: Qiushi Wu Reviewed-by: Cornelia Huck Reviewed-by: Kirti Wankhede Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 1957ac8d1b4f10c38aa97f1dc60eb4aeb18d680e Author: Xiyu Yang Date: Mon May 25 22:12:46 2020 +0800 ASoC: fsl_asrc_dma: Fix dma_chan leak when config DMA channel failed [ Upstream commit 36124fb19f1ae68a500cd76a76d40c6e81bee346 ] fsl_asrc_dma_hw_params() invokes dma_request_channel() or fsl_asrc_get_dma_channel(), which returns a reference of the specified dma_chan object to "pair->dma_chan[dir]" with increased refcnt. The reference counting issue happens in one exception handling path of fsl_asrc_dma_hw_params(). When config DMA channel failed for Back-End, the function forgets to decrease the refcnt increased by dma_request_channel() or fsl_asrc_get_dma_channel(), causing a refcnt leak. Fix this issue by calling dma_release_channel() when config DMA channel failed. Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Link: https://lore.kernel.org/r/1590415966-52416-1-git-send-email-xiyuyang19@fudan.edu.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c75f1641ef58d341bd5bfdb9a9064ef278f7531d Author: Christophe JAILLET Date: Sun May 10 11:53:03 2020 +0200 extcon: adc-jack: Fix an error handling path in 'adc_jack_probe()' [ Upstream commit bc84cff2c92ae5ccb2c37da73756e7174b1b430f ] In some error handling paths, a call to 'iio_channel_get()' is not balanced by a corresponding call to 'iio_channel_release()'. This can be achieved easily by using the devm_ variant of 'iio_channel_get()'. This has the extra benefit to simplify the remove function. Fixes: 19939860dcae ("extcon: adc_jack: adc-jack driver to support 3.5 pi or simliar devices") Signed-off-by: Christophe JAILLET Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin commit 5ed5f8db95821c14f37483b950d0dd31bf592981 Author: huhai Date: Thu May 21 17:26:48 2020 +1000 powerpc/4xx: Don't unmap NULL mbase [ Upstream commit bcec081ecc940fc38730b29c743bbee661164161 ] Signed-off-by: huhai Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200521072648.1254699-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit 838d3e75ba508ee648b6cc8b4c30fc6e5f1c632e Author: Nathan Chancellor Date: Mon May 18 11:10:43 2020 -0700 input: i8042 - Remove special PowerPC handling [ Upstream commit e4f4ffa8a98c24a4ab482669b1e2b4cfce3f52f4 ] This causes a build error with CONFIG_WALNUT because kb_cs and kb_data were removed in commit 917f0af9e5a9 ("powerpc: Remove arch/ppc and include/asm-ppc"). ld.lld: error: undefined symbol: kb_cs > referenced by i8042-ppcio.h:28 (drivers/input/serio/i8042-ppcio.h:28) > input/serio/i8042.o:(__i8042_command) in archive drivers/built-in.a > referenced by i8042-ppcio.h:28 (drivers/input/serio/i8042-ppcio.h:28) > input/serio/i8042.o:(__i8042_command) in archive drivers/built-in.a > referenced by i8042-ppcio.h:28 (drivers/input/serio/i8042-ppcio.h:28) > input/serio/i8042.o:(__i8042_command) in archive drivers/built-in.a ld.lld: error: undefined symbol: kb_data > referenced by i8042.c:309 (drivers/input/serio/i8042.c:309) > input/serio/i8042.o:(__i8042_command) in archive drivers/built-in.a > referenced by i8042-ppcio.h:33 (drivers/input/serio/i8042-ppcio.h:33) > input/serio/i8042.o:(__i8042_command) in archive drivers/built-in.a > referenced by i8042.c:319 (drivers/input/serio/i8042.c:319) > input/serio/i8042.o:(__i8042_command) in archive drivers/built-in.a > referenced 15 more times Presumably since nobody has noticed this for the last 12 years, there is not anyone actually trying to use this driver so we can just remove this special walnut code and use the generic header so it builds for all configurations. Fixes: 917f0af9e5a9 ("powerpc: Remove arch/ppc and include/asm-ppc") Reported-by: kbuild test robot Signed-off-by: Nathan Chancellor Signed-off-by: Michael Ellerman Acked-by: Dmitry Torokhov Link: https://lore.kernel.org/r/20200518181043.3363953-1-natechancellor@gmail.com Signed-off-by: Sasha Levin commit cde05d643e5175ccde845fa0b1d897a02246e968 Author: Dan Carpenter Date: Wed May 20 15:04:14 2020 +0300 of: Fix a refcounting bug in __of_attach_node_sysfs() [ Upstream commit 8a325dd06f2358ea0888e4ff1c9ca4bc23bd53f3 ] The problem in this code is that if kobject_add() fails, then it should call of_node_put(np) to drop the reference count. I've actually moved the of_node_get(np) later in the function to avoid needing to do clean up. Fixes: 5b2c2f5a0ea3 ("of: overlay: add missing of_node_get() in __of_attach_node_sysfs") Signed-off-by: Dan Carpenter Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit f9db526da54787faa2c380a92dbf7bc4678eafaf Author: Olga Kornievskaia Date: Sun Apr 26 11:30:00 2020 -0400 NFSv4.1 fix rpc_call_done assignment for BIND_CONN_TO_SESSION [ Upstream commit 1c709b766e73e54d64b1dde1b7cfbcf25bcb15b9 ] Fixes: 02a95dee8cf0 ("NFS add callback_ops to nfs4_proc_bind_conn_to_session_callback") Signed-off-by: Olga Kornievskaia Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 5e85d78ed4ffa94066fb32e59f0e4e59622f7de2 Author: Fedor Tokarev Date: Sat Mar 28 14:56:55 2020 +0300 net: sunrpc: Fix off-by-one issues in 'rpc_ntop6' [ Upstream commit 118917d696dc59fd3e1741012c2f9db2294bed6f ] Fix off-by-one issues in 'rpc_ntop6': - 'snprintf' returns the number of characters which would have been written if enough space had been available, excluding the terminating null byte. Thus, a return value of 'sizeof(scopebuf)' means that the last character was dropped. - 'strcat' adds a terminating null byte to the string, thus if len == buflen, the null byte is written past the end of the buffer. Signed-off-by: Fedor Tokarev Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit ece3a3337c50c8e4fdd76a9158ac2c5c1067d061 Author: Dan Williams Date: Thu May 21 14:06:17 2020 -0700 /dev/mem: Revoke mappings when a driver claims the region [ Upstream commit 3234ac664a870e6ea69ae3a57d824cd7edbeacc5 ] Close the hole of holding a mapping over kernel driver takeover event of a given address range. Commit 90a545e98126 ("restrict /dev/mem to idle io memory ranges") introduced CONFIG_IO_STRICT_DEVMEM with the goal of protecting the kernel against scenarios where a /dev/mem user tramples memory that a kernel driver owns. However, this protection only prevents *new* read(), write() and mmap() requests. Established mappings prior to the driver calling request_mem_region() are left alone. Especially with persistent memory, and the core kernel metadata that is stored there, there are plentiful scenarios for a /dev/mem user to violate the expectations of the driver and cause amplified damage. Teach request_mem_region() to find and shoot down active /dev/mem mappings that it believes it has successfully claimed for the exclusive use of the driver. Effectively a driver call to request_mem_region() becomes a hole-punch on the /dev/mem device. The typical usage of unmap_mapping_range() is part of truncate_pagecache() to punch a hole in a file, but in this case the implementation is only doing the "first half" of a hole punch. Namely it is just evacuating current established mappings of the "hole", and it relies on the fact that /dev/mem establishes mappings in terms of absolute physical address offsets. Once existing mmap users are invalidated they can attempt to re-establish the mapping, or attempt to continue issuing read(2) / write(2) to the invalidated extent, but they will then be subject to the CONFIG_IO_STRICT_DEVMEM checking that can block those subsequent accesses. Cc: Arnd Bergmann Cc: Ingo Molnar Cc: Kees Cook Cc: Matthew Wilcox Cc: Russell King Cc: Andrew Morton Cc: Greg Kroah-Hartman Fixes: 90a545e98126 ("restrict /dev/mem to idle io memory ranges") Signed-off-by: Dan Williams Reviewed-by: Kees Cook Link: https://lore.kernel.org/r/159009507306.847224.8502634072429766747.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3302d17ef6ea0dd94b5a4acdf831f12f3e72d0c6 Author: John Hubbard Date: Tue May 26 18:26:26 2020 -0700 misc: xilinx-sdfec: improve get_user_pages_fast() error handling [ Upstream commit 57343d51613227373759f5b0f2eede257fd4b82e ] This fixes the case of get_user_pages_fast() returning a -errno. The result needs to be stored in a signed integer. And for safe signed/unsigned comparisons, it's best to keep everything signed. And get_user_pages_fast() also expects a signed value for number of pages to pin. Therefore, change most relevant variables, from u32 to int. Leave "n" unsigned, for convenience in checking for overflow. And provide a WARN_ON_ONCE() and early return, if overflow occurs. Also, as long as we're tidying up: rename the page array from page, to pages, in order to match the conventions used in most other call sites. Fixes: 20ec628e8007e ("misc: xilinx_sdfec: Add ability to configure LDPC") Cc: Derek Kiernan Cc: Dragan Cvetic Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: Michal Simek Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: John Hubbard Link: https://lore.kernel.org/r/20200527012628.1100649-2-jhubbard@nvidia.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 24aa54a8b0ec933cf5b114e868ce660933f20f43 Author: Eddie James Date: Wed Apr 8 15:36:16 2020 -0500 clk: ast2600: Fix AHB clock divider for A1 [ Upstream commit 2d491066ccd4286538450c227fc5094ceb04b494 ] The latest specs for the AST2600 A1 chip include some different bit definitions for calculating the AHB clock divider. Implement these in order to get the correct AHB clock value in Linux. Signed-off-by: Eddie James Link: https://lkml.kernel.org/r/20200408203616.4031-1-eajames@linux.ibm.com Fixes: d3d04f6c330a ("clk: Add support for AST2600 SoC") Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit c66e72f1721a6dfd62aff01aa05f23b9d3dc6b6b Author: Chunyan Zhang Date: Tue May 19 11:00:36 2020 +0800 clk: sprd: return correct type of value for _sprd_pll_recalc_rate [ Upstream commit c2f30986d418f26abefc2eec90ebf06716c970d2 ] The function _sprd_pll_recalc_rate() defines return value to unsigned long, but it would return a negative value when malloc fail, changing to return its parent_rate makes more sense, since if the callback .recalc_rate() is not set, the framework returns the parent_rate as well. Fixes: 3e37b005580b ("clk: sprd: add adjustable pll support") Signed-off-by: Chunyan Zhang Link: https://lkml.kernel.org/r/20200519030036.1785-2-zhang.lyra@gmail.com Reviewed-by: Baolin Wang Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit e5497842e25338c844c70728d6006cba84f47c59 Author: Qian Cai Date: Sun May 10 01:18:34 2020 -0400 KVM: PPC: Book3S: Fix some RCU-list locks [ Upstream commit ab8b65be183180c3eef405d449163964ecc4b571 ] It is unsafe to traverse kvm->arch.spapr_tce_tables and stt->iommu_tables without the RCU read lock held. Also, add cond_resched_rcu() in places with the RCU read lock held that could take a while to finish. arch/powerpc/kvm/book3s_64_vio.c:76 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 no locks held by qemu-kvm/4265. stack backtrace: CPU: 96 PID: 4265 Comm: qemu-kvm Not tainted 5.7.0-rc4-next-20200508+ #2 Call Trace: [c000201a8690f720] [c000000000715948] dump_stack+0xfc/0x174 (unreliable) [c000201a8690f770] [c0000000001d9470] lockdep_rcu_suspicious+0x140/0x164 [c000201a8690f7f0] [c008000010b9fb48] kvm_spapr_tce_release_iommu_group+0x1f0/0x220 [kvm] [c000201a8690f870] [c008000010b8462c] kvm_spapr_tce_release_vfio_group+0x54/0xb0 [kvm] [c000201a8690f8a0] [c008000010b84710] kvm_vfio_destroy+0x88/0x140 [kvm] [c000201a8690f8f0] [c008000010b7d488] kvm_put_kvm+0x370/0x600 [kvm] [c000201a8690f990] [c008000010b7e3c0] kvm_vm_release+0x38/0x60 [kvm] [c000201a8690f9c0] [c0000000005223f4] __fput+0x124/0x330 [c000201a8690fa20] [c000000000151cd8] task_work_run+0xb8/0x130 [c000201a8690fa70] [c0000000001197e8] do_exit+0x4e8/0xfa0 [c000201a8690fb70] [c00000000011a374] do_group_exit+0x64/0xd0 [c000201a8690fbb0] [c000000000132c90] get_signal+0x1f0/0x1200 [c000201a8690fcc0] [c000000000020690] do_notify_resume+0x130/0x3c0 [c000201a8690fda0] [c000000000038d64] syscall_exit_prepare+0x1a4/0x280 [c000201a8690fe20] [c00000000000c8f8] system_call_common+0xf8/0x278 ==== arch/powerpc/kvm/book3s_64_vio.c:368 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by qemu-kvm/4264: #0: c000201ae2d000d8 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0xdc/0x950 [kvm] #1: c000200c9ed0c468 (&kvm->srcu){....}-{0:0}, at: kvmppc_h_put_tce+0x88/0x340 [kvm] ==== arch/powerpc/kvm/book3s_64_vio.c:108 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by qemu-kvm/4257: #0: c000200b1b363a40 (&kv->lock){+.+.}-{3:3}, at: kvm_vfio_set_attr+0x598/0x6c0 [kvm] ==== arch/powerpc/kvm/book3s_64_vio.c:146 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by qemu-kvm/4257: #0: c000200b1b363a40 (&kv->lock){+.+.}-{3:3}, at: kvm_vfio_set_attr+0x598/0x6c0 [kvm] Signed-off-by: Qian Cai Signed-off-by: Paul Mackerras Signed-off-by: Sasha Levin commit fd1a1089aed818a713a2439d8aa3faee47a74e9d Author: Qian Cai Date: Wed May 13 09:39:15 2020 -0400 KVM: PPC: Book3S HV: Ignore kmemleak false positives [ Upstream commit 0aca8a5575544bd21b3363058afb8f1e81505150 ] kvmppc_pmd_alloc() and kvmppc_pte_alloc() allocate some memory but then pud_populate() and pmd_populate() will use __pa() to reference the newly allocated memory. Since kmemleak is unable to track the physical memory resulting in false positives, silence those by using kmemleak_ignore(). unreferenced object 0xc000201c382a1000 (size 4096): comm "qemu-kvm", pid 124828, jiffies 4295733767 (age 341.250s) hex dump (first 32 bytes): c0 00 20 09 f4 60 03 87 c0 00 20 10 72 a0 03 87 .. ..`.... .r... c0 00 20 0e 13 a0 03 87 c0 00 20 1b dc c0 03 87 .. ....... ..... backtrace: [<000000004cc2790f>] kvmppc_create_pte+0x838/0xd20 [kvm_hv] kvmppc_pmd_alloc at arch/powerpc/kvm/book3s_64_mmu_radix.c:366 (inlined by) kvmppc_create_pte at arch/powerpc/kvm/book3s_64_mmu_radix.c:590 [<00000000d123c49a>] kvmppc_book3s_instantiate_page+0x2e0/0x8c0 [kvm_hv] [<00000000bb549087>] kvmppc_book3s_radix_page_fault+0x1b4/0x2b0 [kvm_hv] [<0000000086dddc0e>] kvmppc_book3s_hv_page_fault+0x214/0x12a0 [kvm_hv] [<000000005ae9ccc2>] kvmppc_vcpu_run_hv+0xc5c/0x15f0 [kvm_hv] [<00000000d22162ff>] kvmppc_vcpu_run+0x34/0x48 [kvm] [<00000000d6953bc4>] kvm_arch_vcpu_ioctl_run+0x314/0x420 [kvm] [<000000002543dd54>] kvm_vcpu_ioctl+0x33c/0x950 [kvm] [<0000000048155cd6>] ksys_ioctl+0xd8/0x130 [<0000000041ffeaa7>] sys_ioctl+0x28/0x40 [<000000004afc4310>] system_call_exception+0x114/0x1e0 [<00000000fb70a873>] system_call_common+0xf0/0x278 unreferenced object 0xc0002001f0c03900 (size 256): comm "qemu-kvm", pid 124830, jiffies 4295735235 (age 326.570s) hex dump (first 32 bytes): c0 00 20 10 fa a0 03 87 c0 00 20 10 fa a1 03 87 .. ....... ..... c0 00 20 10 fa a2 03 87 c0 00 20 10 fa a3 03 87 .. ....... ..... backtrace: [<0000000023f675b8>] kvmppc_create_pte+0x854/0xd20 [kvm_hv] kvmppc_pte_alloc at arch/powerpc/kvm/book3s_64_mmu_radix.c:356 (inlined by) kvmppc_create_pte at arch/powerpc/kvm/book3s_64_mmu_radix.c:593 [<00000000d123c49a>] kvmppc_book3s_instantiate_page+0x2e0/0x8c0 [kvm_hv] [<00000000bb549087>] kvmppc_book3s_radix_page_fault+0x1b4/0x2b0 [kvm_hv] [<0000000086dddc0e>] kvmppc_book3s_hv_page_fault+0x214/0x12a0 [kvm_hv] [<000000005ae9ccc2>] kvmppc_vcpu_run_hv+0xc5c/0x15f0 [kvm_hv] [<00000000d22162ff>] kvmppc_vcpu_run+0x34/0x48 [kvm] [<00000000d6953bc4>] kvm_arch_vcpu_ioctl_run+0x314/0x420 [kvm] [<000000002543dd54>] kvm_vcpu_ioctl+0x33c/0x950 [kvm] [<0000000048155cd6>] ksys_ioctl+0xd8/0x130 [<0000000041ffeaa7>] sys_ioctl+0x28/0x40 [<000000004afc4310>] system_call_exception+0x114/0x1e0 [<00000000fb70a873>] system_call_common+0xf0/0x278 Signed-off-by: Qian Cai Signed-off-by: Paul Mackerras Signed-off-by: Sasha Levin commit 39983e18862401604e4d67c8927a119aa96e56b8 Author: Jeffrey Hugo Date: Mon May 25 13:41:25 2020 -0700 scsi: ufs-qcom: Fix scheduling while atomic issue [ Upstream commit 3be60b564de49875e47974c37fabced893cd0931 ] ufs_qcom_dump_dbg_regs() uses usleep_range, a sleeping function, but can be called from atomic context in the following flow: ufshcd_intr -> ufshcd_sl_intr -> ufshcd_check_errors -> ufshcd_print_host_regs -> ufshcd_vops_dbg_register_dump -> ufs_qcom_dump_dbg_regs This causes a boot crash on the Lenovo Miix 630 when the interrupt is handled on the idle thread. Fix the issue by switching to udelay(). Link: https://lore.kernel.org/r/20200525204125.46171-1-jeffrey.l.hugo@gmail.com Fixes: 9c46b8676271 ("scsi: ufs-qcom: dump additional testbus registers") Reviewed-by: Bean Huo Reviewed-by: Avri Altman Signed-off-by: Jeffrey Hugo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 4d33659ac379329bef3565666f4254232be0d064 Author: Nathan Chancellor Date: Sat May 16 01:08:06 2020 -0700 clk: bcm2835: Fix return type of bcm2835_register_gate [ Upstream commit f376c43bec4f8ee8d1ba5c5c4cfbd6e84fb279cb ] bcm2835_register_gate is used as a callback for the clk_register member of bcm2835_clk_desc, which expects a struct clk_hw * return type but bcm2835_register_gate returns a struct clk *. This discrepancy is hidden by the fact that bcm2835_register_gate is cast to the typedef bcm2835_clk_register by the _REGISTER macro. This turns out to be a control flow integrity violation, which is how this was noticed. Change the return type of bcm2835_register_gate to be struct clk_hw * and use clk_hw_register_gate to do so. This should be a non-functional change as clk_register_gate calls clk_hw_register_gate anyways but this is needed to avoid issues with further changes. Fixes: b19f009d4510 ("clk: bcm2835: Migrate to clk_hw based registration and OF APIs") Link: https://github.com/ClangBuiltLinux/linux/issues/1028 Signed-off-by: Nathan Chancellor Link: https://lkml.kernel.org/r/20200516080806.1459784-1-natechancellor@gmail.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 41324c48301dbe72dc76d5b06092f6832dd79955 Author: Dan Carpenter Date: Sat May 23 13:11:29 2020 +0300 scsi: target: tcmu: Fix a use after free in tcmu_check_expired_queue_cmd() [ Upstream commit 9d7464b18892332e35ff37f0b024429a1a9835e6 ] The pr_debug() dereferences "cmd" after we already freed it by calling tcmu_free_cmd(cmd). The debug printk needs to be done earlier. Link: https://lore.kernel.org/r/20200523101129.GB98132@mwanda Fixes: 61fb24822166 ("scsi: target: tcmu: Userspace must not complete queued commands") Reviewed-by: Mike Christie Reviewed-by: David Disseldorp Signed-off-by: Dan Carpenter Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 87b3dca712b4385c98d1641d45d1ada21821071b Author: Qiushi Wu Date: Mon May 25 00:50:11 2020 -0500 ASoC: fix incomplete error-handling in img_i2s_in_probe. [ Upstream commit 25bf943e4e7b47282bd86ae7d39e039217ebb007 ] Function "pm_runtime_get_sync()" is not handled by "pm_runtime_put()" if "PTR_ERR(rst) == -EPROBE_DEFER". Fix this issue by adding "pm_runtime_put()" into this error path. Fixes: f65bb92ca12e ("ASoC: img-i2s-in: Add runtime PM") Signed-off-by: Qiushi Wu Link: https://lore.kernel.org/r/20200525055011.31925-1-wu000273@umn.edu Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5578bf5ce0d8cc44f1393cb167345c2e6e96d3c9 Author: Christophe Leroy Date: Tue May 19 05:48:56 2020 +0000 powerpc/32s: Don't warn when mapping RO data ROX. [ Upstream commit 4b19f96a81bceaf0bcf44d79c0855c61158065ec ] Mapping RO data as ROX is not an issue since that data cannot be modified to introduce an exploit. PPC64 accepts to have RO data mapped ROX, as a trade off between kernel size and strictness of protection. On PPC32, kernel size is even more critical as amount of memory is usually small. Depending on the number of available IBATs, the last IBATs might overflow the end of text. Only warn if it crosses the end of RO data. Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/6499f8eeb2a36330e5c9fc1cee9a79374875bd54.1589866984.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit 9669bf039ff67c183ac51721ecff366623337bb3 Author: Amelie Delaunay Date: Wed Apr 22 11:08:33 2020 +0200 mfd: stmfx: Disable IRQ in suspend to avoid spurious interrupt [ Upstream commit 97eda5dcc2cde5dcc778bef7a9344db3b6bf8ef5 ] When STMFX supply is stopped, spurious interrupt can occur. To avoid that, disable the interrupt in suspend before disabling the regulator and re-enable it at the end of resume. Fixes: 06252ade9156 ("mfd: Add ST Multi-Function eXpander (STMFX) core driver") Signed-off-by: Amelie Delaunay Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit d8d1b8b4178312fff42e2df0eb4ad91cf4ee6a3e Author: Amelie Delaunay Date: Wed Apr 22 11:08:32 2020 +0200 mfd: stmfx: Fix stmfx_irq_init error path [ Upstream commit 60c2c4bcb9202acad4cc26af20b44b6bd7874f7b ] In case the interrupt signal can't be configured, IRQ domain needs to be removed. Fixes: 06252ade9156 ("mfd: Add ST Multi-Function eXpander (STMFX) core driver") Signed-off-by: Amelie Delaunay Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit cf90dd9fb161f6484d53ec8b1fc7364b5b009b14 Author: Amelie Delaunay Date: Wed Apr 22 11:08:31 2020 +0200 mfd: stmfx: Reset chip on resume as supply was disabled [ Upstream commit e583649d87ec090444aa5347af0927cd6e8581ae ] STMFX supply is disabled during suspend. To avoid a too early access to the STMFX firmware on resume, reset the chip and wait for its firmware to be loaded. Fixes: 06252ade9156 ("mfd: Add ST Multi-Function eXpander (STMFX) core driver") Signed-off-by: Amelie Delaunay Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit dc69fec9271adf261b4626d6fd721df21317eb55 Author: Borislav Petkov Date: Mon May 25 12:38:39 2020 +0200 x86/apic: Make TSC deadline timer detection message visible [ Upstream commit de308d1815c9e8fe602a958c5c76142ff6501d75 ] The commit c84cb3735fd5 ("x86/apic: Move TSC deadline timer debug printk") removed the message which said that the deadline timer was enabled. It added a pr_debug() message which is issued when deadline timer validation succeeds. Well, issued only when CONFIG_DYNAMIC_DEBUG is enabled - otherwise pr_debug() calls get optimized away if DEBUG is not defined in the compilation unit. Therefore, make the above message pr_info() so that it is visible in dmesg. Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20200525104218.27018-1-bp@alien8.de Signed-off-by: Sasha Levin commit af92e4a595e006b498c44b617ea38f697eca3469 Author: Potnuri Bharat Teja Date: Mon May 25 00:38:14 2020 +0530 RDMA/iw_cxgb4: cleanup device debugfs entries on ULD remove [ Upstream commit 49ea0c036ede81f126f1a9389d377999fdf5c5a1 ] Remove device specific debugfs entries immediately if LLD detaches a particular ULD device in case of fatal PCI errors. Link: https://lore.kernel.org/r/20200524190814.17599-1-bharat@chelsio.com Signed-off-by: Potnuri Bharat Teja Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 4c8a62c939840b2ad41ac6c6aadc44535761f9e4 Author: Siddharth Gupta Date: Tue May 5 18:52:37 2020 -0700 scripts: headers_install: Exit with error on config leak [ Upstream commit 5967577231f9b19acd5a59485e9075964065bbe3 ] Misuse of CONFIG_* in UAPI headers should result in an error. These config options can be set in userspace by the user application which includes these headers to control the APIs and structures being used in a kernel which supports multiple targets. Signed-off-by: Siddharth Gupta Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit c707e18796c6a001c44254f7087e7ad9f39086d5 Author: Pawel Laszczak Date: Mon May 18 12:08:45 2020 +0200 usb: gadget: Fix issue with config_ep_by_speed function [ Upstream commit 5d363120aa548ba52d58907a295eee25f8207ed2 ] This patch adds new config_ep_by_speed_and_alt function which extends the config_ep_by_speed about alt parameter. This additional parameter allows to find proper usb_ss_ep_comp_descriptor. Problem has appeared during testing f_tcm (BOT/UAS) driver function. f_tcm function for SS use array of headers for both BOT/UAS alternate setting: static struct usb_descriptor_header *uasp_ss_function_desc[] = { (struct usb_descriptor_header *) &bot_intf_desc, (struct usb_descriptor_header *) &uasp_ss_bi_desc, (struct usb_descriptor_header *) &bot_bi_ep_comp_desc, (struct usb_descriptor_header *) &uasp_ss_bo_desc, (struct usb_descriptor_header *) &bot_bo_ep_comp_desc, (struct usb_descriptor_header *) &uasp_intf_desc, (struct usb_descriptor_header *) &uasp_ss_bi_desc, (struct usb_descriptor_header *) &uasp_bi_ep_comp_desc, (struct usb_descriptor_header *) &uasp_bi_pipe_desc, (struct usb_descriptor_header *) &uasp_ss_bo_desc, (struct usb_descriptor_header *) &uasp_bo_ep_comp_desc, (struct usb_descriptor_header *) &uasp_bo_pipe_desc, (struct usb_descriptor_header *) &uasp_ss_status_desc, (struct usb_descriptor_header *) &uasp_status_in_ep_comp_desc, (struct usb_descriptor_header *) &uasp_status_pipe_desc, (struct usb_descriptor_header *) &uasp_ss_cmd_desc, (struct usb_descriptor_header *) &uasp_cmd_comp_desc, (struct usb_descriptor_header *) &uasp_cmd_pipe_desc, NULL, }; The first 5 descriptors are associated with BOT alternate setting, and others are associated with UAS. During handling UAS alternate setting f_tcm driver invokes config_ep_by_speed and this function sets incorrect companion endpoint descriptor in usb_ep object. Instead setting ep->comp_desc to uasp_bi_ep_comp_desc function in this case set ep->comp_desc to uasp_ss_bi_desc. This is due to the fact that it searches endpoint based on endpoint address: for_each_ep_desc(speed_desc, d_spd) { chosen_desc = (struct usb_endpoint_descriptor *)*d_spd; if (chosen_desc->bEndpoitAddress == _ep->address) goto ep_found; } And in result it uses the descriptor from BOT alternate setting instead UAS. Finally, it causes that controller driver during enabling endpoints detect that just enabled endpoint for bot. Signed-off-by: Jayshri Pawar Signed-off-by: Pawel Laszczak Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 84e1326ffc6164c396e58170cc14c9a50e7eea2e Author: Qiushi Wu Date: Fri May 22 23:06:25 2020 -0500 usb: gadget: fix potential double-free in m66592_probe. [ Upstream commit 44734a594196bf1d474212f38fe3a0d37a73278b ] m66592_free_request() is called under label "err_add_udc" and "clean_up", and m66592->ep0_req is not set to NULL after first free, leading to a double-free. Fix this issue by setting m66592->ep0_req to NULL after the first free. Fixes: 0f91349b89f3 ("usb: gadget: convert all users to the new udc infrastructure") Signed-off-by: Qiushi Wu Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 51ad579d64dd1c6c308d7c915da6a8f9c90355d7 Author: Colin Ian King Date: Thu May 21 16:13:00 2020 +0100 usb: gadget: lpc32xx_udc: don't dereference ep pointer before null check [ Upstream commit eafa80041645cd7604c4357b1a0cd4a3c81f2227 ] Currently pointer ep is being dereferenced before it is null checked leading to a null pointer dereference issue. Fix this by only assigning pointer udc once ep is known to be not null. Also remove a debug message that requires a valid udc which may not be possible at that point. Addresses-Coverity: ("Dereference before null check") Fixes: 24a28e428351 ("USB: gadget driver for LPC32xx") Signed-off-by: Colin Ian King Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 4a8c5f25c6bcf31fb06e9ff3ee0b573c723fdea3 Author: Nathan Chancellor Date: Thu Apr 23 09:29:24 2020 -0700 USB: gadget: udc: s3c2410_udc: Remove pointless NULL check in s3c2410_udc_nuke [ Upstream commit 7a0fbcf7c308920bc6116b3a5fb21c8cc5fec128 ] Clang warns: drivers/usb/gadget/udc/s3c2410_udc.c:255:11: warning: comparison of address of 'ep->queue' equal to a null pointer is always false [-Wtautological-pointer-compare] if (&ep->queue == NULL) ~~~~^~~~~ ~~~~ 1 warning generated. It is not wrong, queue is not a pointer so if ep is not NULL, the address of queue cannot be NULL. No other driver does a check like this and this check has been around since the driver was first introduced, presumably with no issues so it does not seem like this check should be something else. Just remove it. Commit afe956c577b2d ("kbuild: Enable -Wtautological-compare") exposed this but it is not the root cause of the warning. Fixes: 3fc154b6b8134 ("USB Gadget driver for Samsung s3c2410 ARM SoC") Link: https://github.com/ClangBuiltLinux/linux/issues/1004 Reviewed-by: Nick Desaulniers Reported-by: kbuild test robot Signed-off-by: Nathan Chancellor Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 0a560f102d8052e5238263cb3df0c088b84236d2 Author: Fabrice Gasnier Date: Thu Apr 23 13:55:53 2020 +0200 usb: dwc2: gadget: move gadget resume after the core is in L0 state [ Upstream commit 8c935deacebb8fac8f41378701eb79d12f3c2e2d ] When the remote wakeup interrupt is triggered, lx_state is resumed from L2 to L0 state. But when the gadget resume is called, lx_state is still L2. This prevents the resume callback to queue any request. Any attempt to queue a request from resume callback will result in: - "submit request only in active state" debug message to be issued - dwc2_hsotg_ep_queue() returns -EAGAIN Call the gadget resume routine after the core is in L0 state. Fixes: f81f46e1f530 ("usb: dwc2: implement hibernation during bus suspend/resume") Acked-by: Minas Harutyunyan Signed-off-by: Fabrice Gasnier Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit f1b9e29983aeb2b80d231e96732f71f04387530b Author: Stefan Riedmueller Date: Fri Apr 3 15:07:28 2020 +0200 watchdog: da9062: No need to ping manually before setting timeout [ Upstream commit a0948ddba65f4f6d3cfb5e2b84685485d0452966 ] There is actually no need to ping the watchdog before disabling it during timeout change. Disabling the watchdog already takes care of resetting the counter. This fixes an issue during boot when the userspace watchdog handler takes over and the watchdog is already running. Opening the watchdog in this case leads to the first ping and directly after that without the required heartbeat delay a second ping issued by the set_timeout call. Due to the missing delay this resulted in a reset. Signed-off-by: Stefan Riedmueller Reviewed-by: Guenter Roeck Reviewed-by: Adam Thomson Link: https://lore.kernel.org/r/20200403130728.39260-3-s.riedmueller@phytec.de Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit 4820050e8438353e710ac1f629945be09f73ce38 Author: Maor Gottlieb Date: Thu May 21 10:26:50 2020 +0300 IB/cma: Fix ports memory leak in cma_configfs [ Upstream commit 63a3345c2d42a9b29e1ce2d3a4043689b3995cea ] The allocated ports structure in never freed. The free function should be called by release_cma_ports_group, but the group is never released since we don't remove its default group. Remove default groups when device group is deleted. Fixes: 045959db65c6 ("IB/cma: Add configfs for rdma_cm") Link: https://lore.kernel.org/r/20200521072650.567908-1-leon@kernel.org Signed-off-by: Maor Gottlieb Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 6e934217c9434a0e6971d949c19447330086beb6 Author: Marc Zyngier Date: Wed Apr 29 17:42:30 2020 +0100 PCI: amlogic: meson: Don't use FAST_LINK_MODE to set up link [ Upstream commit 87dccf09323fc363bd0d072fcc12b96622ab8c69 ] The vim3l board does not work with a standard PCIe switch (ASM1184e), spitting all kind of errors - hinting at HW misconfiguration (no link, port enumeration issues, etc). According to the the Synopsys DWC PCIe Reference Manual, in the section dedicated to the PLCR register, bit 7 is described (FAST_LINK_MODE) as: "Sets all internal timers to fast mode for simulation purposes." it is sound to set this bit from a simulation perspective, but on actual silicon, which expects timers to have a nominal value, it is not. Make sure the FAST_LINK_MODE bit is cleared when configuring the RC to solve this problem. Link: https://lore.kernel.org/r/20200429164230.309922-1-maz@kernel.org Fixes: 9c0ef6d34fdb ("PCI: amlogic: Add the Amlogic Meson PCIe controller driver") Signed-off-by: Marc Zyngier [lorenzo.pieralisi@arm.com: commit log] Signed-off-by: Lorenzo Pieralisi Reviewed-by: Neil Armstrong Acked-by: Rob Herring Signed-off-by: Sasha Levin commit 443ed62ef80de5e22db6b7cb2ec431f21fcf6e89 Author: Marc Zyngier Date: Fri May 1 12:39:21 2020 +0100 PCI: dwc: Fix inner MSI IRQ domain registration [ Upstream commit 0414b93e78d87ecc24ae1a7e61fe97deb29fa2f4 ] On a system that uses the internal DWC MSI widget, I get this warning from debugfs when CONFIG_GENERIC_IRQ_DEBUGFS is selected: debugfs: File ':soc:pcie@fc000000' in directory 'domains' already present! This is due to the fact that the DWC MSI code tries to register two IRQ domains for the same firmware node, without telling the low level code how to distinguish them (by setting a bus token). This further confuses debugfs which tries to create corresponding files for each domain. Fix it by tagging the inner domain as DOMAIN_BUS_NEXUS, which is the closest thing we have as to "generic MSI". Link: https://lore.kernel.org/r/20200501113921.366597-1-maz@kernel.org Signed-off-by: Marc Zyngier Signed-off-by: Lorenzo Pieralisi Acked-by: Jingoo Han Signed-off-by: Sasha Levin commit 0bd8e62464e09bcfbb48f3b18f53e07b49b728d7 Author: Bjorn Helgaas Date: Thu May 21 15:40:07 2020 -0500 PCI/PTM: Inherit Switch Downstream Port PTM settings from Upstream Port [ Upstream commit 7b38fd9760f51cc83d80eed2cfbde8b5ead9e93a ] Except for Endpoints, we enable PTM at enumeration-time. Previously we did not account for the fact that Switch Downstream Ports are not permitted to have a PTM capability; their PTM behavior is controlled by the Upstream Port (PCIe r5.0, sec 7.9.16). Since Downstream Ports don't have a PTM capability, we did not mark them as "ptm_enabled", which meant that pci_enable_ptm() on an Endpoint failed because there was no PTM path to it. Mark Downstream Ports as "ptm_enabled" if their Upstream Port has PTM enabled. Fixes: eec097d43100 ("PCI: Add pci_enable_ptm() for drivers to enable PTM on endpoints") Reported-by: Aditya Paluri Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit f04479f8d519a1eeb7fe832eddf4f347b8b9e374 Author: Hannes Reinecke Date: Tue May 19 10:14:19 2020 +0200 dm zoned: return NULL if dmz_get_zone_for_reclaim() fails to find a zone [ Upstream commit 489dc0f06a5837f87482c0ce61d830d24e17082e ] The only case where dmz_get_zone_for_reclaim() cannot return a zone is if the respective lists are empty. So we should just return a simple NULL value here as we really don't have an error code which would make sense. Signed-off-by: Hannes Reinecke Reviewed-by: Damien Le Moal Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit 96cd8d249a376d9cdfd12a51801d4c1f5abc9094 Author: Qian Cai Date: Thu Mar 5 23:48:52 2020 -0500 powerpc/64s/pgtable: fix an undefined behaviour [ Upstream commit c2e929b18cea6cbf71364f22d742d9aad7f4677a ] Booting a power9 server with hash MMU could trigger an undefined behaviour because pud_offset(p4d, 0) will do, 0 >> (PAGE_SHIFT:16 + PTE_INDEX_SIZE:8 + H_PMD_INDEX_SIZE:10) Fix it by converting pud_index() and friends to static inline functions. UBSAN: shift-out-of-bounds in arch/powerpc/mm/ptdump/ptdump.c:282:15 shift exponent 34 is too large for 32-bit type 'int' CPU: 6 PID: 1 Comm: swapper/0 Not tainted 5.6.0-rc4-next-20200303+ #13 Call Trace: dump_stack+0xf4/0x164 (unreliable) ubsan_epilogue+0x18/0x78 __ubsan_handle_shift_out_of_bounds+0x160/0x21c walk_pagetables+0x2cc/0x700 walk_pud at arch/powerpc/mm/ptdump/ptdump.c:282 (inlined by) walk_pagetables at arch/powerpc/mm/ptdump/ptdump.c:311 ptdump_check_wx+0x8c/0xf0 mark_rodata_ro+0x48/0x80 kernel_init+0x74/0x194 ret_from_kernel_thread+0x5c/0x74 Suggested-by: Christophe Leroy Signed-off-by: Qian Cai Signed-off-by: Michael Ellerman Reviewed-by: Christophe Leroy Link: https://lore.kernel.org/r/20200306044852.3236-1-cai@lca.pw Signed-off-by: Sasha Levin commit a7ba81f26d703c121992a87e2a158e2e62dce7ae Author: Vidya Sagar Date: Thu May 14 19:24:37 2020 +0530 arm64: tegra: Fix flag for 64-bit resources in 'ranges' property [ Upstream commit 3482a7afb261e2de9269a7f9ad0f4a3a82a83a53 ] Fix flag in PCIe controllers device-tree nodes 'ranges' property to correctly represent 64-bit resources. Fixes: 2602c32f15e7 ("arm64: tegra: Add P2U and PCIe controller nodes to Tegra194 DT") Signed-off-by: Vidya Sagar Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 17232b92cf794fe6e3ee3c008bf3df3c97d3cbfd Author: Jon Hunter Date: Fri May 1 08:27:56 2020 +0100 arm64: tegra: Fix ethernet phy-mode for Jetson Xavier [ Upstream commit bba25915b172c72f6fa635f091624d799e3c9cae ] The 'phy-mode' property is currently defined as 'rgmii' for Jetson Xavier. This indicates that the RGMII RX and TX delays are set by the MAC and the internal delays set by the PHY are not used. If the Marvell PHY driver is enabled, such that it is used and not the generic PHY, ethernet failures are seen (DHCP is failing to obtain an IP address) and this is caused because the Marvell PHY driver is disabling the internal RX and TX delays. For Jetson Xavier the internal PHY RX and TX delay should be used and so fix this by setting the 'phy-mode' to 'rgmii-id' and not 'rgmii'. Fixes: f89b58ce71a9 ("arm64: tegra: Add ethernet controller on Tegra194") Signed-off-by: Jon Hunter Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit d658c127fc419ad62ae6a40d0548eeb63d16294c Author: Miklos Szeredi Date: Wed May 20 11:39:35 2020 +0200 fuse: copy_file_range should truncate cache [ Upstream commit 9b46418c40fe910e6537618f9932a8be78a3dd6c ] After the copy operation completes the cache is not up-to-date. Truncate all pages in the interval that has successfully been copied. Truncating completely copied dirty pages is okay, since the data has been overwritten anyway. Truncating partially copied dirty pages is not okay; add a comment for now. Fixes: 88bc7d5097a1 ("fuse: add support for copy_file_range()") Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit c9ddb8dd12e1e8d1ef5895175d54b50279317ce8 Author: Miklos Szeredi Date: Wed May 20 11:39:35 2020 +0200 fuse: fix copy_file_range cache issues [ Upstream commit 2c4656dfd994538176db30ce09c02cc0dfc361ae ] a) Dirty cache needs to be written back not just in the writeback_cache case, since the dirty pages may come from memory maps. b) The fuse_writeback_range() helper takes an inclusive interval, so the end position needs to be pos+len-1 instead of pos+len. Fixes: 88bc7d5097a1 ("fuse: add support for copy_file_range()") Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit ad7f78b7ce3975fa6713b392dbcbfbf3cc2e3fe2 Author: Wei Yongjun Date: Wed May 6 05:14:10 2020 +0000 firmware: imx: scu: Fix possible memory leak in imx_scu_probe() [ Upstream commit 89f12d6509bff004852c51cb713a439a86816b24 ] 'chan_name' is malloced in imx_scu_probe() and should be freed before leaving from the error handling cases, otherwise it will cause memory leak. Fixes: edbee095fafb ("firmware: imx: add SCU firmware driver support") Signed-off-by: Wei Yongjun Reviewed-by: Dong Aisheng Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 95ea51b2690e24fc2f5a593ce52b2001c21ffbdc Author: Bodo Stroesser Date: Mon May 18 18:48:33 2020 +0200 scsi: target: tcmu: Userspace must not complete queued commands [ Upstream commit 61fb2482216679b9e1e797440c148bb143a5040a ] When tcmu queues a new command - no matter whether in command ring or in qfull_queue - a cmd_id from IDR udev->commands is assigned to the command. If userspace sends a wrong command completion containing the cmd_id of a command on the qfull_queue, tcmu_handle_completions() finds the command in the IDR and calls tcmu_handle_completion() for it. This might do some nasty things because commands in qfull_queue do not have a valid dbi list. To fix this bug, we no longer add queued commands to the idr. Instead the cmd_id is assign when a command is written to the command ring. Due to this change I had to adapt the source code at several places where up to now an idr_for_each had been done. [mkp: fix checkpatch warnings] Link: https://lore.kernel.org/r/20200518164833.12775-1-bstroesser@ts.fujitsu.com Acked-by: Mike Christie Signed-off-by: Bodo Stroesser Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1503314a335422d45078466240898b8b16f3ec66 Author: Lang Cheng Date: Fri May 8 17:45:52 2020 +0800 RDMA/hns: Fix cmdq parameter of querying pf timer resource [ Upstream commit 441c88d5b3ff80108ff536c6cf80591187015403 ] The firmware has reduced the number of descriptions of command HNS_ROCE_OPC_QUERY_PF_TIMER_RES to 1. The driver needs to adapt, otherwise the hardware will report error 4(CMD_NEXT_ERR). Fixes: 0e40dc2f70cd ("RDMA/hns: Add timer allocation support for hip08") Link: https://lore.kernel.org/r/1588931159-56875-3-git-send-email-liweihang@huawei.com Signed-off-by: Lang Cheng Signed-off-by: Weihang Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit d09de58d2b651d9bf54ef16d7f38b31b9f04b72e Author: Lijun Ou Date: Fri May 8 17:45:51 2020 +0800 RDMA/hns: Bugfix for querying qkey [ Upstream commit 349be276509455ac2f19fa4051ed773082c6a27e ] The qkey queried through the query ud qp verb is a fixed value and it should be read from qp context. Fixes: 926a01dc000d ("RDMA/hns: Add QP operations support for hip08 SoC") Link: https://lore.kernel.org/r/1588931159-56875-2-git-send-email-liweihang@huawei.com Signed-off-by: Lijun Ou Signed-off-by: Weihang Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 7d95cb8a4073bb27eceeacd704fb41f3f32bff29 Author: Marek Szyprowski Date: Tue May 19 12:26:52 2020 +0200 clk: samsung: exynos5433: Add IGNORE_UNUSED flag to sclk_i2s1 [ Upstream commit 25bdae0f1c6609ceaf55fe6700654f0be2253d8e ] Mark the SCLK clock for Exynos5433 I2S1 device with IGNORE_UNUSED flag to match its behaviour with SCLK clock for AUD_I2S (I2S0) device until a proper fix for Exynos I2S driver is ready. This fixes the following synchronous abort issue revealed by the probe order change caused by the commit 93d2e4322aa7 ("of: platform: Batch fwnode parsing when adding all top level devices") Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 50 Comm: kworker/0:1 Not tainted 5.7.0-rc5+ #701 Hardware name: Samsung TM2E board (DT) Workqueue: events deferred_probe_work_func pstate: 60000005 (nZCv daif -PAN -UAO) pc : samsung_i2s_probe+0x768/0x8f0 lr : samsung_i2s_probe+0x688/0x8f0 ... Call trace: samsung_i2s_probe+0x768/0x8f0 platform_drv_probe+0x50/0xa8 really_probe+0x108/0x370 driver_probe_device+0x54/0xb8 __device_attach_driver+0x90/0xc0 bus_for_each_drv+0x70/0xc8 __device_attach+0xdc/0x140 device_initial_probe+0x10/0x18 bus_probe_device+0x94/0xa0 deferred_probe_work_func+0x70/0xa8 process_one_work+0x2a8/0x718 worker_thread+0x48/0x470 kthread+0x134/0x160 ret_from_fork+0x10/0x1c Code: 17ffffaf d503201f f94086c0 91003000 (88dffc00) ---[ end trace ccf721c9400ddbd6 ]--- Signed-off-by: Marek Szyprowski Signed-off-by: Sylwester Nawrocki Signed-off-by: Sasha Levin commit fddd06f7490f1d124db72820490f11d5e9ea6e2b Author: Souptick Joarder Date: Mon May 18 23:49:51 2020 +0530 fpga: dfl: afu: Corrected error handling levels [ Upstream commit c9d7e3da1f3c4cf5dddfc5d7ce4d76d013aba1cc ] Corrected error handling goto sequnece. Level put_pages should be called when pinned pages >= 0 && pinned != npages. Level free_pages should be called when pinned pages < 0. Fixes: fa8dda1edef9 ("fpga: dfl: afu: add DFL_FPGA_PORT_DMA_MAP/UNMAP ioctls support") Signed-off-by: Souptick Joarder Acked-by: Wu Hao Reviewed-by: Xu Yilun Link: https://lore.kernel.org/r/1589825991-3545-1-git-send-email-jrdr.linux@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7454c171a88c188583bbfe17db1f9e6e75723b5f Author: Gregory CLEMENT Date: Mon May 18 10:45:13 2020 +0200 tty: n_gsm: Fix bogus i++ in gsm_data_kick [ Upstream commit 4dd31f1ffec6c370c3c2e0c605628bf5e16d5c46 ] When submitting the previous fix "tty: n_gsm: Fix waking up upper tty layer when room available". It was suggested to switch from a while to a for loop, but when doing it, there was a remaining bogus i++. This patch removes this i++ and also reorganizes the code making it more compact. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Signed-off-by: Gregory CLEMENT Link: https://lore.kernel.org/r/20200518084517.2173242-3-gregory.clement@bootlin.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4f01308480c546853e199bf0da6ed7dffba43f69 Author: Tang Bin Date: Wed May 13 21:26:47 2020 +0800 USB: host: ehci-mxc: Add error handling in ehci_mxc_drv_probe() [ Upstream commit d49292025f79693d3348f8e2029a8b4703be0f0a ] The function ehci_mxc_drv_probe() does not perform sufficient error checking after executing platform_get_irq(), thus fix it. Fixes: 7e8d5cd93fac ("USB: Add EHCI support for MX27 and MX31 based boards") Signed-off-by: Zhang Shengju Signed-off-by: Tang Bin Reviewed-by: Peter Chen Link: https://lore.kernel.org/r/20200513132647.5456-1-tangbin@cmss.chinamobile.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0e033247379041d689b50e3eff4bcb5ac01ae5c4 Author: Hans de Goede Date: Mon May 18 09:24:16 2020 +0200 ASoC: Intel: bytcr_rt5640: Add quirk for Toshiba Encore WT8-A tablet [ Upstream commit 0e0e10fde0e9808d1991268f5dca69fb36c025f7 ] The Toshiba Encore WT8-A tablet almost fully works with the default settings for non-CR Bay Trail devices. The only problem is that its jack-detect switch is not inverted (it is active high instead of the normal active low). Add a quirk for this model using the default settings + BYT_RT5640_JD_NOT_INV. Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200518072416.5348-1-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f1069001bba71708128a61c29903a5c84a302296 Author: Roy Spliet Date: Tue Apr 7 18:07:37 2020 +0100 drm/msm/mdp5: Fix mdp5_init error path for failed mdp5_kms allocation [ Upstream commit e4337877c5d578722c0716f131fb774522013cf5 ] When allocation for mdp5_kms fails, calling mdp5_destroy() leads to undefined behaviour, likely a nullptr exception or use-after-free troubles. Signed-off-by: Roy Spliet Reviewed-by: Abhinav Kumar Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit fbf719e5da126c6b391ea7b1f38d4493582d8aaf Author: Qais Yousef Date: Mon May 18 16:49:29 2020 +0100 usb/ohci-platform: Fix a warning when hibernating [ Upstream commit 1cb3b0095c3d0bb96912bfbbce4fc006d41f367c ] The following warning was observed when attempting to suspend to disk using a USB flash as a swap device. [ 111.779649] ------------[ cut here ]------------ [ 111.788382] URB (____ptrval____) submitted while active [ 111.796646] WARNING: CPU: 3 PID: 365 at drivers/usb/core/urb.c:363 usb_submit_urb+0x3d8/0x590 [ 111.805417] Modules linked in: [ 111.808584] CPU: 3 PID: 365 Comm: kworker/3:2 Not tainted 5.6.0-rc6-00002-gdfd1731f9a3e-dirty #545 [ 111.817796] Hardware name: ARM Juno development board (r2) (DT) [ 111.823896] Workqueue: usb_hub_wq hub_event [ 111.828217] pstate: 60000005 (nZCv daif -PAN -UAO) [ 111.833156] pc : usb_submit_urb+0x3d8/0x590 [ 111.837471] lr : usb_submit_urb+0x3d8/0x590 [ 111.841783] sp : ffff800018de38b0 [ 111.845205] x29: ffff800018de38b0 x28: 0000000000000003 [ 111.850682] x27: ffff000970530b20 x26: ffff8000133fd000 [ 111.856159] x25: ffff8000133fd000 x24: ffff800018de3b38 [ 111.861635] x23: 0000000000000004 x22: 0000000000000c00 [ 111.867112] x21: 0000000000000000 x20: 00000000fffffff0 [ 111.872589] x19: ffff0009704e7a00 x18: ffffffffffffffff [ 111.878065] x17: 00000000a7c8f4bc x16: 000000002af33de8 [ 111.883542] x15: ffff8000133fda88 x14: 0720072007200720 [ 111.889019] x13: 0720072007200720 x12: 0720072007200720 [ 111.894496] x11: 0000000000000000 x10: 00000000a5286134 [ 111.899973] x9 : 0000000000000002 x8 : ffff000970c837a0 [ 111.905449] x7 : 0000000000000000 x6 : ffff800018de3570 [ 111.910926] x5 : 0000000000000001 x4 : 0000000000000003 [ 111.916401] x3 : 0000000000000000 x2 : ffff800013427118 [ 111.921879] x1 : 9d4e965b4b7d7c00 x0 : 0000000000000000 [ 111.927356] Call trace: [ 111.929892] usb_submit_urb+0x3d8/0x590 [ 111.933852] hub_activate+0x108/0x7f0 [ 111.937633] hub_resume+0xac/0x148 [ 111.941149] usb_resume_interface.isra.10+0x60/0x138 [ 111.946265] usb_resume_both+0xe4/0x140 [ 111.950225] usb_runtime_resume+0x24/0x30 [ 111.954365] __rpm_callback+0xdc/0x138 [ 111.958236] rpm_callback+0x34/0x98 [ 111.961841] rpm_resume+0x4a8/0x720 [ 111.965445] rpm_resume+0x50c/0x720 [ 111.969049] __pm_runtime_resume+0x4c/0xb8 [ 111.973276] usb_autopm_get_interface+0x28/0x60 [ 111.977948] hub_event+0x80/0x16d8 [ 111.981466] process_one_work+0x2a4/0x748 [ 111.985604] worker_thread+0x48/0x498 [ 111.989387] kthread+0x13c/0x140 [ 111.992725] ret_from_fork+0x10/0x18 [ 111.996415] irq event stamp: 354 [ 111.999756] hardirqs last enabled at (353): [] console_unlock+0x504/0x5b8 [ 112.008441] hardirqs last disabled at (354): [] do_debug_exception+0x1a8/0x258 [ 112.017479] softirqs last enabled at (350): [] __do_softirq+0x4bc/0x568 [ 112.025984] softirqs last disabled at (343): [] irq_exit+0x144/0x150 [ 112.034129] ---[ end trace dc96030b9cf6c8a3 ]--- The problem was tracked down to a missing call to pm_runtime_set_active() on resume in ohci-platform. Link: https://lore.kernel.org/lkml/20200323143857.db5zphxhq4hz3hmd@e107158-lin.cambridge.arm.com/ Acked-by: Alan Stern Signed-off-by: Qais Yousef CC: Tony Prisk CC: Greg Kroah-Hartman CC: Mathias Nyman CC: Oliver Neukum CC: linux-arm-kernel@lists.infradead.org CC: linux-usb@vger.kernel.org CC: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/r/20200518154931.6144-1-qais.yousef@arm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8a67dae365e0f23f67d07532edbdfda8dfb8ce44 Author: Alex Williamson Date: Wed Apr 8 11:45:28 2020 -0600 vfio-pci: Mask cap zero [ Upstream commit bc138db1b96264b9c1779cf18d5a3b186aa90066 ] The PCI Code and ID Assignment Specification changed capability ID 0 from reserved to a NULL capability in the v1.1 revision. The NULL capability is defined to include only the 16-bit capability header, ie. only the ID and next pointer. Unfortunately vfio-pci creates a map of config space, where ID 0 is used to reserve the standard type 0 header. Finding an actual capability with this ID therefore results in a bogus range marked in that map and conflicts with subsequent capabilities. As this seems to be a dummy capability anyway and we already support dropping capabilities, let's hide this one rather than delving into the potentially subtle dependencies within our map. Seen on an NVIDIA Tesla T4. Reviewed-by: Cornelia Huck Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit f5e28a0824ece6eba7397c862a76cd1d880def7a Author: Geoff Levand Date: Sat May 9 18:58:32 2020 +0000 powerpc/ps3: Fix kexec shutdown hang [ Upstream commit 126554465d93b10662742128918a5fc338cda4aa ] The ps3_mm_region_destroy() and ps3_mm_vas_destroy() routines are called very late in the shutdown via kexec's mmu_cleanup_all routine. By the time mmu_cleanup_all runs it is too late to use udbg_printf, and calling it will cause PS3 systems to hang. Remove all debugging statements from ps3_mm_region_destroy() and ps3_mm_vas_destroy() and replace any error reporting with calls to lv1_panic. With this change builds with 'DEBUG' defined will not cause kexec reboots to hang, and builds with 'DEBUG' defined or not will end in lv1_panic if an error is encountered. Signed-off-by: Geoff Levand Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/7325c4af2b4c989c19d6a26b90b1fec9c0615ddf.1589049250.git.geoff@infradead.org Signed-off-by: Sasha Levin commit 8f4372f4724d06d054f3a7e5d011741bef79d5f6 Author: Bharat Gooty Date: Wed May 13 23:09:47 2020 +0530 drivers: phy: sr-usb: do not use internal fsm for USB2 phy init [ Upstream commit 6f0577d1411337a0d97d545abe4a784e9e611516 ] During different reboot cycles, USB PHY PLL may not always lock during initialization and therefore can cause USB to be not usable. Hence do not use internal FSM programming sequence for the USB PHY initialization. Fixes: 4dcddbb38b64 ("phy: sr-usb: Add Stingray USB PHY driver") Signed-off-by: Bharat Gooty Signed-off-by: Rayagonda Kokatanur Link: https://lore.kernel.org/r/20200513173947.10919-1-rayagonda.kokatanur@broadcom.com Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Sasha Levin commit 1a588c7edcd08370eacc2ecafff5769e6e9907b0 Author: Nicholas Piggin Date: Fri May 8 14:33:58 2020 +1000 powerpc/pseries/ras: Fix FWNMI_VALID off by one [ Upstream commit deb70f7a35a22dffa55b2c3aac71bc6fb0f486ce ] This was discovered developing qemu fwnmi sreset support. This off-by-one bug means the last 16 bytes of the rtas area can not be used for a 16 byte save area. It's not a serious bug, and QEMU implementation has to retain a workaround for old kernels, but it's good to tighten it. Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Acked-by: Mahesh Salgaonkar Link: https://lore.kernel.org/r/20200508043408.886394-7-npiggin@gmail.com Signed-off-by: Sasha Levin commit 8240829fc38cc09ef13588d661e2b9cc887f6623 Author: Nicholas Piggin Date: Fri May 8 14:33:53 2020 +1000 powerpc/64s/exception: Fix machine check no-loss idle wakeup [ Upstream commit 8a5054d8cbbe03c68dcb0957c291c942132e4101 ] The architecture allows for machine check exceptions to cause idle wakeups which resume at the 0x200 address which has to return via the idle wakeup code, but the early machine check handler is run first. The case of a no state-loss sleep is broken because the early handler uses non-volatile register r1 , which is needed for the wakeup protocol, but it is not restored. Fix this by loading r1 from the MCE exception frame before returning to the idle wakeup code. Also update the comment which has become stale since the idle rewrite in C. This crash was found and fix confirmed with a machine check injection test in qemu powernv model (which is not upstream in qemu yet). Fixes: 10d91611f426d ("powerpc/64s: Reimplement book3s idle code in C") Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200508043408.886394-2-npiggin@gmail.com Signed-off-by: Sasha Levin commit b1bc8753eefc82b79e285977c6177c67bc17344e Author: Feng Tang Date: Fri Apr 17 12:48:28 2020 +0800 ipmi: use vzalloc instead of kmalloc for user creation [ Upstream commit 7c47a219b95d0e06b5ef5fcc7bad807895015eac ] We met mulitple times of failure of staring bmc-watchdog, due to the runtime memory allocation failure of order 4. bmc-watchdog: page allocation failure: order:4, mode:0x40cc0(GFP_KERNEL|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0-1 CPU: 1 PID: 2571 Comm: bmc-watchdog Not tainted 5.5.0-00045-g7d6bb61d6188c #1 Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.00.01.0015.110720180833 11/07/2018 Call Trace: dump_stack+0x66/0x8b warn_alloc+0xfe/0x160 __alloc_pages_slowpath+0xd3e/0xd80 __alloc_pages_nodemask+0x2f0/0x340 kmalloc_order+0x18/0x70 kmalloc_order_trace+0x1d/0xb0 ipmi_create_user+0x55/0x2c0 [ipmi_msghandler] ipmi_open+0x72/0x110 [ipmi_devintf] chrdev_open+0xcb/0x1e0 do_dentry_open+0x1ce/0x380 path_openat+0x305/0x14f0 do_filp_open+0x9b/0x110 do_sys_open+0x1bd/0x250 do_syscall_64+0x5b/0x1f0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Using vzalloc/vfree for creating ipmi_user heals the problem Thanks to Stephen Rothwell for finding the vmalloc.h inclusion issue. Signed-off-by: Feng Tang Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin commit 5c2207ba2394ee6c2dd7383890818aca89ff4b9b Author: Oded Gabbay Date: Fri Mar 27 16:38:37 2020 +0300 habanalabs: increase timeout during reset [ Upstream commit 7a65ee046b2238e053f6ebb610e1a082cfc49490 ] When doing training, the DL framework (e.g. tensorflow) performs hundreds of thousands of memory allocations and mappings. In case the driver needs to perform hard-reset during training, the driver kills the application and unmaps all those memory allocations. Unfortunately, because of that large amount of mappings, the driver isn't able to do that in the current timeout (5 seconds). Therefore, increase the timeout significantly to 30 seconds to avoid situation where the driver resets the device with active mappings, which sometime can cause a kernel bug. BTW, it doesn't mean we will spend all the 30 seconds because the reset thread checks every one second if the unmap operation is done. Reviewed-by: Omer Shpigelman Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin commit 828b192c57e8f4fee77f7a34bd19c1b58b049dad Author: Mika Westerberg Date: Thu May 14 16:30:43 2020 +0300 PCI/PM: Assume ports without DLL Link Active train links in 100 ms [ Upstream commit ec411e02b7a2e785a4ed9ed283207cd14f48699d ] Kai-Heng Feng reported that it takes a long time (> 1 s) to resume Thunderbolt-connected devices from both runtime suspend and system sleep (s2idle). This was because some Downstream Ports that support > 5 GT/s do not also support Data Link Layer Link Active reporting. Per PCIe r5.0 sec 6.6.1: With a Downstream Port that supports Link speeds greater than 5.0 GT/s, software must wait a minimum of 100 ms after Link training completes before sending a Configuration Request to the device immediately below that Port. Software can determine when Link training completes by polling the Data Link Layer Link Active bit or by setting up an associated interrupt (see Section 6.7.3.3). Sec 7.5.3.6 requires such Ports to support DLL Link Active reporting, but at least the Intel JHL6240 Thunderbolt 3 Bridge [8086:15c0] and the Intel JHL7540 Thunderbolt 3 Bridge [8086:15ea] do not. Previously we tried to wait for Link training to complete, but since there was no DLL Link Active reporting, all we could do was wait the worst-case 1000 ms, then another 100 ms. Instead of using the supported speeds to determine whether to wait for Link training, check whether the port supports DLL Link Active reporting. The Ports in question do not, so we'll wait only the 100 ms required for Ports that support Link speeds <= 5 GT/s. This of course assumes these Ports always train the Link within 100 ms even if they are operating at > 5 GT/s, which is not required by the spec. [bhelgaas: commit log, comment] Link: https://bugzilla.kernel.org/show_bug.cgi?id=206837 Link: https://lore.kernel.org/r/20200514133043.27429-1-mika.westerberg@linux.intel.com Reported-by: Kai-Heng Feng Tested-by: Kai-Heng Feng Signed-off-by: Mika Westerberg Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit c6737f3a1b01120ce0991bb0b6b4c8da2b086f1e Author: Cristian Klein Date: Fri May 8 17:26:04 2020 +0200 HID: Add quirks for Trust Panora Graphic Tablet [ Upstream commit fb68ada81e65d593b51544fa43c284322107a742 ] The Trust Panora Graphic Tablet has two interfaces. Interface zero reports pen movement, pen pressure and pen buttons. Interface one reports tablet buttons and tablet scroll. Both use the mouse protocol. Without these quirks, libinput gets confused about what device it talks to. For completeness, here is the usbhid-dump: ``` $ sudo usbhid-dump -d 145f:0212 003:013:001:DESCRIPTOR 1588949402.559961 05 0D 09 01 A1 01 85 07 A1 02 09 00 75 08 95 07 81 02 C0 C0 09 0E A1 01 85 05 09 23 A1 02 09 52 09 53 25 0A 75 08 95 02 B1 02 C0 C0 05 0C 09 36 A1 00 85 06 05 09 19 01 29 20 15 00 25 01 95 20 75 01 81 02 C0 003:013:000:DESCRIPTOR 1588949402.563942 05 01 09 02 A1 01 85 08 09 01 A1 00 05 09 19 01 29 03 15 00 25 01 95 03 75 01 81 02 95 05 81 01 05 01 09 30 09 31 09 38 09 00 15 81 25 7F 75 08 95 04 81 06 C0 C0 05 01 09 02 A1 01 85 09 09 01 A1 00 05 09 19 01 29 03 15 00 25 01 95 03 75 01 81 02 95 05 81 01 05 01 09 30 09 31 26 FF 7F 95 02 75 10 81 02 05 0D 09 30 26 FF 03 95 01 75 10 81 02 C0 C0 05 01 09 00 A1 01 85 04 A1 00 26 FF 00 09 00 75 08 95 07 B1 02 C0 C0 ``` Signed-off-by: Cristian Klein Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 7961800651fad8251eb83fb06c46bf4a20ca4230 Author: Erwin Burema Date: Sun May 10 20:29:11 2020 +0200 ALSA: usb-audio: Add duplex sound support for USB devices using implicit feedback [ Upstream commit 10ce77e4817fef99e1166be7e6685a80c63bf77f ] For USB sound devices using implicit feedback the endpoint used for this feedback should be able to be opened twice, once for required feedback and second time for audio data. This way these devices can be put in duplex audio mode. Since this only works if the settings of the endpoint don't change a check is included for this. This fixes bug 207023 ("MOTU M2 regression on duplex audio") and should also fix bug 103751 ("M-Audio Fast Track Ultra usb audio device will not operate full-duplex") Fixes: c249177944b6 ("ALSA: usb-audio: add implicit fb quirk for MOTU M Series") Signed-off-by: Erwin Burema BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207023 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=103751 Link: https://lore.kernel.org/r/2410739.SCZni40SNb@alpha-wolf Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 860b8717f7247384e500ba15c89e9b5327d00423 Author: Gregory CLEMENT Date: Tue May 12 13:53:23 2020 +0200 tty: n_gsm: Fix waking up upper tty layer when room available [ Upstream commit 01dbb362f0a114fbce19c8abe4cd6f4710e934d5 ] Warn the upper layer when n_gms is ready to receive data again. Without this the associated virtual tty remains blocked indefinitely. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Signed-off-by: Gregory CLEMENT Link: https://lore.kernel.org/r/20200512115323.1447922-4-gregory.clement@bootlin.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3a497f97a3b6927dc9a4ccd1754c8ad683681e5e Author: Gregory CLEMENT Date: Tue May 12 13:53:22 2020 +0200 tty: n_gsm: Fix SOF skipping [ Upstream commit 84d6f81c1fb58b56eba81ff0a36cf31946064b40 ] For at least some modems like the TELIT LE910, skipping SOF makes transfers blocking indefinitely after a short amount of data transferred. Given the small improvement provided by skipping the SOF (just one byte on about 100 bytes), it seems better to completely remove this "feature" than make it optional. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Signed-off-by: Gregory CLEMENT Link: https://lore.kernel.org/r/20200512115323.1447922-3-gregory.clement@bootlin.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7fcc2ca6a3fbe21b70162bd6a2a2ebf4417bf929 Author: Michael Ellerman Date: Tue Apr 28 22:31:30 2020 +1000 powerpc/64: Don't initialise init_task->thread.regs [ Upstream commit 7ffa8b7dc11752827329e4e84a574ea6aaf24716 ] Aneesh increased the size of struct pt_regs by 16 bytes and started seeing this WARN_ON: smp: Bringing up secondary CPUs ... ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at arch/powerpc/kernel/process.c:455 giveup_all+0xb4/0x110 Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.7.0-rc2-gcc-8.2.0-1.g8f6a41f-default+ #318 NIP: c00000000001a2b4 LR: c00000000001a29c CTR: c0000000031d0000 REGS: c0000000026d3980 TRAP: 0700 Not tainted (5.7.0-rc2-gcc-8.2.0-1.g8f6a41f-default+) MSR: 800000000282b033 CR: 48048224 XER: 00000000 CFAR: c000000000019cc8 IRQMASK: 1 GPR00: c00000000001a264 c0000000026d3c20 c0000000026d7200 800000000280b033 GPR04: 0000000000000001 0000000000000000 0000000000000077 30206d7372203164 GPR08: 0000000000002000 0000000002002000 800000000280b033 3230303030303030 GPR12: 0000000000008800 c0000000031d0000 0000000000800050 0000000002000066 GPR16: 000000000309a1a0 000000000309a4b0 000000000309a2d8 000000000309a890 GPR20: 00000000030d0098 c00000000264da40 00000000fd620000 c0000000ff798080 GPR24: c00000000264edf0 c0000001007469f0 00000000fd620000 c0000000020e5e90 GPR28: c00000000264edf0 c00000000264d200 000000001db60000 c00000000264d200 NIP [c00000000001a2b4] giveup_all+0xb4/0x110 LR [c00000000001a29c] giveup_all+0x9c/0x110 Call Trace: [c0000000026d3c20] [c00000000001a264] giveup_all+0x64/0x110 (unreliable) [c0000000026d3c90] [c00000000001ae34] __switch_to+0x104/0x480 [c0000000026d3cf0] [c000000000e0b8a0] __schedule+0x320/0x970 [c0000000026d3dd0] [c000000000e0c518] schedule_idle+0x38/0x70 [c0000000026d3df0] [c00000000019c7c8] do_idle+0x248/0x3f0 [c0000000026d3e70] [c00000000019cbb8] cpu_startup_entry+0x38/0x40 [c0000000026d3ea0] [c000000000011bb0] rest_init+0xe0/0xf8 [c0000000026d3ed0] [c000000002004820] start_kernel+0x990/0x9e0 [c0000000026d3f90] [c00000000000c49c] start_here_common+0x1c/0x400 Which was unexpected. The warning is checking the thread.regs->msr value of the task we are switching from: usermsr = tsk->thread.regs->msr; ... WARN_ON((usermsr & MSR_VSX) && !((usermsr & MSR_FP) && (usermsr & MSR_VEC))); ie. if MSR_VSX is set then both of MSR_FP and MSR_VEC are also set. Dumping tsk->thread.regs->msr we see that it's: 0x1db60000 Which is not a normal looking MSR, in fact the only valid bit is MSR_VSX, all the other bits are reserved in the current definition of the MSR. We can see from the oops that it was swapper/0 that we were switching from when we hit the warning, ie. init_task. So its thread.regs points to the base (high addresses) in init_stack. Dumping the content of init_task->thread.regs, with the members of pt_regs annotated (the 16 bytes larger version), we see: 0000000000000000 c000000002780080 gpr[0] gpr[1] 0000000000000000 c000000002666008 gpr[2] gpr[3] c0000000026d3ed0 0000000000000078 gpr[4] gpr[5] c000000000011b68 c000000002780080 gpr[6] gpr[7] 0000000000000000 0000000000000000 gpr[8] gpr[9] c0000000026d3f90 0000800000002200 gpr[10] gpr[11] c000000002004820 c0000000026d7200 gpr[12] gpr[13] 000000001db60000 c0000000010aabe8 gpr[14] gpr[15] c0000000010aabe8 c0000000010aabe8 gpr[16] gpr[17] c00000000294d598 0000000000000000 gpr[18] gpr[19] 0000000000000000 0000000000001ff8 gpr[20] gpr[21] 0000000000000000 c00000000206d608 gpr[22] gpr[23] c00000000278e0cc 0000000000000000 gpr[24] gpr[25] 000000002fff0000 c000000000000000 gpr[26] gpr[27] 0000000002000000 0000000000000028 gpr[28] gpr[29] 000000001db60000 0000000004750000 gpr[30] gpr[31] 0000000002000000 000000001db60000 nip msr 0000000000000000 0000000000000000 orig_r3 ctr c00000000000c49c 0000000000000000 link xer 0000000000000000 0000000000000000 ccr softe 0000000000000000 0000000000000000 trap dar 0000000000000000 0000000000000000 dsisr result 0000000000000000 0000000000000000 ppr kuap 0000000000000000 0000000000000000 pad[2] pad[3] This looks suspiciously like stack frames, not a pt_regs. If we look closely we can see return addresses from the stack trace above, c000000002004820 (start_kernel) and c00000000000c49c (start_here_common). init_task->thread.regs is setup at build time in processor.h: #define INIT_THREAD { \ .ksp = INIT_SP, \ .regs = (struct pt_regs *)INIT_SP - 1, /* XXX bogus, I think */ \ The early boot code where we setup the initial stack is: LOAD_REG_ADDR(r3,init_thread_union) /* set up a stack pointer */ LOAD_REG_IMMEDIATE(r1,THREAD_SIZE) add r1,r3,r1 li r0,0 stdu r0,-STACK_FRAME_OVERHEAD(r1) Which creates a stack frame of size 112 bytes (STACK_FRAME_OVERHEAD). Which is far too small to contain a pt_regs. So the result is init_task->thread.regs is pointing at some stack frames on the init stack, not at a pt_regs. We have gotten away with this for so long because with pt_regs at its current size the MSR happens to point into the first frame, at a location that is not written to by the early asm. With the 16 byte expansion the MSR falls into the second frame, which is used by the compiler, and collides with a saved register that tends to be non-zero. As far as I can see this has been wrong since the original merge of 64-bit ppc support, back in 2002. Conceptually swapper should have no regs, it never entered from userspace, and in fact that's what we do on 32-bit. It's also presumably what the "bogus" comment is referring to. So I think the right fix is to just not-initialise regs at all. I'm slightly worried this will break some code that isn't prepared for a NULL regs, but we'll have to see. Remove the comment in head_64.S which refers to us setting up the regs (even though we never did), and is otherwise not really accurate any more. Reported-by: Aneesh Kumar K.V Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200428123130.73078-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit c7fab8a5c3ba182486eda7bf4f9e6b341d273aee Author: Rob Herring Date: Wed May 13 17:38:58 2020 -0500 PCI: Fix pci_register_host_bridge() device_register() error handling [ Upstream commit 1b54ae8327a4d630111c8d88ba7906483ec6010b ] If device_register() has an error, we should bail out of pci_register_host_bridge() rather than continuing on. Fixes: 37d6a0a6f470 ("PCI: Add pci_register_host_bridge() interface") Link: https://lore.kernel.org/r/20200513223859.11295-1-robh@kernel.org Signed-off-by: Rob Herring Signed-off-by: Bjorn Helgaas Reviewed-by: Lorenzo Pieralisi Reviewed-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 86e8dd9d249c45f834cf0a03467e43ff3f726df3 Author: Tero Kristo Date: Wed Apr 29 16:13:39 2020 +0300 clk: ti: composite: fix memory leak [ Upstream commit c7c1cbbc9217ebb5601b88d138d4a5358548de9d ] The parent_names is never released for a component clock definition, causing some memory leak. Fix by releasing it once it is no longer needed. Reported-by: Tomi Valkeinen Signed-off-by: Tero Kristo Link: https://lkml.kernel.org/r/20200429131341.4697-2-t-kristo@ti.com Acked-by: Tony Lindgren Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 4536dbe64bd17b7d16cb0da56a15616dda247940 Author: Wei Yongjun Date: Wed May 6 13:56:25 2020 +0000 USB: ohci-sm501: fix error return code in ohci_hcd_sm501_drv_probe() [ Upstream commit b919e077cccfbb77beb98809568b2fb0b4d113ec ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 7d9e6f5aebe8 ("usb: host: ohci-sm501: init genalloc for local memory") Signed-off-by: Wei Yongjun Acked-by: Alan Stern Link: https://lore.kernel.org/r/20200506135625.106910-1-weiyongjun1@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c17e7243051a5189ea1182528d4b2b0e97418752 Author: Arnd Bergmann Date: Thu May 7 23:34:28 2020 +0200 dlm: remove BUG() before panic() [ Upstream commit fe204591cc9480347af7d2d6029b24a62e449486 ] Building a kernel with clang sometimes fails with an objtool error in dlm: fs/dlm/lock.o: warning: objtool: revert_lock_pc()+0xbd: can't find jump dest instruction at .text+0xd7fc The problem is that BUG() never returns and the compiler knows that anything after it is unreachable, however the panic still emits some code that does not get fully eliminated. Having both BUG() and panic() is really pointless as the BUG() kills the current process and the subsequent panic() never hits. In most cases, we probably don't really want either and should replace the DLM_ASSERT() statements with WARN_ON(), as has been done for some of them. Remove the BUG() here so the user at least sees the panic message and we can reliably build randconfig kernels. Fixes: e7fd41792fc0 ("[DLM] The core of the DLM for GFS2/CLVM") Cc: Josh Poimboeuf Cc: clang-built-linux@googlegroups.com Signed-off-by: Arnd Bergmann Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit d40e6a98aa5519ffde6751ba10ab2ec17cc746dc Author: Dafna Hirschfeld Date: Wed May 6 12:09:03 2020 +0200 pinctrl: rockchip: fix memleak in rockchip_dt_node_to_map [ Upstream commit d7faa8ffb6be57bf8233a4b5a636d76b83c51ce7 ] In function rockchip_dt_node_to_map, a new_map variable is allocated by: new_map = devm_kcalloc(pctldev->dev, map_num, sizeof(*new_map), GFP_KERNEL); This uses devres and attaches new_map to the pinctrl driver. This cause a leak since new_map is not released when the probed driver is removed. Fix it by using kcalloc to allocate new_map and free it in `rockchip_dt_free_map` Signed-off-by: Dafna Hirschfeld Reviewed-by: Heiko Stuebner Link: https://lore.kernel.org/r/20200506100903.15420-1-dafna.hirschfeld@collabora.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 5248114b9bcfa5bbbb2965a98f97110684faec7e Author: Christophe JAILLET Date: Tue May 12 15:43:25 2020 +0200 ASoC: ti: omap-mcbsp: Fix an error handling path in 'asoc_mcbsp_probe()' [ Upstream commit 03990fd58d2b7c8f7d53e514ba9b8749fac260f9 ] If an error occurs after the call to 'omap_mcbsp_init()', the reference to 'mcbsp->fclk' must be decremented, as already done in the remove function. This can be achieved easily by using the devm_ variant of 'clk_get()' when the reference is taken in 'omap_mcbsp_init()' This fixes the leak in the probe and has the side effect to simplify both the error handling path of 'omap_mcbsp_init()' and the remove function. Signed-off-by: Christophe JAILLET Acked-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20200512134325.252073-1-christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5acfef99644cf63e800c68848969f3efab07c420 Author: Christophe JAILLET Date: Tue May 12 12:07:05 2020 +0200 ASoC: ux500: mop500: Fix some refcounted resources issues [ Upstream commit 4e8748fcaeec073e3ba794871ce86c545e4f961f ] There are 2 issues here: - if one of the 'of_parse_phandle' fails, calling 'mop500_of_node_put()' is a no-op because the 'mop500_dai_links' structure has not been initialized yet, so the referenced are not decremented - The reference stored in 'mop500_dai_links[i].codecs' is refcounted only once in the probe and must be decremented only once. Fixes: 39013bd60e79 ("ASoC: Ux500: Dispose of device nodes correctly") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/20200512100705.246349-1-christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b0ccdd2fdd0068f2514ddd43c6d46143cc07c4bb Author: Yongbo Zhang Date: Tue May 12 17:30:03 2020 +0800 SoC: rsnd: add interrupt support for SSI BUSIF buffer [ Upstream commit 66c705d07d784fb6b4622c6e47b6acae357472db ] SSI BUSIF buffer is possible to overflow or underflow, especially in a hypervisor environment. If there is no interrupt support, it will eventually lead to errors in pcm data. This patch adds overflow and underflow interrupt support for SSI BUSIF buffer. Reported-by: Chen Li Signed-off-by: Yongbo Zhang Tested-by: Chen Li Acked-by: Kuninori Morimoto Link: https://lore.kernel.org/r/20200512093003.28332-1-giraffesnn123@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f34a3697a8d426de347f2d106453d6dacad8a3bc Author: Suganath Prabu S Date: Fri May 8 07:07:38 2020 -0400 scsi: mpt3sas: Fix double free warnings [ Upstream commit cbbfdb2a2416c9f0cde913cf09670097ac281282 ] Fix following warning from Smatch static analyser: drivers/scsi/mpt3sas/mpt3sas_base.c:5256 _base_allocate_memory_pools() warn: 'ioc->hpr_lookup' double freed drivers/scsi/mpt3sas/mpt3sas_base.c:5256 _base_allocate_memory_pools() warn: 'ioc->internal_lookup' double freed Link: https://lore.kernel.org/r/20200508110738.30732-1-suganath-prabu.subramani@broadcom.com Reported-by: Dan Carpenter Signed-off-by: Suganath Prabu S Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f20dfec03b8248e9a4f6ba601ec10fce629b1943 Author: Bodo Stroesser Date: Tue Apr 28 20:26:17 2020 +0200 scsi: target: loopback: Fix READ with data and sensebytes [ Upstream commit c68a56736c129f5dd1632856956f9c3e04bae200 ] We use tcm_loop with tape emulations running on tcmu. In case application reads a short tape block with a longer READ, or a long tape block with a short READ, according to SCC spec data has to be tranferred _and_ sensebytes with ILI set and information field containing the residual count. Similar problem also exists when using fixed block size in READ. Up to now tcm_loop is not prepared to handle sensebytes if input data is provided, as in tcm_loop_queue_data_in() it only sets SAM_STAT_GOOD and, if necessary, the residual count. To fix the bug, the same handling for sensebytes as present in tcm_loop_queue_status() must be done in tcm_loop_queue_data_in() also. After adding this handling, the two function now are nearly identical, so I created a single function with two wrappers. Link: https://lore.kernel.org/r/20200428182617.32726-1-bstroesser@ts.fujitsu.com Signed-off-by: Bodo Stroesser Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a798daf42a35e2f385f6758f061235d8faae9ee9 Author: Loic Poulain Date: Tue Apr 21 14:00:24 2020 +0200 arm64: dts: msm8996: Fix CSI IRQ types [ Upstream commit 4a4a26317ec8aba575f6b85789a42639937bc1a4 ] Each IRQ_TYPE_NONE interrupt causes a warning at boot. Fix that by defining an appropriate type. Fixes: e0531312e78f ("arm64: dts: qcom: msm8996: Add CAMSS support") Signed-off-by: Loic Poulain Link: https://lore.kernel.org/r/1587470425-13726-1-git-send-email-loic.poulain@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 6544b95bd789bf79dd0e87a8ccb0eb0ce79431a7 Author: Wei Yongjun Date: Sat May 9 09:33:37 2020 +0000 ASoC: SOF: core: fix error return code in sof_probe_continue() [ Upstream commit 7d8785bc7adbb4dc5ba8ee06994107637848ded8 ] Fix to return negative error code -ENOMEM from the IPC init error handling case instead of 0, as done elsewhere in this function. Fixes: c16211d6226d ("ASoC: SOF: Add Sound Open Firmware driver core") Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Link: https://lore.kernel.org/r/20200509093337.78897-1-weiyongjun1@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 79790202d4f3772447403089e94077ff483cd5eb Author: Dmitry Osipenko Date: Sun Mar 29 18:15:44 2020 +0200 power: supply: smb347-charger: IRQSTAT_D is volatile [ Upstream commit c32ea07a30630ace950e07ffe7a18bdcc25898e1 ] Fix failure when USB cable is connected: smb347 2-006a: reading IRQSTAT_D failed Fixes: 1502cfe19bac ("smb347-charger: Fix battery status reporting logic for charger faults") Tested-by: David Heidelberg Signed-off-by: Dmitry Osipenko Signed-off-by: David Heidelberg Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit ad8b5b5faf9d18b3af160525e1ea638851f66c4a Author: Christophe JAILLET Date: Sat May 9 10:23:23 2020 +0200 power: supply: lp8788: Fix an error handling path in 'lp8788_charger_probe()' [ Upstream commit 934ed3847a4ebc75b655659c4d2349ba4337941c ] In the probe function, in case of error, resources allocated in 'lp8788_setup_adc_channel()' must be released. This can be achieved easily by using the devm_ variant of 'iio_channel_get()'. This has the extra benefit to simplify the remove function and to axe the 'lp8788_release_adc_channel()' function which is now useless. Fixes: 98a276649358 ("power_supply: Add new lp8788 charger driver") Signed-off-by: Christophe JAILLET Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit c1bcf01aea0ec11c8cd0ffcc43591429dd67fbf3 Author: Takashi Sakamoto Date: Fri May 8 13:36:26 2020 +0900 ALSA: firewire-lib: fix invalid assignment to union data for directional parameter [ Upstream commit 8304cf77c92038cd1c50c27b69d30be695cc8003 ] Although the value of FDF is used just for outgoing stream, the assignment to union member is done for both directions of stream. At present this causes no issue because the value of same position is reassigned later for opposite stream. However, it's better to add if statement. Fixes: d3d10a4a1b19 ("ALSA: firewire-lib: use union for directional parameters") Signed-off-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20200508043635.349339-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 3201bb03c8fda1a048cb322c4a2be424840aa2bd Author: Viacheslav Dubeyko Date: Fri Apr 10 11:07:08 2020 +0300 scsi: qla2xxx: Fix warning after FC target reset [ Upstream commit f839544ccff60cbe534282aac68858fc3fb278ca ] Currently, FC target reset finishes with the warning message: [84010.596893] ------------[ cut here ]------------ [84010.596917] WARNING: CPU: 238 PID: 279973 at ../drivers/scsi/qla2xxx/qla_target.c:6644 qlt_enable_vha+0x1d0/0x260 [qla2xxx] [84010.596918] Modules linked in: vrf af_packet 8021q garp mrp stp llc netlink_diag target_tatlin_tblock(OEX) dm_ec(OEX) ttln_rdma(OEX) dm_frontend(OEX) nvme_rdma nvmet tcm_qla2xxx iscsi_target_mod target_core_mod at24 nvmem_core pnv_php ipmi_watchdog ipmi_ssif vmx_crypto gf128mul crct10dif_vpmsum qla2xxx rpcrdma nvme_fc powernv_flash(X) nvme_fabrics uio_pdrv_genirq mtd rtc_opal(X) ibmpowernv(X) opal_prd(X) uio scsi_transport_fc i2c_opal(X) ses enclosure ipmi_poweroff ast i2c_algo_bit ttm bmc_mcu(OEX) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm drm_panel_orientation_quirks agpgart nfsd auth_rpcgss nfs_acl ipmi_powernv(X) lockd ipmi_devintf ipmi_msghandler grace dummy ext4 crc16 jbd2 mbcache sd_mod rdma_ucm ib_iser rdma_cm ib_umad iw_cm ib_ipoib libiscsi scsi_transport_iscsi ib_cm [84010.596975] configfs mlx5_ib ib_uverbs ib_core mlx5_core crc32c_vpmsum xhci_pci xhci_hcd mpt3sas(OEX) tg3 usbcore mlxfw tls raid_class libphy scsi_transport_sas devlink ptp pps_core nvme nvme_core sunrpc dm_mirror dm_region_hash dm_log sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua scsi_mod autofs4 [84010.597001] Supported: Yes, External [84010.597004] CPU: 238 PID: 279973 Comm: bash Tainted: G OE 4.12.14-197.29-default #1 SLE15-SP1 [84010.597006] task: c000000a104c0000 task.stack: c000000b52188000 [84010.597007] NIP: d00000001ffd7f78 LR: d00000001ffd7f6c CTR: c0000000001676c0 [84010.597008] REGS: c000000b5218b910 TRAP: 0700 Tainted: G OE (4.12.14-197.29-default) [84010.597008] MSR: 900000010282b033 [84010.597015] CR: 48242424 XER: 00000000 [84010.597016] CFAR: d00000001ff45d08 SOFTE: 1 GPR00: d00000001ffd7f6c c000000b5218bb90 d00000002001b228 0000000000000102 GPR04: 0000000000000001 0000000000000001 00013d91ed0a5e2d 0000000000000000 GPR08: c000000007793300 0000000000000000 0000000000000000 c000000a086e7818 GPR12: 0000000000002200 c000000007793300 0000000000000000 000000012bc937c0 GPR16: 000000012bbf7ed0 0000000000000000 000000012bc3dd10 0000000000000000 GPR20: 000000012bc4db28 0000010036442810 000000012bc97828 000000012bc96c70 GPR24: 00000100365b1550 0000000000000000 00000100363f3d80 c000000be20d3080 GPR28: c000000bda7eae00 c000000be20db7e8 c000000be20d3778 c000000be20db7e8 [84010.597042] NIP [d00000001ffd7f78] qlt_enable_vha+0x1d0/0x260 [qla2xxx] [84010.597051] LR [d00000001ffd7f6c] qlt_enable_vha+0x1c4/0x260 [qla2xxx] [84010.597051] Call Trace: [84010.597061] [c000000b5218bb90] [d00000001ffd7f6c] qlt_enable_vha+0x1c4/0x260 [qla2xxx] (unreliable) [84010.597064] [c000000b5218bc20] [d000000009820b6c] tcm_qla2xxx_tpg_enable_store+0xc4/0x130 [tcm_qla2xxx] [84010.597067] [c000000b5218bcb0] [d0000000185d0e68] configfs_write_file+0xd0/0x190 [configfs] [84010.597072] [c000000b5218bd00] [c0000000003d0edc] __vfs_write+0x3c/0x1e0 [84010.597074] [c000000b5218bd90] [c0000000003d2ea8] vfs_write+0xd8/0x220 [84010.597076] [c000000b5218bde0] [c0000000003d4ddc] SyS_write+0x6c/0x110 [84010.597079] [c000000b5218be30] [c00000000000b188] system_call+0x3c/0x130 [84010.597080] Instruction dump: [84010.597082] 7d0050a8 7d084b78 7d0051ad 40c2fff4 7fa3eb78 4bf73965 60000000 7fa3eb78 [84010.597086] 4bf6dcd9 60000000 2fa30000 419eff40 <0fe00000> 4bffff38 e95f0058 a12a0180 [84010.597090] ---[ end trace e32abaf6e6fee826 ]--- To reproduce: echo 0x7fffffff > /sys/module/qla2xxx/parameters/logging modprobe target_core_mod modprobe tcm_qla2xxx mkdir /sys/kernel/config/target/qla2xxx mkdir /sys/kernel/config/target/qla2xxx/ mkdir /sys/kernel/config/target/qla2xxx//tpgt_1 echo 1 > /sys/kernel/config/target/qla2xxx//tpgt_1/enable echo 0 > /sys/kernel/config/target/qla2xxx//tpgt_1/enable echo 1 > /sys/kernel/config/target/qla2xxx//tpgt_1/enable SYSTEM START kernel: pid 327:drivers/scsi/qla2xxx/qla_init.c:2174 qla2x00_initialize_adapter(): vha->flags.online 0x0 <...> kernel: pid 327:drivers/scsi/qla2xxx/qla_os.c:3444 qla2x00_probe_one(): vha->flags.online 0x1 echo 1 > /sys/kernel/config/target/qla2xxx/21:00:00:24:ff:86:a6:2a/tpgt_1/enable kernel: pid 348:drivers/scsi/qla2xxx/qla_init.c:6641 qla2x00_abort_isp_cleanup(): vha->flags.online 0x0, ISP_ABORT_NEEDED 0x0 <...> kernel: pid 348:drivers/scsi/qla2xxx/qla_init.c:6998 qla2x00_restart_isp(): vha->flags.online 0x0 echo 0 > /sys/kernel/config/target/qla2xxx/21:00:00:24:ff:86:a6:2a/tpgt_1/enable kernel: pid 348:drivers/scsi/qla2xxx/qla_init.c:6641 qla2x00_abort_isp_cleanup(): vha->flags.online 0x0, ISP_ABORT_NEEDED 0x0 <...> kernel: pid 1404:drivers/scsi/qla2xxx/qla_os.c:1107 qla2x00_wait_for_hba_online(): base_vha->flags.online 0x0 echo 1 > /sys/kernel/config/target/qla2xxx/21:00:00:24:ff:86:a6:2a/tpgt_1/enable kernel: pid 1404:drivers/scsi/qla2xxx/qla_os.c:1107 qla2x00_wait_for_hba_online(): base_vha->flags.online 0x0 kernel: -----------[ cut here ]----------- kernel: WARNING: CPU: 1 PID: 1404 at drivers/scsi/qla2xxx/qla_target.c:6654 qlt_enable_vha+0x1e0/0x280 [qla2xxx] The issue happens because no real ISP reset is executed. The qla2x00_abort_isp(scsi_qla_host_t *vha) function expects that vha->flags.online will be not zero for ISP reset procedure. This patch sets vha->flags.online to 1 before calling ->abort_isp() for starting the ISP reset. Link: https://lore.kernel.org/r/1d7b21bf9f7676643239eb3d60eaca7cfa505cf0.camel@yadro.com Reviewed-by: Roman Bolshakov Signed-off-by: Viacheslav Dubeyko Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 766c787e55ca2fc66a2ce8fc7f3cb0d3cf9fd58f Author: Kai-Heng Feng Date: Wed May 6 01:34:21 2020 +0800 PCI/ASPM: Allow ASPM on links to PCIe-to-PCI/PCI-X Bridges [ Upstream commit 66ff14e59e8a30690755b08bc3042359703fb07a ] 7d715a6c1ae5 ("PCI: add PCI Express ASPM support") added the ability for Linux to enable ASPM, but for some undocumented reason, it didn't enable ASPM on links where the downstream component is a PCIe-to-PCI/PCI-X Bridge. Remove this exclusion so we can enable ASPM on these links. The Dell OptiPlex 7080 mentioned in the bugzilla has a TI XIO2001 PCIe-to-PCI Bridge. Enabling ASPM on the link leading to it allows the Intel SoC to enter deeper Package C-states, which is a significant power savings. [bhelgaas: commit log] Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207571 Link: https://lore.kernel.org/r/20200505173423.26968-1-kai.heng.feng@canonical.com Signed-off-by: Kai-Heng Feng Signed-off-by: Bjorn Helgaas Reviewed-by: Mika Westerberg Signed-off-by: Sasha Levin commit 742f8ac8edd4f810471378d239868130e1ce7109 Author: Andrew Murray Date: Fri Oct 4 14:29:41 2019 +0100 PCI: rcar: Fix incorrect programming of OB windows [ Upstream commit 2b9f217433e31d125fb697ca7974d3de3ecc3e92 ] The outbound windows (PCIEPAUR(x), PCIEPALR(x)) describe a mapping between a CPU address (which is determined by the window number 'x') and a programmed PCI address - Thus allowing the controller to translate CPU accesses into PCI accesses. However the existing code incorrectly writes the CPU address - lets fix this by writing the PCI address instead. For memory transactions, existing DT users describe a 1:1 identity mapping and thus this change should have no effect. However the same isn't true for I/O. Link: https://lore.kernel.org/r/20191004132941.6660-1-andrew.murray@arm.com Fixes: c25da4778803 ("PCI: rcar: Add Renesas R-Car PCIe driver") Tested-by: Marek Vasut Signed-off-by: Andrew Murray Signed-off-by: Lorenzo Pieralisi Reviewed-by: Marek Vasut Signed-off-by: Sasha Levin commit efb5f7b106ea75cd26d2257f224a1d0f3cf607d5 Author: Kuppuswamy Sathyanarayanan Date: Wed Apr 8 14:40:03 2020 -0700 drivers: base: Fix NULL pointer exception in __platform_driver_probe() if a driver developer is foolish [ Upstream commit 388bcc6ecc609fca1b4920de7dc3806c98ec535e ] If platform bus driver registration is failed then, accessing platform bus spin lock (&drv->driver.bus->p->klist_drivers.k_lock) in __platform_driver_probe() without verifying the return value __platform_driver_register() can lead to NULL pointer exception. So check the return value before attempting the spin lock. One such example is below: For a custom usecase, I have intentionally failed the platform bus registration and I expected all the platform device/driver registrations to fail gracefully. But I came across this panic issue. [ 1.331067] BUG: kernel NULL pointer dereference, address: 00000000000000c8 [ 1.331118] #PF: supervisor write access in kernel mode [ 1.331163] #PF: error_code(0x0002) - not-present page [ 1.331208] PGD 0 P4D 0 [ 1.331233] Oops: 0002 [#1] PREEMPT SMP [ 1.331268] CPU: 3 PID: 1 Comm: swapper/0 Tainted: G W 5.6.0-00049-g670d35fb0144 #165 [ 1.331341] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 [ 1.331406] RIP: 0010:_raw_spin_lock+0x15/0x30 [ 1.331588] RSP: 0000:ffffc9000001be70 EFLAGS: 00010246 [ 1.331632] RAX: 0000000000000000 RBX: 00000000000000c8 RCX: 0000000000000001 [ 1.331696] RDX: 0000000000000001 RSI: 0000000000000092 RDI: 0000000000000000 [ 1.331754] RBP: 00000000ffffffed R08: 0000000000000501 R09: 0000000000000001 [ 1.331817] R10: ffff88817abcc520 R11: 0000000000000670 R12: 00000000ffffffed [ 1.331881] R13: ffffffff82dbc268 R14: ffffffff832f070a R15: 0000000000000000 [ 1.331945] FS: 0000000000000000(0000) GS:ffff88817bd80000(0000) knlGS:0000000000000000 [ 1.332008] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.332062] CR2: 00000000000000c8 CR3: 000000000681e001 CR4: 00000000003606e0 [ 1.332126] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1.332189] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 1.332252] Call Trace: [ 1.332281] __platform_driver_probe+0x92/0xee [ 1.332323] ? rtc_dev_init+0x2b/0x2b [ 1.332358] cmos_init+0x37/0x67 [ 1.332396] do_one_initcall+0x7d/0x168 [ 1.332428] kernel_init_freeable+0x16c/0x1c9 [ 1.332473] ? rest_init+0xc0/0xc0 [ 1.332508] kernel_init+0x5/0x100 [ 1.332543] ret_from_fork+0x1f/0x30 [ 1.332579] CR2: 00000000000000c8 [ 1.332616] ---[ end trace 3bd87f12e9010b87 ]--- [ 1.333549] note: swapper/0[1] exited with preempt_count 1 [ 1.333592] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 [ 1.333736] Kernel Offset: disabled Note, this can only be triggered if a driver errors out from this call, which should never happen. If it does, the driver needs to be fixed. Signed-off-by: Kuppuswamy Sathyanarayanan Link: https://lore.kernel.org/r/20200408214003.3356-1-sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 33cf7944af54e0af80c69b7ce9298728013d507d Author: John Stultz Date: Tue Apr 28 18:40:50 2020 +0000 serial: amba-pl011: Make sure we initialize the port.lock spinlock [ Upstream commit 8508f4cba308f785b2fd4b8c38849c117b407297 ] Valentine reported seeing: [ 3.626638] INFO: trying to register non-static key. [ 3.626639] the code is fine but needs lockdep annotation. [ 3.626640] turning off the locking correctness validator. [ 3.626644] CPU: 7 PID: 51 Comm: kworker/7:1 Not tainted 5.7.0-rc2-00115-g8c2e9790f196 #116 [ 3.626646] Hardware name: HiKey960 (DT) [ 3.626656] Workqueue: events deferred_probe_work_func [ 3.632476] sd 0:0:0:0: [sda] Optimal transfer size 8192 bytes not a multiple of physical block size (16384 bytes) [ 3.640220] Call trace: [ 3.640225] dump_backtrace+0x0/0x1b8 [ 3.640227] show_stack+0x20/0x30 [ 3.640230] dump_stack+0xec/0x158 [ 3.640234] register_lock_class+0x598/0x5c0 [ 3.640235] __lock_acquire+0x80/0x16c0 [ 3.640236] lock_acquire+0xf4/0x4a0 [ 3.640241] _raw_spin_lock_irqsave+0x70/0xa8 [ 3.640245] uart_add_one_port+0x388/0x4b8 [ 3.640248] pl011_register_port+0x70/0xf0 [ 3.640250] pl011_probe+0x184/0x1b8 [ 3.640254] amba_probe+0xdc/0x180 [ 3.640256] really_probe+0xe0/0x338 [ 3.640257] driver_probe_device+0x60/0xf8 [ 3.640259] __device_attach_driver+0x8c/0xd0 [ 3.640260] bus_for_each_drv+0x84/0xd8 [ 3.640261] __device_attach+0xe4/0x140 [ 3.640263] device_initial_probe+0x1c/0x28 [ 3.640265] bus_probe_device+0xa4/0xb0 [ 3.640266] deferred_probe_work_func+0x7c/0xb8 [ 3.640269] process_one_work+0x2c0/0x768 [ 3.640271] worker_thread+0x4c/0x498 [ 3.640272] kthread+0x14c/0x158 [ 3.640275] ret_from_fork+0x10/0x1c Which seems to be due to the fact that after allocating the uap structure, nothing initializes the spinlock. Its a little confusing, as uart_port_spin_lock_init() is one place where the lock is supposed to be initialized, but it has an exception for the case where the port is a console. This makes it seem like a deeper fix is needed to properly register the console, but I'm not sure what that entails, and Andy suggested that this approach is less invasive. Thus, this patch resolves the issue by initializing the spinlock in the driver, and resolves the resulting warning. Cc: Andy Shevchenko Cc: Russell King Cc: Jiri Slaby Cc: linux-serial@vger.kernel.org Reported-by: Valentin Schneider Reviewed-by: Andy Shevchenko Signed-off-by: John Stultz Reviewed-and-tested-by: Valentin Schneider Link: https://lore.kernel.org/r/20200428184050.6501-1-john.stultz@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 32a5bc992b6cf44ec658eb589b0dbe39e15ed197 Author: Russell King Date: Mon Apr 27 19:49:22 2020 +0100 i2c: pxa: fix i2c_pxa_scream_blue_murder() debug output [ Upstream commit 88b73ee7ca4c90baf136ed5a8377fc5a9b73ac08 ] The IRQ log output is supposed to appear on a single line. However, commit 3a2dc1677b60 ("i2c: pxa: Update debug function to dump more info on error") resulted in it being printed one-entry-per-line, which is excessively long. Fixing this is not a trivial matter; using pr_cont() doesn't work as the previous dev_dbg() may not have been compiled in, or may be dynamic. Since the rest of this function output is at error level, and is also debug output, promote this to error level as well to avoid this problem. Reduce the number of always zero prefix digits to save screen real- estate. Signed-off-by: Russell King Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 9eb54d0e8962d2f5d7a430f3a245037c990e3b42 Author: Christophe JAILLET Date: Sat Apr 18 10:16:37 2020 +0200 PCI: v3-semi: Fix a memory leak in v3_pci_probe() error handling paths [ Upstream commit bca718988b9008d0d5f504e2d318178fc84958c1 ] If we fails somewhere in 'v3_pci_probe()', we need to free 'host'. Use the managed version of 'pci_alloc_host_bridge()' to do that easily. The use of managed resources is already widely used in this driver. Link: https://lore.kernel.org/r/20200418081637.1585-1-christophe.jaillet@wanadoo.fr Fixes: 68a15eb7bd0c ("PCI: v3-semi: Add V3 Semiconductor PCI host driver") Signed-off-by: Christophe JAILLET [lorenzo.pieralisi@arm.com: commit log] Signed-off-by: Lorenzo Pieralisi Acked-by: Linus Walleij Signed-off-by: Sasha Levin commit 4d30daf901aa7942f5e803023a4d3176a1e2f1bc Author: Matej Dujava Date: Thu Apr 30 22:09:24 2020 +0200 staging: sm750fb: add missing case while setting FB_VISUAL [ Upstream commit fa90133377f4a7f15a937df6ad55133bb57c5665 ] Switch statement does not contain all cases: 8, 16, 24, 32. This patch will add missing one (24) Fixes: 81dee67e215b ("staging: sm750fb: add sm750 to staging") Signed-off-by: Matej Dujava Link: https://lore.kernel.org/r/1588277366-19354-2-git-send-email-mdujava@kocurkovo.cz Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2428682e3f6cb6a5bb2855500669746639a0c98d Author: Oscar Carter Date: Mon May 4 17:09:11 2020 +0200 staging: wilc1000: Increase the size of wid_list array [ Upstream commit a4338ed2e1cf724563956ec5f91deeaabfedbe23 ] Increase by one the size of wid_list array as index variable can reach a value of 5. If this happens, an out-of-bounds access is performed. Also, use a #define instead of a hard-coded literal for the new array size. Addresses-Coverity-ID: 1451981 ("Out-of-bounds access") Fixes: f5a3cb90b802d ("staging: wilc1000: add passive scan support") Acked-by: Ajay Singh Signed-off-by: Oscar Carter Link: https://lore.kernel.org/r/20200504150911.4470-1-oscar.carter@gmx.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b14b7359535d84ed88d97c18df76589d01146882 Author: Thinh Nguyen Date: Sun Mar 29 16:12:57 2020 -0700 usb: dwc3: gadget: Properly handle failed kick_transfer [ Upstream commit 8d99087c2db863c5fa3a4a1f3cb82b3a493705ca ] If dwc3 fails to issue START_TRANSFER/UPDATE_TRANSFER command, then we should properly end an active transfer and give back all the started requests. However if it's for an isoc endpoint, the failure maybe due to bus-expiry status. In this case, don't give back the requests and wait for the next retry. Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver") Signed-off-by: Thinh Nguyen Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 1bfa0914728229f332478a0ba9f60a92f0dca046 Author: Thinh Nguyen Date: Thu Mar 5 13:23:55 2020 -0800 usb: dwc3: gadget: Properly handle ClearFeature(halt) [ Upstream commit cb11ea56f37a36288cdd0a4799a983ee3aa437dd ] DWC3 must not issue CLEAR_STALL command to control endpoints. The controller automatically clears the STALL when it receives the SETUP token. Also, when the driver receives ClearFeature(halt_ep), DWC3 must stop any active transfer from the endpoint and give back all the requests to the function drivers. Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver") Signed-off-by: Thinh Nguyen Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit e320bb0e01dbd11913ed96192ecb847f12e201be Author: Arnd Bergmann Date: Tue Apr 28 23:53:29 2020 +0200 HID: intel-ish-hid: avoid bogus uninitialized-variable warning [ Upstream commit 0b66fb3e6b7a53688f8e20945ac78cd3d832c65f ] Older compilers like gcc-4.8 don't see that the variable is initialized when it is used: In file included from include/linux/compiler_types.h:68:0, from :0: drivers/hid/intel-ish-hid/ishtp-fw-loader.c: In function 'load_fw_from_host': include/linux/compiler-gcc.h:75:45: warning: 'fw_info.ldr_capability.max_dma_buf_size' may be used uninitialized in this function [-Wmaybe-uninitialized] #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__) ^ drivers/hid/intel-ish-hid/ishtp-fw-loader.c:770:22: note: 'fw_info.ldr_capability.max_dma_buf_size' was declared here struct shim_fw_info fw_info; ^ Make sure to initialize it before returning an error from ish_query_loader_prop(). Fixes: 91b228107da3 ("HID: intel-ish-hid: ISH firmware loader client driver") Signed-off-by: Arnd Bergmann Acked-by: Srinivas Pandruvada Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit cbec16266a354db4d1c80d7f46883b73bb335c26 Author: Pierre-Louis Bossart Date: Mon Apr 20 02:51:15 2020 +0800 soundwire: slave: don't init debugfs on device registration error [ Upstream commit 8893ab5e8ee5d7c12e0fc1dca4a309475064473d ] The error handling flow seems incorrect, there is no reason to try and add debugfs support if the device registration did not succeed. Return on error. Signed-off-by: Pierre-Louis Bossart Signed-off-by: Bard Liao Reviewed-by: Ranjani Sridharan Reviewed-by: Guennadi Liakhovetski Link: https://lore.kernel.org/r/20200419185117.4233-2-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit a45fc52449d7a0686f31c079dc5f412b11d0f187 Author: Yong Zhi Date: Fri May 1 18:44:21 2020 -0500 ASoC: max98373: reorder max98373_reset() in resume [ Upstream commit 1a446873d7dd3a450f685928ce7f1907bde4583d ] During S3 test, the following error was observed: [ 726.174237] i2c_designware i2c_designware.0: platform_pm_resume+0x0/0x3d returned 0 after 0 usecs [ 726.184187] max98373 i2c-MX98373:00: calling max98373_resume+0x0/0x30 [snd_soc_max98373] @ 12698, parent: i2c-11 [ 726.195589] max98373 i2c-MX98373:00: Reset command failed. (ret:-16) When calling regmap_update_bits(), since map->reg_update_bits is NULL, _regmap_read() is entered with the following logic: if (!map->cache_bypass) { ret = regcache_read(map, reg, val); if (ret == 0) return 0; } if (map->cache_only) return -EBUSY; regcache_read() hits -EINVAL because MAX98373_R2000_SW_RESET is volatile, as map->cache_only is set by codec suspend, thus -EBUSY is returned. Fix by moving max98373_reset() after cache_only set to false in max98373_resume(). Signed-off-by: Yong Zhi Link: https://lore.kernel.org/r/1588376661-29799-1-git-send-email-yong.zhi@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7377ba16b54240cb68e15dc8441ff4aabc888810 Author: Martin Blumenstingl Date: Fri May 1 23:57:17 2020 +0200 clk: meson: meson8b: Don't rely on u-boot to init all GP_PLL registers [ Upstream commit a29ae8600d50ece1856b062a39ed296b8b952259 ] Not all u-boot versions initialize the HHI_GP_PLL_CNTL[2-5] registers. In that case all HHI_GPLL_PLL_CNTL[1-5] registers are 0x0 and when booting Linux the PLL fails to lock. The initialization sequence from u-boot is: - put the PLL into reset - write 0x59C88000 to HHI_GP_PLL_CNTL2 - write 0xCA463823 to HHI_GP_PLL_CNTL3 - write 0x0286A027 to HHI_GP_PLL_CNTL4 - write 0x00003000 to HHI_GP_PLL_CNTL5 - set M, N, OD and the enable bit - take the PLL out of reset - check if it has locked - disable the PLL In Linux we already initialize M, N, OD, the enable and the reset bits. Also the HHI_GP_PLL_CNTL[2-5] registers with these magic values (the exact meaning is unknown) so the PLL can lock when the vendor u-boot did not initialize these registers yet. Fixes: b882964b376f21 ("clk: meson: meson8b: add support for the GP_PLL clock on Meson8m2") Signed-off-by: Martin Blumenstingl Signed-off-by: Jerome Brunet Link: https://lore.kernel.org/r/20200501215717.735393-1-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin commit ea78361174c4746e8df8e6fdc0ec1dc710a6869d Author: Sudip Mukherjee Date: Fri Apr 24 17:19:44 2020 +0100 thermal/drivers/ti-soc-thermal: Avoid dereferencing ERR_PTR [ Upstream commit 7440f518dad9d861d76c64956641eeddd3586f75 ] On error the function ti_bandgap_get_sensor_data() returns the error code in ERR_PTR() but we only checked if the return value is NULL or not. And, so we can dereference an error code inside ERR_PTR. While at it, convert a check to IS_ERR_OR_NULL. Signed-off-by: Sudip Mukherjee Reviewed-by: Amit Kucheria Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20200424161944.6044-1-sudipm.mukherjee@gmail.com Signed-off-by: Sasha Levin commit 3296e566b0d26d47f19163e238ea85f20c2dbd90 Author: Uwe Kleine-König Date: Mon Apr 20 20:27:51 2020 +0300 gpio: pca953x: fix handling of automatic address incrementing [ Upstream commit bcf41dc480b179bfb669a232080a2e26dc7294b4 ] Some of the chips supported by the pca953x driver need the most significant bit in the address word set to automatically increment the address pointer on subsequent reads and writes (example: PCA9505). With this bit unset the same register is read multiple times on a multi-byte read sequence. Other chips must not have this bit set and autoincrement always (example: PCA9555). Up to now this AI bit was interpreted to be part of the address, which resulted in inconsistent regmap caching when a register was written with AI set and then read without it. This happened for the PCA9505 in pca953x_gpio_set_multiple() where pca953x_read_regs() bulk read from the cache for registers 0x8-0xc and then wrote to registers 0x88-0x8c. (Side note: reading 5 values from offset 0x8 yiels OP0 5 times because AI must be set to get OP0-OP4, which is another bug that is resolved here as a by-product.) The same problem happens when calls to gpio_set_value() and gpio_set_array_value() were mixed. With this patch the AI bit is always set for chips that support it. This works as there are no code locations that make use of the behaviour with AI unset (for the chips that support it). Note that the call to pca953x_setup_gpio() had to be done a bit earlier to make the NBANK macro work. The history of this bug is a bit complicated. Commit b32cecb46bdc ("gpio: pca953x: Extract the register address mangling to single function") changed which chips and functions are affected. Commit 3b00691cc46a ("gpio: pca953x: hack to fix 24 bit gpio expanders") used some duct tape to make the driver at least appear to work. Commit 49427232764d ("gpio: pca953x: Perform basic regmap conversion") introduced the caching. Commit b4818afeacbd ("gpio: pca953x: Add set_multiple to allow multiple bits to be set in one write.") introduced the .set_multiple() callback which didn't work for chips that need the AI bit which was fixed later for some chips in 8958262af3fb ("gpio: pca953x: Repair multi-byte IO address increment on PCA9575"). So I'm sorry, I don't know which commit I should pick for a Fixes: line. Tested-by: Marcel Gudert Signed-off-by: Uwe Kleine-König Tested-by: Andy Shevchenko Reviewed-by: Andy Shevchenko Signed-off-by: Andy Shevchenko Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit dd47c98992d6b534d82c631094f2747dc5f3ffd5 Author: Martin Blumenstingl Date: Fri Apr 17 20:41:26 2020 +0200 clk: meson: meson8b: Fix the vclk_div{1, 2, 4, 6, 12}_en gate bits [ Upstream commit 8bb629cfb28f4dad9d47f69249366e50ae5edc25 ] The DIV{1,2,4,6,12}_EN bits are actually located in HHI_VID_CLK_CNTL register: - HHI_VID_CLK_CNTL[0] = DIV1_EN - HHI_VID_CLK_CNTL[1] = DIV2_EN - HHI_VID_CLK_CNTL[2] = DIV4_EN - HHI_VID_CLK_CNTL[3] = DIV6_EN - HHI_VID_CLK_CNTL[4] = DIV12_EN Update the bits accordingly so we will enable the bits in the correct register once we switch these clocks to be mutable. Fixes: 6cb57c678bb70e ("clk: meson: meson8b: add the read-only video clock trees") Signed-off-by: Martin Blumenstingl Signed-off-by: Jerome Brunet Link: https://lore.kernel.org/r/20200417184127.1319871-4-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin commit ecb9a8068ba525ca7cf9fe168067f701663cd599 Author: Martin Blumenstingl Date: Fri Apr 17 20:41:25 2020 +0200 clk: meson: meson8b: Fix the polarity of the RESET_N lines [ Upstream commit 0d3051c790ed2ef6bd91b92b07220313f06b95b3 ] CLKC_RESET_VID_DIVIDER_CNTL_RESET_N_POST and CLKC_RESET_VID_DIVIDER_CNTL_RESET_N_PRE are active low. This means: - asserting them requires setting the register value to 0 - de-asserting them requires setting the register value to 1 Set the register value accordingly for these two reset lines by setting the inverted the register value compared to all other reset lines. Fixes: 189621726bc2f6 ("clk: meson: meson8b: register the built-in reset controller") Signed-off-by: Martin Blumenstingl Signed-off-by: Jerome Brunet Link: https://lore.kernel.org/r/20200417184127.1319871-3-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin commit 1fa1d1ceb02f2a19c61178fbaaaee9ef070c0a43 Author: Martin Blumenstingl Date: Fri Apr 17 20:41:24 2020 +0200 clk: meson: meson8b: Fix the first parent of vid_pll_in_sel [ Upstream commit da1978ac3d6cf278dedf5edbf350445a0fff2f08 ] Use hdmi_pll_lvds_out as parent of the vid_pll_in_sel clock. It's not easy to see that the vendor kernel does the same, but it actually does. meson_clk_pll_ops in mainline still cannot fully recalculate all rates from the HDMI PLL registers because some register bits (at the time of writing it's unknown which bits are used for this) double the HDMI PLL output rate (compared to simply considering M, N and FRAC) for some (but not all) PLL settings. Update the vid_pll_in_sel parent so our clock calculation works for simple clock settings like the CVBS output (where no rate doubling is going on). The PLL ops need to be fixed later on for more complex clock settings (all HDMI rates). Fixes: 6cb57c678bb70 ("clk: meson: meson8b: add the read-only video clock trees") Suggested-by: Neil Armstrong Signed-off-by: Martin Blumenstingl Signed-off-by: Jerome Brunet Link: https://lore.kernel.org/r/20200417184127.1319871-2-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin commit 9a624802e628d8860983d663ab3a9ae9baa067c3 Author: Srinivas Kandagatla Date: Fri Apr 17 10:36:18 2020 +0100 slimbus: ngd: get drvdata from correct device [ Upstream commit b58c663059b484f7ff547d076a34cf6d7a302e56 ] Get drvdata directly from parent instead of ngd dev, as ngd dev can probe defer and previously set drvdata will become null. Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20200417093618.7929-1-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 793e15fb6681d11f41293b9df251cfda752be6c7 Author: Raghavendra Rao Ananta Date: Mon Apr 27 20:26:01 2020 -0700 tty: hvc: Fix data abort due to race in hvc_open [ Upstream commit e2bd1dcbe1aa34ff5570b3427c530e4332ecf0fe ] Potentially, hvc_open() can be called in parallel when two tasks calls open() on /dev/hvcX. In such a scenario, if the hp->ops->notifier_add() callback in the function fails, where it sets the tty->driver_data to NULL, the parallel hvc_open() can see this NULL and cause a memory abort. Hence, serialize hvc_open and check if tty->private_data is NULL before proceeding ahead. The issue can be easily reproduced by launching two tasks simultaneously that does nothing but open() and close() on /dev/hvcX. For example: $ ./simple_open_close /dev/hvc0 & ./simple_open_close /dev/hvc0 & Signed-off-by: Raghavendra Rao Ananta Link: https://lore.kernel.org/r/20200428032601.22127-1-rananta@codeaurora.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit eb3e85b3375d9cab91a251044c57e8d8a3ccf74b Author: Julian Wiedmann Date: Thu Apr 9 09:59:39 2020 +0200 s390/qdio: put thinint indicator after early error [ Upstream commit 75e82bec6b2622c6f455b7a543fb5476a5d0eed7 ] qdio_establish() calls qdio_setup_thinint() via qdio_setup_irq(). If the subsequent qdio_establish_thinint() fails, we miss to put the DSCI again. Thus the DSCI isn't available for re-use. Given enough of such errors, we could end up with having only the shared DSCI available. Merge qdio_setup_thinint() into qdio_establish_thinint(), and deal with such an error internally. Fixes: 779e6e1c724d ("[S390] qdio: new qdio driver.") Signed-off-by: Julian Wiedmann Reviewed-by: Benjamin Block Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit d7852661f9fd3c448d05a079ca303a9f151f463d Author: Takashi Iwai Date: Fri Apr 24 09:40:16 2020 +0200 ALSA: usb-audio: Fix racy list management in output queue [ Upstream commit 5b6cc38f3f3f37109ce72b60bda215a5f6892c0b ] The linked list entry from FIFO is peeked at queue_pending_output_urbs() but the actual element pop-out is performed outside the spinlock, and it's potentially racy. Do delete the link at the right place inside the spinlock. Fixes: 8fdff6a319e7 ("ALSA: snd-usb: implement new endpoint streaming model") Link: https://lore.kernel.org/r/20200424074016.14301-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit aba41867dd66939d336fdf604e4d73b805d8039f Author: Alexander Tsoy Date: Fri Apr 24 05:24:48 2020 +0300 ALSA: usb-audio: Improve frames size computation [ Upstream commit f0bd62b64016508938df9babe47f65c2c727d25c ] For computation of the the next frame size current value of fs/fps and accumulated fractional parts of fs/fps are used, where values are stored in Q16.16 format. This is quite natural for computing frame size for asynchronous endpoints driven by explicit feedback, since in this case fs/fps is a value provided by the feedback endpoint and it's already in the Q format. If an error is accumulated over time, the device can adjust fs/fps value to prevent buffer overruns/underruns. But for synchronous endpoints the accuracy provided by these computations is not enough. Due to accumulated error the driver periodically produces frames with incorrect size (+/- 1 audio sample). This patch fixes this issue by implementing a different algorithm for frame size computation. It is based on accumulating of the remainders from division fs/fps and it doesn't accumulate errors over time. This new method is enabled for synchronous and adaptive playback endpoints. Signed-off-by: Alexander Tsoy Link: https://lore.kernel.org/r/20200424022449.14972-1-alexander@tsoy.me Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 3468bca1ea441680aeba27e38b4360d2bf9a1706 Author: Xiyu Yang Date: Thu Apr 23 13:15:40 2020 +0800 staging: gasket: Fix mapping refcnt leak when register/store fails [ Upstream commit e3436ce60cf5f5eaedda2b8c622f69feb97595e2 ] gasket_sysfs_register_store() invokes get_mapping(), which returns a reference of the specified gasket_sysfs_mapping object to "mapping" with increased refcnt. When gasket_sysfs_register_store() returns, local variable "mapping" becomes invalid, so the refcount should be decreased to keep refcount balanced. The reference counting issue happens in one exception handling path of gasket_sysfs_register_store(). When gasket_dev is NULL, the function forgets to decrease the refcnt increased by get_mapping(), causing a refcnt leak. Fix this issue by calling put_mapping() when gasket_dev is NULL. Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Link: https://lore.kernel.org/r/1587618941-13718-1-git-send-email-xiyuyang19@fudan.edu.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b3b4dcdc2bb49047762fcc14db0b1967622b5188 Author: Xiyu Yang Date: Thu Apr 23 13:14:55 2020 +0800 staging: gasket: Fix mapping refcnt leak when put attribute fails [ Upstream commit 57a66838e1494cd881b7f4e110ec685736e8e3ca ] gasket_sysfs_put_attr() invokes get_mapping(), which returns a reference of the specified gasket_sysfs_mapping object to "mapping" with increased refcnt. When gasket_sysfs_put_attr() returns, local variable "mapping" becomes invalid, so the refcount should be decreased to keep refcount balanced. The reference counting issue happens in one path of gasket_sysfs_put_attr(). When mapping attribute is unknown, the function forgets to decrease the refcnt increased by get_mapping(), causing a refcnt leak. Fix this issue by calling put_mapping() when put attribute fails due to unknown attribute. Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Link: https://lore.kernel.org/r/1587618895-13660-1-git-send-email-xiyuyang19@fudan.edu.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0c884f3236f3b04d8fca163e0b2dcde13a5faa34 Author: Christoph Hellwig Date: Tue Apr 14 14:31:36 2020 +0200 firmware: qcom_scm: fix bogous abuse of dma-direct internals [ Upstream commit 459b1f86f1cba7de813fbc335df476c111feec22 ] As far as the device is concerned the dma address is the physical address. There is no need to convert it to a physical address, especially not using dma-direct internals that are not available to drivers and which will interact badly with IOMMUs. Last but not least the commit introducing it claimed to just fix a type issue, but actually changed behavior. Fixes: 6e37ccf78a532 ("firmware: qcom_scm: Use proper types for dma mappings") Reviewed-by: Bjorn Andersson Signed-off-by: Christoph Hellwig Link: https://lore.kernel.org/r/20200414123136.441454-1-hch@lst.de Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 0c48b6df64c0e4070bf82c678f1dbc1259a3187a Author: Jonathan Marek Date: Mon Apr 20 11:35:43 2020 -0400 arm64: dts: qcom: fix pm8150 gpio interrupts [ Upstream commit 61d2ca503d0b55d2849fd656ce51d8e1e9ba0b6c ] This was mistakenly copied from the downstream dts, however the upstream driver works differently. I only tested this with the pm8150_gpios node (used with volume button), but the 2 others should be the same. Fixes: e92b61c8e775 ("arm64: dts: qcom: pm8150l: Add base dts file") Fixes: 229d5bcad0d0 ("arm64: dts: qcom: pm8150b: Add base dts file") Fixes: 5101f22a5c37 ("arm64: dts: qcom: pm8150: Add base dts file") Reviewed-by: Bjorn Andersson Signed-off-by: Jonathan Marek Link: https://lore.kernel.org/r/20200420153543.14512-1-jonathan@marek.ca Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 2b5e027657d4362b3232b7b269c951cc8c2a7b38 Author: Vivek Goyal Date: Mon Apr 20 17:01:34 2020 +0200 virtiofs: schedule blocking async replies in separate worker [ Upstream commit bb737bbe48bea9854455cb61ea1dc06e92ce586c ] In virtiofs (unlike in regular fuse) processing of async replies is serialized. This can result in a deadlock in rare corner cases when there's a circular dependency between the completion of two or more async replies. Such a deadlock can be reproduced with xfstests:generic/503 if TEST_DIR == SCRATCH_MNT (which is a misconfiguration): - Process A is waiting for page lock in worker thread context and blocked (virtio_fs_requests_done_work()). - Process B is holding page lock and waiting for pending writes to finish (fuse_wait_on_page_writeback()). - Write requests are waiting in virtqueue and can't complete because worker thread is blocked on page lock (process A). Fix this by creating a unique work_struct for each async reply that can block (O_DIRECT read). Fixes: a62a8ef9d97d ("virtio-fs: add virtiofs filesystem") Signed-off-by: Vivek Goyal Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit ff86bd6cca2e9bc42fc8eb3a6dbe08f6a30fcf97 Author: Jason Yan Date: Fri Apr 17 19:16:04 2020 +0800 pinctrl: rza1: Fix wrong array assignment of rza1l_swio_entries [ Upstream commit 4b4e8e93eccc2abc4209fe226ec89e7fbe9f3c61 ] The rza1l_swio_entries referred to the wrong array rza1h_swio_pins, which was intended to be rza1l_swio_pins. So let's fix it. This is detected by the following gcc warning: drivers/pinctrl/pinctrl-rza1.c:401:35: warning: ‘rza1l_swio_pins’ defined but not used [-Wunused-const-variable=] static const struct rza1_swio_pin rza1l_swio_pins[] = { ^~~~~~~~~~~~~~~ Fixes: 039bc58e73b77723 ("pinctrl: rza1: Add support for RZ/A1L") Reported-by: Hulk Robot Signed-off-by: Jason Yan Link: https://lore.kernel.org/r/20200417111604.19143-1-yanaijie@huawei.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit cd3f4ed1c567dc8b162751d9fed16dc1875d6e0c Author: Chad Dupuis Date: Thu Apr 16 01:43:13 2020 -0700 scsi: qedf: Fix crash when MFW calls for protocol stats while function is still probing [ Upstream commit ad40f5256095c68dc17c991eb976261d5ea2daaa ] The MFW may make a call to qed and then to qedf for protocol statistics while the function is still probing. If this happens it's possible that some members of the struct qedf_ctx may not be fully initialized which can result in a NULL pointer dereference or general protection fault. To prevent this, add a new flag call QEDF_PROBING and set it when the __qedf_probe() function is active. Then in the qedf_get_protocol_tlv_data() function we can check if the function is still probing and return immediantely before any uninitialized structures can be touched. Link: https://lore.kernel.org/r/20200416084314.18851-9-skashyap@marvell.com Signed-off-by: Chad Dupuis Signed-off-by: Saurav Kashyap Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a0a00156d50ed08f6a4f60280e45ce0fd1aaef11 Author: Andy Shevchenko Date: Wed Apr 15 17:15:21 2020 +0300 gpio: dwapb: Append MODULE_ALIAS for platform driver [ Upstream commit c58220cba2e03618659fa7d5dfae31f5ad4ae9d0 ] The commit 3d2613c4289f ("GPIO: gpio-dwapb: Enable platform driver binding to MFD driver") introduced a use of the platform driver but missed to add the following line to it: MODULE_ALIAS("platform:gpio-dwapb"); Add this to get driver loaded automatically if platform device is registered. Fixes: 3d2613c4289f ("GPIO: gpio-dwapb: Enable platform driver binding to MFD driver") Signed-off-by: Andy Shevchenko Tested-by: Serge Semin Reviewed-by: Serge Semin Link: https://lore.kernel.org/r/20200415141534.31240-2-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 02416142fdf4b37fed04aa74ac42b9527045fecf Author: Yishai Hadas Date: Mon Apr 6 20:35:40 2020 +0300 RDMA/mlx5: Fix udata response upon SRQ creation [ Upstream commit cf26deff9036cd3270af562dbec545239e5c7f07 ] Fix udata response upon SRQ creation to use the UAPI structure (i.e. mlx5_ib_create_srq_resp). It did not zero the reserved field in userspace. Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Link: https://lore.kernel.org/r/20200406173540.1466477-1-leon@kernel.org Signed-off-by: Yishai Hadas Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 7acbadd1aa294b422657f90d3349f20c06dae541 Author: Vincent Stehlé Date: Sat Apr 11 19:48:43 2020 +0200 ARM: dts: sun8i-h2-plus-bananapi-m2-zero: Fix led polarity [ Upstream commit 34b6826df7462c541752cf8b1de2691b26d78ae0 ] The PWR-LED on the bananapi m2 zero board is on when gpio PL10 is low. This has been verified on a board and in the schematics [1]. [1]: http://wiki.banana-pi.org/Banana_Pi_BPI-M2_ZERO#Documents Fixes: 8b8061fcbfae ("ARM: dts: sun8i: h2+: add support for Banana Pi M2 Zero board") Signed-off-by: Vincent Stehlé Cc: Icenowy Zheng Cc: Maxime Ripard Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit ef0c0fbf1d4a0ec85ec293dafdc0f97eba4ec5fc Author: Amit Kucheria Date: Mon Mar 30 15:36:26 2020 +0530 arm64: dts: qcom: msm8916: remove unit name for thermal trip points [ Upstream commit fe2aff0c574d206f34f1864d5a0b093694c27142 ] The thermal trip points have unit name but no reg property, so we can remove them. It also fixes the following warnings from 'make dtbs_check' after adding the thermal yaml bindings. arch/arm64/boot/dts/qcom/apq8016-sbc.dt.yaml: thermal-zones: gpu-thermal:trips: 'trip-point@0' does not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\\-_]{0,63}$', 'pinctrl-[0-9]+' arch/arm64/boot/dts/qcom/apq8016-sbc.dt.yaml: thermal-zones: camera-thermal:trips: 'trip-point@0' does not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\\-_]{0,63}$', 'pinctrl-[0-9]+' arch/arm64/boot/dts/qcom/apq8016-sbc.dt.yaml: thermal-zones: modem-thermal:trips: 'trip-point@0' does not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\\-_]{0,63}$', 'pinctrl-[0-9]+' arch/arm64/boot/dts/qcom/msm8916-mtp.dt.yaml: thermal-zones: gpu-thermal:trips: 'trip-point@0' does not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\\-_]{0,63}$', 'pinctrl-[0-9]+' arch/arm64/boot/dts/qcom/msm8916-mtp.dt.yaml: thermal-zones: camera-thermal:trips: 'trip-point@0' does not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\\-_]{0,63}$', 'pinctrl-[0-9]+' arch/arm64/boot/dts/qcom/msm8916-mtp.dt.yaml: thermal-zones: modem-thermal:trips: 'trip-point@0' does not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\\-_]{0,63}$', 'pinctrl-[0-9]+' Signed-off-by: Amit Kucheria Link: https://lore.kernel.org/r/2d3d045c18a2fb85b28cf304aa11ae6e6538d75e.1585562459.git.amit.kucheria@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit f37623862ec5580928f3569e5cc0d11d5b015642 Author: Nilesh Javali Date: Tue Apr 7 23:43:30 2020 -0700 scsi: qedi: Do not flush offload work if ARP not resolved [ Upstream commit 927527aea0e2a9c1d336c7d33f77f1911481d008 ] For an unreachable target, offload_work is not initialized and the endpoint state is set to OFLDCONN_NONE. This results in a WARN_ON due to the check of the work function field being set to zero. ------------[ cut here ]------------ WARNING: CPU: 24 PID: 18587 at ../kernel/workqueue.c:3037 __flush_work+0x1c1/0x1d0 : Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 02/01/2020 RIP: 0010:__flush_work+0x1c1/0x1d0 Code: ba 6d 00 03 80 c9 f0 eb b6 48 c7 c7 20 ee 6c a4 e8 52 d3 04 00 0f 0b 31 c0 e9 d1 fe ff ff 48 c7 c7 20 ee 6c a4 e8 3d d3 04 00 <0f> 0b 31 c0 e9 bc fe ff ff e8 11 f3 f 00 31 f6 RSP: 0018:ffffac5a8cd47a80 EFLAGS: 00010282 RAX: 0000000000000024 RBX: ffff98d68c1fcaf0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff98ce9fd99898 RDI: ffff98ce9fd99898 RBP: ffff98d68c1fcbc0 R08: 00000000000006fa R09: 0000000000000001 R10: ffffac5a8cd47b50 R11: 0000000000000001 R12: 0000000000000000 R13: 000000000000489b R14: ffff98d68c1fc800 R15: ffff98d692132c00 FS: 00007f65f7f62280(0000) GS:ffff98ce9fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffd2435e880 CR3: 0000000809334003 CR4: 00000000007606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? class_create_release+0x40/0x40 ? klist_put+0x2c/0x80 qedi_ep_disconnect+0xdd/0x400 [qedi] iscsi_if_ep_disconnect.isra.20+0x59/0x70 [scsi_transport_iscsi] iscsi_if_rx+0x129b/0x1670 [scsi_transport_iscsi] ? __netlink_lookup+0xe7/0x160 netlink_unicast+0x21d/0x300 netlink_sendmsg+0x30f/0x430 sock_sendmsg+0x5b/0x60 ____sys_sendmsg+0x1e2/0x240 ? copy_msghdr_from_user+0xd9/0x160 ___sys_sendmsg+0x88/0xd0 ? ___sys_recvmsg+0xa2/0xe0 ? hrtimer_try_to_cancel+0x25/0x100 ? do_nanosleep+0x9c/0x170 ? __sys_sendmsg+0x5e/0xa0 __sys_sendmsg+0x5e/0xa0 do_syscall_64+0x60/0x1f0 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7f65f6f16107 Code: 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 80 00 00 00 00 8b 05 aa d2 2b 00 48 63 d2 48 63 ff 85 c0 75 18 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 59 f3 c3 0f 1f 8 0 00 00 00 00 53 48 89 f3 48 RSP: 002b:00007ffd24367ca8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000055a7aeaaf110 RCX: 00007f65f6f16107 RDX: 0000000000000000 RSI: 00007ffd24367cc0 RDI: 0000000000000003 RBP: 0000000000000070 R08: 0000000000000000 R09: 0000000000000000 R10: 000000000000075c R11: 0000000000000246 R12: 00007ffd24367cc0 R13: 000055a7ae560008 R14: 00007ffd24367db0 R15: 0000000000000000 ---[ end trace 54f499c05d41f8bb ]--- Only flush if the connection endpoint state if different from OFLDCONN_NONE. [mkp: clarified commit desc] Link: https://lore.kernel.org/r/20200408064332.19377-5-mrangankar@marvell.com Reviewed-by: Lee Duncan Signed-off-by: Nilesh Javali Signed-off-by: Manish Rangankar Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 0e5d7bff3b067a561602af916bf18d342c6c81c8 Author: Hsin-Yi Wang Date: Mon Feb 10 14:35:22 2020 +0800 arm64: dts: mt8173: fix unit name warnings [ Upstream commit 72b29215aced394d01ca25e432963b619daa0098 ] Fixing several unit name warnings: Warning (unit_address_vs_reg): /oscillator@0: node has a unit name, but no reg property Warning (unit_address_vs_reg): /oscillator@1: node has a unit name, but no reg property Warning (unit_address_vs_reg): /oscillator@2: node has a unit name, but no reg property Warning (unit_address_vs_reg): /thermal-zones/cpu_thermal/trips/trip-point@0: node has a unit name, but no reg property Warning (unit_address_vs_reg): /thermal-zones/cpu_thermal/trips/trip-point@1: node has a unit name, but no reg property Warning (unit_address_vs_reg): /thermal-zones/cpu_thermal/trips/cpu_crit@0: node has a unit name, but no reg property Warning (unit_address_vs_reg): /thermal-zones/cpu_thermal/cooling-maps/map@0: node has a unit name, but no reg property Warning (unit_address_vs_reg): /thermal-zones/cpu_thermal/cooling-maps/map@1: node has a unit name, but no reg property Warning (unit_address_vs_reg): /reserved-memory/vpu_dma_mem_region: node has a reg or ranges property, but no unit name Warning (simple_bus_reg): /soc/pinctrl@10005000: simple-bus unit address format error, expected "1000b000" Warning (simple_bus_reg): /soc/interrupt-controller@10220000: simple-bus unit address format error, expected "10221000" Signed-off-by: Hsin-Yi Wang Link: https://lore.kernel.org/r/20200210063523.133333-4-hsinyi@chromium.org [mb: drop fixes for '_' in property name] Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit 7bf3a213f79ec013aa8e9f7e1b99fe7d7891bc05 Author: Chen Zhou Date: Wed Apr 1 11:00:17 2020 +0800 staging: greybus: fix a missing-check bug in gb_lights_light_config() [ Upstream commit 9bb086e5ba9495ac150fbbcc5c8c2bccc06261dd ] In gb_lights_light_config(), 'light->name' is allocated by kstrndup(). It returns NULL when fails, add check for it. Signed-off-by: Chen Zhou Acked-by: Rui Miguel Silva Link: https://lore.kernel.org/r/20200401030017.100274-1-chenzhou10@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c970dcc085b89ca93a9b934a90091f904e5f404b Author: Hans de Goede Date: Tue Mar 17 14:08:40 2020 +0100 x86/purgatory: Disable various profiling and sanitizing options [ Upstream commit e2ac07c06058ae2d58b45bbf2a2a352771d76fcb ] Since the purgatory is a special stand-alone binary, various profiling and sanitizing options must be disabled. Having these options enabled typically will cause dependencies on various special symbols exported by special libs / stubs used by these frameworks. Since the purgatory is special, it is not linked against these stubs causing missing symbols in the purgatory if these options are not disabled. Sync the set of disabled profiling and sanitizing options with that from drivers/firmware/efi/libstub/Makefile, adding -DDISABLE_BRANCH_PROFILING to the CFLAGS and setting: GCOV_PROFILE := n UBSAN_SANITIZE := n This fixes broken references to ftrace_likely_update() when CONFIG_TRACE_BRANCH_PROFILING is enabled and to __gcov_init() and __gcov_exit() when CONFIG_GCOV_KERNEL is enabled. Signed-off-by: Hans de Goede Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20200317130841.290418-1-hdegoede@redhat.com Signed-off-by: Sasha Levin commit a78c65cb4b67bd77f8aa455fe63ab72ea73eba3b Author: John Johansen Date: Wed Sep 25 08:02:48 2019 -0700 apparmor: fix nnp subset test for unconfined [ Upstream commit 3ed4aaa94fc07db3cd0c91be95e3e1b9782a2710 ] The subset test is not taking into account the unconfined exception which will cause profile transitions in the stacked confinement case to fail when no_new_privs is applied. This fixes a regression introduced in the fix for https://bugs.launchpad.net/bugs/1839037 BugLink: https://bugs.launchpad.net/bugs/1844186 Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit af1f72ad18bb4a5fedcd28c6b6adaedb34bae9fc Author: Tyrel Datwyler Date: Wed Jun 3 15:36:32 2020 -0500 scsi: ibmvscsi: Don't send host info in adapter info MAD after LPM [ Upstream commit 4919b33b63c8b69d8dcf2b867431d0e3b6dc6d28 ] The adapter info MAD is used to send the client info and receive the host info as a response. A persistent buffer is used and as such the client info is overwritten after the response. During the course of a normal adapter reset the client info is refreshed in the buffer in preparation for sending the adapter info MAD. However, in the special case of LPM where we reenable the CRQ instead of a full CRQ teardown and reset we fail to refresh the client info in the adapter info buffer. As a result, after Live Partition Migration (LPM) we erroneously report the host's info as our own. [mkp: typos] Link: https://lore.kernel.org/r/20200603203632.18426-1-tyreld@linux.ibm.com Signed-off-by: Tyrel Datwyler Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 08d2ea2e236a6765d447af6baf0bc8fac3221b7f Author: Simon Arlott Date: Sat May 30 18:59:44 2020 +0100 scsi: sr: Fix sr_probe() missing deallocate of device minor [ Upstream commit 6555781b3fdec5e94e6914511496144241df7dee ] If the cdrom fails to be registered then the device minor should be deallocated. Link: https://lore.kernel.org/r/072dac4b-8402-4de8-36bd-47e7588969cd@0882a8b5-c6c3-11e9-b005-00805fc181fe Signed-off-by: Simon Arlott Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 8f73ac0b64341c62f7707ac825b1728d8f75ddf6 Author: Jakub Sitnicki Date: Sun Jun 7 22:52:28 2020 +0200 bpf, sockhash: Fix memory leak when unlinking sockets in sock_hash_free [ Upstream commit 33a7c831565c43a7ee2f38c7df4c4a40e1dfdfed ] When sockhash gets destroyed while sockets are still linked to it, we will walk the bucket lists and delete the links. However, we are not freeing the list elements after processing them, leaking the memory. The leak can be triggered by close()'ing a sockhash map when it still contains sockets, and observed with kmemleak: unreferenced object 0xffff888116e86f00 (size 64): comm "race_sock_unlin", pid 223, jiffies 4294731063 (age 217.404s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 81 de e8 41 00 00 00 00 c0 69 2f 15 81 88 ff ff ...A.....i/..... backtrace: [<00000000dd089ebb>] sock_hash_update_common+0x4ca/0x760 [<00000000b8219bd5>] sock_hash_update_elem+0x1d2/0x200 [<000000005e2c23de>] __do_sys_bpf+0x2046/0x2990 [<00000000d0084618>] do_syscall_64+0xad/0x9a0 [<000000000d96f263>] entry_SYSCALL_64_after_hwframe+0x49/0xb3 Fix it by freeing the list element when we're done with it. Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by: Jakub Sitnicki Signed-off-by: Alexei Starovoitov Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200607205229.2389672-2-jakub@cloudflare.com Signed-off-by: Sasha Levin commit efdb1bf81aab0f68b90da9e052502fd05f9f5e49 Author: Pavel Machek (CIP) Date: Sat Jun 6 17:31:03 2020 +0200 ASoC: meson: add missing free_irq() in error path [ Upstream commit 3b8a299a58b2afce464ae11324b59dcf0f1d10a7 ] free_irq() is missing in case of error, fix that. Signed-off-by: Pavel Machek (CIP) Reviewed-by: Jerome Brunet Link: https://lore.kernel.org/r/20200606153103.GA17905@amd Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 390f1688fb4648474b29c8ea6c2c710b689cd669 Author: Chao Yu Date: Mon Jun 8 20:03:16 2020 +0800 f2fs: handle readonly filesystem in f2fs_ioc_shutdown() [ Upstream commit 8626441f05dc45a2f4693ee6863d02456ce39e60 ] If mountpoint is readonly, we should allow shutdowning filesystem successfully, this fixes issue found by generic/599 testcase of xfstest. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 039a79ef0b1eb81ab060f29e14d3f9df0e6bc447 Author: Mauricio Faria de Oliveira Date: Tue Jun 2 18:15:16 2020 -0300 apparmor: check/put label on apparmor_sk_clone_security() [ Upstream commit 3b646abc5bc6c0df649daea4c2c976bd4d47e4c8 ] Currently apparmor_sk_clone_security() does not check for existing label/peer in the 'new' struct sock; it just overwrites it, if any (with another reference to the label of the source sock.) static void apparmor_sk_clone_security(const struct sock *sk, struct sock *newsk) { struct aa_sk_ctx *ctx = SK_CTX(sk); struct aa_sk_ctx *new = SK_CTX(newsk); new->label = aa_get_label(ctx->label); new->peer = aa_get_label(ctx->peer); } This might leak label references, which might overflow under load. Thus, check for and put labels, to prevent such errors. Note this is similarly done on: static int apparmor_socket_post_create(struct socket *sock, ...) ... if (sock->sk) { struct aa_sk_ctx *ctx = SK_CTX(sock->sk); aa_put_label(ctx->label); ctx->label = aa_get_label(label); } ... Context: ------- The label reference count leak is observed if apparmor_sock_graft() is called previously: this sets the 'ctx->label' field by getting a reference to the current label (later overwritten, without put.) static void apparmor_sock_graft(struct sock *sk, ...) { struct aa_sk_ctx *ctx = SK_CTX(sk); if (!ctx->label) ctx->label = aa_get_current_label(); } And that is the case on crypto/af_alg.c:af_alg_accept(): int af_alg_accept(struct sock *sk, struct socket *newsock, ...) ... struct sock *sk2; ... sk2 = sk_alloc(...); ... security_sock_graft(sk2, newsock); security_sk_clone(sk, sk2); ... Apparently both calls are done on their own right, especially for other LSMs, being introduced in 2010/2014, before apparmor socket mediation in 2017 (see commits [1,2,3,4]). So, it looks OK there! Let's fix the reference leak in apparmor. Test-case: --------- Exercise that code path enough to overflow label reference count. $ cat aa-refcnt-af_alg.c #include #include #include #include #include int main() { int sockfd; struct sockaddr_alg sa; /* Setup the crypto API socket */ sockfd = socket(AF_ALG, SOCK_SEQPACKET, 0); if (sockfd < 0) { perror("socket"); return 1; } memset(&sa, 0, sizeof(sa)); sa.salg_family = AF_ALG; strcpy((char *) sa.salg_type, "rng"); strcpy((char *) sa.salg_name, "stdrng"); if (bind(sockfd, (struct sockaddr *) &sa, sizeof(sa)) < 0) { perror("bind"); return 1; } /* Accept a "connection" and close it; repeat. */ while (!close(accept(sockfd, NULL, 0))); return 0; } $ gcc -o aa-refcnt-af_alg aa-refcnt-af_alg.c $ ./aa-refcnt-af_alg [ 9928.475953] refcount_t overflow at apparmor_sk_clone_security+0x37/0x70 in aa-refcnt-af_alg[1322], uid/euid: 1000/1000 ... [ 9928.507443] RIP: 0010:apparmor_sk_clone_security+0x37/0x70 ... [ 9928.514286] security_sk_clone+0x33/0x50 [ 9928.514807] af_alg_accept+0x81/0x1c0 [af_alg] [ 9928.516091] alg_accept+0x15/0x20 [af_alg] [ 9928.516682] SYSC_accept4+0xff/0x210 [ 9928.519609] SyS_accept+0x10/0x20 [ 9928.520190] do_syscall_64+0x73/0x130 [ 9928.520808] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 Note that other messages may be seen, not just overflow, depending on the value being incremented by kref_get(); on another run: [ 7273.182666] refcount_t: saturated; leaking memory. ... [ 7273.185789] refcount_t: underflow; use-after-free. Kprobes: ------- Using kprobe events to monitor sk -> sk_security -> label -> count (kref): Original v5.7 (one reference leak every iteration) ... (af_alg_accept+0x0/0x1c0) label=0xffff8a0f36c25eb0 label_refcnt=0x11fd2 ... (af_alg_release_parent+0x0/0xd0) label=0xffff8a0f36c25eb0 label_refcnt=0x11fd4 ... (af_alg_accept+0x0/0x1c0) label=0xffff8a0f36c25eb0 label_refcnt=0x11fd3 ... (af_alg_release_parent+0x0/0xd0) label=0xffff8a0f36c25eb0 label_refcnt=0x11fd5 ... (af_alg_accept+0x0/0x1c0) label=0xffff8a0f36c25eb0 label_refcnt=0x11fd4 ... (af_alg_release_parent+0x0/0xd0) label=0xffff8a0f36c25eb0 label_refcnt=0x11fd6 Patched v5.7 (zero reference leak per iteration) ... (af_alg_accept+0x0/0x1c0) label=0xffff9ff376c25eb0 label_refcnt=0x593 ... (af_alg_release_parent+0x0/0xd0) label=0xffff9ff376c25eb0 label_refcnt=0x594 ... (af_alg_accept+0x0/0x1c0) label=0xffff9ff376c25eb0 label_refcnt=0x593 ... (af_alg_release_parent+0x0/0xd0) label=0xffff9ff376c25eb0 label_refcnt=0x594 ... (af_alg_accept+0x0/0x1c0) label=0xffff9ff376c25eb0 label_refcnt=0x593 ... (af_alg_release_parent+0x0/0xd0) label=0xffff9ff376c25eb0 label_refcnt=0x594 Commits: ------- [1] commit 507cad355fc9 ("crypto: af_alg - Make sure sk_security is initialized on accept()ed sockets") [2] commit 4c63f83c2c2e ("crypto: af_alg - properly label AF_ALG socket") [3] commit 2acce6aa9f65 ("Networking") a.k.a ("crypto: af_alg - Avoid sock_graft call warning) [4] commit 56974a6fcfef ("apparmor: add base infastructure for socket mediation") Fixes: 56974a6fcfef ("apparmor: add base infastructure for socket mediation") Reported-by: Brian Moyles Signed-off-by: Mauricio Faria de Oliveira Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 2a9b3e4667f5f57386a0c351142b252d8bf800b6 Author: Martin Blumenstingl Date: Sun Jun 7 15:02:58 2020 +0200 net: dsa: lantiq_gswip: fix and improve the unsupported interface error [ Upstream commit 4d3da2d8d91f66988a829a18a0ce59945e8ae4fb ] While trying to use the lantiq_gswip driver on one of my boards I made a mistake when specifying the phy-mode (because the out-of-tree driver wants phy-mode "gmii" or "mii" for the internal PHYs). In this case the following error is printed multiple times: Unsupported interface: 3 While it gives at least a hint at what may be wrong it is not very user friendly. Print the human readable phy-mode and also which port is configured incorrectly (this hardware supports ports 0..6) to improve the cases where someone made a mistake. Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200") Signed-off-by: Martin Blumenstingl Acked-by: Hauke Mehrtens Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 88bc3e06039035fcd63a0d52ed8625e8682b107a Author: John Johansen Date: Fri Jun 5 18:12:21 2020 -0700 apparmor: fix introspection of of task mode for unconfined tasks [ Upstream commit dd2569fbb053719f7df7ef8fdbb45cf47156a701 ] Fix two issues with introspecting the task mode. 1. If a task is attached to a unconfined profile that is not the ns->unconfined profile then. Mode the mode is always reported as - $ ps -Z LABEL PID TTY TIME CMD unconfined 1287 pts/0 00:00:01 bash test (-) 1892 pts/0 00:00:00 ps instead of the correct value of (unconfined) as shown below $ ps -Z LABEL PID TTY TIME CMD unconfined 2483 pts/0 00:00:01 bash test (unconfined) 3591 pts/0 00:00:00 ps 2. if a task is confined by a stack of profiles that are unconfined the output of label mode is again the incorrect value of (-) like above, instead of (unconfined). This is because the visibile profile count increment is skipped by the special casing of unconfined. Fixes: f1bd904175e8 ("apparmor: add the base fns() for domain labels") Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit d782d6a142d51d84fc08d9d93aa3235900303ffc Author: ashimida Date: Tue Jun 2 15:45:17 2020 +0800 mksysmap: Fix the mismatch of '.L' symbols in System.map [ Upstream commit 72d24accf02add25e08733f0ecc93cf10fcbd88c ] When System.map was generated, the kernel used mksysmap to filter the kernel symbols, but all the symbols with the second letter 'L' in the kernel were filtered out, not just the symbols starting with 'dot + L'. For example: ashimida@ubuntu:~/linux$ cat System.map |grep ' .L' ashimida@ubuntu:~/linux$ nm -n vmlinux |grep ' .L' ffff0000088028e0 t bLength_show ...... ffff0000092e0408 b PLLP_OUTC_lock ffff0000092e0410 b PLLP_OUTA_lock The original intent should be to filter out all local symbols starting with '.L', so the dot should be escaped. Fixes: 00902e984732 ("mksysmap: Add h8300 local symbol pattern") Signed-off-by: ashimida Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit d0af43b47418eeb2b580dc0e7ecc849a8fa7d287 Author: Logan Gunthorpe Date: Wed Jan 9 12:22:28 2019 -0700 NTB: Fix the default port and peer numbers for legacy drivers [ Upstream commit fc8b086d9dbd57458d136c4fa70ee26f832c3a2e ] When the commit adding ntb_default_port_number() and ntb_default_peer_port_number() entered the kernel there was no users of it so it was impossible to tell what the API needed. When a user finally landed a year later (ntb_pingpong) there were more NTB topologies were created and no consideration was considered to how other drivers had changed. Now that there is a user it can be fixed to provide a sensible default for the legacy drivers that do not implement ntb_{peer_}port_number(). Seeing ntb_pingpong doesn't check error codes returning EINVAL was also not sensible. Patches for ntb_pingpong and ntb_perf follow (which are broken otherwise) to support hardware that doesn't have port numbers. This is important not only to not break support with existing drivers but for the cross link topology which, due to its perfect symmetry, cannot assign unique port numbers to each side. Fixes: 1e5301196a88 ("NTB: Add indexed ports NTB API") Signed-off-by: Logan Gunthorpe Acked-by: Allen Hubbe Tested-by: Alexander Fomichev Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit f0b8eead5b1cc0091b60352dbc169634ff94d758 Author: Logan Gunthorpe Date: Wed Jan 9 12:22:29 2019 -0700 NTB: ntb_pingpong: Choose doorbells based on port number [ Upstream commit ca93c45755da98302c93abdd788fc09113baf9e0 ] This commit fixes pingpong support for existing drivers that do not implement ntb_default_port_number() and ntb_default_peer_port_number(). This is required for hardware (like the crosslink topology of switchtec) which cannot assign reasonable port numbers to each port due to its perfect symmetry. Instead of picking the doorbell to use based on the the index of the peer, we use the peer's port number. This is a bit clearer and easier to understand. Fixes: c7aeb0afdcc2 ("NTB: ntb_pp: Add full multi-port NTB API support") Signed-off-by: Logan Gunthorpe Acked-by: Allen Hubbe Tested-by: Alexander Fomichev Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit 0ec407dfc1ec43deabb8eafa64160dc489f44021 Author: Wang Hai Date: Thu Jun 4 20:18:51 2020 +0800 yam: fix possible memory leak in yam_init_driver [ Upstream commit 98749b7188affbf2900c2aab704a8853901d1139 ] If register_netdev(dev) fails, free_netdev(dev) needs to be called, otherwise a memory leak will occur. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Hulk Robot Signed-off-by: Wang Hai Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a4d4b84377310e1f3741af6384ba79ac49cc2d0c Author: Will Deacon Date: Tue May 26 18:33:00 2020 +0100 sparc32: mm: Don't try to free page-table pages if ctor() fails [ Upstream commit 454b0289c6b5f2c66164654b80212d15fbef7a03 ] The pages backing page-table allocations for SRMMU are allocated via memblock as part of the "nocache" region initialisation during srmmu_paging_init() and should not be freed even if a later call to pgtable_pte_page_ctor() fails. Remove the broken call to __free_page(). Cc: David S. Miller Cc: Kirill A. Shutemov Fixes: 1ae9ae5f7df7 ("sparc: handle pgtable_page_ctor() fail") Signed-off-by: Will Deacon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7f16ba366a66b532fa33aa218c5c7db271f0e530 Author: Navid Emamdoost Date: Mon Jun 1 02:11:16 2020 -0500 pwm: img: Call pm_runtime_put() in pm_runtime_get_sync() failed case [ Upstream commit ca162ce98110b98e7d97b7157328d34dcfdd40a9 ] Even in failed case of pm_runtime_get_sync(), the usage_count is incremented. In order to keep the usage_count with correct value call appropriate pm_runtime_put(). Signed-off-by: Navid Emamdoost Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 9b163c91620ca61a08bb02bfca22cf264e44f74f Author: Pingfan Liu Date: Wed Apr 1 22:00:44 2020 +0800 powerpc/crashkernel: Take "mem=" option into account [ Upstream commit be5470e0c285a68dc3afdea965032f5ddc8269d7 ] 'mem=" option is an easy way to put high pressure on memory during some test. Hence after applying the memory limit, instead of total mem, the actual usable memory should be considered when reserving mem for crashkernel. Otherwise the boot up may experience OOM issue. E.g. it would reserve 4G prior to the change and 512M afterward, if passing crashkernel="2G-4G:384M,4G-16G:512M,16G-64G:1G,64G-128G:2G,128G-:4G", and mem=5G on a 256G machine. This issue is powerpc specific because it puts higher priority on fadump and kdump reservation than on "mem=". Referring the following code: if (fadump_reserve_mem() == 0) reserve_crashkernel(); ... /* Ensure that total memory size is page-aligned. */ limit = ALIGN(memory_limit ?: memblock_phys_mem_size(), PAGE_SIZE); memblock_enforce_memory_limit(limit); While on other arches, the effect of "mem=" takes a higher priority and pass through memblock_phys_mem_size() before calling reserve_crashkernel(). Signed-off-by: Pingfan Liu Reviewed-by: Hari Bathini Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/1585749644-4148-1-git-send-email-kernelfans@gmail.com Signed-off-by: Sasha Levin commit 211836827af353e958b597257f6d71e5d6c41762 Author: John Stultz Date: Fri May 29 21:38:23 2020 +0000 ASoC: qcom: q6asm-dai: kCFI fix [ Upstream commit a6b675a89e51a1cdad0481b809b7840d3f86e4b5 ] Fixes the following kCFI crash seen on db845c, caused by the function prototypes not matching the callback function prototype. [ 82.585661] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000001 [ 82.595387] Mem abort info: [ 82.599463] ESR = 0x96000005 [ 82.602658] EC = 0x25: DABT (current EL), IL = 32 bits [ 82.608177] SET = 0, FnV = 0 [ 82.611829] EA = 0, S1PTW = 0 [ 82.615369] Data abort info: [ 82.618751] ISV = 0, ISS = 0x00000005 [ 82.622641] CM = 0, WnR = 0 [ 82.625774] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000174259000 [ 82.632292] [0000000000000001] pgd=0000000000000000, pud=0000000000000000 [ 82.639167] Internal error: Oops: 96000005 [#1] PREEMPT SMP [ 82.644795] Modules linked in: hci_uart btqca xhci_plat_hcd xhci_pci_renesas xhci_pci xhci_hcd wcn36xx wcnss_ctrl wcd934x vctrl_regulator ufs_qcom syscon_reboot_e [ 82.644927] qcom_apcs_ipc_mailbox q6asm_dai q6routing q6asm q6afe_dai q6adm q6afe q6core q6dsp_common pm8941_pwrkey pm8916_wdt platform_mhu pinctrl_spmi_mpp pine [ 82.812982] CPU: 3 PID: 240 Comm: kworker/u16:4 Tainted: G W 5.6.0-rc7-mainline-00960-g0c34353d11b9-dirty #1 [ 82.824201] Hardware name: Thundercomm Dragonboard 845c (DT) [ 82.829937] Workqueue: qcom_apr_rx apr_rxwq [apr] [ 82.834698] pstate: 80c00005 (Nzcv daif +PAN +UAO) [ 82.839553] pc : __cfi_check_fail+0x4/0x1c [q6asm_dai] [ 82.844754] lr : __cfi_check+0x3a8/0x3b0 [q6asm_dai] [ 82.849767] sp : ffffffc0105f3c20 [ 82.853123] x29: ffffffc0105f3c30 x28: 0000000000000020 [ 82.858489] x27: ffffff80f4588400 x26: ffffff80f458ec94 [ 82.863854] x25: ffffff80f458ece8 x24: ffffffe3670c7000 [ 82.869220] x23: ffffff8094bb7b34 x22: ffffffe367137000 [ 82.874585] x21: bd07909b332eada6 x20: 0000000000000001 [ 82.879950] x19: ffffffe36713863c x18: ffffff80f8df4430 [ 82.885316] x17: 0000000000000001 x16: ffffffe39d15e660 [ 82.890681] x15: 0000000000000001 x14: 0000000000000027 [ 82.896047] x13: 0000000000000000 x12: ffffffe39e6465a0 [ 82.901413] x11: 0000000000000051 x10: 000000000000ffff [ 82.906779] x9 : 000ffffffe366c19 x8 : c3c5f18762d1ceef [ 82.912145] x7 : 0000000000000000 x6 : ffffffc010877698 [ 82.917511] x5 : ffffffc0105f3c00 x4 : 0000000000000000 [ 82.922877] x3 : 0000000000000000 x2 : 0000000000000001 [ 82.928243] x1 : ffffffe36713863c x0 : 0000000000000001 [ 82.933610] Call trace: [ 82.936099] __cfi_check_fail+0x4/0x1c [q6asm_dai] [ 82.940955] q6asm_srvc_callback+0x22c/0x618 [q6asm] [ 82.945973] apr_rxwq+0x1a8/0x27c [apr] [ 82.949861] process_one_work+0x2e8/0x54c [ 82.953919] worker_thread+0x27c/0x4d4 [ 82.957715] kthread+0x144/0x154 [ 82.960985] ret_from_fork+0x10/0x18 [ 82.964603] Code: a8c37bfd f85f8e5e d65f03c0 b40000a0 (39400008) [ 82.970762] ---[ end trace 410accb839617143 ]--- [ 82.975429] Kernel panic - not syncing: Fatal exception Signed-off-by: John Stultz Reviewed-by: Srinivas Kandagatla Cc: Patrick Lai Cc: Banajit Goswami Cc: Liam Girdwood Cc: Mark Brown Cc: Jaroslav Kysela Cc: Takashi Iwai Cc: Srinivas Kandagatla Cc: Vinod Koul Cc: Kuninori Morimoto Cc: Stephan Gerhold Cc: Sami Tolvanen Cc: Todd Kjos Cc: Alistair Delva Cc: Amit Pundir Cc: Sumit Semwal Cc: alsa-devel@alsa-project.org Link: https://lore.kernel.org/r/20200529213823.98812-1-john.stultz@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 117929a41db142172eba077a5029e56a46546610 Author: Paulo Alcantara Date: Tue May 19 15:38:27 2020 -0300 cifs: set up next DFS target before generic_ip_connect() [ Upstream commit aaa3aef34d3ab9499a5c7633823429f7a24e6dff ] If we mount a very specific DFS link \\FS0.FOO.COM\dfs\link -> \FS0\share1, \FS1\share2 where its target list contains NB names ("FS0" & "FS1") rather than FQDN ones ("FS0.FOO.COM" & "FS1.FOO.COM"), we end up connecting to \FOO\share1 but server->hostname will have "FOO.COM". The reason is because both "FS0" and "FS0.FOO.COM" resolve to same IP address and they share same TCP server connection, but "FS0.FOO.COM" was the first hostname set -- which is OK. However, if the echo thread timeouts and we still have a good connection to "FS0", in cifs_reconnect() rc = generic_ip_connect(server) -> success if (rc) { ... reconn_inval_dfs_target(server, cifs_sb, &tgt_list, &tgt_it); ... } ... it successfully reconnects to "FS0" server but does not set up next DFS target - which should be the same target server "\FS0\share1" - and server->hostname remains set to "FS0.FOO.COM" rather than "FS0", as reconn_inval_dfs_target() would have it set to "FS0" if called earlier. Finally, in __smb2_reconnect(), the reconnect of tcons would fail because tcon->ses->server->hostname (FS0.FOO.COM) does not match DFS target's hostname (FS0). Fix that by calling reconn_inval_dfs_target() before generic_ip_connect() so server->hostname will get updated correctly prior to reconnecting its tcons in __smb2_reconnect(). With "cifs: handle hostnames that resolve to same ip in failover" patch - The above problem would not occur. - We could save an DNS query to find out that they both resolve to the same ip address. Signed-off-by: Paulo Alcantara (SUSE) Reviewed-by: Aurelien Aptel Signed-off-by: Steve French Signed-off-by: Sasha Levin commit c0c8c8b10567f79f296200847f554b12a38f313d Author: Qiushi Wu Date: Wed May 27 22:02:30 2020 -0500 RDMA/core: Fix several reference count leaks. [ Upstream commit 0b8e125e213204508e1b3c4bdfe69713280b7abd ] kobject_init_and_add() takes reference even when it fails. If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Previous commit b8eb718348b8 ("net-sysfs: Fix reference count leak in rx|netdev_queue_add_kobject") fixed a similar problem. Link: https://lore.kernel.org/r/20200528030231.9082-1-wu000273@umn.edu Signed-off-by: Qiushi Wu Reviewed-by: Jason Gunthorpe Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 3851967ff5678f4321ee75dbbbad1a5a3305e912 Author: Jon Derrick Date: Wed May 27 23:02:39 2020 -0400 PCI: vmd: Filter resource type bits from shadow register [ Upstream commit 3e5095eebe015d5a4d566aa5e03c8621add5f0a7 ] Versions of VMD with the Host Physical Address shadow register use this register to calculate the bus address offset needed to do guest passthrough of the domain. This register shadows the Host Physical Address registers including the resource type bits. After calculating the offset, the extra resource type bits lead to the VMD resources being over-provisioned at the front and under-provisioned at the back. Example: pci 10000:80:02.0: reg 0x10: [mem 0xf801fffc-0xf803fffb 64bit] Expected: pci 10000:80:02.0: reg 0x10: [mem 0xf8020000-0xf803ffff 64bit] If other devices are mapped in the over-provisioned front, it could lead to resource conflict issues with VMD or those devices. Link: https://lore.kernel.org/r/20200528030240.16024-3-jonathan.derrick@intel.com Fixes: a1a30170138c9 ("PCI: vmd: Fix shadow offsets to reflect spec changes") Signed-off-by: Jon Derrick Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin commit e8cac2e3067e8587f8271c2177cc5ca924a61b54 Author: Xiyu Yang Date: Mon May 25 22:15:41 2020 +0800 nfsd: Fix svc_xprt refcnt leak when setup callback client failed [ Upstream commit a4abc6b12eb1f7a533c2e7484cfa555454ff0977 ] nfsd4_process_cb_update() invokes svc_xprt_get(), which increases the refcount of the "c->cn_xprt". The reference counting issue happens in one exception handling path of nfsd4_process_cb_update(). When setup callback client failed, the function forgets to decrease the refcnt increased by svc_xprt_get(), causing a refcnt leak. Fix this issue by calling svc_xprt_put() when setup callback client failed. Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit db686568ae52f9c17f48a1a7d4d5c5d4a18c9d71 Author: Kajol Jain Date: Mon May 25 16:13:03 2020 +0530 powerpc/perf/hv-24x7: Fix inconsistent output values incase multiple hv-24x7 events run [ Upstream commit b4ac18eead28611ff470d0f47a35c4e0ac080d9c ] Commit 2b206ee6b0df ("powerpc/perf/hv-24x7: Display change in counter values")' added to print _change_ in the counter value rather then raw value for 24x7 counters. Incase of transactions, the event count is set to 0 at the beginning of the transaction. It also sets the event's prev_count to the raw value at the time of initialization. Because of setting event count to 0, we are seeing some weird behaviour, whenever we run multiple 24x7 events at a time. For example: command#: ./perf stat -e "{hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/, hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/}" -C 0 -I 1000 sleep 100 1.000121704 120 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/ 1.000121704 5 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/ 2.000357733 8 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/ 2.000357733 10 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/ 3.000495215 18,446,744,073,709,551,616 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/ 3.000495215 18,446,744,073,709,551,616 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/ 4.000641884 56 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/ 4.000641884 18,446,744,073,709,551,616 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/ 5.000791887 18,446,744,073,709,551,616 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/ Getting these large values in case we do -I. As we are setting event_count to 0, for interval case, overall event_count is not coming in incremental order. As we may can get new delta lesser then previous count. Because of which when we print intervals, we are getting negative value which create these large values. This patch removes part where we set event_count to 0 in function 'h_24x7_event_read'. There won't be much impact as we do set event->hw.prev_count to the raw value at the time of initialization to print change value. With this patch In power9 platform command#: ./perf stat -e "{hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/, hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/}" -C 0 -I 1000 sleep 100 1.000117685 93 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/ 1.000117685 1 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/ 2.000349331 98 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/ 2.000349331 2 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/ 3.000495900 131 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/ 3.000495900 4 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/ 4.000645920 204 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/ 4.000645920 61 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/ 4.284169997 22 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/ Suggested-by: Sukadev Bhattiprolu Signed-off-by: Kajol Jain Tested-by: Madhavan Srinivasan Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200525104308.9814-2-kjain@linux.ibm.com Signed-off-by: Sasha Levin commit ecb9c4d344c970401fa6cd7f692127df437a496a Author: Mark Zhang Date: Wed May 27 16:57:03 2020 +0300 IB/mlx5: Fix DEVX support for MLX5_CMD_OP_INIT2INIT_QP command [ Upstream commit d246a3061528be6d852156d25c02ea69d6db7e65 ] The commit citied in the Fixes line wasn't complete and solved only part of the problems. Update the mlx5_ib to properly support MLX5_CMD_OP_INIT2INIT_QP command in the DEVX, that is required when modify the QP tx_port_affinity. Fixes: 819f7427bafd ("RDMA/mlx5: Add init2init as a modify command") Link: https://lore.kernel.org/r/20200527135703.482501-1-leon@kernel.org Signed-off-by: Mark Zhang Reviewed-by: Maor Gottlieb Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit a2fe8d88aeff585a5fb5d66adbf18cd5a9a249d4 Author: Alain Volmat Date: Sun Mar 22 15:07:40 2020 +0100 clk: clk-flexgen: fix clock-critical handling [ Upstream commit a403bbab1a73d798728d76931cab3ff0399b9560 ] Fixes an issue leading to having all clocks following a critical clocks marked as well as criticals. Fixes: fa6415affe20 ("clk: st: clk-flexgen: Detect critical clocks") Signed-off-by: Alain Volmat Link: https://lkml.kernel.org/r/20200322140740.3970-1-avolmat@me.com Reviewed-by: Patrice Chotard Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 6a70c943a26f0673bebc01b4f01d5eda84984e2f Author: Sudhakar Panneerselvam Date: Fri May 22 16:51:57 2020 +0000 scsi: vhost: Notify TCM about the maximum sg entries supported per command [ Upstream commit 5ae6a6a915033bfee79e76e0c374d4f927909edc ] vhost-scsi pre-allocates the maximum sg entries per command and if a command requires more than VHOST_SCSI_PREALLOC_SGLS entries, then that command is failed by it. This patch lets vhost communicate the max sg limit when it registers vhost_scsi_ops with TCM. With this change, TCM would report the max sg entries through "Block Limits" VPD page which will be typically queried by the SCSI initiator during device discovery. By knowing this limit, the initiator could ensure the maximum transfer length is less than or equal to what is reported by vhost-scsi. Link: https://lore.kernel.org/r/1590166317-953-1-git-send-email-sudhakar.panneerselvam@oracle.com Cc: Michael S. Tsirkin Cc: Jason Wang Cc: Paolo Bonzini Cc: Stefan Hajnoczi Reviewed-by: Mike Christie Signed-off-by: Sudhakar Panneerselvam Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 296cec70500ba6c429f1713d8fa4d6fdb0b0f575 Author: Xiyu Yang Date: Mon May 25 22:16:24 2020 +0800 scsi: lpfc: Fix lpfc_nodelist leak when processing unsolicited event [ Upstream commit 7217e6e694da3aae6d17db8a7f7460c8d4817ebf ] In order to create or activate a new node, lpfc_els_unsol_buffer() invokes lpfc_nlp_init() or lpfc_enable_node() or lpfc_nlp_get(), all of them will return a reference of the specified lpfc_nodelist object to "ndlp" with increased refcnt. When lpfc_els_unsol_buffer() returns, local variable "ndlp" becomes invalid, so the refcount should be decreased to keep refcount balanced. The reference counting issue happens in one exception handling path of lpfc_els_unsol_buffer(). When "ndlp" in DEV_LOSS, the function forgets to decrease the refcnt increased by lpfc_nlp_init() or lpfc_enable_node() or lpfc_nlp_get(), causing a refcnt leak. Fix this issue by calling lpfc_nlp_put() when "ndlp" in DEV_LOSS. Link: https://lore.kernel.org/r/1590416184-52592-1-git-send-email-xiyuyang19@fudan.edu.cn Reviewed-by: Daniel Wagner Reviewed-by: James Smart Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 82ac4863030cfc033d4f6d8e0f51e63bfad13956 Author: Quanyang Wang Date: Mon Mar 2 13:50:43 2020 -0800 clk: zynqmp: fix memory leak in zynqmp_register_clocks [ Upstream commit 58b0fb86260063f86afecaebf4056c876fff2a19 ] This is detected by kmemleak running on zcu102 board: unreferenced object 0xffffffc877e48180 (size 128): comm "swapper/0", pid 1, jiffies 4294892909 (age 315.436s) hex dump (first 32 bytes): 64 70 5f 76 69 64 65 6f 5f 72 65 66 5f 64 69 76 dp_video_ref_div 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1............... backtrace: [<00000000c9be883b>] __kmalloc_track_caller+0x200/0x380 [<00000000f02c3809>] kvasprintf+0x7c/0x100 [<00000000e51dde4d>] kasprintf+0x60/0x80 [<0000000092298b05>] zynqmp_register_clocks+0x29c/0x398 [<00000000faaff182>] zynqmp_clock_probe+0x3cc/0x4c0 [<000000005f5986f0>] platform_drv_probe+0x58/0xa8 [<00000000d5810136>] really_probe+0xd8/0x2a8 [<00000000f5b671be>] driver_probe_device+0x5c/0x100 [<0000000038f91fcf>] __device_attach_driver+0x98/0xb8 [<000000008a3f2ac2>] bus_for_each_drv+0x74/0xd8 [<000000001cb2783d>] __device_attach+0xe0/0x140 [<00000000c268031b>] device_initial_probe+0x24/0x30 [<000000006998de4b>] bus_probe_device+0x9c/0xa8 [<00000000647ae6ff>] device_add+0x3c0/0x610 [<0000000071c14bb8>] of_device_add+0x40/0x50 [<000000004bb5d132>] of_platform_device_create_pdata+0xbc/0x138 This is because that when num_nodes is larger than 1, clk_out is allocated using kasprintf for these nodes but only the last node's clk_out is freed. Signed-off-by: Quanyang Wang Signed-off-by: Michal Simek Signed-off-by: Tejas Patel Signed-off-by: Jolly Shah Link: https://lkml.kernel.org/r/1583185843-20707-5-git-send-email-jolly.shah@xilinx.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit bee9cc351308c48948d97851dda85432842267e8 Author: Dan Carpenter Date: Thu May 21 15:12:21 2020 +0300 scsi: cxgb3i: Fix some leaks in init_act_open() [ Upstream commit b6170a49c59c27a10efed26c5a2969403e69aaba ] There wasn't any clean up done if cxgb3_alloc_atid() failed and also the original code didn't release "csk->l2t". Link: https://lore.kernel.org/r/20200521121221.GA247492@mwanda Fixes: 6f7efaabefeb ("[SCSI] cxgb3i: change cxgb3i to use libcxgbi") Signed-off-by: Dan Carpenter Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 4deddbf7db45e30952838ef5289c7edef1fd7aee Author: Marek Szyprowski Date: Mon Apr 27 09:48:29 2020 +0200 mfd: wm8994: Fix driver operation if loaded as modules [ Upstream commit d4f9b5428b53dd67f49ee8deed8d4366ed6b1933 ] WM8994 chip has built-in regulators, which might be used for chip operation. They are controlled by a separate wm8994-regulator driver, which should be loaded before this driver calls regulator_get(), because that driver also provides consumer-supply mapping for the them. If that driver is not yet loaded, regulator core substitute them with dummy regulator, what breaks chip operation, because the built-in regulators are never enabled. Fix this by annotating this driver with MODULE_SOFTDEP() "pre" dependency to "wm8994_regulator" module. Signed-off-by: Marek Szyprowski Acked-by: Charles Keepax Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 8e52a1eef19bcce3d60a5b822eb06e02004b6f73 Author: Christophe Leroy Date: Tue May 19 05:48:51 2020 +0000 powerpc/ptdump: Add _PAGE_COHERENT flag [ Upstream commit 3af4786eb429b2df76cbd7ce3bae21467ac3e4fb ] For platforms using shared.c (4xx, Book3e, Book3s/32), also handle the _PAGE_COHERENT flag which corresponds to the M bit of the WIMG flags. Signed-off-by: Christophe Leroy [mpe: Make it more verbose, use "coherent" rather than "m"] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/324c3d860717e8e91fca3bb6c0f8b23e1644a404.1589866984.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit 805bae7592fa2cfede898b24e2a8d85fdd6317ee Author: Peter Chen Date: Sun May 10 13:30:41 2020 +0800 usb: gadget: core: sync interrupt before unbind the udc [ Upstream commit 3c73bc52195def14165c3a7d91bdbb33b51725f5 ] The threaded interrupt handler may still be called after the usb_gadget_disconnect is called, it causes the structures used at interrupt handler was freed before it uses, eg the usb_request. This issue usually occurs we remove the udc function during the transfer. Below is the example when doing stress test for android switch function, the EP0's request is freed by .unbind (configfs_composite_unbind -> composite_dev_cleanup), but the threaded handler accesses this request during handling setup packet request. In fact, there is no protection between unbind the udc and udc interrupt handling, so we have to avoid the interrupt handler is occurred or scheduled during the .unbind flow. init: Sending signal 9 to service 'adbd' (pid 18077) process group... android_work: did not send uevent (0 0 000000007bec2039) libprocessgroup: Successfully killed process cgroup uid 0 pid 18077 in 6ms init: Service 'adbd' (pid 18077) received signal 9 init: Sending signal 9 to service 'adbd' (pid 18077) process group... libprocessgroup: Successfully killed process cgroup uid 0 pid 18077 in 0ms init: processing action (init.svc.adbd=stopped) from (/init.usb.configfs.rc:14) init: Received control message 'start' for 'adbd' from pid: 399 (/vendor/bin/hw/android.hardware.usb@1. init: starting service 'adbd'... read descriptors read strings Unable to handle kernel read from unreadable memory at virtual address 000000000000002a android_work: sent uevent USB_STATE=CONNECTED Mem abort info: ESR = 0x96000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000000e97f1000 using random self ethernet address [000000000000002a] pgd=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 232 Comm: irq/68-5b110000 Not tainted 5.4.24-06075-g94a6b52b5815 #92 Hardware name: Freescale i.MX8QXP MEK (DT) pstate: 00400085 (nzcv daIf +PAN -UAO) using random host ethernet address pc : composite_setup+0x5c/0x1730 lr : android_setup+0xc0/0x148 sp : ffff80001349bba0 x29: ffff80001349bba0 x28: ffff00083a50da00 x27: ffff8000124e6000 x26: ffff800010177950 x25: 0000000000000040 x24: ffff000834e18010 x23: 0000000000000000 x22: 0000000000000000 x21: ffff00083a50da00 x20: ffff00082e75ec40 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000001 x11: ffff80001180fb58 x10: 0000000000000040 x9 : ffff8000120fc980 x8 : 0000000000000000 x7 : ffff00083f98df50 x6 : 0000000000000100 x5 : 00000307e8978431 x4 : ffff800011386788 x3 : 0000000000000000 x2 : ffff800012342000 x1 : 0000000000000000 x0 : ffff800010c6d3a0 Call trace: composite_setup+0x5c/0x1730 android_setup+0xc0/0x148 cdns3_ep0_delegate_req+0x64/0x90 cdns3_check_ep0_interrupt_proceed+0x384/0x738 cdns3_device_thread_irq_handler+0x124/0x6e0 cdns3_thread_irq+0x94/0xa0 irq_thread_fn+0x30/0xa0 irq_thread+0x150/0x248 kthread+0xfc/0x128 ret_from_fork+0x10/0x18 Code: 910e8000 f9400693 12001ed7 79400f79 (3940aa61) ---[ end trace c685db37f8773fba ]--- Kernel panic - not syncing: Fatal exception SMP: stopping secondary CPUs Kernel Offset: disabled CPU features: 0x0002,20002008 Memory Limit: none Rebooting in 5 seconds.. Reviewed-by: Jun Li Signed-off-by: Peter Chen Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 2ec338547c67ffd5fd9670ec1612f56111dfe520 Author: Andy Shevchenko Date: Tue May 19 16:12:30 2020 +0300 gpio: dwapb: Call acpi_gpiochip_free_interrupts() on GPIO chip de-registration [ Upstream commit 494a94e38dcf62543a32a4424d646ff80b4b28bd ] Add missed acpi_gpiochip_free_interrupts() call when unregistering ports. While at it, drop extra check to call acpi_gpiochip_request_interrupts(). There is no need to have an additional check to call acpi_gpiochip_request_interrupts(). Even without any interrupts available the registered ACPI Event handlers can be useful for debugging purposes. Fixes: e6cb3486f5a1 ("gpio: dwapb: add gpio-signaled acpi event support") Signed-off-by: Andy Shevchenko Tested-by: Serge Semin Acked-by: Serge Semin Link: https://lore.kernel.org/r/20200519131233.59032-1-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 02bdd581404d58315a1b8022b4d09fba81483e3d Author: Christophe JAILLET Date: Sat Apr 18 09:07:51 2020 +0200 m68k/PCI: Fix a memory leak in an error handling path [ Upstream commit c3f4ec050f56eeab7c1f290321f9b762c95bd332 ] If 'ioremap' fails, we must free 'bridge', as done in other error handling path bellow. Fixes: 19cc4c843f40 ("m68k/PCI: Replace pci_fixup_irqs() call with host bridge IRQ mapping hooks") Signed-off-by: Christophe JAILLET Reviewed-by: Geert Uytterhoeven Signed-off-by: Greg Ungerer Signed-off-by: Sasha Levin commit ec475f960e92a087e29eda93b17767b80897751a Author: Jon Derrick Date: Mon May 11 12:21:14 2020 -0400 PCI: pci-bridge-emul: Fix PCIe bit conflicts [ Upstream commit c88d19181771bd189147681ef38fc1533ebeff4c ] This patch fixes two bit conflicts in the pci-bridge-emul driver: 1. Bit 3 of Device Status (19 of Device Control) is marked as both Write-1-to-Clear and Read-Only. It should be Write-1-to-Clear. The Read-Only and Reserved bitmasks are shifted by 1 bit due to this error. 2. Bit 12 of Slot Control is marked as both Read-Write and Reserved. It should be Read-Write. Link: https://lore.kernel.org/r/20200511162117.6674-2-jonathan.derrick@intel.com Signed-off-by: Jon Derrick Signed-off-by: Lorenzo Pieralisi Acked-by: Rob Herring Signed-off-by: Sasha Levin commit ba5192db9672530683ebf5bb5abc39f88f0dba33 Author: Luo Jiaxing Date: Fri May 15 22:13:42 2020 +0800 scsi: hisi_sas: Do not reset phy timer to wait for stray phy up [ Upstream commit e16b9ed61e078d836a0f24a82080cf29d7539c7e ] We found out that after phy up, the hardware reports another oob interrupt but did not follow a phy up interrupt: oob ready -> phy up -> DEV found -> oob read -> wait phy up -> timeout We run link reset when wait phy up timeout, and it send a normal disk into reset processing. So we made some circumvention action in the code, so that this abnormal oob interrupt will not start the timer to wait for phy up. Link: https://lore.kernel.org/r/1589552025-165012-2-git-send-email-john.garry@huawei.com Signed-off-by: Luo Jiaxing Signed-off-by: John Garry Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 2b670bbfd8c0244362fafddceeb2e096eb32caa2 Author: Aharon Landau Date: Wed May 13 12:55:50 2020 +0300 RDMA/mlx5: Add init2init as a modify command [ Upstream commit 819f7427bafd494ef7ca4942ec6322db20722d7b ] Missing INIT2INIT entry in the list of modify commands caused DEVX applications to be unable to modify_qp for this transition state. Add the MLX5_CMD_OP_INIT2INIT_QP opcode to the list of allowed DEVX opcodes. Fixes: e662e14d801b ("IB/mlx5: Add DEVX support for modify and query commands") Link: https://lore.kernel.org/r/20200513095550.211345-1-leon@kernel.org Signed-off-by: Aharon Landau Reviewed-by: Maor Gottlieb Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit cbd55ce91abf878d082355cdfa3b978579c17d95 Author: Sai Prakash Ranjan Date: Mon May 18 12:02:32 2020 -0600 coresight: tmc: Fix TMC mode read in tmc_read_prepare_etb() [ Upstream commit 347adb0d6385c3220dc01ab61807a5b1892901cc ] On some QCOM platforms like SC7180, SDM845 and SM8150, reading TMC mode register without proper coresight power management can lead to async exceptions like the one in the call trace below in tmc_read_prepare_etb(). This can happen if the user tries to read the TMC etf data via device node without setting up source and the sink first. Fix this by having a check for coresight sysfs mode before reading TMC mode management register. Kernel panic - not syncing: Asynchronous SError Interrupt CPU: 7 PID: 2605 Comm: hexdump Tainted: G S 5.4.30 #122 Call trace: dump_backtrace+0x0/0x188 show_stack+0x20/0x2c dump_stack+0xdc/0x144 panic+0x168/0x36c panic+0x0/0x36c arm64_serror_panic+0x78/0x84 do_serror+0x130/0x138 el1_error+0x84/0xf8 tmc_read_prepare_etb+0x88/0xb8 tmc_open+0x40/0xd8 misc_open+0x120/0x158 chrdev_open+0xb8/0x1a4 do_dentry_open+0x268/0x3a0 vfs_open+0x34/0x40 path_openat+0x39c/0xdf4 do_filp_open+0x90/0x10c do_sys_open+0x150/0x3e8 __arm64_compat_sys_openat+0x28/0x34 el0_svc_common+0xa8/0x160 el0_svc_compat_handler+0x2c/0x38 el0_svc_compat+0x8/0x10 Fixes: 4525412a5046 ("coresight: tmc: making prepare/unprepare functions generic") Reported-by: Stephen Boyd Suggested-by: Mathieu Poirier Signed-off-by: Sai Prakash Ranjan Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200518180242.7916-14-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c74ead4597474658bef352edd6a2f9880cf07f8f Author: Qian Cai Date: Sun May 10 12:16:56 2020 -0400 vfio/pci: fix memory leaks in alloc_perm_bits() [ Upstream commit 3e63b94b6274324ff2e7d8615df31586de827c4e ] vfio_pci_disable() calls vfio_config_free() but forgets to call free_perm_bits() resulting in memory leaks, unreferenced object 0xc000000c4db2dee0 (size 16): comm "qemu-kvm", pid 4305, jiffies 4295020272 (age 3463.780s) hex dump (first 16 bytes): 00 00 ff 00 ff ff ff ff ff ff ff ff ff ff 00 00 ................ backtrace: [<00000000a6a4552d>] alloc_perm_bits+0x58/0xe0 [vfio_pci] [<00000000ac990549>] vfio_config_init+0xdf0/0x11b0 [vfio_pci] init_pci_cap_msi_perm at drivers/vfio/pci/vfio_pci_config.c:1125 (inlined by) vfio_msi_cap_len at drivers/vfio/pci/vfio_pci_config.c:1180 (inlined by) vfio_cap_len at drivers/vfio/pci/vfio_pci_config.c:1241 (inlined by) vfio_cap_init at drivers/vfio/pci/vfio_pci_config.c:1468 (inlined by) vfio_config_init at drivers/vfio/pci/vfio_pci_config.c:1707 [<000000006db873a1>] vfio_pci_open+0x234/0x700 [vfio_pci] [<00000000630e1906>] vfio_group_fops_unl_ioctl+0x8e0/0xb84 [vfio] [<000000009e34c54f>] ksys_ioctl+0xd8/0x130 [<000000006577923d>] sys_ioctl+0x28/0x40 [<000000006d7b1cf2>] system_call_exception+0x114/0x1e0 [<0000000008ea7dd5>] system_call_common+0xf0/0x278 unreferenced object 0xc000000c4db2e330 (size 16): comm "qemu-kvm", pid 4305, jiffies 4295020272 (age 3463.780s) hex dump (first 16 bytes): 00 ff ff 00 ff ff ff ff ff ff ff ff ff ff 00 00 ................ backtrace: [<000000004c71914f>] alloc_perm_bits+0x44/0xe0 [vfio_pci] [<00000000ac990549>] vfio_config_init+0xdf0/0x11b0 [vfio_pci] [<000000006db873a1>] vfio_pci_open+0x234/0x700 [vfio_pci] [<00000000630e1906>] vfio_group_fops_unl_ioctl+0x8e0/0xb84 [vfio] [<000000009e34c54f>] ksys_ioctl+0xd8/0x130 [<000000006577923d>] sys_ioctl+0x28/0x40 [<000000006d7b1cf2>] system_call_exception+0x114/0x1e0 [<0000000008ea7dd5>] system_call_common+0xf0/0x278 Fixes: 89e1f7d4c66d ("vfio: Add PCI device driver") Signed-off-by: Qian Cai [aw: rolled in follow-up patch] Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 24911d387b840464356be309a5362bcb322a8302 Author: Andre Przywara Date: Wed May 13 11:29:58 2020 +0100 arm64: dts: fvp/juno: Fix node address fields [ Upstream commit bb5cce12ac717c7462217cd493ed701d12d6dbce ] The Arm Ltd. boards were using an outdated address convention in the DT node names, by separating the high from the low 32-bits of an address by a comma. Remove the comma from the node name suffix to be DT spec compliant. Link: https://lore.kernel.org/r/20200513103016.130417-3-andre.przywara@arm.com Signed-off-by: Andre Przywara Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 6d79ba8094fa39dea67f1520e43c1a0f0646ceea Author: Emmanuel Nicolet Date: Sat May 9 18:58:32 2020 +0000 ps3disk: use the default segment boundary [ Upstream commit 720bc316690bd27dea9d71510b50f0cd698ffc32 ] Since commit dcebd755926b ("block: use bio_for_each_bvec() to compute multi-page bvec count"), the kernel will bug_on on the PS3 because bio_split() is called with sectors == 0: kernel BUG at block/bio.c:1853! Oops: Exception in kernel mode, sig: 5 [#1] BE PAGE_SIZE=4K MMU=Hash PREEMPT SMP NR_CPUS=8 NUMA PS3 Modules linked in: firewire_sbp2 rtc_ps3(+) soundcore ps3_gelic(+) \ ps3rom(+) firewire_core ps3vram(+) usb_common crc_itu_t CPU: 0 PID: 97 Comm: blkid Not tainted 5.3.0-rc4 #1 NIP: c00000000027d0d0 LR: c00000000027d0b0 CTR: 0000000000000000 REGS: c00000000135ae90 TRAP: 0700 Not tainted (5.3.0-rc4) MSR: 8000000000028032 CR: 44008240 XER: 20000000 IRQMASK: 0 GPR00: c000000000289368 c00000000135b120 c00000000084a500 c000000004ff8300 GPR04: 0000000000000c00 c000000004c905e0 c000000004c905e0 000000000000ffff GPR08: 0000000000000000 0000000000000001 0000000000000000 000000000000ffff GPR12: 0000000000000000 c0000000008ef000 000000000000003e 0000000000080001 GPR16: 0000000000000100 000000000000ffff 0000000000000000 0000000000000004 GPR20: c00000000062fd7e 0000000000000001 000000000000ffff 0000000000000080 GPR24: c000000000781788 c00000000135b350 0000000000000080 c000000004c905e0 GPR28: c00000000135b348 c000000004ff8300 0000000000000000 c000000004c90000 NIP [c00000000027d0d0] .bio_split+0x28/0xac LR [c00000000027d0b0] .bio_split+0x8/0xac Call Trace: [c00000000135b120] [c00000000027d130] .bio_split+0x88/0xac (unreliable) [c00000000135b1b0] [c000000000289368] .__blk_queue_split+0x11c/0x53c [c00000000135b2d0] [c00000000028f614] .blk_mq_make_request+0x80/0x7d4 [c00000000135b3d0] [c000000000283a8c] .generic_make_request+0x118/0x294 [c00000000135b4b0] [c000000000283d34] .submit_bio+0x12c/0x174 [c00000000135b580] [c000000000205a44] .mpage_bio_submit+0x3c/0x4c [c00000000135b600] [c000000000206184] .mpage_readpages+0xa4/0x184 [c00000000135b750] [c0000000001ff8fc] .blkdev_readpages+0x24/0x38 [c00000000135b7c0] [c0000000001589f0] .read_pages+0x6c/0x1a8 [c00000000135b8b0] [c000000000158c74] .__do_page_cache_readahead+0x118/0x184 [c00000000135b9b0] [c0000000001591a8] .force_page_cache_readahead+0xe4/0xe8 [c00000000135ba50] [c00000000014fc24] .generic_file_read_iter+0x1d8/0x830 [c00000000135bb50] [c0000000001ffadc] .blkdev_read_iter+0x40/0x5c [c00000000135bbc0] [c0000000001b9e00] .new_sync_read+0x144/0x1a0 [c00000000135bcd0] [c0000000001bc454] .vfs_read+0xa0/0x124 [c00000000135bd70] [c0000000001bc7a4] .ksys_read+0x70/0xd8 [c00000000135be20] [c00000000000a524] system_call+0x5c/0x70 Instruction dump: 7fe3fb78 482e30dc 7c0802a6 482e3085 7c9e2378 f821ff71 7ca42b78 7d3e00d0 7c7d1b78 79290fe0 7cc53378 69290001 <0b090000> 81230028 7bca0020 7929ba62 [ end trace 313fec760f30aa1f ]--- The problem originates from setting the segment boundary of the request queue to -1UL. This makes get_max_segment_size() return zero when offset is zero, whatever the max segment size. The test with BLK_SEG_BOUNDARY_MASK fails and 'mask - (mask & offset) + 1' overflows to zero in the return statement. Not setting the segment boundary and using the default value (BLK_SEG_BOUNDARY_MASK) fixes the problem. Signed-off-by: Emmanuel Nicolet Signed-off-by: Geoff Levand Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/060a416c43138f45105c0540eff1a45539f7e2fc.1589049250.git.geoff@infradead.org Signed-off-by: Sasha Levin commit bc881cd5334caceda5ffbf18779ec51b5bfff0d7 Author: Pali Rohár Date: Thu Apr 30 10:06:15 2020 +0200 PCI: aardvark: Don't blindly enable ASPM L0s and don't write to read-only register [ Upstream commit 90c6cb4a355e7befcb557d217d1d8b8bd5875a05 ] Trying to change Link Status register does not have any effect as this is a read-only register. Trying to overwrite bits for Negotiated Link Width does not make sense. In future proper change of link width can be done via Lane Count Select bits in PCIe Control 0 register. Trying to unconditionally enable ASPM L0s via ASPM Control bits in Link Control register is wrong. There should be at least some detection if endpoint supports L0s as isn't mandatory. Moreover ASPM Control bits in Link Control register are controlled by pcie/aspm.c code which sets it according to system ASPM settings, immediately after aardvark driver probes. So setting these bits by aardvark driver has no long running effect. Remove code which touches ASPM L0s bits from this driver and let kernel's ASPM implementation to set ASPM state properly. Some users are reporting issues that this code is problematic for some Intel wifi cards and removing it fixes them, see e.g.: https://bugzilla.kernel.org/show_bug.cgi?id=196339 If problems with Intel wifi cards occur even after this commit, then pcie/aspm.c code could be modified / hooked to not enable ASPM L0s state for affected problematic cards. Link: https://lore.kernel.org/r/20200430080625.26070-3-pali@kernel.org Tested-by: Tomasz Maciej Nowak Signed-off-by: Pali Rohár Signed-off-by: Lorenzo Pieralisi Acked-by: Rob Herring Acked-by: Thomas Petazzoni Signed-off-by: Sasha Levin commit 492c50fe65a9a50eac0968442ca0e3b9253e7a78 Author: Andre Przywara Date: Wed May 13 11:30:06 2020 +0100 arm64: dts: fvp: Fix GIC child nodes [ Upstream commit 78631aecc52c4b2adcf611769df2ff9c67ac16d0 ] The GIC DT nodes for the fastmodels were not fully compliant with the DT binding, which has certain expectations about child nodes and their size and address cells values. Use smaller #address-cells and #size-cells values, as the binding requests, and adjust the reg properties accordingly. This requires adjusting the interrupt nexus nodes as well, as one field of the interrupt-map property depends on the GIC's address-size. Since the .dts files share interrupt nexus nodes across different interrupt controllers (GICv2 vs. GICv3), we need to use the only commonly allowed #address-size value of <1> for both. Link: https://lore.kernel.org/r/20200513103016.130417-11-andre.przywara@arm.com Signed-off-by: Andre Przywara Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 376ef9d7ee4c0886cdf624727415048e10295c00 Author: Daniel Baluta Date: Fri May 15 16:59:51 2020 +0300 ASoC: SOF: Do nothing when DSP PM callbacks are not set [ Upstream commit c26fde3b15ed41f5f452f1da727795f787833287 ] This provides a better separation between runtime and PM sleep callbacks. Only do nothing if given runtime flag is set and calback is not set. With the current implementation, if PM sleep callback is set but runtime callback is not set then at runtime resume we reload the firmware even if we do not support runtime resume callback. Signed-off-by: Daniel Baluta Signed-off-by: Kai Vehmanen Reviewed-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Link: https://lore.kernel.org/r/20200515135958.17511-2-kai.vehmanen@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1cdae7bb4221fb1a886efd2c75b54a3b1a2cb87f Author: Geert Uytterhoeven Date: Thu May 7 09:47:13 2020 +0200 clk: renesas: cpg-mssr: Fix STBCR suspend/resume handling [ Upstream commit ace342097768e35fd41934285604fa97da1e235a ] On SoCs with Standby Control Registers (STBCRs) instead of Module Stop Control Registers (MSTPCRs), the suspend handler saves the wrong registers, and the resume handler prints the wrong register in an error message. Fortunately this cannot happen yet, as the suspend/resume code is used on PSCI systems only, and systems with STBCRs (RZ/A1 and RZ/A2) do not use PSCI. Still, it is better to fix this, to avoid this becoming a problem in the future. Distinguish between STBCRs and MSTPCRs where needed. Replace the useless printing of the virtual register address in the resume error message by printing the register index. Fixes: fde35c9c7db5732c ("clk: renesas: cpg-mssr: Add R7S9210 support") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20200507074713.30113-1-geert+renesas@glider.be Signed-off-by: Sasha Levin commit 14c5e25d3b00a72782a6cfbb39da09c6579e7579 Author: Lars Povlsen Date: Wed May 13 14:55:21 2020 +0200 pinctrl: ocelot: Fix GPIO interrupt decoding on Jaguar2 [ Upstream commit 0b47afc65453a70bc521e251138418056f65793f ] This fixes a problem with using the GPIO as an interrupt on Jaguar2 (and similar), as the register layout of the platforms with 64 GPIO's are pairwise, such that the original offset must be multiplied with the platform stride. Fixes: da801ab56ad8 pinctrl: ocelot: add MSCC Jaguar2 support. Reviewed-by: Alexandre Belloni Signed-off-by: Lars Povlsen Link: https://lore.kernel.org/r/20200513125532.24585-4-lars.povlsen@microchip.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 4e55b843fa61be7cb7013d878d200c76b878b49f Author: Andre Przywara Date: Wed May 13 11:30:05 2020 +0100 arm64: dts: juno: Fix GIC child nodes [ Upstream commit a78aee9e434932a500db36cc6d88daeff3745e9f ] The GIC DT nodes for the Juno boards were not fully compliant with the DT binding, which has certain expectations about child nodes and their size and address cells values. Use smaller #address-cells and #size-cells values, as the binding requests, and adjust the reg properties accordingly. This requires adjusting the interrupt nexus nodes as well, as one field of the interrupt-map property depends on the GIC's address-size. Link: https://lore.kernel.org/r/20200513103016.130417-10-andre.przywara@arm.com Signed-off-by: Andre Przywara Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 7df82e1754dfa83332c71513eb2acd00da3873b0 Author: Marek Behún Date: Wed May 6 21:29:16 2020 +0200 arm64: dts: armada-3720-turris-mox: fix SFP binding [ Upstream commit c2671acbbbd822ef077cc168991e0a7dbe2172c9 ] The sfp compatible should be 'sff,sfp', not 'sff,sfp+'. We used patched kernel where the latter was working. Fixes: 7109d817db2e ("arm64: dts: marvell: add DTS for Turris Mox") Signed-off-by: Marek Behún Cc: Gregory CLEMENT Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit 4ca96a5de8127e87a3b277356eff01e26b0cad8d Author: Marek Behún Date: Fri May 1 01:11:44 2020 +0200 arm64: dts: armada-3720-turris-mox: forbid SDR104 on SDIO for FCC purposes [ Upstream commit 7a2c36b039d2343cc29fec6102da839477b8dc60 ] Use sdhci-caps-mask to forbid SDR104 mode on the SDIO capable SDHCI controller. Without this the device cannot pass electromagnetic interference certifications. Fixes: 7109d817db2e ("arm64: dts: marvell: add DTS for Turris Mox") Signed-off-by: Marek Behún Cc: Gregory CLEMENT Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit a86306dbefc3bd8dca4c4437b7510dcb54825033 Author: Martin Wilck Date: Mon Apr 20 22:29:09 2020 +0200 dm mpath: switch paths in dm_blk_ioctl() code path [ Upstream commit 2361ae595352dec015d14292f1b539242d8446d6 ] SCSI LUN passthrough code such as qemu's "scsi-block" device model pass every IO to the host via SG_IO ioctls. Currently, dm-multipath calls choose_pgpath() only in the block IO code path, not in the ioctl code path (unless current_pgpath is NULL). This has the effect that no path switching and thus no load balancing is done for SCSI-passthrough IO, unless the active path fails. Fix this by using the same logic in multipath_prepare_ioctl() as in multipath_clone_and_map(). Note: The allegedly best path selection algorithm, service-time, still wouldn't work perfectly, because the io size of the current request is always set to 0. Changing that for the IO passthrough case would require the ioctl cmd and arg to be passed to dm's prepare_ioctl() method. Signed-off-by: Martin Wilck Reviewed-by: Hannes Reinecke Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit 08f396eb02c8e5adf8c933414627879ae39876e5 Author: Srinivas Kandagatla Date: Tue May 12 12:09:30 2020 +0100 misc: fastrpc: fix potential fastrpc_invoke_ctx leak [ Upstream commit 74003385cf716f1b88cc7753ca282f5493f204a2 ] fastrpc_invoke_ctx can have refcount of 2 in error path where rpmsg_send() fails to send invoke message. decrement the refcount properly in the error path to fix this leak. This also fixes below static checker warning: drivers/misc/fastrpc.c:990 fastrpc_internal_invoke() warn: 'ctx->refcount.refcount.ref.counter' not decremented on lines: 990. Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context") Reported-by: Dan Carpenter Signed-off-by: Srinivas Kandagatla Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/20200512110930.2550-1-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8d8991bb2bf042d46fe277d7a52adccdfc98b8eb Author: Srinivas Kandagatla Date: Mon May 11 17:27:22 2020 +0100 misc: fastrpc: Fix an incomplete memory release in fastrpc_rpmsg_probe() [ Upstream commit 0978de9fc7335c73934ab8fac189fb4cb3f23191 ] fastrpc_channel_ctx is not freed if misc_register() fails, this would lead to a memory leak. Fix this leak by adding kfree in misc_register() error path. Fixes: 278d56f970ae ("misc: fastrpc: Reference count channel context") Signed-off-by: Srinivas Kandagatla Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/20200511162722.2552-1-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c2ff1fcc2530a4e7bd2d7d660661dae3216681a9 Author: Serge Semin Date: Thu May 7 02:31:32 2020 +0300 serial: 8250: Fix max baud limit in generic 8250 port [ Upstream commit 7b668c064ec33f3d687c3a413d05e355172e6c92 ] Standard 8250 UART ports are designed in a way so they can communicate with baud rates up to 1/16 of a reference frequency. It's expected from most of the currently supported UART controllers. That's why the former version of serial8250_get_baud_rate() method called uart_get_baud_rate() with min and max baud rates passed as (port->uartclk / 16 / UART_DIV_MAX) and ((port->uartclk + tolerance) / 16) respectively. Doing otherwise, like it was suggested in commit ("serial: 8250_mtk: support big baud rate."), caused acceptance of bauds, which was higher than the normal UART controllers actually supported. As a result if some user-space program requested to set a baud greater than (uartclk / 16) it would have been permitted without truncation, but then serial8250_get_divisor(baud) (which calls uart_get_divisor() to get the reference clock divisor) would have returned a zero divisor. Setting zero divisor will cause an unpredictable effect varying from chip to chip. In case of DW APB UART the communications just stop. Lets fix this problem by getting back the limitation of (uartclk + tolerance) / 16 maximum baud supported by the generic 8250 port. Mediatek 8250 UART ports driver developer shouldn't have touched it in the first place notably seeing he already provided a custom version of set_termios() callback in that glue-driver which took into account the extended baud rate values and accordingly updated the standard and vendor-specific divisor latch registers anyway. Fixes: 81bb549fdf14 ("serial: 8250_mtk: support big baud rate.") Signed-off-by: Serge Semin Cc: Alexey Malahov Cc: Thomas Bogendoerfer Cc: Paul Burton Cc: Ralf Baechle Cc: Arnd Bergmann Cc: Long Cheng Cc: Andy Shevchenko Cc: Maxime Ripard Cc: Catalin Marinas Cc: Will Deacon Cc: Russell King Cc: linux-mips@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Link: https://lore.kernel.org/r/20200506233136.11842-2-Sergey.Semin@baikalelectronics.ru Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9e6a9201b78bc1926f38c92c5d0bab01895be7f4 Author: Oliver Neukum Date: Thu May 7 10:58:06 2020 +0200 usblp: poison URBs upon disconnect [ Upstream commit 296a193b06120aa6ae7cf5c0d7b5e5b55968026e ] syzkaller reported an URB that should have been killed to be active. We do not understand it, but this should fix the issue if it is real. Signed-off-by: Oliver Neukum Reported-by: syzbot+be5b5f86a162a6c281e6@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20200507085806.5793-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit cc9024f69ba7811293bd403f34e1a4d5b5807fd0 Author: Marek Szyprowski Date: Wed May 6 15:26:58 2020 +0200 clk: samsung: Mark top ISP and CAM clocks on Exynos542x as critical [ Upstream commit e47bd937e602bb4379546095d1bd0b9871fa60c2 ] The TOP 'aclk*_isp', 'aclk550_cam', 'gscl_wa' and 'gscl_wb' clocks must be kept enabled all the time to allow proper access to power management control for the ISP and CAM power domains. The last two clocks, although related to GScaler device and GSCL power domain, provides also the I_WRAP_CLK signal to MIPI CSIS0/1 devices, which are a part of CAM power domain and are needed for proper power on/off sequence. Currently there are no drivers for the devices, which are part of CAM and ISP power domains yet. This patch only fixes the race between disabling the unused power domains and disabling unused clocks, which randomly resulted in the following error during boot: Power domain CAM disable failed Power domain ISP disable failed Fixes: 318fa46cc60d ("clk/samsung: exynos542x: mark some clocks as critical") Signed-off-by: Marek Szyprowski Acked-by: Chanwoo Choi Signed-off-by: Sylwester Nawrocki Signed-off-by: Sasha Levin commit 2b5e61da68e880ab77c423b007a4df2f7deac8ab Author: Sibi Sankar Date: Wed Apr 15 12:46:18 2020 +0530 remoteproc: qcom_q6v5_mss: map/unmap mpss segments before/after use [ Upstream commit be050a3429f46ecf13eb2b80f299479f8bb823fb ] The application processor accessing the mpss region when the Q6 modem is running will lead to an XPU violation. Fix this by un-mapping the mpss segments post copy during mpss authentication and coredumps. Tested-by: Evan Green Signed-off-by: Sibi Sankar Link: https://lore.kernel.org/r/20200415071619.6052-1-sibis@codeaurora.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 8a44731af689d5571dcf43eecaf49e1b11ff6b97 Author: Russell King Date: Wed May 6 10:36:38 2020 +0100 i2c: pxa: clear all master action bits in i2c_pxa_stop_message() [ Upstream commit e81c979f4e071d516aa27cf5a0c3939da00dc1ca ] If we timeout during a message transfer, the control register may contain bits that cause an action to be set. Read-modify-writing the register leaving these bits set may trigger the hardware to attempt one of these actions unintentionally. Always clear these bits when cleaning up after a message or after a timeout. Signed-off-by: Russell King Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit ceb63ec0ef6e693d92a1befe0ddd07cda8043c72 Author: Konstantin Khlebnikov Date: Mon May 11 09:15:18 2020 +0300 f2fs: report delalloc reserve as non-free in statfs for project quota [ Upstream commit baaa7ebf25c78c5cb712fac16b7f549100beddd3 ] This reserved space isn't committed yet but cannot be used for allocations. For userspace it has no difference from used space. See the same fix in ext4 commit f06925c73942 ("ext4: report delalloc reserve as non-free in statfs for project quota"). Fixes: ddc34e328d06 ("f2fs: introduce f2fs_statfs_project") Signed-off-by: Konstantin Khlebnikov Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit ca90f67ece5c23304d57d18359b7af43c8052757 Author: Andreas Klinger Date: Mon May 4 20:10:34 2020 +0200 iio: bmp280: fix compensation of humidity [ Upstream commit dee2dabc0e4115b80945fe2c91603e634f4b4686 ] Limit the output of humidity compensation to the range between 0 and 100 percent. Depending on the calibration parameters of the individual sensor it happens, that a humidity above 100 percent or below 0 percent is calculated, which don't make sense in terms of relative humidity. Add a clamp to the compensation formula as described in the datasheet of the sensor in chapter 4.2.3. Although this clamp is documented, it was never in the driver of the kernel. It depends on the circumstances (calibration parameters, temperature, humidity) if one can see a value above 100 percent without the clamp. The writer of this patch was working with this type of sensor without noting this error. So it seems to be a rare event when this bug occures. Signed-off-by: Andreas Klinger Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 30bd1f36b6eb00bf9d96d83584e91b10e5f69dc4 Author: Qiushi Wu Date: Sun May 3 13:22:35 2020 -0500 rtc: mc13xxx: fix a double-unlock issue [ Upstream commit 8816cd726a4fee197af2d851cbe25991ae19ea14 ] In function mc13xxx_rtc_probe, the mc13xxx_unlock() is called before rtc_register_device(). But in the error path of rtc_register_device(), the mc13xxx_unlock() is called again, which causes a double-unlock problem. Thus add a call of the function “mc13xxx_lock” in an if branch for the completion of the exception handling. Fixes: e4ae7023e182a ("rtc: mc13xxx: set range") Signed-off-by: Qiushi Wu Link: https://lore.kernel.org/r/20200503182235.1652-1-wu000273@umn.edu Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 91fce7922a756127ad2aaea6cce87a95f71f5a4c Author: Christophe Leroy Date: Wed Apr 8 15:58:49 2020 +0000 powerpc/kasan: Fix stack overflow by increasing THREAD_SHIFT [ Upstream commit edbadaf0671072298e506074128b64e003c5812c ] When CONFIG_KASAN is selected, the stack usage is increased. In the same way as x86 and arm64 architectures, increase THREAD_SHIFT when CONFIG_KASAN is selected. Fixes: 2edb16efc899 ("powerpc/32: Add KASAN support") Reported-by: Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://bugzilla.kernel.org/show_bug.cgi?id=207129 Link: https://lore.kernel.org/r/2c50f3b1c9bbaa4217c9a98f3044bd2a36c46a4f.1586361277.git.christophe.leroy@c-s.fr Signed-off-by: Sasha Levin commit a6a0317bf9c2f1604f50a389b6711c53509e5e0d Author: Marco Felsch Date: Sat May 9 14:34:35 2020 -0700 Input: edt-ft5x06 - fix get_default register write access [ Upstream commit 255cdaf73412de13608fb776101402dca68bed2b ] Since commit b6eba86030bf ("Input: edt-ft5x06 - add offset support for ev-ft5726") offset-x and offset-y is supported. Devices using those offset parameters don't support the offset parameter so we need to add the NO_REGISTER check for edt_ft5x06_ts_get_defaults(). Fixes: b6eba86030bf ("Input: edt-ft5x06 - add offset support for ev-ft5726") Signed-off-by: Marco Felsch Link: https://lore.kernel.org/r/20200227112819.16754-2-m.felsch@pengutronix.de Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 70a2296d4bab858b69bff11f447740a11511d4f4 Author: Viacheslav Dubeyko Date: Wed Apr 22 13:55:52 2020 +0300 scsi: qla2xxx: Fix issue with adapter's stopping state [ Upstream commit 803e45550b11c8e43d89812356fe6f105adebdf9 ] The goal of the following command sequence is to restart the adapter. However, the tgt_stop flag remains set, indicating that the adapter is still in stopping state even after re-enabling it. echo 0x7fffffff > /sys/module/qla2xxx/parameters/logging modprobe target_core_mod modprobe tcm_qla2xxx mkdir /sys/kernel/config/target/qla2xxx mkdir /sys/kernel/config/target/qla2xxx/ mkdir /sys/kernel/config/target/qla2xxx//tpgt_1 echo 1 > /sys/kernel/config/target/qla2xxx//tpgt_1/enable echo 0 > /sys/kernel/config/target/qla2xxx//tpgt_1/enable echo 1 > /sys/kernel/config/target/qla2xxx//tpgt_1/enable kernel: PID 1396:qla_target.c:1555 qlt_stop_phase1(): tgt_stop 0x0, tgt_stopped 0x0 kernel: qla2xxx [0001:00:02.0]-e803:1: PID 1396:qla_target.c:1567: Stopping target for host 1(c0000000033557e8) kernel: PID 1396:qla_target.c:1579 qlt_stop_phase1(): tgt_stop 0x1, tgt_stopped 0x0 kernel: PID 1396:qla_target.c:1266 qlt_schedule_sess_for_deletion(): tgt_stop 0x1, tgt_stopped 0x0 kernel: qla2xxx [0001:00:02.0]-e801:1: PID 1396:qla_target.c:1316: Scheduling sess c00000002d5cd800 for deletion 21:00:00:24:ff:7f:35:c7 kernel: qla2xxx [0001:00:02.0]-290a:1: PID 340:qla_target.c:1187: qlt_unreg_sess sess c00000002d5cd800 for deletion 21:00:00:24:ff:7f:35:c7 kernel: qla2xxx [0001:00:02.0]-f801:1: PID 340:qla_target.c:1145: Unregistration of sess c00000002d5cd800 21:00:00:24:ff:7f:35:c7 finished fcp_cnt 0 kernel: PID 340:qla_target.c:1155 qlt_free_session_done(): tgt_stop 0x1, tgt_stopped 0x0 kernel: qla2xxx [0001:00:02.0]-4807:1: PID 346:qla_os.c:6329: ISP abort scheduled. kernel: qla2xxx [0001:00:02.0]-28f1:1: PID 346:qla_os.c:3956: Mark all dev lost kernel: PID 346:qla_target.c:1266 qlt_schedule_sess_for_deletion(): tgt_stop 0x1, tgt_stopped 0x0 kernel: qla2xxx [0001:00:02.0]-4808:1: PID 346:qla_os.c:6338: ISP abort end. kernel: PID 1396:qla_target.c:6812 qlt_enable_vha(): tgt_stop 0x1, tgt_stopped 0x0 kernel: qla2xxx [0001:00:02.0]-4807:1: PID 346:qla_os.c:6329: ISP abort scheduled. kernel: qla2xxx [0001:00:02.0]-4808:1: PID 346:qla_os.c:6338: ISP abort end. qlt_handle_cmd_for_atio() rejects the request to send commands because the adapter is in the stopping state: kernel: PID 0:qla_target.c:4442 qlt_handle_cmd_for_atio(): tgt_stop 0x1, tgt_stopped 0x0 kernel: qla2xxx [0001:00:02.0]-3861:1: PID 0:qla_target.c:4447: New command while device c000000005314600 is shutting down kernel: qla2xxx [0001:00:02.0]-e85f:1: PID 0:qla_target.c:5728: qla_target: Unable to send command to target This patch calls qla_stop_phase2() in addition to qlt_stop_phase1() in tcm_qla2xxx_tpg_enable_store() and tcm_qla2xxx_npiv_tpg_enable_store(). The qlt_stop_phase1() marks adapter as stopping (tgt_stop == 0x1, tgt_stopped == 0x0) but qlt_stop_phase2() marks adapter as stopped (tgt_stop == 0x0, tgt_stopped == 0x1). Link: https://lore.kernel.org/r/52be1e8a3537f6c5407eae3edd4c8e08a9545ea5.camel@yadro.com Reviewed-by: Roman Bolshakov Reviewed-by: Himanshu Madhani Signed-off-by: Viacheslav Dubeyko Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 5800b7f7d2316d0defc5288eb62907460dd275e1 Author: Ard Biesheuvel Date: Tue Apr 21 18:22:56 2020 +0200 PCI: Allow pci_resize_resource() for devices on root bus [ Upstream commit d09ddd8190fbdc07696bf34b548ae15aa1816714 ] When resizing a BAR, pci_reassign_bridge_resources() is invoked to bring the bridge windows of parent bridges in line with the new BAR assignment. This assumes the device whose BAR is being resized lives on a subordinate bus, but this is not necessarily the case. A device may live on the root bus, in which case dev->bus->self is NULL, and passing a NULL pci_dev pointer to pci_reassign_bridge_resources() will cause it to crash. So let's make the call to pci_reassign_bridge_resources() conditional on whether dev->bus->self is non-NULL in the first place. Fixes: 8bb705e3e79d84e7 ("PCI: Add pci_resize_resource() for resizing BARs") Link: https://lore.kernel.org/r/20200421162256.26887-1-ardb@kernel.org Signed-off-by: Ard Biesheuvel Signed-off-by: Bjorn Helgaas Reviewed-by: Christian König Signed-off-by: Sasha Levin commit 956a2e737a2c2ffeec4f0c67c36d4670c9ba0cd6 Author: Dan Carpenter Date: Fri May 1 12:40:11 2020 +0300 ALSA: isa/wavefront: prevent out of bounds write in ioctl [ Upstream commit 7f0d5053c5a9d23fe5c2d337495a9d79038d267b ] The "header->number" comes from the ioctl and it needs to be clamped to prevent out of bounds writes. Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/20200501094011.GA960082@mwanda Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 23337efa940c0f27835e92d46b27bad1e0816f79 Author: Kai-Heng Feng Date: Thu Apr 30 16:32:51 2020 +0800 ALSA: hda/realtek - Introduce polarity for micmute LED GPIO [ Upstream commit dbd13179780555ecd3c992dea1222ca31920e892 ] Currently mute LED and micmute LED share the same GPIO polarity. So split the polarity for mute and micmute, in case they have different polarities. Signed-off-by: Kai-Heng Feng Link: https://lore.kernel.org/r/20200430083255.5093-1-kai.heng.feng@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 66a177ae4ed06e10decc9aa1741441fb439d85d9 Author: Neil Armstrong Date: Thu Mar 26 17:59:55 2020 +0100 arm64: dts: meson: fixup SCP sram nodes [ Upstream commit 9ecded10b4b6af238da0c86197b0418912e7513e ] The GX and AXG SCP sram nodes were using invalid compatible and node names for the sram entries. Fixup the sram entries node names, and use proper compatible for them. It notably fixes: sram@c8000000: 'scp-shmem@0', 'scp-shmem@200' do not match any of the regexes: '^([a-z]*-)?sram(-section)?@[a-f0-9]+$', 'pinctrl-[0-9]+' Signed-off-by: Neil Armstrong Signed-off-by: Kevin Hilman Link: https://lore.kernel.org/r/20200326165958.19274-3-narmstrong@baylibre.com Signed-off-by: Sasha Levin commit 7631dc491a3f3323eaf93e6f18f4fa268f15b2ca Author: Dan Carpenter Date: Tue Apr 28 16:19:39 2020 +0300 scsi: qedi: Check for buffer overflow in qedi_set_path() [ Upstream commit 4a4c0cfb4be74e216dd4446b254594707455bfc6 ] Smatch complains that the "path_data->handle" variable is user controlled. It comes from iscsi_set_path() so that seems possible. It's harmless to add a limit check. The qedi->ep_tbl[] array has qedi->max_active_conns elements (which is always ISCSI_MAX_SESS_PER_HBA (4096) elements). The array is allocated in the qedi_cm_alloc_mem() function. Link: https://lore.kernel.org/r/20200428131939.GA696531@mwanda Fixes: ace7f46ba5fd ("scsi: qedi: Add QLogic FastLinQ offload iSCSI driver framework.") Acked-by: Manish Rangankar Signed-off-by: Dan Carpenter Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 545b86efa0d06e4f8f74fb11b658a1e618103ee7 Author: Johannes Thumshirn Date: Tue Apr 28 19:45:55 2020 +0900 scsi: core: free sgtables in case command setup fails [ Upstream commit 20a66f2bf280277ab5bb22e27445153b4eb0ac88 ] In case scsi_setup_fs_cmnd() fails we're not freeing the sgtables allocated by scsi_init_io(), thus we leak the allocated memory. Free the sgtables allocated by scsi_init_io() in case scsi_setup_fs_cmnd() fails. Technically scsi_setup_scsi_cmnd() does not suffer from this problem as it can only fail if scsi_init_io() fails, so it does not have sgtables allocated. But to maintain symmetry and as a measure of defensive programming, free the sgtables on scsi_setup_scsi_cmnd() failure as well. scsi_mq_free_sgtables() has safeguards against double-freeing of memory so this is safe to do. While we're at it, rename scsi_mq_free_sgtables() to scsi_free_sgtables(). Link: https://bugzilla.kernel.org/show_bug.cgi?id=205595 Link: https://lore.kernel.org/r/20200428104605.8143-2-johannes.thumshirn@wdc.com Reviewed-by: Christoph Hellwig Reviewed-by: Daniel Wagner Reviewed-by: Hannes Reinecke Signed-off-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit bde2d5d443c436a046591521d50441e2d1020150 Author: Marek Vasut Date: Wed Apr 22 12:45:58 2020 +0200 ARM: dts: stm32: Add missing ethernet PHY reset on AV96 [ Upstream commit 010ca9fe500bfe365860b50220ff80541c18f0e1 ] Add PHY reset GPIO on AV96 ethernet PHY. Reviewed-by: Manivannan Sadhasivam Signed-off-by: Marek Vasut Cc: Alexandre Torgue Cc: Manivannan Sadhasivam Cc: Maxime Coquelin Cc: Patrice Chotard Cc: Patrick Delaunay Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit 38ede4d7736ee504c62325fc3e1486a514d719c1 Author: Linus Walleij Date: Thu Feb 13 15:27:54 2020 +0100 ARM: integrator: Add some Kconfig selections [ Upstream commit d2854bbe5f5c4b4bec8061caf4f2e603d8819446 ] The CMA and DMA_CMA Kconfig options need to be selected by the Integrator in order to produce boot console on some Integrator systems. The REGULATOR and REGULATOR_FIXED_VOLTAGE need to be selected in order to boot the system from an external MMC card when using MMCI/PL181 from the device tree probe path. Select these things directly from the Kconfig so we are sure to be able to bring the systems up with console from any device tree. Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit a1359b9fdd8d8748ae20c5a78ece513a2d4e9691 Author: Xiyu Yang Date: Sat Apr 25 20:48:35 2020 +0800 ASoC: davinci-mcasp: Fix dma_chan refcnt leak when getting dma type [ Upstream commit a697ae6ea56e23397341b027098c1b11d9ab13da ] davinci_mcasp_get_dma_type() invokes dma_request_chan(), which returns a reference of the specified dma_chan object to "chan" with increased refcnt. When davinci_mcasp_get_dma_type() returns, local variable "chan" becomes invalid, so the refcount should be decreased to keep refcount balanced. The reference counting issue happens in one exception handling path of davinci_mcasp_get_dma_type(). When chan device is NULL, the function forgets to decrease the refcnt increased by dma_request_chan(), causing a refcnt leak. Fix this issue by calling dma_release_channel() when chan device is NULL. Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Acked-by: Peter Ujfalusi Link: https://lore.kernel.org/r/1587818916-38730-1-git-send-email-xiyuyang19@fudan.edu.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8908c555e06e5ccb56869a405d9e22caffad646c Author: Yoshihiro Shimoda Date: Tue Apr 21 18:35:56 2020 +0900 ARM: dts: renesas: Fix IOMMU device node names [ Upstream commit ae990a1de014396ffc8d0fcc31b6888c9b0ce59a ] Fix IOMMU device node names as "iommu@". Fixes: bbb44da0b595 ("ARM: dts: r8a7743: Add IPMMU DT nodes") Fixes: 0dcba3de5835 ("ARM: dts: r8a7745: Add IPMMU DT nodes") Fixes: 350ae49b97c4 ("ARM: dts: r8a7744: Add IPMMU DT nodes") Fixes: 70496727c082 ("ARM: shmobile: r8a7790: Add IPMMU DT nodes") Fixes: f1951852ed17 ("ARM: shmobile: r8a7791: Add IPMMU DT nodes") Fixes: 098cb3a601e6 ("ARM: shmobile: r8a7793: Add IPMMU nodes") Fixes: 1cb2794f6082 ("ARM: shmobile: r8a7794: Add IPMMU DT nodes") Signed-off-by: Yoshihiro Shimoda Reviewed-by: Niklas Söderlund Link: https://lore.kernel.org/r/1587461756-13317-1-git-send-email-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 2c40fc80331be6ac3e7ab61b39073ad28081a67b Author: Jon Hunter Date: Mon Feb 24 14:07:48 2020 +0000 backlight: lp855x: Ensure regulators are disabled on probe failure [ Upstream commit d8207c155a7c6015eb7f43739baa7dfb1fa638af ] If probing the LP885x backlight fails after the regulators have been enabled, then the following warning is seen when releasing the regulators ... WARNING: CPU: 1 PID: 289 at drivers/regulator/core.c:2051 _regulator_put.part.28+0x158/0x160 Modules linked in: tegra_xudc lp855x_bl(+) host1x pwm_tegra ip_tables x_tables ipv6 nf_defrag_ipv6 CPU: 1 PID: 289 Comm: systemd-udevd Not tainted 5.6.0-rc2-next-20200224 #1 Hardware name: NVIDIA Jetson TX1 Developer Kit (DT) ... Call trace: _regulator_put.part.28+0x158/0x160 regulator_put+0x34/0x50 devm_regulator_release+0x10/0x18 release_nodes+0x12c/0x230 devres_release_all+0x34/0x50 really_probe+0x1c0/0x370 driver_probe_device+0x58/0x100 device_driver_attach+0x6c/0x78 __driver_attach+0xb0/0xf0 bus_for_each_dev+0x68/0xc8 driver_attach+0x20/0x28 bus_add_driver+0x160/0x1f0 driver_register+0x60/0x110 i2c_register_driver+0x40/0x80 lp855x_driver_init+0x20/0x1000 [lp855x_bl] do_one_initcall+0x58/0x1a0 do_init_module+0x54/0x1d0 load_module+0x1d80/0x21c8 __do_sys_finit_module+0xe8/0x100 __arm64_sys_finit_module+0x18/0x20 el0_svc_common.constprop.3+0xb0/0x168 do_el0_svc+0x20/0x98 el0_sync_handler+0xf4/0x1b0 el0_sync+0x140/0x180 Fix this by ensuring that the regulators are disabled, if enabled, on probe failure. Finally, ensure that the vddio regulator is disabled in the driver remove handler. Signed-off-by: Jon Hunter Reviewed-by: Daniel Thompson Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 53057bd4ac84fe6bc18982d413123d7be0b4c1aa Author: Shengjiu Wang Date: Mon Apr 27 14:23:21 2020 +0800 ASoC: fsl_esai: Disable exception interrupt before scheduling tasklet [ Upstream commit 1fecbb71fe0e46b886f84e3b6decca6643c3af6d ] Disable exception interrupt before scheduling tasklet, otherwise if the tasklet isn't handled immediately, there will be endless xrun interrupt. Fixes: 7ccafa2b3879 ("ASoC: fsl_esai: recover the channel swap after xrun") Signed-off-by: Shengjiu Wang Acked-by: Nicolin Chen Link: https://lore.kernel.org/r/a8f2ad955aac9e52587beedc1133b3efbe746895.1587968824.git.shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b543c3595188c55b49a2dc0d103d0811a13dc5ad Author: Bryan O'Donoghue Date: Sun Mar 29 13:41:16 2020 +0100 clk: qcom: msm8916: Fix the address location of pll->config_reg [ Upstream commit f47ab3c2f5338828a67e89d5f688d2cef9605245 ] During the process of debugging a processor derived from the msm8916 which we found the new processor was not starting one of its PLLs. After tracing the addresses and writes that downstream was doing and comparing to upstream it became obvious that we were writing to a different register location than downstream when trying to configure the PLL. This error is also present in upstream msm8916. As an example clk-pll.c::clk_pll_recalc_rate wants to write to pll->config_reg updating the bit-field POST_DIV_RATIO. That bit-field is defined in PLL_USER_CTL not in PLL_CONFIG_CTL. Taking the BIMC PLL as an example lm80-p0436-13_c_qc_snapdragon_410_processor_hrd.pdf 0x01823010 GCC_BIMC_PLL_USER_CTL 0x01823014 GCC_BIMC_PLL_CONFIG_CTL This pattern is repeated for gpll0, gpll1, gpll2 and bimc_pll. This error is likely not apparent since the bootloader will already have initialized these PLLs. This patch corrects the location of config_reg from PLL_CONFIG_CTL to PLL_USER_CTL for all relevant PLLs on msm8916. Fixes commit 3966fab8b6ab ("clk: qcom: Add MSM8916 Global Clock Controller support") Cc: Georgi Djakov Cc: Andy Gross Cc: Bjorn Andersson Cc: Michael Turquette Cc: Stephen Boyd Signed-off-by: Bryan O'Donoghue Link: https://lkml.kernel.org/r/20200329124116.4185447-1-bryan.odonoghue@linaro.org Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 7906a075c900c657ec4ef460a44a4e1099d7edad Author: Alex Elder Date: Wed Apr 15 14:48:52 2020 -0600 remoteproc: Fix IDR initialisation in rproc_alloc() [ Upstream commit 6442df49400b466431979e7634849a464a5f1861 ] If ida_simple_get() returns an error when called in rproc_alloc(), put_device() is called to clean things up. By this time the rproc device type has been assigned, with rproc_type_release() as the release function. The first thing rproc_type_release() does is call: idr_destroy(&rproc->notifyids); But at the time the ida_simple_get() call is made, the notifyids field in the remoteproc structure has not been initialized. I'm not actually sure this case causes an observable problem, but it's incorrect. Fix this by initializing the notifyids field before calling ida_simple_get() in rproc_alloc(). Fixes: b5ab5e24e960 ("remoteproc: maintain a generic child device for each rproc") Signed-off-by: Alex Elder Reviewed-by: Mathieu Poirier Reviewed-by: Suman Anna Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/20200415204858.2448-2-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 8bd207bb1a257371bb47b07aff557af2b0efcb6e Author: Andy Shevchenko Date: Mon Mar 23 12:41:25 2020 +0200 iio: pressure: bmp280: Tolerate IRQ before registering [ Upstream commit 97b31a6f5fb95b1ec6575b78a7240baddba34384 ] With DEBUG_SHIRQ enabled we have a kernel crash [ 116.482696] BUG: kernel NULL pointer dereference, address: 0000000000000000 ... [ 116.606571] Call Trace: [ 116.609023] [ 116.611047] complete+0x34/0x50 [ 116.614206] bmp085_eoc_irq+0x9/0x10 [bmp280] because DEBUG_SHIRQ mechanism fires an IRQ before registration and drivers ought to be able to handle an interrupt happening before request_irq() returns. Fixes: aae953949651 ("iio: pressure: bmp280: add support for BMP085 EOC interrupt") Signed-off-by: Andy Shevchenko Acked-by: Linus Walleij Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 2e714a547ef862719bd15d20a048aed4606fe640 Author: YueHaibing Date: Thu Apr 9 10:18:28 2020 +0300 ASoC: SOF: imx8: Fix randbuild error [ Upstream commit fe17e6cdc0fefca96ba9659be4b2b07487cbf0c5 ] when do randconfig like this: CONFIG_SND_SOC_SOF_IMX8_SUPPORT=y CONFIG_SND_SOC_SOF_IMX8=y CONFIG_SND_SOC_SOF_OF=y CONFIG_IMX_DSP=m CONFIG_IMX_SCU=y there is a link error: sound/soc/sof/imx/imx8.o: In function 'imx8_send_msg': imx8.c:(.text+0x380): undefined reference to 'imx_dsp_ring_doorbell' Select IMX_DSP in SND_SOC_SOF_IMX8_SUPPORT to fix this Fixes: f9ad75468453 ("ASoC: SOF: imx: fix reverse CONFIG_SND_SOC_SOF_OF dependency") Reported-by: Hulk Robot Signed-off-by: YueHaibing Signed-off-by: Daniel Baluta Link: https://lore.kernel.org/r/20200409071832.2039-2-daniel.baluta@oss.nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit dc570a1fb48c1214193b154fb6cf083d1121a551 Author: Adam Honse Date: Fri Apr 10 15:48:44 2020 -0500 i2c: piix4: Detect secondary SMBus controller on AMD AM4 chipsets [ Upstream commit f27237c174fd9653033330e4e532cd9d153ce824 ] The AMD X370 and other AM4 chipsets (A/B/X 3/4/5 parts) and Threadripper equivalents have a secondary SMBus controller at I/O port address 0x0B20. This bus is used by several manufacturers to control motherboard RGB lighting via embedded controllers. I have been using this bus in my OpenRGB project to control the Aura RGB on many motherboards and ASRock also uses this bus for their Polychrome RGB controller. I am not aware of any CZ-compatible platforms which do not have the second SMBus channel. All of AMD's AM4- and Threadripper- series chipsets that OpenRGB users have tested appear to have this secondary bus. I also noticed this secondary bus is present on older AMD platforms including my FM1 home server. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202587 Signed-off-by: Adam Honse Reviewed-by: Jean Delvare Reviewed-by: Sebastian Reichel Tested-by: Sebastian Reichel Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 30e82a3edd9475a78cadabe22ad2d4899a14fa71 Author: Dmitry Osipenko Date: Mon Mar 30 23:40:11 2020 +0300 ASoC: tegra: tegra_wm8903: Support nvidia, headset property [ Upstream commit 3ef9d5073b552d56bd6daf2af1e89b7e8d4df183 ] The microphone-jack state needs to be masked in a case of a 4-pin jack when microphone and ground pins are shorted. Presence of nvidia,headset tells that WM8903 CODEC driver should mask microphone's status if short circuit is detected, i.e headphones are inserted. Signed-off-by: Dmitry Osipenko Link: https://lore.kernel.org/r/20200330204011.18465-3-digetx@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7b139b714a5d6f0a4fd1f23d85ba09d756f1967a Author: Rikard Falkeborn Date: Tue Mar 17 22:13:32 2020 +0100 clk: sunxi: Fix incorrect usage of round_down() [ Upstream commit ee25d9742dabed3fd18158b518f846abeb70f319 ] round_down() can only round to powers of 2. If round_down() is asked to round to something that is not a power of 2, incorrect results are produced. The incorrect results can be both too large and too small. Instead, use rounddown() which can round to any number. Fixes: 6a721db180a2 ("clk: sunxi: Add A31 clocks support") Signed-off-by: Rikard Falkeborn Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit 8aa822a1305c61047567dff8336614b5702264ba Author: Enric Balletbo i Serra Date: Mon Apr 13 16:10:51 2020 +0200 power: supply: bq24257_charger: Replace depends on REGMAP_I2C with select [ Upstream commit 87c3d579c8ed0eaea6b1567d529a8daa85a2bc6c ] regmap is a library function that gets selected by drivers that need it. No driver modules should depend on it. Depending on REGMAP_I2C makes this driver only build if another driver already selected REGMAP_I2C, as the symbol can't be selected through the menu kernel configuration. Fixes: 2219a935963e ("power_supply: Add TI BQ24257 charger driver") Signed-off-by: Enric Balletbo i Serra Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 220a93eef6d4da6ee60f004eb7608ea4d5902bed Author: Alexandre Frade Date: Tue Jun 23 18:17:56 2020 -0300 Linux 5.4.48-xanmod1 Signed-off-by: Alexandre Frade commit 40ff03ec19dfbfcf6e0d45bac1820f857af0fbd9 Merge: cffcb9a5a38e 67cb016870e2 Author: Alexandre Frade Date: Tue Jun 23 18:16:20 2020 -0300 Merge tag 'v5.4.48' into 5.4 This is the 5.4.48 stable release