commit c34892e1995da8ca0dfbdcb115d6156f15000435 Author: Greg Kroah-Hartman Date: Sun Sep 26 14:10:25 2021 +0200 Linux 5.14.8 Link: https://lore.kernel.org/r/20210924124341.214446495@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Fox Chen Tested-by: Shuah Khan Tested-by: Salvatore Bonaccorso Link: https://lore.kernel.org/r/20210925120755.238551529@linuxfoundation.org Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Rudi Heitbaum Signed-off-by: Greg Kroah-Hartman commit 1236431c8531dd0dd2c80fa26453f686cd09321d Author: Guenter Roeck Date: Wed Sep 8 12:08:17 2021 -0700 drm/nouveau/nvkm: Replace -ENOSYS with -ENODEV commit e8f71f89236ef82d449991bfbc237e3cb6ea584f upstream. nvkm test builds fail with the following error. drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c: In function 'nvkm_control_mthd_pstate_info': drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c:60:35: error: overflow in conversion from 'int' to '__s8' {aka 'signed char'} changes value from '-251' to '5' The code builds on most architectures, but fails on parisc where ENOSYS is defined as 251. Replace the error code with -ENODEV (-19). The actual error code does not really matter and is not passed to userspace - it just has to be negative. Fixes: 7238eca4cf18 ("drm/nouveau: expose pstate selection per-power source in sysfs") Signed-off-by: Guenter Roeck Cc: Ben Skeggs Cc: David Airlie Cc: Daniel Vetter Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bef2b32a149030babba8ad5d2b6c121638fb911d Author: Paul Moore Date: Thu Sep 23 09:50:11 2021 -0400 selinux,smack: fix subjective/objective credential use mixups commit a3727a8bac0a9e77c70820655fd8715523ba3db7 upstream. Jann Horn reported a problem with commit eb1231f73c4d ("selinux: clarify task subjective and objective credentials") where some LSM hooks were attempting to access the subjective credentials of a task other than the current task. Generally speaking, it is not safe to access another task's subjective credentials and doing so can cause a number of problems. Further, while looking into the problem, I realized that Smack was suffering from a similar problem brought about by a similar commit 1fb057dcde11 ("smack: differentiate between subjective and objective task credentials"). This patch addresses this problem by restoring the use of the task's objective credentials in those cases where the task is other than the current executing task. Not only does this resolve the problem reported by Jann, it is arguably the correct thing to do in these cases. Cc: stable@vger.kernel.org Fixes: eb1231f73c4d ("selinux: clarify task subjective and objective credentials") Fixes: 1fb057dcde11 ("smack: differentiate between subjective and objective task credentials") Reported-by: Jann Horn Acked-by: Eric W. Biederman Acked-by: Casey Schaufler Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit dcd45a08b9a62ce8f52e14d441b0327582e6c366 Author: Hao Xu Date: Tue Sep 7 11:22:43 2021 +0800 io_uring: fix off-by-one in BUILD_BUG_ON check of __REQ_F_LAST_BIT [ Upstream commit 32c2d33e0b7c4ea53284d5d9435dd022b582c8cf ] Build check of __REQ_F_LAST_BIT should be larger than, not equal or larger than. It's perfectly valid to have __REQ_F_LAST_BIT be 32, as that means that the last valid bit is 31 which does fit in the type. Signed-off-by: Hao Xu Link: https://lore.kernel.org/r/20210907032243.114190-1-haoxu@linux.alibaba.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit d1217e40d082ebec361ba66852d2b3aa1aa854ae Author: Enzo Matsumiya Date: Thu Sep 9 18:46:45 2021 -0300 cifs: properly invalidate cached root handle when closing it [ Upstream commit 9351590f51cdda49d0265932a37f099950998504 ] Cached root file was not being completely invalidated sometimes. Reproducing: - With a DFS share with 2 targets, one disabled and one enabled - start some I/O on the mount # while true; do ls /mnt/dfs; done - at the same time, disable the enabled target and enable the disabled one - wait for DFS cache to expire - on reconnect, the previous cached root handle should be invalid, but open_cached_dir_by_dentry() will still try to use it, but throws a use-after-free warning (kref_get()) Make smb2_close_cached_fid() invalidate all fields every time, but only send an SMB2_close() when the entry is still valid. Signed-off-by: Enzo Matsumiya Reviewed-by: Paulo Alcantara (SUSE) Signed-off-by: Steve French Signed-off-by: Sasha Levin commit cacfce79af9bc0f03a3b33377718d76a138651f5 Author: Sebastian Andrzej Siewior Date: Mon Sep 6 13:30:34 2021 +0200 sched/idle: Make the idle timer expire in hard interrupt context [ Upstream commit 9848417926353daa59d2b05eb26e185063dbac6e ] The intel powerclamp driver will setup a per-CPU worker with RT priority. The worker will then invoke play_idle() in which it remains in the idle poll loop until it is stopped by the timer it started earlier. That timer needs to expire in hard interrupt context on PREEMPT_RT. Otherwise the timer will expire in ksoftirqd as a SOFT timer but that task won't be scheduled on the CPU because its priority is lower than the priority of the worker which is in the idle loop. Always expire the idle timer in hard interrupt context. Reported-by: Thomas Gleixner Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20210906113034.jgfxrjdvxnjqgtmc@linutronix.de Signed-off-by: Sasha Levin commit affd236df3e83800405e910b93e6bdd596ed265a Author: Yu-Tung Chang Date: Mon Aug 30 13:25:32 2021 +0800 rtc: rx8010: select REGMAP_I2C [ Upstream commit 0c45d3e24ef3d3d87c5e0077b8f38d1372af7176 ] The rtc-rx8010 uses the I2C regmap but doesn't select it in Kconfig so depending on the configuration the build may fail. Fix it. Signed-off-by: Yu-Tung Chang Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210830052532.40356-1-mtwget@gmail.com Signed-off-by: Sasha Levin commit 46384252a8f42985e76b6e5d8dbd7988b1e9bef9 Author: Song Liu Date: Tue Sep 7 16:03:38 2021 -0700 blk-mq: allow 4x BLK_MAX_REQUEST_COUNT at blk_plug for multiple_queues [ Upstream commit 7f2a6a69f7ced6db8220298e0497cf60482a9d4b ] Limiting number of request to BLK_MAX_REQUEST_COUNT at blk_plug hurts performance for large md arrays. [1] shows resync speed of md array drops for md array with more than 16 HDDs. Fix this by allowing more request at plug queue. The multiple_queue flag is used to only apply higher limit to multiple queue cases. [1] https://lore.kernel.org/linux-raid/CAFDAVznS71BXW8Jxv6k9dXc2iR3ysX3iZRBww_rzA8WifBFxGg@mail.gmail.com/ Tested-by: Marcin Wanat Signed-off-by: Song Liu Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit a3330c1c83190c08632ee2fa8952730df02170cf Author: Li Jinlin Date: Tue Sep 7 20:12:42 2021 +0800 blk-throttle: fix UAF by deleteing timer in blk_throtl_exit() [ Upstream commit 884f0e84f1e3195b801319c8ec3d5774e9bf2710 ] The pending timer has been set up in blk_throtl_init(). However, the timer is not deleted in blk_throtl_exit(). This means that the timer handler may still be running after freeing the timer, which would result in a use-after-free. Fix by calling del_timer_sync() to delete the timer in blk_throtl_exit(). Signed-off-by: Li Jinlin Link: https://lore.kernel.org/r/20210907121242.2885564-1-lijinlin3@huawei.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 2ab96bfe3201b73c5092681a0b75f9c7311b60ec Author: Tetsuo Handa Date: Tue Sep 7 20:52:13 2021 +0900 block: genhd: don't call blkdev_show() with major_names_lock held [ Upstream commit dfbb3409b27fa42b96f5727a80d3ceb6a8663991 ] If CONFIG_BLK_DEV_LOOP && CONFIG_MTD (at least; there might be other combinations), lockdep complains circular locking dependency at __loop_clr_fd(), for major_names_lock serves as a locking dependency aggregating hub across multiple block modules. ====================================================== WARNING: possible circular locking dependency detected 5.14.0+ #757 Tainted: G E ------------------------------------------------------ systemd-udevd/7568 is trying to acquire lock: ffff88800f334d48 ((wq_completion)loop0){+.+.}-{0:0}, at: flush_workqueue+0x70/0x560 but task is already holding lock: ffff888014a7d4a0 (&lo->lo_mutex){+.+.}-{3:3}, at: __loop_clr_fd+0x4d/0x400 [loop] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #6 (&lo->lo_mutex){+.+.}-{3:3}: lock_acquire+0xbe/0x1f0 __mutex_lock_common+0xb6/0xe10 mutex_lock_killable_nested+0x17/0x20 lo_open+0x23/0x50 [loop] blkdev_get_by_dev+0x199/0x540 blkdev_open+0x58/0x90 do_dentry_open+0x144/0x3a0 path_openat+0xa57/0xda0 do_filp_open+0x9f/0x140 do_sys_openat2+0x71/0x150 __x64_sys_openat+0x78/0xa0 do_syscall_64+0x3d/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #5 (&disk->open_mutex){+.+.}-{3:3}: lock_acquire+0xbe/0x1f0 __mutex_lock_common+0xb6/0xe10 mutex_lock_nested+0x17/0x20 bd_register_pending_holders+0x20/0x100 device_add_disk+0x1ae/0x390 loop_add+0x29c/0x2d0 [loop] blk_request_module+0x5a/0xb0 blkdev_get_no_open+0x27/0xa0 blkdev_get_by_dev+0x5f/0x540 blkdev_open+0x58/0x90 do_dentry_open+0x144/0x3a0 path_openat+0xa57/0xda0 do_filp_open+0x9f/0x140 do_sys_openat2+0x71/0x150 __x64_sys_openat+0x78/0xa0 do_syscall_64+0x3d/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #4 (major_names_lock){+.+.}-{3:3}: lock_acquire+0xbe/0x1f0 __mutex_lock_common+0xb6/0xe10 mutex_lock_nested+0x17/0x20 blkdev_show+0x19/0x80 devinfo_show+0x52/0x60 seq_read_iter+0x2d5/0x3e0 proc_reg_read_iter+0x41/0x80 vfs_read+0x2ac/0x330 ksys_read+0x6b/0xd0 do_syscall_64+0x3d/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #3 (&p->lock){+.+.}-{3:3}: lock_acquire+0xbe/0x1f0 __mutex_lock_common+0xb6/0xe10 mutex_lock_nested+0x17/0x20 seq_read_iter+0x37/0x3e0 generic_file_splice_read+0xf3/0x170 splice_direct_to_actor+0x14e/0x350 do_splice_direct+0x84/0xd0 do_sendfile+0x263/0x430 __se_sys_sendfile64+0x96/0xc0 do_syscall_64+0x3d/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #2 (sb_writers#3){.+.+}-{0:0}: lock_acquire+0xbe/0x1f0 lo_write_bvec+0x96/0x280 [loop] loop_process_work+0xa68/0xc10 [loop] process_one_work+0x293/0x480 worker_thread+0x23d/0x4b0 kthread+0x163/0x180 ret_from_fork+0x1f/0x30 -> #1 ((work_completion)(&lo->rootcg_work)){+.+.}-{0:0}: lock_acquire+0xbe/0x1f0 process_one_work+0x280/0x480 worker_thread+0x23d/0x4b0 kthread+0x163/0x180 ret_from_fork+0x1f/0x30 -> #0 ((wq_completion)loop0){+.+.}-{0:0}: validate_chain+0x1f0d/0x33e0 __lock_acquire+0x92d/0x1030 lock_acquire+0xbe/0x1f0 flush_workqueue+0x8c/0x560 drain_workqueue+0x80/0x140 destroy_workqueue+0x47/0x4f0 __loop_clr_fd+0xb4/0x400 [loop] blkdev_put+0x14a/0x1d0 blkdev_close+0x1c/0x20 __fput+0xfd/0x220 task_work_run+0x69/0xc0 exit_to_user_mode_prepare+0x1ce/0x1f0 syscall_exit_to_user_mode+0x26/0x60 do_syscall_64+0x4c/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae other info that might help us debug this: Chain exists of: (wq_completion)loop0 --> &disk->open_mutex --> &lo->lo_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&lo->lo_mutex); lock(&disk->open_mutex); lock(&lo->lo_mutex); lock((wq_completion)loop0); *** DEADLOCK *** 2 locks held by systemd-udevd/7568: #0: ffff888012554128 (&disk->open_mutex){+.+.}-{3:3}, at: blkdev_put+0x4c/0x1d0 #1: ffff888014a7d4a0 (&lo->lo_mutex){+.+.}-{3:3}, at: __loop_clr_fd+0x4d/0x400 [loop] stack backtrace: CPU: 0 PID: 7568 Comm: systemd-udevd Tainted: G E 5.14.0+ #757 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 02/27/2020 Call Trace: dump_stack_lvl+0x79/0xbf print_circular_bug+0x5d6/0x5e0 ? stack_trace_save+0x42/0x60 ? save_trace+0x3d/0x2d0 check_noncircular+0x10b/0x120 validate_chain+0x1f0d/0x33e0 ? __lock_acquire+0x953/0x1030 ? __lock_acquire+0x953/0x1030 __lock_acquire+0x92d/0x1030 ? flush_workqueue+0x70/0x560 lock_acquire+0xbe/0x1f0 ? flush_workqueue+0x70/0x560 flush_workqueue+0x8c/0x560 ? flush_workqueue+0x70/0x560 ? sched_clock_cpu+0xe/0x1a0 ? drain_workqueue+0x41/0x140 drain_workqueue+0x80/0x140 destroy_workqueue+0x47/0x4f0 ? blk_mq_freeze_queue_wait+0xac/0xd0 __loop_clr_fd+0xb4/0x400 [loop] ? __mutex_unlock_slowpath+0x35/0x230 blkdev_put+0x14a/0x1d0 blkdev_close+0x1c/0x20 __fput+0xfd/0x220 task_work_run+0x69/0xc0 exit_to_user_mode_prepare+0x1ce/0x1f0 syscall_exit_to_user_mode+0x26/0x60 do_syscall_64+0x4c/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f0fd4c661f7 Code: 00 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 13 fc ff ff RSP: 002b:00007ffd1c9e9fd8 EFLAGS: 00000246 ORIG_RAX: 0000000000000003 RAX: 0000000000000000 RBX: 00007f0fd46be6c8 RCX: 00007f0fd4c661f7 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000006 RBP: 0000000000000006 R08: 000055fff1eaf400 R09: 0000000000000000 R10: 00007f0fd46be6c8 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000002f08 R15: 00007ffd1c9ea050 Commit 1c500ad706383f1a ("loop: reduce the loop_ctl_mutex scope") is for breaking "loop_ctl_mutex => &lo->lo_mutex" dependency chain. But enabling a different block module results in forming circular locking dependency due to shared major_names_lock mutex. The simplest fix is to call probe function without holding major_names_lock [1], but Christoph Hellwig does not like such idea. Therefore, instead of holding major_names_lock in blkdev_show(), introduce a different lock for blkdev_show() in order to break "sb_writers#$N => &p->lock => major_names_lock" dependency chain. Link: https://lkml.kernel.org/r/b2af8a5b-3c1b-204e-7f56-bea0b15848d6@i-love.sakura.ne.jp [1] Signed-off-by: Tetsuo Handa Link: https://lore.kernel.org/r/18a02da2-0bf3-550e-b071-2b4ab13c49f0@i-love.sakura.ne.jp Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit e2860e2175c0599f9875aabca9dd582c8a5a4bc2 Author: Hannes Reinecke Date: Mon Sep 6 09:04:03 2021 +0200 nvmet: fixup buffer overrun in nvmet_subsys_attr_serial() [ Upstream commit f04064814c2a15c22ed9c803f9b634ef34f91092 ] The serial number is copied into the buffer via memcpy_and_pad() with the length NVMET_SN_MAX_SIZE. So when printing out we also need to take just that length as anything beyond that will be uninitialized. Signed-off-by: Hannes Reinecke Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit da66431417408f3ca742c28974ec3e4a272f1a84 Author: Uwe Kleine-König Date: Wed Jul 7 18:27:53 2021 +0200 pwm: stm32-lp: Don't modify HW state in .remove() callback [ Upstream commit d44084c93427bb0a9261432db1a8ca76a42d805e ] A consumer is expected to disable a PWM before calling pwm_put(). And if they didn't there is hopefully a good reason (or the consumer needs fixing). Also if disabling an enabled PWM was the right thing to do, this should better be done in the framework instead of in each low level driver. Signed-off-by: Uwe Kleine-König Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 2c92f9e8e0392caf91d8fd43de177df505696e62 Author: Uwe Kleine-König Date: Wed Jul 7 18:27:52 2021 +0200 pwm: rockchip: Don't modify HW state in .remove() callback [ Upstream commit 9d768cd7fd42bb0be16f36aec48548fca5260759 ] A consumer is expected to disable a PWM before calling pwm_put(). And if they didn't there is hopefully a good reason (or the consumer needs fixing). Also if disabling an enabled PWM was the right thing to do, this should better be done in the framework instead of in each low level driver. Signed-off-by: Uwe Kleine-König Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit f53bd7fe1bf6cc5e9ca53b5b864121d75f622e34 Author: Uwe Kleine-König Date: Wed Jul 7 18:27:51 2021 +0200 pwm: img: Don't modify HW state in .remove() callback [ Upstream commit c68eb29c8e9067c08175dd0414f6984f236f719d ] A consumer is expected to disable a PWM before calling pwm_put(). And if they didn't there is hopefully a good reason (or the consumer needs fixing). Also if disabling an enabled PWM was the right thing to do, this should better be done in the framework instead of in each low level driver. Signed-off-by: Uwe Kleine-König Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit ddd8601dd8533f4c3bd82fe03cd55a4bd8f0d695 Author: farah kassabri Date: Sun Aug 15 11:16:16 2021 +0300 habanalabs: cannot sleep while holding spinlock [ Upstream commit 607b1468c2263e082d74c1a3e71399a9026b41ce ] Fix 2 areas in the code where it's possible the code will go to sleep while holding a spinlock. Reported-by: Dan Carpenter Signed-off-by: farah kassabri Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin commit f621eeead8d6eca12289dc8f52727cd23d5c5b21 Author: Omer Shpigelman Date: Mon Aug 16 13:27:12 2021 +0300 habanalabs: add "in device creation" status [ Upstream commit 71731090ab17a208a58020e4b342fdfee280458a ] On init, the disabled state is cleared right before hw_init and that causes the device to report on "Operational" state before the device initialization is finished. Although the char device is not yet exposed to the user at this stage, the sysfs entries are exposed. This can cause errors in monitoring applications that use the sysfs entries. In order to avoid this, a new state "in device creation" is introduced to ne reported when the device is not disabled but is still in init flow. Signed-off-by: Omer Shpigelman Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin commit 836c0806500d645446a614259cecd0b072bda2eb Author: Yuri Nudelman Date: Thu Jul 29 11:54:50 2021 +0300 habanalabs: fix mmu node address resolution in debugfs [ Upstream commit 09ae43043c748423a5dcdc7bb1e63e4dcabe9bd6 ] The address resolution via debugfs was not taking into consideration the page offset, resulting in a wrong address. Signed-off-by: Yuri Nudelman Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin commit 46d712b460804801ebed83c3e54c38738f1ad081 Author: Ofir Bitton Date: Tue Jul 20 09:16:05 2021 +0300 habanalabs: add validity check for event ID received from F/W [ Upstream commit a6c849012b0f51c674f52384bd9a4f3dc0a33c31 ] Currently there is no validity check for event ID received from F/W, Thus exposing driver to memory overrun. Signed-off-by: Ofir Bitton Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin commit 350b2f2b1f2af93581008b9d0e4ab4a8af84b379 Author: Philip Yang Date: Thu Jul 29 17:19:54 2021 -0400 drm/amdgpu: fix fdinfo race with process exit [ Upstream commit d7eff46c214c036606dd3cd305bd5a128aecfe8c ] Get process vm root BO ref in case process is exiting and root BO is freed, to avoid NULL pointer dereference backtrace: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 Call Trace: amdgpu_show_fdinfo+0xfe/0x2a0 [amdgpu] seq_show+0x12c/0x180 seq_read+0x153/0x410 vfs_read+0x91/0x140[ 3427.206183] ksys_read+0x4f/0xb0 do_syscall_64+0x5b/0x1a0 entry_SYSCALL_64_after_hwframe+0x65/0xca Signed-off-by: Philip Yang Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 25b4e51e2333761389f905c213fe48f44c581b5d Author: Anson Jacob Date: Fri Aug 13 17:11:51 2021 -0400 drm/amd/display: Fix memory leak reported by coverity [ Upstream commit 03388a347fe7cf7c3bdf68b0823ba316d177d470 ] Free memory allocated if any of the previous allocations failed. >>> CID 1487129: Resource leaks (RESOURCE_LEAK) >>> Variable "vpg" going out of scope leaks the storage it points to. Addresses-Coverity-ID: 1487129: ("Resource leaks") Reviewed-by: Aric Cyr Acked-by: Mikita Lipski Signed-off-by: Anson Jacob Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 682645659796a874b6921c22681431e834782866 Author: Luben Tuikov Date: Tue Aug 24 11:01:32 2021 -0400 drm/amdgpu: Fixes to returning VBIOS RAS EEPROM address [ Upstream commit a6a355a22f7a0efa6a11bc90b5161f394d51fe95 ] 1) Generalize the function--if the user didn't set i2c_address, still return true/false to indicate whether VBIOS contains the RAS EEPROM address. This function shouldn't evaluate whether the user set the i2c_address pointer or not. 2) Don't touch the caller's i2c_address, unless you have to--this function shouldn't have side effects. 3) Correctly set the function comment as a kernel-doc comment. Cc: John Clements Cc: Hawking Zhang Cc: Alex Deucher Signed-off-by: Luben Tuikov Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d5b10c0b4288980433551e172b0e3fa7f5d3c70f Author: Tomer Tayar Date: Fri Jul 9 00:06:47 2021 +0300 habanalabs: fix nullifying of destroyed mmu pgt pool [ Upstream commit 89aad770d692e4d2d9a604c1674e9dfa69421430 ] In case of host-resident MMU, when the page tables pool is destroyed, its pointer is not nullified correctly. As a result, on a device fini which happens after a failing reset, the already destroyed pool is accessed, which leads to a kernel panic. The patch fixes the setting of the pool pointer to NULL. Signed-off-by: Tomer Tayar Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin commit d51100f735619cd7128f8c8eab902618c7d15342 Author: Niklas Söderlund Date: Wed Aug 4 11:18:18 2021 +0200 thermal/drivers/rcar_gen3_thermal: Store TSC id as unsigned int [ Upstream commit d3a2328e741bf6e9e6bda750e0a63832fa365a74 ] The TSC id and number of TSC ids should be stored as unsigned int as they can't be negative. Fix the datatype of the loop counter 'i' and rcar_gen3_thermal_tsc.id to reflect this. Signed-off-by: Niklas Söderlund Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210804091818.2196806-3-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Sasha Levin commit 0ea5f803c39d2b8abafe934ec8e07ed4b935f355 Author: Nanyong Sun Date: Tue Sep 7 20:00:23 2021 -0700 nilfs2: fix memory leak in nilfs_sysfs_delete_snapshot_group [ Upstream commit 17243e1c3072b8417a5ebfc53065d0a87af7ca77 ] kobject_put() should be used to cleanup the memory associated with the kobject instead of kobject_del(). See the section "Kobject removal" of "Documentation/core-api/kobject.rst". Link: https://lkml.kernel.org/r/20210629022556.3985106-7-sunnanyong@huawei.com Link: https://lkml.kernel.org/r/1625651306-10829-7-git-send-email-konishi.ryusuke@gmail.com Signed-off-by: Nanyong Sun Signed-off-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 7797daf14c3f41a37038d9f91c14bd928d14fe73 Author: Nanyong Sun Date: Tue Sep 7 20:00:21 2021 -0700 nilfs2: fix memory leak in nilfs_sysfs_create_snapshot_group [ Upstream commit b2fe39c248f3fa4bbb2a20759b4fdd83504190f7 ] If kobject_init_and_add returns with error, kobject_put() is needed here to avoid memory leak, because kobject_init_and_add may return error without freeing the memory associated with the kobject it allocated. Link: https://lkml.kernel.org/r/20210629022556.3985106-6-sunnanyong@huawei.com Link: https://lkml.kernel.org/r/1625651306-10829-6-git-send-email-konishi.ryusuke@gmail.com Signed-off-by: Nanyong Sun Signed-off-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 6e17978ca9b812720e8c8d1ab80e1536f8172e6e Author: Nanyong Sun Date: Tue Sep 7 20:00:18 2021 -0700 nilfs2: fix memory leak in nilfs_sysfs_delete_##name##_group [ Upstream commit a3e181259ddd61fd378390977a1e4e2316853afa ] The kobject_put() should be used to cleanup the memory associated with the kobject instead of kobject_del. See the section "Kobject removal" of "Documentation/core-api/kobject.rst". Link: https://lkml.kernel.org/r/20210629022556.3985106-5-sunnanyong@huawei.com Link: https://lkml.kernel.org/r/1625651306-10829-5-git-send-email-konishi.ryusuke@gmail.com Signed-off-by: Nanyong Sun Signed-off-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 90b8f51480a4bc8dc39c6a8885986ea1407b9c12 Author: Nanyong Sun Date: Tue Sep 7 20:00:15 2021 -0700 nilfs2: fix memory leak in nilfs_sysfs_create_##name##_group [ Upstream commit 24f8cb1ed057c840728167dab33b32e44147c86f ] If kobject_init_and_add return with error, kobject_put() is needed here to avoid memory leak, because kobject_init_and_add may return error without freeing the memory associated with the kobject it allocated. Link: https://lkml.kernel.org/r/20210629022556.3985106-4-sunnanyong@huawei.com Link: https://lkml.kernel.org/r/1625651306-10829-4-git-send-email-konishi.ryusuke@gmail.com Signed-off-by: Nanyong Sun Signed-off-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit e005476348f9d2edbbf9ad22ce2f63298b871d8f Author: Nanyong Sun Date: Tue Sep 7 20:00:12 2021 -0700 nilfs2: fix NULL pointer in nilfs_##name##_attr_release [ Upstream commit dbc6e7d44a514f231a64d9d5676e001b660b6448 ] In nilfs_##name##_attr_release, kobj->parent should not be referenced because it is a NULL pointer. The release() method of kobject is always called in kobject_put(kobj), in the implementation of kobject_put(), the kobj->parent will be assigned as NULL before call the release() method. So just use kobj to get the subgroups, which is more efficient and can fix a NULL pointer reference problem. Link: https://lkml.kernel.org/r/20210629022556.3985106-3-sunnanyong@huawei.com Link: https://lkml.kernel.org/r/1625651306-10829-3-git-send-email-konishi.ryusuke@gmail.com Signed-off-by: Nanyong Sun Signed-off-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 255c3bfa28262908d26d0afc0eeb943dbb2c1613 Author: Nanyong Sun Date: Tue Sep 7 20:00:09 2021 -0700 nilfs2: fix memory leak in nilfs_sysfs_create_device_group [ Upstream commit 5f5dec07aca7067216ed4c1342e464e7307a9197 ] Patch series "nilfs2: fix incorrect usage of kobject". This patchset from Nanyong Sun fixes memory leak issues and a NULL pointer dereference issue caused by incorrect usage of kboject in nilfs2 sysfs implementation. This patch (of 6): Reported by syzkaller: BUG: memory leak unreferenced object 0xffff888100ca8988 (size 8): comm "syz-executor.1", pid 1930, jiffies 4294745569 (age 18.052s) hex dump (first 8 bytes): 6c 6f 6f 70 31 00 ff ff loop1... backtrace: kstrdup+0x36/0x70 mm/util.c:60 kstrdup_const+0x35/0x60 mm/util.c:83 kvasprintf_const+0xf1/0x180 lib/kasprintf.c:48 kobject_set_name_vargs+0x56/0x150 lib/kobject.c:289 kobject_add_varg lib/kobject.c:384 [inline] kobject_init_and_add+0xc9/0x150 lib/kobject.c:473 nilfs_sysfs_create_device_group+0x150/0x7d0 fs/nilfs2/sysfs.c:986 init_nilfs+0xa21/0xea0 fs/nilfs2/the_nilfs.c:637 nilfs_fill_super fs/nilfs2/super.c:1046 [inline] nilfs_mount+0x7b4/0xe80 fs/nilfs2/super.c:1316 legacy_get_tree+0x105/0x210 fs/fs_context.c:592 vfs_get_tree+0x8e/0x2d0 fs/super.c:1498 do_new_mount fs/namespace.c:2905 [inline] path_mount+0xf9b/0x1990 fs/namespace.c:3235 do_mount+0xea/0x100 fs/namespace.c:3248 __do_sys_mount fs/namespace.c:3456 [inline] __se_sys_mount fs/namespace.c:3433 [inline] __x64_sys_mount+0x14b/0x1f0 fs/namespace.c:3433 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae If kobject_init_and_add return with error, then the cleanup of kobject is needed because memory may be allocated in kobject_init_and_add without freeing. And the place of cleanup_dev_kobject should use kobject_put to free the memory associated with the kobject. As the section "Kobject removal" of "Documentation/core-api/kobject.rst" says, kobject_del() just makes the kobject "invisible", but it is not cleaned up. And no more cleanup will do after cleanup_dev_kobject, so kobject_put is needed here. Link: https://lkml.kernel.org/r/1625651306-10829-1-git-send-email-konishi.ryusuke@gmail.com Link: https://lkml.kernel.org/r/1625651306-10829-2-git-send-email-konishi.ryusuke@gmail.com Reported-by: Hulk Robot Link: https://lkml.kernel.org/r/20210629022556.3985106-2-sunnanyong@huawei.com Signed-off-by: Nanyong Sun Signed-off-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 0e78f3da8e58f57e5b58f5624de6bcf65d9ee50f Author: Anand Jain Date: Tue Aug 31 09:21:28 2021 +0800 btrfs: fix lockdep warning while mounting sprout fs [ Upstream commit c124706900c20dee70f921bb3a90492431561a0a ] Following test case reproduces lockdep warning. Test case: $ mkfs.btrfs -f $ btrfstune -S 1 $ mount $ btrfs device add -f $ umount $ mount $ umount The warning claims a possible ABBA deadlock between the threads initiated by [#1] btrfs device add and [#0] the mount. [ 540.743122] WARNING: possible circular locking dependency detected [ 540.743129] 5.11.0-rc7+ #5 Not tainted [ 540.743135] ------------------------------------------------------ [ 540.743142] mount/2515 is trying to acquire lock: [ 540.743149] ffffa0c5544c2ce0 (&fs_devs->device_list_mutex){+.+.}-{4:4}, at: clone_fs_devices+0x6d/0x210 [btrfs] [ 540.743458] but task is already holding lock: [ 540.743461] ffffa0c54a7932b8 (btrfs-chunk-00){++++}-{4:4}, at: __btrfs_tree_read_lock+0x32/0x200 [btrfs] [ 540.743541] which lock already depends on the new lock. [ 540.743543] the existing dependency chain (in reverse order) is: [ 540.743546] -> #1 (btrfs-chunk-00){++++}-{4:4}: [ 540.743566] down_read_nested+0x48/0x2b0 [ 540.743585] __btrfs_tree_read_lock+0x32/0x200 [btrfs] [ 540.743650] btrfs_read_lock_root_node+0x70/0x200 [btrfs] [ 540.743733] btrfs_search_slot+0x6c6/0xe00 [btrfs] [ 540.743785] btrfs_update_device+0x83/0x260 [btrfs] [ 540.743849] btrfs_finish_chunk_alloc+0x13f/0x660 [btrfs] <--- device_list_mutex [ 540.743911] btrfs_create_pending_block_groups+0x18d/0x3f0 [btrfs] [ 540.743982] btrfs_commit_transaction+0x86/0x1260 [btrfs] [ 540.744037] btrfs_init_new_device+0x1600/0x1dd0 [btrfs] [ 540.744101] btrfs_ioctl+0x1c77/0x24c0 [btrfs] [ 540.744166] __x64_sys_ioctl+0xe4/0x140 [ 540.744170] do_syscall_64+0x4b/0x80 [ 540.744174] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 540.744180] -> #0 (&fs_devs->device_list_mutex){+.+.}-{4:4}: [ 540.744184] __lock_acquire+0x155f/0x2360 [ 540.744188] lock_acquire+0x10b/0x5c0 [ 540.744190] __mutex_lock+0xb1/0xf80 [ 540.744193] mutex_lock_nested+0x27/0x30 [ 540.744196] clone_fs_devices+0x6d/0x210 [btrfs] [ 540.744270] btrfs_read_chunk_tree+0x3c7/0xbb0 [btrfs] [ 540.744336] open_ctree+0xf6e/0x2074 [btrfs] [ 540.744406] btrfs_mount_root.cold.72+0x16/0x127 [btrfs] [ 540.744472] legacy_get_tree+0x38/0x90 [ 540.744475] vfs_get_tree+0x30/0x140 [ 540.744478] fc_mount+0x16/0x60 [ 540.744482] vfs_kern_mount+0x91/0x100 [ 540.744484] btrfs_mount+0x1e6/0x670 [btrfs] [ 540.744536] legacy_get_tree+0x38/0x90 [ 540.744537] vfs_get_tree+0x30/0x140 [ 540.744539] path_mount+0x8d8/0x1070 [ 540.744541] do_mount+0x8d/0xc0 [ 540.744543] __x64_sys_mount+0x125/0x160 [ 540.744545] do_syscall_64+0x4b/0x80 [ 540.744547] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 540.744551] other info that might help us debug this: [ 540.744552] Possible unsafe locking scenario: [ 540.744553] CPU0 CPU1 [ 540.744554] ---- ---- [ 540.744555] lock(btrfs-chunk-00); [ 540.744557] lock(&fs_devs->device_list_mutex); [ 540.744560] lock(btrfs-chunk-00); [ 540.744562] lock(&fs_devs->device_list_mutex); [ 540.744564] *** DEADLOCK *** [ 540.744565] 3 locks held by mount/2515: [ 540.744567] #0: ffffa0c56bf7a0e0 (&type->s_umount_key#42/1){+.+.}-{4:4}, at: alloc_super.isra.16+0xdf/0x450 [ 540.744574] #1: ffffffffc05a9628 (uuid_mutex){+.+.}-{4:4}, at: btrfs_read_chunk_tree+0x63/0xbb0 [btrfs] [ 540.744640] #2: ffffa0c54a7932b8 (btrfs-chunk-00){++++}-{4:4}, at: __btrfs_tree_read_lock+0x32/0x200 [btrfs] [ 540.744708] stack backtrace: [ 540.744712] CPU: 2 PID: 2515 Comm: mount Not tainted 5.11.0-rc7+ #5 But the device_list_mutex in clone_fs_devices() is redundant, as explained below. Two threads [1] and [2] (below) could lead to clone_fs_device(). [1] open_ctree <== mount sprout fs btrfs_read_chunk_tree() mutex_lock(&uuid_mutex) <== global lock read_one_dev() open_seed_devices() clone_fs_devices() <== seed fs_devices mutex_lock(&orig->device_list_mutex) <== seed fs_devices [2] btrfs_init_new_device() <== sprouting mutex_lock(&uuid_mutex); <== global lock btrfs_prepare_sprout() lockdep_assert_held(&uuid_mutex) clone_fs_devices(seed_fs_device) <== seed fs_devices Both of these threads hold uuid_mutex which is sufficient to protect getting the seed device(s) freed while we are trying to clone it for sprouting [2] or mounting a sprout [1] (as above). A mounted seed device can not free/write/replace because it is read-only. An unmounted seed device can be freed by btrfs_free_stale_devices(), but it needs uuid_mutex. So this patch removes the unnecessary device_list_mutex in clone_fs_devices(). And adds a lockdep_assert_held(&uuid_mutex) in clone_fs_devices(). Reported-by: Su Yue Tested-by: Su Yue Signed-off-by: Anand Jain Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit ebed7d89e54c6a130897c9b2eabb2733a3834f98 Author: Josef Bacik Date: Tue Jul 27 17:01:17 2021 -0400 btrfs: delay blkdev_put until after the device remove [ Upstream commit 3fa421dedbc82f985f030c5a6480ea2d784334c3 ] When removing the device we call blkdev_put() on the device once we've removed it, and because we have an EXCL open we need to take the ->open_mutex on the block device to clean it up. Unfortunately during device remove we are holding the sb writers lock, which results in the following lockdep splat: ====================================================== WARNING: possible circular locking dependency detected 5.14.0-rc2+ #407 Not tainted ------------------------------------------------------ losetup/11595 is trying to acquire lock: ffff973ac35dd138 ((wq_completion)loop0){+.+.}-{0:0}, at: flush_workqueue+0x67/0x5e0 but task is already holding lock: ffff973ac9812c68 (&lo->lo_mutex){+.+.}-{3:3}, at: __loop_clr_fd+0x41/0x660 [loop] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 (&lo->lo_mutex){+.+.}-{3:3}: __mutex_lock+0x7d/0x750 lo_open+0x28/0x60 [loop] blkdev_get_whole+0x25/0xf0 blkdev_get_by_dev.part.0+0x168/0x3c0 blkdev_open+0xd2/0xe0 do_dentry_open+0x161/0x390 path_openat+0x3cc/0xa20 do_filp_open+0x96/0x120 do_sys_openat2+0x7b/0x130 __x64_sys_openat+0x46/0x70 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #3 (&disk->open_mutex){+.+.}-{3:3}: __mutex_lock+0x7d/0x750 blkdev_put+0x3a/0x220 btrfs_rm_device.cold+0x62/0xe5 btrfs_ioctl+0x2a31/0x2e70 __x64_sys_ioctl+0x80/0xb0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #2 (sb_writers#12){.+.+}-{0:0}: lo_write_bvec+0xc2/0x240 [loop] loop_process_work+0x238/0xd00 [loop] process_one_work+0x26b/0x560 worker_thread+0x55/0x3c0 kthread+0x140/0x160 ret_from_fork+0x1f/0x30 -> #1 ((work_completion)(&lo->rootcg_work)){+.+.}-{0:0}: process_one_work+0x245/0x560 worker_thread+0x55/0x3c0 kthread+0x140/0x160 ret_from_fork+0x1f/0x30 -> #0 ((wq_completion)loop0){+.+.}-{0:0}: __lock_acquire+0x10ea/0x1d90 lock_acquire+0xb5/0x2b0 flush_workqueue+0x91/0x5e0 drain_workqueue+0xa0/0x110 destroy_workqueue+0x36/0x250 __loop_clr_fd+0x9a/0x660 [loop] block_ioctl+0x3f/0x50 __x64_sys_ioctl+0x80/0xb0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae other info that might help us debug this: Chain exists of: (wq_completion)loop0 --> &disk->open_mutex --> &lo->lo_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&lo->lo_mutex); lock(&disk->open_mutex); lock(&lo->lo_mutex); lock((wq_completion)loop0); *** DEADLOCK *** 1 lock held by losetup/11595: #0: ffff973ac9812c68 (&lo->lo_mutex){+.+.}-{3:3}, at: __loop_clr_fd+0x41/0x660 [loop] stack backtrace: CPU: 0 PID: 11595 Comm: losetup Not tainted 5.14.0-rc2+ #407 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 Call Trace: dump_stack_lvl+0x57/0x72 check_noncircular+0xcf/0xf0 ? stack_trace_save+0x3b/0x50 __lock_acquire+0x10ea/0x1d90 lock_acquire+0xb5/0x2b0 ? flush_workqueue+0x67/0x5e0 ? lockdep_init_map_type+0x47/0x220 flush_workqueue+0x91/0x5e0 ? flush_workqueue+0x67/0x5e0 ? verify_cpu+0xf0/0x100 drain_workqueue+0xa0/0x110 destroy_workqueue+0x36/0x250 __loop_clr_fd+0x9a/0x660 [loop] ? blkdev_ioctl+0x8d/0x2a0 block_ioctl+0x3f/0x50 __x64_sys_ioctl+0x80/0xb0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fc21255d4cb So instead save the bdev and do the put once we've dropped the sb writers lock in order to avoid the lockdep recursion. Reviewed-by: Anand Jain Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 13d4c38e5c513906c34d499ef47d467de4030634 Author: Josef Bacik Date: Tue Jul 27 17:01:16 2021 -0400 btrfs: update the bdev time directly when closing [ Upstream commit 8f96a5bfa1503e0a5f3c78d51e993a1794d4aff1 ] We update the ctime/mtime of a block device when we remove it so that blkid knows the device changed. However we do this by re-opening the block device and calling filp_update_time. This is more correct because it'll call the inode->i_op->update_time if it exists, but the block dev inodes do not do this. Instead call generic_update_time() on the bd_inode in order to avoid the blkdev_open path and get rid of the following lockdep splat: ====================================================== WARNING: possible circular locking dependency detected 5.14.0-rc2+ #406 Not tainted ------------------------------------------------------ losetup/11596 is trying to acquire lock: ffff939640d2f538 ((wq_completion)loop0){+.+.}-{0:0}, at: flush_workqueue+0x67/0x5e0 but task is already holding lock: ffff939655510c68 (&lo->lo_mutex){+.+.}-{3:3}, at: __loop_clr_fd+0x41/0x660 [loop] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 (&lo->lo_mutex){+.+.}-{3:3}: __mutex_lock+0x7d/0x750 lo_open+0x28/0x60 [loop] blkdev_get_whole+0x25/0xf0 blkdev_get_by_dev.part.0+0x168/0x3c0 blkdev_open+0xd2/0xe0 do_dentry_open+0x161/0x390 path_openat+0x3cc/0xa20 do_filp_open+0x96/0x120 do_sys_openat2+0x7b/0x130 __x64_sys_openat+0x46/0x70 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #3 (&disk->open_mutex){+.+.}-{3:3}: __mutex_lock+0x7d/0x750 blkdev_get_by_dev.part.0+0x56/0x3c0 blkdev_open+0xd2/0xe0 do_dentry_open+0x161/0x390 path_openat+0x3cc/0xa20 do_filp_open+0x96/0x120 file_open_name+0xc7/0x170 filp_open+0x2c/0x50 btrfs_scratch_superblocks.part.0+0x10f/0x170 btrfs_rm_device.cold+0xe8/0xed btrfs_ioctl+0x2a31/0x2e70 __x64_sys_ioctl+0x80/0xb0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #2 (sb_writers#12){.+.+}-{0:0}: lo_write_bvec+0xc2/0x240 [loop] loop_process_work+0x238/0xd00 [loop] process_one_work+0x26b/0x560 worker_thread+0x55/0x3c0 kthread+0x140/0x160 ret_from_fork+0x1f/0x30 -> #1 ((work_completion)(&lo->rootcg_work)){+.+.}-{0:0}: process_one_work+0x245/0x560 worker_thread+0x55/0x3c0 kthread+0x140/0x160 ret_from_fork+0x1f/0x30 -> #0 ((wq_completion)loop0){+.+.}-{0:0}: __lock_acquire+0x10ea/0x1d90 lock_acquire+0xb5/0x2b0 flush_workqueue+0x91/0x5e0 drain_workqueue+0xa0/0x110 destroy_workqueue+0x36/0x250 __loop_clr_fd+0x9a/0x660 [loop] block_ioctl+0x3f/0x50 __x64_sys_ioctl+0x80/0xb0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae other info that might help us debug this: Chain exists of: (wq_completion)loop0 --> &disk->open_mutex --> &lo->lo_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&lo->lo_mutex); lock(&disk->open_mutex); lock(&lo->lo_mutex); lock((wq_completion)loop0); *** DEADLOCK *** 1 lock held by losetup/11596: #0: ffff939655510c68 (&lo->lo_mutex){+.+.}-{3:3}, at: __loop_clr_fd+0x41/0x660 [loop] stack backtrace: CPU: 1 PID: 11596 Comm: losetup Not tainted 5.14.0-rc2+ #406 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 Call Trace: dump_stack_lvl+0x57/0x72 check_noncircular+0xcf/0xf0 ? stack_trace_save+0x3b/0x50 __lock_acquire+0x10ea/0x1d90 lock_acquire+0xb5/0x2b0 ? flush_workqueue+0x67/0x5e0 ? lockdep_init_map_type+0x47/0x220 flush_workqueue+0x91/0x5e0 ? flush_workqueue+0x67/0x5e0 ? verify_cpu+0xf0/0x100 drain_workqueue+0xa0/0x110 destroy_workqueue+0x36/0x250 __loop_clr_fd+0x9a/0x660 [loop] ? blkdev_ioctl+0x8d/0x2a0 block_ioctl+0x3f/0x50 __x64_sys_ioctl+0x80/0xb0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Reviewed-by: Anand Jain Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit e0f8639c87e1aacf46f542f98c271010a96130e3 Author: Vasily Gorbik Date: Wed Sep 1 16:05:59 2021 +0200 s390/unwind: use current_frame_address() to unwind current task [ Upstream commit 88b604263f3d6eedae0b1c2c3bbd602d1e2e8775 ] current_stack_pointer() simply returns current value of %r15. If current_stack_pointer() caller allocates stack (which is the case in unwind code) %r15 points to a stack frame allocated for callees, meaning current_stack_pointer() caller (e.g. stack_trace_save) will end up in the stacktrace. This is not expected by stack_trace_save*() callers and causes problems. current_frame_address() on the other hand returns function stack frame address, which matches %r15 upon function invocation. Using it in get_stack_pointer() makes it more aligned with x86 implementation (according to BACKTRACE_SELF_TEST output) and meets stack_trace_save*() caller's expectations, notably KCSAN. Also make sure unwind_start is always inlined. Reported-by: Nathan Chancellor Suggested-by: Marco Elver Signed-off-by: Vasily Gorbik Tested-by: Marco Elver Tested-by: Nathan Chancellor Link: https://lore.kernel.org/r/patch.git-04dd26be3043.your-ad-here.call-01630504868-ext-6188@work.hours Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 31db9b13e54e52693870ed5fb6755fcd829bfc68 Author: Jeff Layton Date: Thu Sep 2 08:31:03 2021 -0400 ceph: lockdep annotations for try_nonblocking_invalidate [ Upstream commit 3eaf5aa1cfa8c97c72f5824e2e9263d6cc977b03 ] Signed-off-by: Jeff Layton Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 6ca3781b4664ae5ba71a14daf6c33591dab1eb5a Author: Xiubo Li Date: Wed Aug 25 21:45:43 2021 +0800 ceph: remove the capsnaps when removing caps [ Upstream commit a6d37ccdd240e80f26aaea0e62cda310e0e184d7 ] capsnaps will take inode references via ihold when queueing to flush. When force unmounting, the client will just close the sessions and may never get a flush reply, causing a leak and inode ref leak. Fix this by removing the capsnaps for an inode when removing the caps. URL: https://tracker.ceph.com/issues/52295 Signed-off-by: Xiubo Li Reviewed-by: Jeff Layton Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 8e46eccfc10f8a16cbfb175fe72e73876cbbdf50 Author: Jeff Layton Date: Wed Aug 11 06:40:42 2021 -0400 ceph: request Fw caps before updating the mtime in ceph_write_iter [ Upstream commit b11ed50346683a749632ea664959b28d524d7395 ] The current code will update the mtime and then try to get caps to handle the write. If we end up having to request caps from the MDS, then the mtime in the cap grant will clobber the updated mtime and it'll be lost. This is most noticable when two clients are alternately writing to the same file. Fw caps are continually being granted and revoked, and the mtime ends up stuck because the updated mtimes are always being overwritten with the old one. Fix this by changing the order of operations in ceph_write_iter to get the caps before updating the times. Also, make sure we check the pool full conditions before even getting any caps or uninlining. URL: https://tracker.ceph.com/issues/46574 Reported-by: Jozef Kováč Signed-off-by: Jeff Layton Reviewed-by: Xiubo Li Reviewed-by: Luis Henriques Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 8e4e080b2be0b979cbd90b1a587d4afa9ef074ab Author: Jeff Layton Date: Thu Jul 1 10:41:46 2021 -0400 ceph: fix memory leak on decode error in ceph_handle_caps [ Upstream commit 2ad32cf09bd28a21e6ad1595355a023ed631b529 ] If we hit a decoding error late in the frame, then we might exit the function without putting the pool_ns string. Ensure that we always put that reference on the way out of the function. Signed-off-by: Jeff Layton Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit abae6b3bab39538dd1562ef60e2194f57239db86 Author: Mario Limonciello Date: Wed Sep 1 09:21:11 2021 -0500 ACPI: PM: s2idle: Run both AMD and Microsoft methods if both are supported [ Upstream commit fa209644a7124b3f4cf811ced55daef49ae39ac6 ] It was reported that on "HP ENVY x360" that power LED does not come back, certain keys like brightness controls do not work, and the fan never spins up, even under load on 5.14 final. In analysis of the SSDT it's clear that the Microsoft UUID doesn't provide functional support, but rather the AMD UUID should be supporting this system. Because this is a gap in the expected logic, we checked back with internal team. The conclusion was that on Windows AMD uPEP *does* run even when Microsoft UUID present, but most OEM systems have adopted value of "0x3" for supported functions and hence nothing runs. Henceforth add support for running both Microsoft and AMD methods. This approach will also allow the same logic on Intel systems if desired at a future time as well by pulling the evaluation of `lps0_dsm_func_mask_microsoft` out of the `if` block for `acpi_s2idle_vendor_amd`. Link: https://gitlab.freedesktop.org/drm/amd/uploads/9fbcd7ec3a385cc6949c9bacf45dc41b/acpi-f.20.bin BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1691 Reported-by: Maxwell Beck Signed-off-by: Mario Limonciello [ rjw: Edits of the new comments ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 417cd319e99853626222178bf89c753e1d4d4e4c Author: Kuninori Morimoto Date: Mon Aug 30 09:44:44 2021 +0900 ASoC: audio-graph: respawn Platform Support [ Upstream commit 5f939f49771002f347039edf984aca42f30fc31a ] commit 63f2f9cceb09f8 ("ASoC: audio-graph: remove Platform support") removed Platform support from audio-graph, because it doesn't have "plat" support on DT (simple-card has). But, Platform support is needed if user is using snd_dmaengine_pcm_register() which adds generic DMA as Platform. And this Platform dev is using CPU dev. Without this patch, at least STM32MP15 audio sound card is no more functional (v5.13 or later). This patch respawn Platform Support on audio-graph again. Reported-by: Olivier MOYSAN Signed-off-by: Kuninori Morimoto Tested-by: Olivier MOYSAN Link: https://lore.kernel.org/r/878s0jzrpf.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0a96c9734bd85b7eddd590d8d8e32fd63b70fb9f Author: Sven Schnelle Date: Fri Aug 27 08:36:06 2021 +0200 s390: add kmemleak annotation in stack_alloc() [ Upstream commit 436fc4feeabbf103d78d50a8e091b3aac28cc37f ] kmemleak with enabled auto scanning reports that our stack allocation is lost. This is because we're saving the pointer + STACK_INIT_OFFSET to lowcore. When kmemleak now scans the objects, it thinks that this one is lost because it can't find a corresponding pointer. Reported-by: Marc Hartmayer Signed-off-by: Sven Schnelle Tested-by: Marc Hartmayer Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 5c9fc54187142bd893a87d5b465774c15b6550b5 Author: Radhey Shyam Pandey Date: Thu Aug 19 14:28:48 2021 +0530 dmaengine: xilinx_dma: Set DMA mask for coherent APIs [ Upstream commit aac6c0f90799d66b8989be1e056408f33fd99fe6 ] The xilinx dma driver uses the consistent allocations, so for correct operation also set the DMA mask for coherent APIs. It fixes the below kernel crash with dmatest client when DMA IP is configured with 64-bit address width and linux is booted from high (>4GB) memory. Call trace: [ 489.531257] dma_alloc_from_pool+0x8c/0x1c0 [ 489.535431] dma_direct_alloc+0x284/0x330 [ 489.539432] dma_alloc_attrs+0x80/0xf0 [ 489.543174] dma_pool_alloc+0x160/0x2c0 [ 489.547003] xilinx_cdma_prep_memcpy+0xa4/0x180 [ 489.551524] dmatest_func+0x3cc/0x114c [ 489.555266] kthread+0x124/0x130 [ 489.558486] ret_from_fork+0x10/0x3c [ 489.562051] ---[ end trace 248625b2d596a90a ]--- Signed-off-by: Radhey Shyam Pandey Reviewed-by: Harini Katakam Link: https://lore.kernel.org/r/1629363528-30347-1-git-send-email-radhey.shyam.pandey@xilinx.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 996a4337be965a7afc0765dae2996fb45669df14 Author: Johannes Berg Date: Mon Aug 9 11:24:09 2021 +0200 dmaengine: ioat: depends on !UML [ Upstream commit bbac7a92a46f0876e588722ebe552ddfe6fd790f ] Now that UML has PCI support, this driver must depend also on !UML since it pokes at X86_64 architecture internals that don't exist on ARCH=um. Reported-by: Geert Uytterhoeven Signed-off-by: Johannes Berg Acked-by: Dave Jiang Link: https://lore.kernel.org/r/20210809112409.a3a0974874d2.I2ffe3d11ed37f735da2f39884a74c953b258b995@changeid Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 964a9834492210f48b360baa9e20a9eedf4d08ff Author: Dan Williams Date: Mon Aug 2 10:29:59 2021 -0700 cxl/pci: Introduce cdevm_file_operations [ Upstream commit 9cc238c7a526dba9ee8c210fa2828886fc65db66 ] In preparation for moving cxl_memdev allocation to the core, introduce cdevm_file_operations to coordinate file operations shutdown relative to driver data release. The motivation for moving cxl_memdev allocation to the core (beyond better file organization of sysfs attributes in core/ and drivers in cxl/), is that device lifetime is longer than module lifetime. The cxl_pci module should be free to come and go without needing to coordinate with devices that need the text associated with cxl_memdev_release() to stay resident. The move will fix a use after free bug when looping driver load / unload with CONFIG_DEBUG_KOBJECT_RELEASE=y. Another motivation for passing in file_operations to the core cxl_memdev creation flow is to allow for alternate drivers, like unit test code, to define their own ioctl backends. Signed-off-by: Ben Widawsky Reviewed-by: Jonathan Cameron Link: https://lore.kernel.org/r/162792539962.368511.2962268954245340288.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams Signed-off-by: Sasha Levin commit e921d59a75c7932fd33bfa64c156fd40d7ba4da9 Author: Ben Widawsky Date: Mon Aug 2 10:29:38 2021 -0700 cxl: Move cxl_core to new directory [ Upstream commit 5161a55c069f53d88da49274cbef6e3c74eadea9 ] CXL core is growing, and it's already arguably unmanageable. To support future growth, move core functionality to a new directory and rename the file to represent just bus support. Future work will remove non-bus functionality. Note that mem.h is renamed to cxlmem.h to avoid a namespace collision with the global ARCH=um mem.h header. Reported-by: kernel test robot Signed-off-by: Ben Widawsky Reviewed-by: Jonathan Cameron Link: https://lore.kernel.org/r/162792537866.368511.8915631504621088321.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams Signed-off-by: Sasha Levin commit 786c11aebd4f4b4a1d5caaa68599f5fc33dd4e25 Author: Zou Wei Date: Tue May 4 10:22:57 2021 +0800 dmaengine: sprd: Add missing MODULE_DEVICE_TABLE [ Upstream commit 4faee8b65ec32346f8096e64c5fa1d5a73121742 ] This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by: Hulk Robot Signed-off-by: Zou Wei Reviewed-by: Baolin Wang Link: https://lore.kernel.org/r/1620094977-70146-1-git-send-email-zou_wei@huawei.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 70100a0fb72dd1867dffb7558a6c54a721bc16e7 Author: Johannes Berg Date: Fri Jun 25 10:38:10 2021 +0200 dmaengine: idxd: depends on !UML [ Upstream commit b2296eeac91555bd13f774efa7ab7d4b12fb71ef ] Now that UML has PCI support, this driver must depend also on !UML since it pokes at X86_64 architecture internals that don't exist on ARCH=um. Reported-by: kernel test robot Signed-off-by: Johannes Berg Acked-by: Dave Jiang Acked-By: Anton Ivanov Link: https://lore.kernel.org/r/20210625103810.fe877ae0aef4.If240438e3f50ae226f3f755fc46ea498c6858393@changeid Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 4d74704a397558ce30e0f0c67101758c29c4aab7 Author: Geert Uytterhoeven Date: Thu Aug 26 15:19:39 2021 +0200 riscv: dts: microchip: mpfs-icicle: Fix serial console [ Upstream commit cbba17870881cd17bca24673ccb72859431da5bd ] Currently, nothing is output on the serial console, unless "console=ttyS0,115200n8" or "earlycon" are appended to the kernel command line. Enable automatic console selection using chosen/stdout-path by adding a proper alias, and configure the expected serial rate. While at it, add aliases for the other three serial ports, which are provided on the same micro-USB connector as the first one. Fixes: 0fa6107eca4186ad ("RISC-V: Initial DTS for Microchip ICICLE board") Signed-off-by: Geert Uytterhoeven Reviewed-by: Bin Meng Reviewed-by: Conor Dooley Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit f8d2c2cfbff382fa8c11bf40054ae35afe2911ca Author: Saravana Kannan Date: Thu Sep 9 18:14:45 2021 -0700 of: property: Disable fw_devlink DT support for X86 [ Upstream commit 4a48b66b3f52aa1a8aaa8a8863891eed35769731 ] Andre reported fw_devlink=on breaking OLPC XO-1.5 [1]. OLPC XO-1.5 is an X86 system that uses a mix of ACPI and OF to populate devices. The root cause seems to be ISA devices not setting their fwnode field. But trying to figure out how to fix that doesn't seem worth the trouble because the OLPC devicetree is very sparse/limited and fw_devlink only adds the links causing this issue. Considering that there aren't many users of OF in an X86 system, simply fw_devlink DT support for X86. [1] - https://lore.kernel.org/lkml/3c1f2473-92ad-bfc4-258e-a5a08ad73dd0@web.de/ Fixes: ea718c699055 ("Revert "Revert "driver core: Set fw_devlink=on by default""") Signed-off-by: Saravana Kannan Cc: Andre Muller Acked-by: Greg Kroah-Hartman Tested-by: Andre Müller Link: https://lore.kernel.org/r/20210910011446.3208894-1-saravanak@google.com Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit f7525b4c5d402a6be0cb5e62956ca71607e77260 Author: xinhui pan Date: Tue Sep 7 12:08:32 2021 +0800 drm/ttm: Fix a deadlock if the target BO is not idle during swap [ Upstream commit 70982eef4d7eebb47a3b1ef25ec1bc742f3a21cf ] The ret value might be -EBUSY, caller will think lru lock is still locked but actually NOT. So return -ENOSPC instead. Otherwise we hit list corruption. ttm_bo_cleanup_refs might fail too if BO is not idle. If we return 0, caller(ttm_tt_populate -> ttm_global_swapout ->ttm_device_swapout) will be stuck as we actually did not free any BO memory. This usually happens when the fence is not signaled for a long time. Signed-off-by: xinhui pan Reviewed-by: Christian König Fixes: ebd59851c796 ("drm/ttm: move swapout logic around v3") Link: https://patchwork.freedesktop.org/patch/msgid/20210907040832.1107747-1-xinhui.pan@amd.com Signed-off-by: Christian König Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin commit 3a4a126d3515188aa25362007b7d7501bb1b5625 Author: Ard Biesheuvel Date: Thu Aug 26 18:56:13 2021 +0200 arm64: mm: limit linear region to 51 bits for KVM in nVHE mode [ Upstream commit 88053ec8cb1b91df566353cd3116470193797e00 ] KVM in nVHE mode divides up its VA space into two equal halves, and picks the half that does not conflict with the HYP ID map to map its linear region. This worked fine when the kernel's linear map itself was guaranteed to cover precisely as many bits of VA space, but this was changed by commit f4693c2716b35d08 ("arm64: mm: extend linear region for 52-bit VA configurations"). The result is that, depending on the placement of the ID map, kernel-VA to hyp-VA translations may produce addresses that either conflict with other HYP mappings (including the ID map itself) or generate addresses outside of the 52-bit addressable range, neither of which is likely to lead to anything useful. Given that 52-bit capable cores are guaranteed to implement VHE, this only affects configurations such as pKVM where we opt into non-VHE mode even if the hardware is VHE capable. So just for these configurations, let's limit the kernel linear map to 51 bits and work around the problem. Fixes: f4693c2716b3 ("arm64: mm: extend linear region for 52-bit VA configurations") Signed-off-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20210826165613.60774-1-ardb@kernel.org Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 4ca60140f83ea53bdb3e691360b7aa4ff6945e88 Author: Fenghua Yu Date: Sat Aug 28 15:06:22 2021 +0800 iommu/vt-d: Fix a deadlock in intel_svm_drain_prq() [ Upstream commit 6ef0505158f7ca1b32763a3b038b5d11296b642b ] pasid_mutex and dev->iommu->param->lock are held while unbinding mm is flushing IO page fault workqueue and waiting for all page fault works to finish. But an in-flight page fault work also need to hold the two locks while unbinding mm are holding them and waiting for the work to finish. This may cause an ABBA deadlock issue as shown below: idxd 0000:00:0a.0: unbind PASID 2 ====================================================== WARNING: possible circular locking dependency detected 5.14.0-rc7+ #549 Not tainted [ 186.615245] ---------- dsa_test/898 is trying to acquire lock: ffff888100d854e8 (¶m->lock){+.+.}-{3:3}, at: iopf_queue_flush_dev+0x29/0x60 but task is already holding lock: ffffffff82b2f7c8 (pasid_mutex){+.+.}-{3:3}, at: intel_svm_unbind+0x34/0x1e0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (pasid_mutex){+.+.}-{3:3}: __mutex_lock+0x75/0x730 mutex_lock_nested+0x1b/0x20 intel_svm_page_response+0x8e/0x260 iommu_page_response+0x122/0x200 iopf_handle_group+0x1c2/0x240 process_one_work+0x2a5/0x5a0 worker_thread+0x55/0x400 kthread+0x13b/0x160 ret_from_fork+0x22/0x30 -> #1 (¶m->fault_param->lock){+.+.}-{3:3}: __mutex_lock+0x75/0x730 mutex_lock_nested+0x1b/0x20 iommu_report_device_fault+0xc2/0x170 prq_event_thread+0x28a/0x580 irq_thread_fn+0x28/0x60 irq_thread+0xcf/0x180 kthread+0x13b/0x160 ret_from_fork+0x22/0x30 -> #0 (¶m->lock){+.+.}-{3:3}: __lock_acquire+0x1134/0x1d60 lock_acquire+0xc6/0x2e0 __mutex_lock+0x75/0x730 mutex_lock_nested+0x1b/0x20 iopf_queue_flush_dev+0x29/0x60 intel_svm_drain_prq+0x127/0x210 intel_svm_unbind+0xc5/0x1e0 iommu_sva_unbind_device+0x62/0x80 idxd_cdev_release+0x15a/0x200 [idxd] __fput+0x9c/0x250 ____fput+0xe/0x10 task_work_run+0x64/0xa0 exit_to_user_mode_prepare+0x227/0x230 syscall_exit_to_user_mode+0x2c/0x60 do_syscall_64+0x48/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae other info that might help us debug this: Chain exists of: ¶m->lock --> ¶m->fault_param->lock --> pasid_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(pasid_mutex); lock(¶m->fault_param->lock); lock(pasid_mutex); lock(¶m->lock); *** DEADLOCK *** 2 locks held by dsa_test/898: #0: ffff888100cc1cc0 (&group->mutex){+.+.}-{3:3}, at: iommu_sva_unbind_device+0x53/0x80 #1: ffffffff82b2f7c8 (pasid_mutex){+.+.}-{3:3}, at: intel_svm_unbind+0x34/0x1e0 stack backtrace: CPU: 2 PID: 898 Comm: dsa_test Not tainted 5.14.0-rc7+ #549 Hardware name: Intel Corporation Kabylake Client platform/KBL S DDR4 UD IMM CRB, BIOS KBLSE2R1.R00.X050.P01.1608011715 08/01/2016 Call Trace: dump_stack_lvl+0x5b/0x74 dump_stack+0x10/0x12 print_circular_bug.cold+0x13d/0x142 check_noncircular+0xf1/0x110 __lock_acquire+0x1134/0x1d60 lock_acquire+0xc6/0x2e0 ? iopf_queue_flush_dev+0x29/0x60 ? pci_mmcfg_read+0xde/0x240 __mutex_lock+0x75/0x730 ? iopf_queue_flush_dev+0x29/0x60 ? pci_mmcfg_read+0xfd/0x240 ? iopf_queue_flush_dev+0x29/0x60 mutex_lock_nested+0x1b/0x20 iopf_queue_flush_dev+0x29/0x60 intel_svm_drain_prq+0x127/0x210 ? intel_pasid_tear_down_entry+0x22e/0x240 intel_svm_unbind+0xc5/0x1e0 iommu_sva_unbind_device+0x62/0x80 idxd_cdev_release+0x15a/0x200 pasid_mutex protects pasid and svm data mapping data. It's unnecessary to hold pasid_mutex while flushing the workqueue. To fix the deadlock issue, unlock pasid_pasid during flushing the workqueue to allow the works to be handled. Fixes: d5b9e4bfe0d8 ("iommu/vt-d: Report prq to io-pgfault framework") Reported-and-tested-by: Dave Jiang Signed-off-by: Fenghua Yu Link: https://lore.kernel.org/r/20210826215918.4073446-1-fenghua.yu@intel.com Signed-off-by: Lu Baolu Link: https://lore.kernel.org/r/20210828070622.2437559-3-baolu.lu@linux.intel.com [joro: Removed timing information from kernel log messages] Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit cab628d695ab19fb8665831780122f3798ed1830 Author: Fenghua Yu Date: Sat Aug 28 15:06:21 2021 +0800 iommu/vt-d: Fix PASID leak in intel_svm_unbind_mm() [ Upstream commit a21518cb23a3c7d49bafcb59862fd389fd829d4b ] The mm->pasid will be used in intel_svm_free_pasid() after load_pasid() during unbinding mm. Clearing it in load_pasid() will cause PASID cannot be freed in intel_svm_free_pasid(). Additionally mm->pasid was updated already before load_pasid() during pasid allocation. No need to update it again in load_pasid() during binding mm. Don't update mm->pasid to avoid the issues in both binding mm and unbinding mm. Fixes: 4048377414162 ("iommu/vt-d: Use iommu_sva_alloc(free)_pasid() helpers") Reported-and-tested-by: Dave Jiang Co-developed-by: Jacob Pan Signed-off-by: Jacob Pan Signed-off-by: Fenghua Yu Link: https://lore.kernel.org/r/20210826215918.4073446-1-fenghua.yu@intel.com Signed-off-by: Lu Baolu Link: https://lore.kernel.org/r/20210828070622.2437559-2-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit f74210e642c892be57495d431a463e52521d1517 Author: Wei Huang Date: Fri Aug 20 15:29:55 2021 -0500 iommu/amd: Relocate GAMSup check to early_enable_iommus [ Upstream commit c3811a50addd23b9bb5a36278609ee1638debcf6 ] Currently, iommu_init_ga() checks and disables IOMMU VAPIC support (i.e. AMD AVIC support in IOMMU) when GAMSup feature bit is not set. However it forgets to clear IRQ_POSTING_CAP from the previously set amd_iommu_irq_ops.capability. This triggers an invalid page fault bug during guest VM warm reboot if AVIC is enabled since the irq_remapping_cap(IRQ_POSTING_CAP) is incorrectly set, and crash the system with the following kernel trace. BUG: unable to handle page fault for address: 0000000000400dd8 RIP: 0010:amd_iommu_deactivate_guest_mode+0x19/0xbc Call Trace: svm_set_pi_irte_mode+0x8a/0xc0 [kvm_amd] ? kvm_make_all_cpus_request_except+0x50/0x70 [kvm] kvm_request_apicv_update+0x10c/0x150 [kvm] svm_toggle_avic_for_irq_window+0x52/0x90 [kvm_amd] svm_enable_irq_window+0x26/0xa0 [kvm_amd] vcpu_enter_guest+0xbbe/0x1560 [kvm] ? avic_vcpu_load+0xd5/0x120 [kvm_amd] ? kvm_arch_vcpu_load+0x76/0x240 [kvm] ? svm_get_segment_base+0xa/0x10 [kvm_amd] kvm_arch_vcpu_ioctl_run+0x103/0x590 [kvm] kvm_vcpu_ioctl+0x22a/0x5d0 [kvm] __x64_sys_ioctl+0x84/0xc0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae Fixes by moving the initializing of AMD IOMMU interrupt remapping mode (amd_iommu_guest_ir) earlier before setting up the amd_iommu_irq_ops.capability with appropriate IRQ_POSTING_CAP flag. [joro: Squashed the two patches and limited check_features_on_all_iommus() to CONFIG_IRQ_REMAP to fix a compile warning.] Signed-off-by: Wei Huang Co-developed-by: Suravee Suthikulpanit Signed-off-by: Suravee Suthikulpanit Link: https://lore.kernel.org/r/20210820202957.187572-2-suravee.suthikulpanit@amd.com Link: https://lore.kernel.org/r/20210820202957.187572-3-suravee.suthikulpanit@amd.com Fixes: 8bda0cfbdc1a ("iommu/amd: Detect and initialize guest vAPIC log") Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 2d0bfe7e6f5ddbe669bf043963c9f2367dee9eb4 Author: Guenter Roeck Date: Wed Sep 8 08:30:41 2021 -0700 parisc: Move pci_dev_is_behind_card_dino to where it is used [ Upstream commit 907872baa9f1538eed02ec737b8e89eba6c6e4b9 ] parisc build test images fail to compile with the following error. drivers/parisc/dino.c:160:12: error: 'pci_dev_is_behind_card_dino' defined but not used Move the function just ahead of its only caller to avoid the error. Fixes: 5fa1659105fa ("parisc: Disable HP HSC-PCI Cards to prevent kernel crash") Cc: Helge Deller Signed-off-by: Guenter Roeck Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 9a9d2fb4995a946a4102374ef1d19a94357ad6bb Author: Geert Uytterhoeven Date: Thu Sep 2 14:49:12 2021 +0200 dma-buf: DMABUF_DEBUG should depend on DMA_SHARED_BUFFER [ Upstream commit cca62758ebdd71fcfb6d589d6487a7f26398d50d ] DMA-BUF debug checks are an option of DMA-BUF. Enabling DMABUF_DEBUG without DMA_SHARED_BUFFER does not have any impact, as drivers/dma-buf/ is not entered during the build when DMA_SHARED_BUFFER is disabled. Fixes: 84335675f2223cbd ("dma-buf: Add debug option") Signed-off-by: Geert Uytterhoeven Signed-off-by: Sumit Semwal Link: https://patchwork.freedesktop.org/patch/msgid/20210902124913.2698760-3-geert@linux-m68k.org Signed-off-by: Sasha Levin commit 7eb2c8604702982094a61f36de5039bfc983823c Author: Geert Uytterhoeven Date: Thu Sep 2 14:49:11 2021 +0200 dma-buf: DMABUF_MOVE_NOTIFY should depend on DMA_SHARED_BUFFER [ Upstream commit c4f3a3460a5daebc772d9263500e4099b11e7300 ] Move notify between drivers is an option of DMA-BUF. Enabling DMABUF_MOVE_NOTIFY without DMA_SHARED_BUFFER does not have any impact, as drivers/dma-buf/ is not entered during the build when DMA_SHARED_BUFFER is disabled. Fixes: bb42df4662a44765 ("dma-buf: add dynamic DMA-buf handling v15") Signed-off-by: Geert Uytterhoeven Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210902124913.2698760-2-geert@linux-m68k.org Signed-off-by: Sasha Levin commit 0a1b8623d10c91959b53238e99529eaedb605f6e Author: Thomas Gleixner Date: Tue Aug 31 13:48:34 2021 +0200 drivers: base: cacheinfo: Get rid of DEFINE_SMP_CALL_CACHE_FUNCTION() [ Upstream commit 4b92d4add5f6dcf21275185c997d6ecb800054cd ] DEFINE_SMP_CALL_CACHE_FUNCTION() was usefel before the CPU hotplug rework to ensure that the cache related functions are called on the upcoming CPU because the notifier itself could run on any online CPU. The hotplug state machine guarantees that the callbacks are invoked on the upcoming CPU. So there is no need to have this SMP function call obfuscation. That indirection was missed when the hotplug notifiers were converted. This also solves the problem of ARM64 init_cache_level() invoking ACPI functions which take a semaphore in that context. That's invalid as SMP function calls run with interrupts disabled. Running it just from the callback in context of the CPU hotplug thread solves this. Fixes: 8571890e1513 ("arm64: Add support for ACPI based firmware tables") Reported-by: Guenter Roeck Signed-off-by: Thomas Gleixner Tested-by: Guenter Roeck Acked-by: Will Deacon Acked-by: Peter Zijlstra Link: https://lore.kernel.org/r/871r69ersb.ffs@tglx Signed-off-by: Sasha Levin commit 52cf80714d50598c9195c945237286cd223a0326 Author: Koba Ko Date: Mon Aug 30 10:02:00 2021 +0800 drm/amdgpu: Disable PCIE_DPM on Intel RKL Platform [ Upstream commit b3dc549986eb7b38eba4a144e979dc93f386751f ] Due to high latency in PCIE clock switching on RKL platforms, switching the PCIE clock dynamically at runtime can lead to HDMI/DP audio problems. On newer asics this is handled in the SMU firmware. For SMU7-based asics, disable PCIE clock switching to avoid the issue. AMD provide a parameter to disable PICE_DPM. modprobe amdgpu ppfeaturemask=0xfff7bffb It's better to contorl PCIE_DPM in amd gpu driver, switch PCI_DPM by determining intel RKL platform for SMU7-based asics. Fixes: 1a31474cdb48 ("drm/amd/pm: workaround for audio noise issue") Ref: https://lists.freedesktop.org/archives/amd-gfx/2021-August/067413.html Signed-off-by: Koba Ko Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 654b40ff096ef8493efd8fe90c10cce6c563b0f1 Author: Arnd Bergmann Date: Thu Jul 22 11:06:44 2021 +0200 thermal/core: Fix thermal_cooling_device_register() prototype [ Upstream commit fb83610762dd5927212aa62a468dd3b756b57a88 ] There are two pairs of declarations for thermal_cooling_device_register() and thermal_of_cooling_device_register(), and only one set was changed in a recent patch, so the other one now causes a compile-time warning: drivers/net/wireless/mediatek/mt76/mt7915/init.c: In function 'mt7915_thermal_init': drivers/net/wireless/mediatek/mt76/mt7915/init.c:134:48: error: passing argument 1 of 'thermal_cooling_device_register' discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers] 134 | cdev = thermal_cooling_device_register(wiphy_name(wiphy), phy, | ^~~~~~~~~~~~~~~~~ In file included from drivers/net/wireless/mediatek/mt76/mt7915/init.c:7: include/linux/thermal.h:407:39: note: expected 'char *' but argument is of type 'const char *' 407 | thermal_cooling_device_register(char *type, void *devdata, | ~~~~~~^~~~ Change the dummy helper functions to have the same arguments as the normal version. Fixes: f991de53a8ab ("thermal: make device_register's type argument const") Signed-off-by: Arnd Bergmann Reviewed-by: Jean-Francois Dagenais Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210722090717.1116748-1-arnd@kernel.org Signed-off-by: Sasha Levin commit 57df1f724b35bda1769746344f24f2e7d657b1fb Author: Masami Hiramatsu Date: Thu Sep 9 04:38:03 2021 +0900 tracing/boot: Fix to loop on only subkeys [ Upstream commit cfd799837dbc48499abb05d1891b3d9992354d3a ] Since the commit e5efaeb8a8f5 ("bootconfig: Support mixing a value and subkeys under a key") allows to co-exist a value node and key nodes under a node, xbc_node_for_each_child() is not only returning key node but also a value node. In the boot-time tracing using xbc_node_for_each_child() to iterate the events, groups and instances, but those must be key nodes. Thus it must use xbc_node_for_each_subkey(). Link: https://lkml.kernel.org/r/163112988361.74896.2267026262061819145.stgit@devnote2 Fixes: e5efaeb8a8f5 ("bootconfig: Support mixing a value and subkeys under a key") Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 59faa7816df1b45c4964e6881ab036df9afa3785 Author: Masami Hiramatsu Date: Sun Sep 5 00:54:31 2021 +0900 tools/bootconfig: Fix tracing_on option checking in ftrace2bconf.sh [ Upstream commit 32ba9f0fb027cc43074e3ea26fcf831adeee8e03 ] Since tracing_on indicates only "1" (default) or "0", ftrace2bconf.sh only need to check the value is "0". Link: https://lkml.kernel.org/r/163077087144.222577.6888011847727968737.stgit@devnote2 Fixes: 55ed4560774d ("tools/bootconfig: Add tracing_on support to helper scripts") Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit bdf3f584913c0312fd5729491a3f8f749d1544d9 Author: Lukas Bulwahn Date: Tue Sep 7 20:00:47 2021 -0700 Kconfig.debug: drop selecting non-existing HARDLOCKUP_DETECTOR_ARCH [ Upstream commit 6fe26259b4884b657cbc233fb9cdade9d704976e ] Commit 05a4a9527931 ("kernel/watchdog: split up config options") adds a new config HARDLOCKUP_DETECTOR, which selects the non-existing config HARDLOCKUP_DETECTOR_ARCH. Hence, ./scripts/checkkconfigsymbols.py warns: HARDLOCKUP_DETECTOR_ARCH Referencing files: lib/Kconfig.debug Simply drop selecting the non-existing HARDLOCKUP_DETECTOR_ARCH. Link: https://lkml.kernel.org/r/20210806115618.22088-1-lukas.bulwahn@gmail.com Fixes: 05a4a9527931 ("kernel/watchdog: split up config options") Signed-off-by: Lukas Bulwahn Cc: Nicholas Piggin Cc: Masahiro Yamada Cc: Babu Moger Cc: Don Zickus Cc: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 71f9ab9c157cb64007da47ecec6fcf3d4be4d57e Author: Rasmus Villemoes Date: Tue Sep 7 20:00:03 2021 -0700 init: move usermodehelper_enable() to populate_rootfs() [ Upstream commit b234ed6d629420827e2839c8c8935be85a0867fd ] Currently, usermodehelper is enabled right before PID1 starts going through the initcalls. However, any call of a usermodehelper from a pure_, core_, postcore_, arch_, subsys_ or fs_ initcall is futile, as there is no filesystem contents yet. Up until commit e7cb072eb988 ("init/initramfs.c: do unpacking asynchronously"), such calls, whether via some request_module(), a legacy uevent "/sbin/hotplug" notification or something else, would just fail silently with (presumably) -ENOENT from kernel_execve(). However, that commit introduced the wait_for_initramfs() synchronization hook which must be called from the usermodehelper exec path right before the kernel_execve, in order that request_module() et al done from *after* rootfs_initcall() time (i.e. device_ and late_ initcalls) would continue to find a populated initramfs as they used to. Any call of wait_for_initramfs() done before the unpacking has been scheduled (i.e. before rootfs_initcall time) must just return immediately [and let the caller find an empty file system] in order not to deadlock the machine. I mistakenly thought, and my limited testing confirmed, that there were no such calls, so I added a pr_warn_once() in wait_for_initramfs(). It turns out that one can indeed hit request_module() as well as kobject_uevent_env() during those early init calls, leading to a user-visible warning in the kernel log emitted consistently for certain configurations. We could just remove the pr_warn_once(), but I think it's better to postpone enabling the usermodehelper framework until there is at least some chance of finding the executable. That is also a little more efficient in that a lot of work done in umh.c will be elided. However, it does change the error seen by those early callers from -ENOENT to -EBUSY, so there is a risk of a regression if any caller care about the exact error value. Link: https://lkml.kernel.org/r/20210728134638.329060-1-linux@rasmusvillemoes.dk Fixes: e7cb072eb988 ("init/initramfs.c: do unpacking asynchronously") Signed-off-by: Rasmus Villemoes Reported-by: Alexander Egorenkov Reported-by: Bruno Goncalves Reported-by: Heiner Kallweit Cc: Luis Chamberlain Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 4abef9e1103540c8119d502b047e16e4d47f3e6b Author: Geert Uytterhoeven Date: Tue Sep 7 19:58:36 2021 -0700 math: RATIONAL_KUNIT_TEST should depend on RATIONAL instead of selecting it [ Upstream commit 8ba739ede49dec361ddcb70afe24986b4b8cfe17 ] RATIONAL_KUNIT_TEST selects RATIONAL, thus enabling an optional feature the user may not want to have enabled. Fix this by making the test depend on RATIONAL instead. Link: https://lkml.kernel.org/r/20210706100945.3803694-3-geert@linux-m68k.org Fixes: b6c75c4afceb8bc0 ("lib/math/rational: add Kunit test cases") Signed-off-by: Geert Uytterhoeven Cc: Andy Shevchenko Cc: Brendan Higgins Cc: Colin Ian King Cc: Trent Piepho Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 7e68a2bd21691ecc7e00a830f111a2fb77187ab8 Author: NeilBrown Date: Mon Aug 30 08:36:34 2021 +1000 SUNRPC: don't pause on incomplete allocation [ Upstream commit e38b3f20059426a0adbde014ff71071739ab5226 ] alloc_pages_bulk_array() attempts to allocate at least one page based on the provided pages, and then opportunistically allocates more if that can be done without dropping the spinlock. So if it returns fewer than requested, that could just mean that it needed to drop the lock. In that case, try again immediately. Only pause for a time if no progress could be made. Reported-and-tested-by: Mike Javorski Reported-and-tested-by: Lothar Paltins Fixes: f6e70aab9dfe ("SUNRPC: refresh rq_pages using a bulk page allocator") Signed-off-by: NeilBrown Acked-by: Mel Gorman Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit bf55b052cfeb0cea9493b3fd0921624423313a7b Author: Heiko Carstens Date: Fri Aug 27 13:45:14 2021 +0200 s390/entry: make oklabel within CHKSTG macro local [ Upstream commit 15256194eff64f9a774b33b7817ea663e352394a ] Make the oklabel within the CHKSTG macro local. This makes sure that tools like objdump and the crash debugging tool still disassemble full functions where the macro has been used instead of stopping half way where such a global label is used and one has to guess how to disassemble the rest of such a function: E.g.: 0000000000cb0270 : cb0270: b2 05 03 20 stck 800 ... cb0354: a7 74 00 97 jne cb0482 0000000000cb0358 : cb0358: c0 e0 00 22 4e 8f larl %r14,10fa076 ... Fixes: d35925b34996 ("s390/mcck: move storage error checks to assembler") Reviewed-by: Alexander Gordeev Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 674534e6327e334fa3d212ccb7c3be0134fb4efb Author: Gwendal Grignou Date: Mon Aug 30 11:00:50 2021 -0700 platform/chrome: cros_ec_trace: Fix format warnings [ Upstream commit 4665584888ad2175831c972c004115741ec799e9 ] Fix printf format issues in new tracing events. Fixes: 814318242687 ("platform/chrome: cros_ec_trace: Add fields to command traces") Signed-off-by: Gwendal Grignou Link: https://lore.kernel.org/r/20210830180050.2077261-1-gwendal@chromium.org Signed-off-by: Benson Leung Signed-off-by: Sasha Levin commit c3315f6436e7ad4b32ce929a216da7bc077a3e40 Author: Gwendal Grignou Date: Thu May 13 17:57:33 2021 -0700 platform/chrome: sensorhub: Add trace events for sample [ Upstream commit d453ceb6549af8798913de6a20444cb7200fdb69 ] Add trace event to report samples and their timestamp coming from the EC. It allows to check if the timestamps are correct and the filter is working correctly without introducing too much latency. To enable these events: cd /sys/kernel/debug/tracing/ echo 1 > events/cros_ec/enable echo 0 > events/cros_ec/cros_ec_request_start/enable echo 0 > events/cros_ec/cros_ec_request_done/enable echo 1 > tracing_on cat trace_pipe Observe event flowing: irq/105-chromeo-95 [000] .... 613.659758: cros_ec_sensorhub_timestamp: ... irq/105-chromeo-95 [000] .... 613.665219: cros_ec_sensorhub_filter: dx: ... Signed-off-by: Gwendal Grignou Signed-off-by: Enric Balletbo i Serra Signed-off-by: Sasha Levin commit 0e53af9116e41528e9c5c3278f675a2562ee9a2f Author: Dave Jiang Date: Tue Aug 3 15:37:15 2021 -0700 dmaengine: idxd: clear block on fault flag when clear wq [ Upstream commit bd2f4ae5e019efcfadd6b491204fd60adf14f4a3 ] The block on fault flag is not cleared when we disable or reset wq. This causes it to remain set if the user does not clear it on the next configuration load. Add clear of flag in dxd_wq_disable_cleanup() routine. Fixes: da32b28c95a7 ("dmaengine: idxd: cleanup workqueue config after disabling") Signed-off-by: Dave Jiang Link: https://lore.kernel.org/r/162803023553.3086015.8158952172068868803.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit ecf3158aad685a26f394dccb47201151c6688edb Author: Dave Jiang Date: Thu Jul 22 13:10:51 2021 -0700 dmaengine: idxd: fix abort status check [ Upstream commit b60bb6e2bfc192091b8f792781b83b5e0f9324f6 ] Coverity static analysis of linux-next found issue. The check (status == IDXD_COMP_DESC_ABORT) is always false since status was previously masked with 0x7f and IDXD_COMP_DESC_ABORT is 0xff. Fixes: 6b4b87f2c31a ("dmaengine: idxd: fix submission race window") Reported-by: Colin Ian King Signed-off-by: Dave Jiang Link: https://lore.kernel.org/r/162698465160.3560828.18173186265683415384.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 858343654607939f8fddb6e0473c5b35e48c5b60 Author: Dave Jiang Date: Thu Jul 22 10:54:10 2021 -0700 dmaengine: idxd: fix wq slot allocation index check [ Upstream commit 673d812d30be67942762bb9e8548abb26a3ba4a7 ] The sbitmap wait and allocate routine checks the index that is returned from sbitmap_queue_get(). It should be idxd >= 0 as 0 is also a valid index. This fixes issue where submission path hangs when WQ size is 1. Fixes: 0705107fcc80 ("dmaengine: idxd: move submission to sbitmap_queue") Signed-off-by: Dave Jiang Link: https://lore.kernel.org/r/162697645067.3478714.506720687816951762.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 6c578df6fdd9b76c2b409f73b0145330b4865dc3 Author: Dave Jiang Date: Thu Jun 3 11:01:37 2021 -0700 dmaengine: idxd: have command status always set [ Upstream commit 53499d1fc11267e078557fc68ce943c1eb3b7a37 ] The cached command status is only set when the write back status is is passed in. Move the variable set outside of the check so it is always set. Fixes: 0d5c10b4c84d ("dmaengine: idxd: add work queue drain support") Reported-by: Ramesh Thomas Signed-off-by: Dave Jiang Link: https://lore.kernel.org/r/162274329740.1822314.3443875665504707588.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit acf769fe268d18a093638217970018e9761ab34e Author: Dave Jiang Date: Fri Jun 4 17:06:21 2021 -0700 dmanegine: idxd: cleanup all device related bits after disabling device [ Upstream commit 0dcfe41e9a4ca759ccc87a48e3bb9cc3b08ff1e8 ] The previous state cleanup patch only performed wq state cleanups. This does not go far enough as when device is disabled or reset, the state for groups and engines must also be cleaned up. Add additional state cleanup beyond wq cleanup. Tie those cleanups directly to device disable and reset, and wq disable and reset. Fixes: da32b28c95a7 ("dmaengine: idxd: cleanup workqueue config after disabling") Signed-off-by: Dave Jiang Link: https://lore.kernel.org/r/162285154108.2096632.5572805472362321307.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 81680e81b71ac64eb66e590da152f674fa4dfcde Author: Uwe Kleine-König Date: Wed Jul 7 18:27:50 2021 +0200 pwm: mxs: Don't modify HW state in .probe() after the PWM chip was registered commit 020162d6f49f2963062229814a56a89c86cbeaa8 upstream. This fixes a race condition: After pwmchip_add() is called there might already be a consumer and then modifying the hardware behind the consumer's back is bad. So reset before calling pwmchip_add(). Note that reseting the hardware isn't the right thing to do if the PWM is already running as it might e.g. disable (or even enable) a backlight that is supposed to be on (or off). Fixes: 4dce82c1e840 ("pwm: add pwm-mxs support") Cc: Sascha Hauer Cc: Shawn Guo Signed-off-by: Uwe Kleine-König Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit 1c90a357cef4219cb436e59cc7463888103e104b Author: Uwe Kleine-König Date: Wed Jul 7 18:27:49 2021 +0200 pwm: lpc32xx: Don't modify HW state in .probe() after the PWM chip was registered commit 3d2813fb17e5fd0d73c1d1442ca0192bde4af10e upstream. This fixes a race condition: After pwmchip_add() is called there might already be a consumer and then modifying the hardware behind the consumer's back is bad. So set the default before. (Side-note: I don't know what this register setting actually does, if this modifies the polarity there is an inconsistency because the inversed polarity isn't considered if the PWM is already running during .probe().) Fixes: acfd92fdfb93 ("pwm: lpc32xx: Set PWM_PIN_LEVEL bit to default value") Cc: Sylvain Lemieux Signed-off-by: Uwe Kleine-König Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit ec33d4bcec801ca07d57e63432b8d3fdc984b1ea Author: Jeff Layton Date: Tue Jul 27 15:47:12 2021 -0400 ceph: cancel delayed work instead of flushing on mdsc teardown commit b4002173b7989588b6feaefc42edaf011b596782 upstream. The first thing metric_delayed_work does is check mdsc->stopping, and then return immediately if it's set. That's good since we would have already torn down the metric structures at this point, otherwise, but there is no locking around mdsc->stopping. It's possible that the ceph_metric_destroy call could race with the delayed_work, in which case we could end up with the delayed_work accessing destroyed percpu variables. At this point in the mdsc teardown, the "stopping" flag has already been set, so there's no benefit to flushing the work. Move the work cancellation in ceph_metric_destroy ahead of the percpu variable destruction, and eliminate the flush_delayed_work call in ceph_mdsc_destroy. Fixes: 18f473b384a6 ("ceph: periodically send perf metrics to MDSes") Signed-off-by: Jeff Layton Reviewed-by: Xiubo Li Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 02006feaf26f750aa2404ad4178d95528bfd8922 Author: Matthias Kaehlcke Date: Mon Aug 23 13:47:30 2021 -0700 thermal/drivers/qcom/spmi-adc-tm5: Don't abort probing if a sensor is not used commit 70ee251ded6ba24c15537f4abb8a318e233d0d1a upstream. adc_tm5_register_tzd() registers the thermal zone sensors for all channels of the thermal monitor. If the registration of one channel fails the function skips the processing of the remaining channels and returns an error, which results in _probe() being aborted. One of the reasons the registration could fail is that none of the thermal zones is using the channel/sensor, which hardly is a critical error (if it is an error at all). If this case is detected emit a warning and continue with processing the remaining channels. Fixes: ca66dca5eda6 ("thermal: qcom: add support for adc-tm5 PMIC thermal monitor") Signed-off-by: Matthias Kaehlcke Reported-by: Stephen Boyd Reviewed-by: Stephen Boyd Reviewed-by: Dmitry Baryshkov Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210823134726.1.I1dd23ddf77e5b3568625d80d6827653af071ce19@changeid Signed-off-by: Greg Kroah-Hartman commit 04864f20674f0a631d5e74c009ce17dbab1a15ed Author: Prasad Sodagudi Date: Tue Sep 7 04:24:23 2021 -0700 PM: sleep: core: Avoid setting power.must_resume to false commit 4a9344cd0aa4499beb3772bbecb40bb78888c0e1 upstream. There are variables(power.may_skip_resume and dev->power.must_resume) and DPM_FLAG_MAY_SKIP_RESUME flags to control the resume of devices after a system wide suspend transition. Setting the DPM_FLAG_MAY_SKIP_RESUME flag means that the driver allows its "noirq" and "early" resume callbacks to be skipped if the device can be left in suspend after a system-wide transition into the working state. PM core determines that the driver's "noirq" and "early" resume callbacks should be skipped or not with dev_pm_skip_resume() function by checking power.may_skip_resume variable. power.must_resume variable is getting set to false in __device_suspend() function without checking device's DPM_FLAG_MAY_SKIP_RESUME settings. In problematic scenario, where all the devices in the suspend_late stage are successful and some device can fail to suspend in suspend_noirq phase. So some devices successfully suspended in suspend_late stage are not getting chance to execute __device_suspend_noirq() to set dev->power.must_resume variable to true and not getting resumed in early_resume phase. Add a check for device's DPM_FLAG_MAY_SKIP_RESUME flag before setting power.must_resume variable in __device_suspend function. Fixes: 6e176bf8d461 ("PM: sleep: core: Do not skip callbacks in the resume phase") Signed-off-by: Prasad Sodagudi Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 07906d13ba6b918dbb8f01c7d3481055f9356f4d Author: Pavel Skripkin Date: Tue Sep 7 19:58:21 2021 -0700 profiling: fix shift-out-of-bounds bugs commit 2d186afd04d669fe9c48b994c41a7405a3c9f16d upstream. Syzbot reported shift-out-of-bounds bug in profile_init(). The problem was in incorrect prof_shift. Since prof_shift value comes from userspace we need to clamp this value into [0, BITS_PER_LONG -1] boundaries. Second possible shiht-out-of-bounds was found by Tetsuo: sample_step local variable in read_profile() had "unsigned int" type, but prof_shift allows to make a BITS_PER_LONG shift. So, to prevent possible shiht-out-of-bounds sample_step type was changed to "unsigned long". Also, "unsigned short int" will be sufficient for storing [0, BITS_PER_LONG] value, that's why there is no need for "unsigned long" prof_shift. Link: https://lkml.kernel.org/r/20210813140022.5011-1-paskripkin@gmail.com Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-and-tested-by: syzbot+e68c89a9510c159d9684@syzkaller.appspotmail.com Suggested-by: Tetsuo Handa Signed-off-by: Pavel Skripkin Cc: Thomas Gleixner Cc: Steven Rostedt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ada62fe1bdbc85317bcb6005445bd9c1f4109ee3 Author: Zhen Lei Date: Tue Sep 7 20:00:26 2021 -0700 nilfs2: use refcount_dec_and_lock() to fix potential UAF commit 98e2e409e76ef7781d8511f997359e9c504a95c1 upstream. When the refcount is decreased to 0, the resource reclamation branch is entered. Before CPU0 reaches the race point (1), CPU1 may obtain the spinlock and traverse the rbtree to find 'root', see nilfs_lookup_root(). Although CPU1 will call refcount_inc() to increase the refcount, it is obviously too late. CPU0 will release 'root' directly, CPU1 then accesses 'root' and triggers UAF. Use refcount_dec_and_lock() to ensure that both the operations of decrease refcount to 0 and link deletion are lock protected eliminates this risk. CPU0 CPU1 nilfs_put_root(): <-------- (1) spin_lock(&nilfs->ns_cptree_lock); rb_erase(&root->rb_node, &nilfs->ns_cptree); spin_unlock(&nilfs->ns_cptree_lock); kfree(root); <-------- use-after-free refcount_t: underflow; use-after-free. WARNING: CPU: 2 PID: 9476 at lib/refcount.c:28 \ refcount_warn_saturate+0x1cf/0x210 lib/refcount.c:28 Modules linked in: CPU: 2 PID: 9476 Comm: syz-executor.0 Not tainted 5.10.45-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), ... RIP: 0010:refcount_warn_saturate+0x1cf/0x210 lib/refcount.c:28 ... ... Call Trace: __refcount_sub_and_test include/linux/refcount.h:283 [inline] __refcount_dec_and_test include/linux/refcount.h:315 [inline] refcount_dec_and_test include/linux/refcount.h:333 [inline] nilfs_put_root+0xc1/0xd0 fs/nilfs2/the_nilfs.c:795 nilfs_segctor_destroy fs/nilfs2/segment.c:2749 [inline] nilfs_detach_log_writer+0x3fa/0x570 fs/nilfs2/segment.c:2812 nilfs_put_super+0x2f/0xf0 fs/nilfs2/super.c:467 generic_shutdown_super+0xcd/0x1f0 fs/super.c:464 kill_block_super+0x4a/0x90 fs/super.c:1446 deactivate_locked_super+0x6a/0xb0 fs/super.c:335 deactivate_super+0x85/0x90 fs/super.c:366 cleanup_mnt+0x277/0x2e0 fs/namespace.c:1118 __cleanup_mnt+0x15/0x20 fs/namespace.c:1125 task_work_run+0x8e/0x110 kernel/task_work.c:151 tracehook_notify_resume include/linux/tracehook.h:188 [inline] exit_to_user_mode_loop kernel/entry/common.c:164 [inline] exit_to_user_mode_prepare+0x13c/0x170 kernel/entry/common.c:191 syscall_exit_to_user_mode+0x16/0x30 kernel/entry/common.c:266 do_syscall_64+0x45/0x80 arch/x86/entry/common.c:56 entry_SYSCALL_64_after_hwframe+0x44/0xa9 There is no reproduction program, and the above is only theoretical analysis. Link: https://lkml.kernel.org/r/1629859428-5906-1-git-send-email-konishi.ryusuke@gmail.com Fixes: ba65ae4729bf ("nilfs2: add checkpoint tree to nilfs object") Link: https://lkml.kernel.org/r/20210723012317.4146-1-thunder.leizhen@huawei.com Signed-off-by: Zhen Lei Signed-off-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 154d764b1f8273b4c98c863532ff875c046168b8 Author: Cyrill Gorcunov Date: Tue Sep 7 20:00:41 2021 -0700 prctl: allow to setup brk for et_dyn executables commit e1fbbd073137a9d63279f6bf363151a938347640 upstream. Keno Fischer reported that when a binray loaded via ld-linux-x the prctl(PR_SET_MM_MAP) doesn't allow to setup brk value because it lays before mm:end_data. For example a test program shows | # ~/t | | start_code 401000 | end_code 401a15 | start_stack 7ffce4577dd0 | start_data 403e10 | end_data 40408c | start_brk b5b000 | sbrk(0) b5b000 and when executed via ld-linux | # /lib64/ld-linux-x86-64.so.2 ~/t | | start_code 7fc25b0a4000 | end_code 7fc25b0c4524 | start_stack 7fffcc6b2400 | start_data 7fc25b0ce4c0 | end_data 7fc25b0cff98 | start_brk 55555710c000 | sbrk(0) 55555710c000 This of course prevent criu from restoring such programs. Looking into how kernel operates with brk/start_brk inside brk() syscall I don't see any problem if we allow to setup brk/start_brk without checking for end_data. Even if someone pass some weird address here on a purpose then the worst possible result will be an unexpected unmapping of existing vma (own vma, since prctl works with the callers memory) but test for RLIMIT_DATA is still valid and a user won't be able to gain more memory in case of expanding VMAs via new values shipped with prctl call. Link: https://lkml.kernel.org/r/20210121221207.GB2174@grain Fixes: bbdc6076d2e5 ("binfmt_elf: move brk out of mmap when doing direct loader exec") Signed-off-by: Cyrill Gorcunov Reported-by: Keno Fischer Acked-by: Andrey Vagin Tested-by: Andrey Vagin Cc: Dmitry Safonov <0x7f454c46@gmail.com> Cc: Kirill Tkhai Cc: Eric W. Biederman Cc: Pavel Tikhomirov Cc: Alexander Mikhalitsyn Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 861006fa37d88419c4cfa0a4468d1638bf1f31fa Author: Uwe Kleine-König Date: Mon Jul 5 18:55:10 2021 +0200 pwm: ab8500: Fix register offset calculation to not depend on probe order commit eb41f334589d66b9da6f2b1acf7963ef8ca8d94e upstream. The assumption that lead to commit 5e5da1e9fbee ("pwm: ab8500: Explicitly allocate pwm chip base dynamically") was wrong: The pwm-ab8500 devices are not directly instantiated from device tree, but from the ab8500 mfd driver. So the pdev->id isn't -1, but a number between 1 and 3. Now that pwmchip ids are always allocated dynamically, this cannot easily be reverted. Introduce a new member in the driver data struct that tracks the hardware id and use this to calculate the register offset. Side-note: Using chip->base to calculate the offset was never robust because if there was already a PWM with id 1 at the time ab8500-pwm.1 was probed, the associated pwmchip would get assigned chip->base = 2 (or something bigger). Fixes: 5e5da1e9fbee ("pwm: ab8500: Explicitly allocate pwm chip base dynamically") Fixes: 6173f8f4ed9c ("pwm: Move AB8500 PWM driver to PWM framework") Signed-off-by: Uwe Kleine-König Acked-by: Linus Walleij Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit bc013a3943afd300d8cda8771c2a57fc58789353 Author: Xie Yongji Date: Mon May 17 16:35:57 2021 +0800 9p/trans_virtio: Remove sysfs file on probe failure commit f997ea3b7afc108eb9761f321b57de2d089c7c48 upstream. This ensures we don't leak the sysfs file if we failed to allocate chan->vc_wq during probe. Link: http://lkml.kernel.org/r/20210517083557.172-1-xieyongji@bytedance.com Fixes: 86c8437383ac ("net/9p: Add sysfs mount_tag file for virtio 9P device") Signed-off-by: Xie Yongji Signed-off-by: Dominique Martinet Signed-off-by: Greg Kroah-Hartman commit e0e873820b55d1e1b6f433c0b3eda6a9cdcbc76d Author: Dan Carpenter Date: Tue Aug 10 11:44:13 2021 +0300 thermal/drivers/exynos: Fix an error code in exynos_tmu_probe() commit 02d438f62c05f0d055ceeedf12a2f8796b258c08 upstream. This error path return success but it should propagate the negative error code from devm_clk_get(). Fixes: 6c247393cfdd ("thermal: exynos: Add TMU support for Exynos7 SoC") Signed-off-by: Dan Carpenter Reviewed-by: Krzysztof Kozlowski Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210810084413.GA23810@kili Signed-off-by: Greg Kroah-Hartman commit 61c87f0674e59aa31f86220c7f400f676edd1605 Author: Yang Yingliang Date: Thu Sep 9 17:06:08 2021 +0800 n64cart: fix return value check in n64cart_probe() commit 221e8360834c59f0c9952630fa5904a94ebd2bb8 upstream. In case of error, the function devm_platform_ioremap_resource() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Fixes: d9b2a2bbbb4d ("block: Add n64 cart driver") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Reviewed-by: Chaitanya Kulkarni Link: https://lore.kernel.org/r/20210909090608.2989716-1-yangyingliang@huawei.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 8843c3dc1ad215f866a582a964877f8e92b6ed7e Author: Fabio Aiuto Date: Thu Jul 15 16:57:00 2021 +0200 staging: rtl8723bs: fix wpa_set_auth_algs() function commit b658acbf64ae38b8fca982c2929ccc0bf4eb1ea2 upstream. fix authentication algorithm constants. wpa_set_auth_algs() function contains some conditional statements masking the checked value with the wrong constants. This produces some unintentional dead code. Mask the value with the right macros. Fixes: 5befa937e8da ("staging: rtl8723bs: Fix IEEE80211 authentication algorithm constants.") Reported-by: Colin Ian King Tested-on: Lenovo Ideapad MiiX 300-10IBY Signed-off-by: Fabio Aiuto Link: https://lore.kernel.org/r/20210715145700.9427-1-fabioaiuto83@gmail.com Signed-off-by: Greg Kroah-Hartman commit 24a026e4ae1d7a9f7889d2ce6202be3e1ea6a3c0 Author: Namhyung Kim Date: Fri Sep 10 15:46:30 2021 -0700 perf tools: Allow build-id with trailing zeros commit 4a86d41404005a3c7e7b6065e8169ac6202887a9 upstream. Currently perf saves a build-id with size but old versions assumes the size of 20. In case the build-id is less than 20 (like for MD5), it'd fill the rest with 0s. I saw a problem when old version of perf record saved a binary in the build-id cache and new version of perf reads the data. The symbols should be read from the build-id cache (as the path no longer has the same binary) but it failed due to mismatch in the build-id. symsrc__init: build id mismatch for /home/namhyung/.debug/.build-id/53/e4c2f42a4c61a2d632d92a72afa08f00000000/elf. The build-id event in the data has 20 byte build-ids, but it saw a different size (16) when it reads the build-id of the elf file in the build-id cache. $ readelf -n ~/.debug/.build-id/53/e4c2f42a4c61a2d632d92a72afa08f00000000/elf Displaying notes found in: .note.gnu.build-id Owner Data size Description GNU 0x00000010 NT_GNU_BUILD_ID (unique build ID bitstring) Build ID: 53e4c2f42a4c61a2d632d92a72afa08f Let's fix this by allowing trailing zeros if the size is different. Fixes: 39be8d0115b321ed ("perf tools: Pass build_id object to dso__build_id_equal()") Signed-off-by: Namhyung Kim Acked-by: Jiri Olsa Cc: Andi Kleen Cc: Ian Rogers Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20210910224630.1084877-1-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 60a830dc0a2ba7a93bb3c9625d1f476a5e1e9dc8 Author: Remi Bernon Date: Thu Sep 9 21:26:36 2021 +0200 perf symbol: Look for ImageBase in PE file to compute .text offset commit d2930ede5218be28413a00130a6895d14393c325 upstream. Instead of using the file offset in the debug file. This fixes a regression from 00a3423492bc90be ("perf symbols: Make dso__load_bfd_symbols() load PE files from debug cache only"), causing incorrect symbol resolution when debug file have been stripped from non-debug sections (in which case its .text section is empty and doesn't have any file position). The debug files could also be created with a different file alignment, and have different file positions from the mmap-ed binary, or have the section reordered. This instead looks for the file image base, using the corresponding bfd *ABS* symbols. As PE symbols only have 4 bytes, it also needs to keep .text section vma high bits. Signed-off-by: Remi Bernon Fixes: 00a3423492bc90be ("perf symbols: Make dso__load_bfd_symbols() load PE files from debug cache only") Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Nicholas Fraser Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20210909192637.4139125-1-rbernon@codeweavers.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit d4e7c85ae25f9402a50da7c7d4d3bc3470079c1b Author: Michael Petlan Date: Thu Aug 5 18:06:11 2021 +0200 perf test: Fix bpf test sample mismatch reporting commit 3e11300cdfd5f1bc13a05dfc6dccf69aca5dd1dc upstream. When the expected sample count in the condition changed, the message needs to be changed too, otherwise we'll get: 0x1001f2091d8: mmap mask[0]: BPF filter result incorrect, expected 56, got 56 samples Fixes: 4b04e0decd2518e5 ("perf test: Fix basic bpf filtering test") Signed-off-by: Michael Petlan Cc: Jiri Olsa Cc: Sumanth Korikkar Link: https //lore.kernel.org/r/20210805160611.5542-1-mpetlan@redhat.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit b005ce62b39c8e14a41cfe96325bbe248ad5dce3 Author: Andy Shevchenko Date: Fri Jul 30 23:27:15 2021 +0300 dmaengine: acpi: Avoid comparison GSI with Linux vIRQ commit 67db87dc8284070adb15b3c02c1c31d5cf51c5d6 upstream. Currently the CRST parsing relies on the fact that on most of x86 devices the IRQ mapping is 1:1 with Linux vIRQ. However, it may be not true for some. Fix this by converting GSI to Linux vIRQ before checking it. Fixes: ee8209fd026b ("dma: acpi-dma: parse CSRT to extract additional resources") Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210730202715.24375-1-andriy.shevchenko@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit e0291e6fb03d20f7852e70c063f959fd46f4d0ad Author: Niklas Schnelle Date: Wed Sep 8 10:18:49 2021 +0200 RDMA/mlx5: Fix xlt_chunk_align calculation commit f4c6f31011eafe027abddf6cee1288a1b5a05b73 upstream. The XLT chunk alignment depends on ent_size not sizeof(ent_size) aka sizeof(size_t). The incoming ent_size is either 8 or 16, so the miscalculation when 16 is required is only an over-alignment and functional harmless. Fixes: 8010d74b9965 ("RDMA/mlx5: Split the WR setup out of mlx5_ib_update_xlt()") Link: https://lore.kernel.org/r/20210908081849.7948-2-schnelle@linux.ibm.com Signed-off-by: Niklas Schnelle Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit e00e0ed534a2f4271b7701e4b4ef20f32afae0d9 Author: Yixing Liu Date: Sat Aug 21 17:53:26 2021 +0800 RDMA/hns: Enable stash feature of HIP09 commit 260f64a40198309008026447f7fda277a73ed8c3 upstream. The stash feature is enabled by default on HIP09. Fixes: f93c39bc9547 ("RDMA/hns: Add support for QP stash") Fixes: bfefae9f108d ("RDMA/hns: Add support for CQ stash") Link: https://lore.kernel.org/r/1629539607-33217-3-git-send-email-liangwenpeng@huawei.com Signed-off-by: Yixing Liu Signed-off-by: Wenpeng Liang Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 6909fa41fbd42a7be7fbbc64d8100e6ee5398667 Author: Johannes Berg Date: Fri Jun 25 10:34:37 2021 +0200 um: virtio_uml: fix memory leak on init failures commit 7ad28e0df7ee9dbcb793bb88dd81d4d22bb9a10e upstream. If initialization fails, e.g. because the connection failed, we leak the 'vu_dev'. Fix that. Reported by smatch. Fixes: 5d38f324993f ("um: drivers: Add virtio vhost-user driver") Signed-off-by: Johannes Berg Acked-By: Anton Ivanov Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit dc25d3bebac1d1c0aa17d534b5a2a33a160c3943 Author: QiuXi Date: Tue Sep 7 20:00:32 2021 -0700 coredump: fix memleak in dump_vma_snapshot() commit 6fcac87e1f9e5b27805a2a404f4849194bb51de8 upstream. dump_vma_snapshot() allocs memory for *vma_meta, when dump_vma_snapshot() returns -EFAULT, the memory will be leaked, so we free it correctly. Link: https://lkml.kernel.org/r/20210810020441.62806-1-qiuxi1@huawei.com Fixes: a07279c9a8cd7 ("binfmt_elf, binfmt_elf_fdpic: use a VMA list snapshot") Signed-off-by: QiuXi Cc: Al Viro Cc: Jann Horn Cc: Greg Kroah-Hartman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 069c28830690a10f61a098868abdeb852c0e045b Author: Johannes Berg Date: Tue Jul 13 23:47:10 2021 +0200 um: fix stub location calculation commit adf9ae0d159d3dc94f58d788fc4757c8749ac0df upstream. In commit 9f0b4807a44f ("um: rework userspace stubs to not hard-code stub location") I changed stub_segv_handler() to do a calculation with a pointer to a stack variable to find the data page that we're using for the stack and the rest of the data. This same commit was meant to do it as well for stub_clone_handler(), but the change inadvertently went into commit 84b2789d6115 ("um: separate child and parent errors in clone stub") instead. This was reported to not be compiled correctly by gcc 5, causing the code to crash here. I'm not sure why, perhaps it's UB because the var isn't initialized? In any case, this trick always seemed bad, so just create a new inline function that does the calculation in assembly. Reported-by: subashab@codeaurora.org Fixes: 9f0b4807a44f ("um: rework userspace stubs to not hard-code stub location") Fixes: 84b2789d6115 ("um: separate child and parent errors in clone stub") Signed-off-by: Johannes Berg Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 5cd412eda5d6aba3abf013998fef80674eb31772 Author: Nathan Chancellor Date: Sat Aug 14 16:56:26 2021 -0700 staging: rtl8192u: Fix bitwise vs logical operator in TranslateRxSignalStuff819xUsb() commit 099ec97ac92911abfb102bb5c68ed270fc12e0dd upstream. clang warns: drivers/staging/rtl8192u/r8192U_core.c:4268:20: warning: bitwise and of boolean expressions; did you mean logical and? [-Wbool-operation-and] bpacket_toself = bpacket_match_bssid & ^~~~~~~~~~~~~~~~~~~~~ && 1 warning generated. Replace the bitwise AND with a logical one to clear up the warning, as that is clearly what was intended. Fixes: 8fc8598e61f6 ("Staging: Added Realtek rtl8192u driver to staging") Signed-off-by: Nathan Chancellor Link: https://lore.kernel.org/r/20210814235625.1780033-1-nathan@kernel.org Signed-off-by: Greg Kroah-Hartman commit f59fcad27535c7efd8017e084cf215ece392a85f Author: nick black Date: Mon Aug 30 04:56:15 2021 -0400 console: consume APC, DM, DCS commit 3a2b2eb55681158d3e3ef464fbf47574cf0c517c upstream. The Linux console's VT102 implementation already consumes OSC ("Operating System Command") sequences, probably because that's how palette changes are transmitted. In addition to OSC, there are three other major clases of ANSI control strings: APC ("Application Program Command"), PM ("Privacy Message"), and DCS ("Device Control String"). They are handled similarly to OSC in terms of termination. Source: vt100.net Add three new enumerated states, one for each of these types. All three are handled the same way right now--they simply consume input until terminated. I hope to expand upon this firmament in the future. Add new predicate ansi_control_string(), returning true for any of these states. Replace explicit checks against ESosc with calls to this function. Transition to these states appropriately from the escape initiation (ESesc) state. This was motivated by the following Notcurses bugs: https://github.com/dankamongmen/notcurses/issues/2050 https://github.com/dankamongmen/notcurses/issues/1828 https://github.com/dankamongmen/notcurses/issues/2069 where standard VT sequences are not consumed by the Linux console. It's not necessary that the Linux console *support* these sequences, but it ought *consume* these well-specified classes of sequences. Tested by sending a variety of escape sequences to the console, and verifying that they still worked, or were now properly consumed. Verified that the escapes were properly terminated at a generic level. Verified that the Notcurses tools continued to show expected output on the Linux console, except now without escape bleedthrough. Link: https://lore.kernel.org/lkml/YSydL0q8iaUfkphg@schwarzgerat.orthanc/ Signed-off-by: nick black Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: Tetsuo Handa Cc: Daniel Vetter Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit fb28e3d5d0d8c6c68f51a4f1c86e275fee0c03d5 Author: Pali Rohár Date: Thu Jul 22 16:40:41 2021 +0200 PCI: aardvark: Fix reporting CRS value commit 43f5c77bcbd27cce70bf33c2b86d6726ce95dd66 upstream. Set CRSVIS flag in emulated root PCI bridge to indicate support for Completion Retry Status. Add check for CRSSVE flag from root PCI brige when issuing Configuration Read Request via PIO to correctly returns fabricated CRS value as it is required by PCIe spec. Link: https://lore.kernel.org/r/20210722144041.12661-5-pali@kernel.org Fixes: 8a3ebd8de328 ("PCI: aardvark: Implement emulated root PCI bridge config space") Signed-off-by: Pali Rohár Signed-off-by: Lorenzo Pieralisi Cc: stable@vger.kernel.org # e0d9d30b7354 ("PCI: pci-bridge-emul: Fix big-endian support") Signed-off-by: Greg Kroah-Hartman commit 952d4ed0bd6588ae80ec6253ff299cbf96470809 Author: Pali Rohár Date: Thu Jul 22 16:40:40 2021 +0200 PCI: pci-bridge-emul: Add PCIe Root Capabilities Register commit e902bb7c24a7099d0eb0eb4cba06f2d91e9299f3 upstream. The 16-bit Root Capabilities register is at offset 0x1e in the PCIe Capability. Rename current 'rsvd' struct member to 'rootcap'. Link: https://lore.kernel.org/r/20210722144041.12661-4-pali@kernel.org Signed-off-by: Pali Rohár Signed-off-by: Lorenzo Pieralisi Reviewed-by: Marek Behún Signed-off-by: Greg Kroah-Hartman