commit df4674d89f7e2b4ff5da6f2f52196d92bf569d6e Author: Sasha Levin Date: Tue Jun 30 16:26:01 2020 -0400 Linux 4.9.229 Signed-off-by: Sasha Levin commit c496fa72719c68637bf243d148d199f4adf02cae 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 2bda23ca5b8186f7906dd29efd1c773bb8b84098 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 5c85c81e86340c50101fb03e9095150d64a0bf99 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 86dfbc17a336905d53835a532c85aa424e25ca0d 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 a20cecece4c3fd6d9a11a221a4f183585e14ce70 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 04e6e060f07300f7a28c563b30d2cc430a0d9035 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 6d3468bd18d80b15f176e841ef60c99c8f3ee3cd 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 587287ce2af409246f890e102e54eaf0bedff22c 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 661a55328d45ed53600af2bf37b6893208a9a6ac 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 d09a61a9351e08da2b55e0542fd0112f2c59c444 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 5257ba36ded597a1600178f7d3fd3ca211d6950b 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 8b3f61571addef86971be07a73c5422e96b3a646 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 b581a11955ffac4e95af1d252357ed1c8bc26c84 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 e3bca0f35bd49b4cb4fc7c6beee9ef8cd7c171f2 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 2523f245a49bad06d7df717fd31e6c0a2c6f38bf 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 981bcb1dd58394cf4ed487900bd0dce4f13543a7 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 c032e65b075931ffbfcf3423bfa8efdd60f2e4b8 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 48427c3b9446170d1a5ad1864fbc12e8d014c953 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 31a2029da4543a33beafd0795d441124e58ac33a 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 70a5b8b3abf5ac2c3abfd3f21929586c7ca6bf8d 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 5fef1b319466387f7dafa89879c90d03919286c9 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 37b31f4f67c2054f38ea6896b2b4d084dd14de53 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 6423d903eb4b09a913899ca4dbad801c97f0eafe 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 19a197ffb4006e07f0c0c6fdf7f1f963f511903f 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 6edb24f20ac8c9a7291a1718ad5aaa1623c086c3 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 386907cf96e1d2594c1c60ad2ab34f9ba4989dc0 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 6a7cfbd6f5638e0f8fdf71a24f164314cc55a255 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 ea6eb20cfeb4d94dea14c740812cca64bc0b89d4 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 79eb4f02c23a090b8c06002d33392c2191fb6110 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 83fc0cb8db7adf36a75f6cf55820ee386721bd1b 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 7e2632caa9b4591aa82fbba57f3b927552545f92 Author: Zhang Xiaoxu Date: Tue Jun 23 07:31:54 2020 -0400 cifs/smb3: Fix data inconsistent when zero file range [ Upstream commit 6b69040247e14b43419a520f841f2b3052833df9 ] 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: Sasha Levin commit 2306f6355d2a5933f6a032e8e4e8add193bba87a Author: Zhang Xiaoxu Date: Tue Jun 23 07:31:53 2020 -0400 cifs/smb3: Fix data inconsistent when punch hole [ Upstream commit acc91c2d8de4ef46ed751c5f9df99ed9a109b100 ] 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: Sasha Levin commit dfa2cacd9f4811982d9d450fb0bf07526f56e9a2 Author: Kai-Heng Feng Date: Wed Jun 24 16:59:49 2020 +0300 xhci: Poll for U0 after disabling USB2 LPM [ Upstream commit b3d71abd135e6919ca0b6cab463738472653ddfb ] 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 Signed-off-by: Sasha Levin commit f05360bfb9befa74e661bed1d882b969f67c0a4f Author: Takashi Iwai Date: Wed Jun 24 14:23:40 2020 +0200 ALSA: usb-audio: Fix OOB access of mixer element list [ Upstream commit 220345e98f1cdc768eeb6e3364a0fa7ab9647fe7 ] 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: Sasha Levin commit 380006c7c1e366b3d0aef666ade254e193aa1947 Author: Takashi Iwai Date: Thu May 3 12:33:32 2018 +0200 ALSA: usb-audio: Clean up mixer element list traverse [ Upstream commit 8c558076c740e8009a96c6fdc3d4245dde62be77 ] Introduce a new macro for iterating over mixer element list for avoiding the open codes in many places. Also the open-coded container_of() and the forced cast to struct usb_mixer_elem_info are replaced with another simple macro, too. No functional changes but just readability improvement. Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 65f4bed11018b6538a363bab1a122b77082ab898 Author: Julian Scheel Date: Thu Nov 16 17:35:17 2017 +0100 ALSA: usb-audio: uac1: Invalidate ctl on interrupt [ Upstream commit b2500b584cfd228d67e1e43daf27c8af865b499e ] When an interrupt occurs, the value of at least one of the belonging controls should have changed. To make sure they get re-read from device on the next read, invalidate the cache. This was correctly implemented for uac2 already, but missing for uac1. Signed-off-by: Julian Scheel Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 8de06e1d3b21c23b4eb9362d82557db6bbe18774 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 dbf2c1a8a2baa68aaa9862e02c34f31c55478055 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 f0a2a8d0add7403cb3f5b9b0d1fd948703760190 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 fc652867977abdc069aff38eabf307ec676453ef 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 6119a89ab578f25177e9c7d61911aeadbc5fa903 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 469adc4cd95ac84af50a318f94ea8f91aeab9180 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 4813288a617662c5c4f630f71ef82a472a35ea8c 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 aedf21cf521c28e5a04500045e230f5bdc0a7677 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 b680168bd6d720deaa3c790951601c8574a025e5 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 6aa66b715392942c9b59cc155aa4487099da495c 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 673212158fc97950d8f9f512e28e1bb275aad463 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 6ac341cec7ade44abb9dea90e6b1f142e4231740 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 5030f6682450a156ebcdea17f26e9a324bf73aec 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 05cc8235420a3c6ae1d2f9890cce7b46e591a3a4 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 743475d91540738deeb738ab14736eb39eb06c07 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 98d3884bfa8719abbd604f35446bc3a82607e17b 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 ae1c468be6fa4dfdf00d9bd4d93d4bf1f437af33 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 b6e5086cec1cbffc20a9e122882a83bf3ecf745a 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 5e43d1cbe3b91e439c1eab631a0c9380b37a6d20 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 31dc204489e35ea00d30e3d0ef52c39c488ab14b 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 6c8b6312d63f6ee42e8a25a6a4c739f7a4777bc3 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 40b56938e09cb48f797ff01fb97f841fef531f04 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 d2c7abe770bb638682e657750860c105fc88afe8 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 307fa7afd3f7f8852e637303cc265298c9463296 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 026305903c47c61a876ef03ec3f5a9b7c5f4ef8f 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 cb6f92ed839f2efbff7a6369a42f0d3b7a9f8268 Author: Ridge Kennedy Date: Tue Feb 4 12:24:00 2020 +1300 l2tp: Allow duplicate session creation with UDP commit 0d0d9a388a858e271bb70e71e99e7fe2a6fd6f64 upstream. In the past it was possible to create multiple L2TPv3 sessions with the same session id as long as the sessions belonged to different tunnels. The resulting sessions had issues when used with IP encapsulated tunnels, but worked fine with UDP encapsulated ones. Some applications began to rely on this behaviour to avoid having to negotiate unique session ids. Some time ago a change was made to require session ids to be unique across all tunnels, breaking the applications making use of this "feature". This change relaxes the duplicate session id check to allow duplicates if both of the colliding sessions belong to UDP encapsulated tunnels. Fixes: dbdbc73b4478 ("l2tp: fix duplicate session creation") Signed-off-by: Ridge Kennedy Acked-by: James Chapman Signed-off-by: David S. Miller Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit ec0bdc2824e7358988dec46dedf01a851832ebcc Author: Martin Wilck Date: Mon Nov 27 23:47:34 2017 +0100 scsi: scsi_devinfo: handle non-terminated strings commit ba69ead9e9e9bb3cec5faf03526c36764ac8942a upstream. devinfo->vendor and devinfo->model aren't necessarily zero-terminated. Fixes: b8018b973c7c "scsi_devinfo: fixup string compare" Signed-off-by: Martin Wilck Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit b17fd5fbdd1f2323bf9ea93f1aee9e4d9895618d Author: Miquel Raynal Date: Tue May 19 15:00:29 2020 +0200 mtd: rawnand: tmio: Fix the probe error path [ Upstream commit 75e9a330a9bd48f97a55a08000236084fe3dae56 ] nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead. There is no real Fixes tag applying here as the use of nand_release() in this driver predates by far the introduction of nand_cleanup() in commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible. However, pointing this commit as the culprit for backporting purposes makes sense even if this commit is not introducing any bug. Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") Signed-off-by: Miquel Raynal Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-57-miquel.raynal@bootlin.com Signed-off-by: Sasha Levin commit fb8233bc7f6ff263527d17228a5f48dc32688cf6 Author: Miquel Raynal Date: Tue May 19 15:00:00 2020 +0200 mtd: rawnand: mtk: Fix the probe error path [ Upstream commit 8a82bbcadec877f5f938c54026278dfc1f05a332 ] nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead. There is no real Fixes tag applying here as the use of nand_release() in this driver predates the introduction of nand_cleanup() in commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible. However, pointing this commit as the culprit for backporting purposes makes sense even if this commit is not introducing any bug. Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") Signed-off-by: Miquel Raynal Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-28-miquel.raynal@bootlin.com Signed-off-by: Sasha Levin commit f8183c7642fa18108d5c0a9033ce51cdc17f03a1 Author: Miquel Raynal Date: Tue May 19 15:00:15 2020 +0200 mtd: rawnand: plat_nand: Fix the probe error path [ Upstream commit 5284024b4dac5e94f7f374ca905c7580dbc455e9 ] nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead. There is no real Fixes tag applying here as the use of nand_release() in this driver predates by far the introduction of nand_cleanup() in commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible, hence pointing it as the commit to fix for backporting purposes, even if this commit is not introducing any bug. Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") Signed-off-by: Miquel Raynal Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-43-miquel.raynal@bootlin.com Signed-off-by: Sasha Levin commit 4f9c0479242399ba65d45fce145a3644f2db4f12 Author: Miquel Raynal Date: Tue May 19 15:00:23 2020 +0200 mtd: rawnand: socrates: Fix the probe error path [ Upstream commit 9c6c2e5cc77119ce0dacb4f9feedb73ce0354421 ] nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead. There is no real Fixes tag applying here as the use of nand_release() in this driver predates by far the introduction of nand_cleanup() in commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible. However, pointing this commit as the culprit for backporting purposes makes sense even if this commit is not introducing any bug. Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") Signed-off-by: Miquel Raynal Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-51-miquel.raynal@bootlin.com Signed-off-by: Sasha Levin commit a2db51da7f315d57a346f6f69f43522ba64aa2f1 Author: Miquel Raynal Date: Tue May 19 15:00:06 2020 +0200 mtd: rawnand: orion: Fix the probe error path [ Upstream commit be238fbf78e4c7c586dac235ab967d3e565a4d1a ] nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead. There is no real Fixes tag applying here as the use of nand_release() in this driver predates by far the introduction of nand_cleanup() in commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible. However, pointing this commit as the culprit for backporting purposes makes sense even if this commit is not introducing any bug. Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") Signed-off-by: Miquel Raynal Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-34-miquel.raynal@bootlin.com Signed-off-by: Sasha Levin commit 9fc4e0210d84ebec374226809ca97e3e03d2b087 Author: Miquel Raynal Date: Tue May 19 15:00:33 2020 +0200 mtd: rawnand: xway: Fix the probe error path [ Upstream commit 34531be5e804a8e1abf314a6c3a19fe342e4a154 ] nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead. There is no real Fixes tag applying here as the use of nand_release() in this driver predates the introduction of nand_cleanup() in commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible. However, pointing this commit as the culprit for backporting purposes makes sense even if this commit is not introducing any bug. Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") Signed-off-by: Miquel Raynal Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-61-miquel.raynal@bootlin.com Signed-off-by: Sasha Levin commit 32125cccda1012b9fbc6604eea4290397eaf6409 Author: Miquel Raynal Date: Tue May 19 15:00:21 2020 +0200 mtd: rawnand: sharpsl: Fix the probe error path [ Upstream commit 0f44b3275b3798ccb97a2f51ac85871c30d6fbbc ] nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead. There is no Fixes tag applying here as the use of nand_release() in this driver predates by far the introduction of nand_cleanup() in commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible. However, pointing this commit as the culprit for backporting purposes makes sense. Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") Signed-off-by: Miquel Raynal Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-49-miquel.raynal@bootlin.com Signed-off-by: Sasha Levin commit ac1337100568aa87cfb2db5af094d03318c87704 Author: Miquel Raynal Date: Tue May 19 14:59:45 2020 +0200 mtd: rawnand: diskonchip: Fix the probe error path [ Upstream commit c5be12e45940f1aa1b5dfa04db5d15ad24f7c896 ] Not sure nand_cleanup() is the right function to call here but in any case it is not nand_release(). Indeed, even a comment says that calling nand_release() is a bit of a hack as there is no MTD device to unregister. So switch to nand_cleanup() for now and drop this comment. There is no Fixes tag applying here as the use of nand_release() in this driver predates by far the introduction of nand_cleanup() in commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible. However, pointing this commit as the culprit for backporting purposes makes sense even if it did not intruce any bug. Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") Signed-off-by: Miquel Raynal Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-13-miquel.raynal@bootlin.com Signed-off-by: Sasha Levin commit 6624691037da39f3dd1481ffe8f867c3d9ee8766 Author: Boris Brezillon Date: Thu Sep 6 14:05:15 2018 +0200 mtd: rawnand: Pass a nand_chip object to nand_release() [ Upstream commit 59ac276f22270fb2094910f9a734c17f41c25e70 ] Let's make the raw NAND API consistent by patching all helpers to take a nand_chip object instead of an mtd_info one. Now is nand_release()'s turn. Signed-off-by: Boris Brezillon Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit fd1a885b1d3a0b2041693100eee3d06fbceea1cc Author: Mauro Carvalho Chehab Date: Fri Jun 5 09:25:18 2020 -0700 media: dvb_frontend: fix return error code commit 330dada5957e3ca0c8811b14c45e3ac42c694651 upstream The correct error code when a function is not defined is -ENOTSUPP. It was typoed wrong as -EOPNOTSUPP, with, unfortunately, exists, but it is not used by the DVB core. Thanks-to: Geert Uytterhoeven Thanks-to: Arnd Bergmann To make me revisit this code. Fixes: a9cb97c3e628 ("media: dvb_frontend: be sure to init dvb_frontend_handle_ioctl() return code") Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit 39f03fefa8d3c16e5068cc11a77be0dfe4f0eb19 Author: Katsuhiro Suzuki Date: Fri Jun 5 09:25:17 2020 -0700 media: dvb_frontend: fix wrong cast in compat_ioctl commit 5c6c9c4830b76d851d38829611b3c3e4be0f5cdf upstream FE_GET_PROPERTY has always failed as following situations: - Use compatible ioctl - The array of 'struct dtv_property' has 2 or more items This patch fixes wrong cast to a pointer 'struct dtv_property' from a pointer of 2nd or after item of 'struct compat_dtv_property' array. Signed-off-by: Katsuhiro Suzuki Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit 20bcc237b3cd59a0ac24f03b1159b13264919cf6 Author: Jaedon Shin Date: Fri Jun 5 09:25:16 2020 -0700 media: dvb_frontend: Add commands implementation for compat ioct commit 18192a77f0810933ab71a46c1b260d230d7352ee upstream The dtv_properties structure and the dtv_property structure are different sizes in 32-bit and 64-bit system. This patch provides FE_SET_PROPERTY and FE_GET_PROPERTY ioctl commands implementation for 32-bit user space applications. Signed-off-by: Jaedon Shin Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit 415ba04b068c546f37a3543a6fc4d99f21e1701a Author: Jaedon Shin Date: Fri Jun 5 09:25:15 2020 -0700 media: dvb_frontend: Add compat_ioctl callback commit c2dfd2276cec63a0c6f6ce18ed83800d96fde542 upstream Adds compat_ioctl for 32-bit user space applications on a 64-bit system. [m.chehab@osg.samsung.com: add missing include compat.h] Signed-off-by: Jaedon Shin Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit 630b81e54ff252520382afef06e9c3649c6802ff Author: Jaedon Shin Date: Fri Jun 5 09:25:14 2020 -0700 media: dvb_frontend: Add unlocked_ioctl in dvb_frontend.c commit a2282fd1fe2ebcda480426dbfaaa7c4e87e27399 upstream Adds unlocked ioctl function directly in dvb_frontend.c instead of using dvb_generic_ioctl(). Signed-off-by: Jaedon Shin Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit ae5c6c40ddc36e9d1ac8b324c6b5054142bab76c Author: Mauro Carvalho Chehab Date: Fri Jun 5 09:25:13 2020 -0700 media: dvb_frontend: be sure to init dvb_frontend_handle_ioctl() return code commit a9cb97c3e628902e37583d8a40bb28cf76522cf1 upstream As smatch warned: drivers/media/dvb-core/dvb_frontend.c:2468 dvb_frontend_handle_ioctl() error: uninitialized symbol 'err'. The ioctl handler actually got a regression here: before changeset d73dcf0cdb95 ("media: dvb_frontend: cleanup ioctl handling logic"), the code used to return -EOPNOTSUPP if an ioctl handler was not implemented on a driver. After the change, it may return a random value. Fixes: d73dcf0cdb95 ("media: dvb_frontend: cleanup ioctl handling logic") Cc: stable@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab Tested-by: Daniel Scheller Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit b252335d73e3d69c84873acddbd202cfdfc8ef82 Author: Satendra Singh Thakur Date: Fri Jun 5 09:25:12 2020 -0700 media: dvb_frontend: dtv_property_process_set() cleanups commit media: dvb_frontend: dtv_property_process_set() cleanups upstream Since all properties in the func dtv_property_process_set() use at most 4 bytes arguments, change the code to pass u32 cmd and u32 data as function arguments, instead of passing a pointer to the entire struct dtv_property *tvp. Instead of having a generic dtv_property_dump(), added its own properties debug logic in the dtv_property_process_set(). Signed-off-by: Satendra Singh Thakur Reviewed-by: Shuah Khan Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit 55089d34f18cfbbcfcb5279b041c1b545ca8e657 Author: Mauro Carvalho Chehab Date: Fri Jun 5 09:25:11 2020 -0700 media: dvb_frontend: fix return values for FE_SET_PROPERTY commit 259a41d9ae8f3689742267f340ad2b159d00b302 upstream There are several problems with regards to the return of FE_SET_PROPERTY. The original idea were to return per-property return codes via tvp->result field, and to return an updated set of values. However, that never worked. What's actually implemented is: - the FE_SET_PROPERTY implementation doesn't call .get_frontend callback in order to get the actual parameters after return; - the tvp->result field is only filled if there's no error. So, it is always filled with zero; - FE_SET_PROPERTY doesn't call memdup_user() nor any other copy_to_user() function. So, any changes to the properties will be lost; - FE_SET_PROPERTY is declared as a write-only ioctl (IOW). While we could fix the above, it could cause regressions. So, let's just assume what the code really does, updating the documentation accordingly and removing the logic that would update the discarded tvp->result. Reviewed-by: Shuah Khan Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit 79c4efef804f09085fa1ad514960b7ab594df564 Author: Mauro Carvalho Chehab Date: Fri Jun 5 09:25:10 2020 -0700 media: dvb_frontend: better document the -EPERM condition commit da5516b5e81d45a96291823620f6c820178dc055 upstream Two readonly ioctls can't be allowed if the frontend device is opened in read only mode. Explain why. Reviewed by: Shuah Khan Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit b287a515fae7a19862eb18fd63c0d5789479b319 Author: Mauro Carvalho Chehab Date: Fri Jun 5 09:25:09 2020 -0700 media: dvb_frontend: get rid of property cache's state commit ef2cc27cf860b79874e9fde1419dd67c3372e41c upstream In the past, I guess the idea was to use state in order to allow an autofush logic. However, in the current code, it is used only for debug messages, on a poor man's solution, as there's already a debug message to indicate when the properties got flushed. So, just get rid of it for good. Reviewed-by: Shuah Khan Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit b20994675cde2988bf622f577223d38efcb0d959 Author: Mauro Carvalho Chehab Date: Fri Jun 5 09:25:08 2020 -0700 media: dvb_frontend: cleanup ioctl handling logic commit d73dcf0cdb95a47f7e4e991ab63dd30f6eb67b4e upstream Currently, there are two handlers for ioctls: - dvb_frontend_ioctl_properties() - dvb_frontend_ioctl_legacy() Despite their names, both handles non-legacy DVB ioctls. Besides that, there's no reason why to not handle all ioctls on a single handler function. So, merge them into a single function (dvb_frontend_handle_ioctl) and reorganize the ioctl's to indicate what's the current DVB API and what's deprecated. Despite the big diff, the handling logic for each ioctl is the same as before. Reviewed-by: Shuah Khan Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit 785a948c039645796e3fbcc0cdb1bbbf8982d1c2 Author: Mauro Carvalho Chehab Date: Fri Jun 5 09:25:07 2020 -0700 media: dvb_frontend: cleanup dvb_frontend_ioctl_properties() commit 2b5df42b8dec69fb926a242007fd462343db4408 upstream Use a switch() on this function, just like on other ioctl handlers and handle parameters inside each part of the switch. That makes it easier to integrate with the already existing ioctl handler function. Reviewed-by: Shuah Khan Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit 43619b35587ebef4070f5f4d61761766e0e3136a Author: Mauro Carvalho Chehab Date: Fri Jun 5 09:25:06 2020 -0700 media: dvb_frontend: get rid of set_property() callback commit 6680e73b5226114992acfc11f9cf5730f706fb01 upstream Now that all clients of set_property() were removed, get rid of this callback. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit 84deefee83b8bb98d6c98c536c9af7a86cac44f5 Author: Mauro Carvalho Chehab Date: Fri Jun 5 09:25:05 2020 -0700 media: friio-fe: get rid of set_property() commit b2c41ca9632e686e79f6c9db9c5f75666d37926e upstream This callback is not actually doing anything but making it to return an error depending on the DTV frontend command. Well, that could break userspace for no good reason, and, if needed, should be implemented, instead, at set_frontend() callback. So, get rid of it. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit f87cc0cd4f551100558cc6d48114526a7fa0a678 Author: Mauro Carvalho Chehab Date: Fri Jun 5 09:25:04 2020 -0700 media: stv6110: get rid of a srate dead code commit 282996925b4d78f9795d176f7fb409281c98d56d upstream The stv6110 has a weird code that checks if get_property and set_property ioctls are defined. If they're, it initializes a "srate" var from properties cache. Otherwise, it sets to 15MBaud, with won't make any sense. Thankfully, it seems that someone else discovered the issue in the past, as "srate" is currently not used anywhere! So, get rid of that really weird dead code logic. Reported-by: Honza Petrous Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit 380a54891daf747c3b15206c5c2b2cb8b59cc20a Author: Mauro Carvalho Chehab Date: Fri Jun 5 09:25:03 2020 -0700 media: stv0288: get rid of set_property boilerplate commit 473e4b4c1cf3046fc6b3437be9a9f3c89c2e61ef upstream This driver doesn't implement support for set_property(). Yet, it implements a boilerplate for it. Get rid of it. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit c0d4c1a37d7acdc7d0d8b719767ea6fa5396a172 Author: Mauro Carvalho Chehab Date: Fri Jun 5 09:25:02 2020 -0700 media: dvb_frontend: get rid of get_property() callback commit 8f8a19fcc1a89b83d0ab6d7cf2bcdd272dbd4334 upstream Only lg2160 implement gets_property, but there's no need for that, as no other driver calls this callback, as get_frontend() does the same, and set_frontend() also calls lg2160 get_frontend(). So, get rid of it. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Michael Ira Krufky Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit dc06ae4f1ba3d30b24140e821e1cebf9ed1a66ef Author: Mauro Carvalho Chehab Date: Fri Jun 5 09:25:01 2020 -0700 media: dvb/frontend.h: document the uAPI file commit 8220ead805b6bab4ade2839857a198e9708b07de upstream Most of the stuff at the Digital TV frontend header file are documented only at the Documentation. However, a few kernel-doc markups are there, several of them with parsing issues. Add the missing documentation, copying definitions from the Documentation when it applies, fixing some bugs. Please notice that DVBv3 stuff that were deprecated weren't commented by purpose. Instead, they were clearly tagged as such. This patch prepares to move part of the documentation from Documentation/ to kernel-doc comments. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit fb4ffc2662cc3023460e00f3dd9e12b99d929978 Author: Mauro Carvalho Chehab Date: Fri Jun 5 09:25:00 2020 -0700 media: dvb/frontend.h: move out a private internal structure commit f35afa4f60c868d7c7811ba747133acbf39410ac upstream struct dtv_cmds_h is just an ancillary struct used by the dvb_frontend.c to internally store frontend commands. It doesn't belong to the userspace header, nor it is used anywhere, except inside the DVB core. So, remove it from the header. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit bf48597d2020d1f288fbd8c96a12e90367362282 Author: Colin Ian King Date: Fri Jul 21 12:01:00 2017 -0400 media: dvb_frontend: initialize variable s with FE_NONE instead of 0 commit 450694c3b9f47b826a002089c463b9454b4bbe42 upstream. GIT_AUTHOR_NAME=Colin King GIT_AUTHOR_EMAIL=colin.king@canonical.com In a previous commit, we added FE_NONE as an unknown fe_status. Initialize variable s to FE_NONE instead of the more opaque value 0. Signed-off-by: Colin Ian King Reviewed-by: Shuah Khan Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit 815be3b360ddbe50f28a789d5225f26926582e17 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 e8f45586d06372c044002b11f12db7a9ba674739 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 97a17ed442c5d1ddf65588784c2a2ba7f33c26ca 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 [ Upstream commit 6bf6be1127f7e6d4bf39f84d56854e944d045d74 ] 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: Sasha Levin commit ed61e8c59be09d2c015bdf576f45425f1e6f41ac Author: Jiri Olsa Date: Tue May 12 17:03:18 2020 +0900 kretprobe: Prevent triggering kretprobe from within kprobe_flush_task [ Upstream commit 9b38cc704e844e41d9cf74e647bff1d249512cb3 ] 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: Sasha Levin commit 45ac65d2f27d20180afa50fae0c925a9183d3539 Author: Masami Hiramatsu Date: Sun Feb 24 01:50:49 2019 +0900 x86/kprobes: Avoid kretprobe recursion bug [ Upstream commit b191fa96ea6dc00d331dcc28c1f7db5e075693a0 ] Avoid kretprobe recursion loop bg by setting a dummy kprobes to current_kprobe per-CPU variable. This bug has been introduced with the asm-coded trampoline code, since previously it used another kprobe for hooking the function return placeholder (which only has a nop) and trampoline handler was called from that kprobe. This revives the old lost kprobe again. With this fix, we don't see deadlock anymore. And you can see that all inner-called kretprobe are skipped. event_1 235 0 event_2 19375 19612 The 1st column is recorded count and the 2nd is missed count. Above shows (event_1 rec) + (event_2 rec) ~= (event_2 missed) (some difference are here because the counter is racy) Reported-by: Andrea Righi Tested-by: Andrea Righi Signed-off-by: Masami Hiramatsu Acked-by: Steven Rostedt Cc: Linus Torvalds Cc: Mathieu Desnoyers Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: stable@vger.kernel.org Fixes: c9becf58d935 ("[PATCH] kretprobe: kretprobe-booster") Link: http://lkml.kernel.org/r/155094064889.6137.972160690963039.stgit@devbox Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit a07f99a6871190cff7016b79c9971e646a47f3fe Author: Naveen N. Rao Date: Wed Feb 8 14:27:31 2017 +0530 powerpc/kprobes: Fixes for kprobe_lookup_name() on BE [ Upstream commit 30176466e36aadba01e1a630cf42397a3438efa4 ] Fix two issues with kprobes.h on BE which were exposed with the optprobes work: - one, having to do with a missing include for linux/module.h for MODULE_NAME_LEN -- this didn't show up previously since the only users of kprobe_lookup_name were in kprobes.c, which included linux/module.h through other headers, and - two, with a missing const qualifier for a local variable which ends up referring a string literal. Again, this is unique to how kprobe_lookup_name is being invoked in optprobes.c Signed-off-by: Naveen N. Rao Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 354fb5951803c8a4036af492cd369c105fabf9c1 Author: Masami Hiramatsu Date: Tue May 12 17:02:56 2020 +0900 kprobes: Fix to protect kick_kprobe_optimizer() by kprobe_mutex [ Upstream commit 1a0aa991a6274161c95a844c58cfb801d681eb59 ] 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: Sasha Levin commit 3f51fa233f4b2d8879025bddc7720fadf70b1f97 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 5dfd73f2562bfd5ed2998958a3419c4920ebc120 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 11c46697a83a3d5ceb827bd68cfc1b682deac11b 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 5fbc7c942787305aa891a7176292271305b44401 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 800a0635d89116ac8df2c3cfcc7b5604bcb7fc81 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 0d6115ea8fa6378ab14c3bbaf6ca774c58faa428 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 e09cb9c8a3c6102b61ee4ced02caf2b400416b9a Author: Jeffle Xu Date: Fri May 22 12:18:44 2020 +0800 ext4: fix partial cluster initialization when splitting extent [ Upstream commit cfb3c85a600c6aa25a2581b3c1c4db3460f14e46 ] 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: Sasha Levin commit 30627877c2074eb6e10092f2cfe19157eea49ad2 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 d604a3a1dd82e296b9efbfe67bd3b64dbe40d8f8 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 203de6555df5089d8baf6f607d95a7167a3c8c37 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 ecc2b1e556983a2d254108b3ec44bb398e09ffd3 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 3a4b09605f727d40cf104c26a83707c67f4e10e9 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 a54b15af2b495ed97660a6276710ef36e06ac6c9 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 be676835b2250861d525b8e2a8e2bed8c1a9027d 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 0f61e86bcc0b3ca51b45ae01fbdfdfea0c0b7fe7 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 104592a5233d77322c3e527e3925dc7c5a30a6af 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 9e148a5e5e0929a4cb3000de9c843a07508ce575 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 a91af579a6f22e7abfb1d32788e3a8c0c4ff2259 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 c5560e91e9afcddd617d239da0778f403eeb7040 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 88b35c5f0b90f0d0993f905c6d643d7e8d839ced 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 1bb5b80d07f167c79c3696ec0476ef299385f468 Author: Nick Desaulniers Date: Thu Jun 4 16:50:49 2020 -0700 elfnote: mark all .note sections SHF_ALLOC [ Upstream commit 51da9dfb7f20911ae4e79e9b412a9c2d4c373d4b ] ELFNOTE_START allows callers to specify flags for .pushsection assembler directives. All callsites but ELF_NOTE use "a" for SHF_ALLOC. For vdso's that explicitly use ELF_NOTE_START and BUILD_SALT, the same section is specified twice after preprocessing, once with "a" flag, once without. Example: .pushsection .note.Linux, "a", @note ; .pushsection .note.Linux, "", @note ; While GNU as allows this ordering, it warns for the opposite ordering, making these directives position dependent. We'd prefer not to precisely match this behavior in Clang's integrated assembler. Instead, the non __ASSEMBLY__ definition of ELF_NOTE uses __attribute__((section(".note.Linux"))) which is created with SHF_ALLOC, so let's make the __ASSEMBLY__ definition of ELF_NOTE consistent with C and just always use "a" flag. This allows Clang to assemble a working mainline (5.6) kernel via: $ make CC=clang AS=clang Signed-off-by: Nick Desaulniers Signed-off-by: Andrew Morton Reviewed-by: Nathan Chancellor Reviewed-by: Fangrui Song Cc: Jeremy Fitzhardinge Cc: Thomas Gleixner Cc: Vincenzo Frascino Link: https://github.com/ClangBuiltLinux/linux/issues/913 Link: http://lkml.kernel.org/r/20200325231250.99205-1-ndesaulniers@google.com Debugged-by: Ilie Halip Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ea2027175315ff4934d2bfbcae1c5dce23ce7cb0 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 900bf0e209f21339aaed0441076c6537b63d98eb 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 7b2dbe405d1a3382ad90ebff6cfb76161afc3117 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 c2f9a6bc4582811b2edba16d96a9f7ee10c6114e 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 fbffea5caf01cd8d55f0e44b5644a4ac4f67b4da 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 d534300dd7df408935575f8dcc2bcefb5efb81eb 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 168b845f8a14bbe8564956222c40b3fed2f44270 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 aa332872c7c9bb1884a4a60582d2b3986ba5df4d 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 ae7a9734da91c3fd1405f3ae74a45be5f5140631 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 bda938df8ac95f80445a483e170c1aa0bab2c680 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 d5f224c582d7bfb036c098c286d062ed7c81c850 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 db2451de8337d426961ceff002565e5a16c0d659 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 b4a4925ab8d18ae17fcd661f1d7d536369543c63 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 03eeb914f9ef479a8ceff1f25d14bd4075bdc3a9 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 e03c43a1e88a788c19350a26e178db583fa60817 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 fd554743e85b7d98c7a0684cd0f2a41cbfc26b22 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 628d23552c497c67077cb4faa53550d32d134c51 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 87c06e46629d07d651eb8b21337e3995b932ab4b 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 6021e1f45162617d857bac7bac89baee6f959fc5 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 3facf1adb9ffedb49ff766869e80a6bdee045a43 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 04e0afc8685f13c572ce9106df13a23f9363dbf6 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 bc99df9396048c62db1b0217610bf020ad8aa6d2 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 707818ed1f56303c1cdffb9c3e9a320d4b793a0b 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 1d2deee6189aa3a18c4f9980e7ddc4796b739e87 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 f3d12f8fea325435b59e1da140f6515bbe28cc4e 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 5365fc3132a36a027fd7c2bb461e651b37f1e4d1 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 4481d24699f0c1d528202c7659cef2c1251c104a 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 73ce7f36a9ac3128b6529a9a9c899534aab02fa2 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 d0627bd8fc5b443e516474004535657defcdf469 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 73a5261b3e647e042f19d34baecde4e21d65a1a7 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 226dc83afbf86878f75c536cbe3516e6d923c1e6 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 a49d7ccfc436f420b7e7108d189487c189e0797c 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 49302f402a6f03e2a768f361f21e91e69214ff34 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 b3ab6af46a4078dc11ccd7b764ea40df3bfb7937 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 3d34e959526e936586ab549dd7b0cf63fd888452 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 7347ed207a721fc9561cca62e81b0a6385e14778 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 e0596b2c96e3462f608892b2a13c3536ced8c478 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 f84bd31331ffffcd5d764ac97bf3f7ba631321e5 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 fe5135063a8664ffdda1be38fa4c74b2b7077a16 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 95839ab52686c37246926176e7788c215129ad0e 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 9367d6e8f41439251d69d71f53502f0ec2798997 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 af1a71e2809aec826b2ac26ca2db3a75a948dbf7 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 b6c61e4fd2d771293f77a6a81cafb6298179391e 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 f8c7afcb6bb534b74f6a959837d4a0a91b8dd284 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 5ef30e443e6d3654cccecec99cf481a69a0a6d3b 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 1e492f9b3b37ebe6a4c963e4963d41d7589101fc 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 0ac65cee7b91add8f0b4c5801ac5f353fe2ad164 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 ef9fe7436e1d32e676fe6a6a3856464c2e1c39bd 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 9cf938848c801a0e052bfc9f57be09c29b66060f 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 45d44c0c0a8868ed51d74c3aac935a407742b9d1 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 69151594c72a1748cf93ae5b5fa68d5084253dce 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 892111331c9d5acf26a98d22d1e37903c323d2eb 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 f09c833c6af93e68d01c23c8f7227235277b7fc8 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 15e816ae1fc4c815a3fd85201a75a0f7ca681429 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 d93d04beba3f973fc577eedb9e26fd429e02fe4a 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 58d4c2ef8851f4c17ad8dec44339a5b590155ecf 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 72ad08b84c03b004d8cbf54c217c6c69445e4bb2 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 9a91d5256e3a26f47533059903e395d5e7a3ded4 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 372a8b5aec4808ea7114c0753667d131e8b435b6 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 18f7ec3aaaf70a6f41961c8d193fbc21f9df18f6 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 6dd652f672b7dad02d5807c41b5106f96d7a2e9f 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 66949914375c4688b4b4242e5e07e553587ffe45 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 e68517463a189938d96605dca05fba3d6164fac6 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 136476d33e05b6a2831d48fd57a59d7aac43b8ff 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 bf54b9ef81d33cdce0d0b8d23bccec54bb8b86ae 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 7cd829f2e4ef87ab6886980e27e48c12f4ad4592 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 ca33fc77e89b39f6df9f4b4d2a6d1bd3e8b68ff9 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 4b2abe8a55561d2d02588b03328ffeb8e9ee643c 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 efe93a779af54f8aeca6bd9e6f3a8499da36257a 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 a00ddd7b1c7c119e4aa4f006e807d258c99d1607 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