user/sven/linux.git, branch v6.2.9

Linux 6.2.9

2023-03-30T10:51:43Z

Link: https://lore.kernel.org/r/20230328142619.643313678@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Markus Reichelt Tested-by: Justin M. Forbes Tested-by: Shuah Khan Tested-by: Bagas Sanjaya Tested-by: Ron Economos Tested-by: Chris Paterson (CIP) Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Conor Dooley Tested-by: Florian Fainelli Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

sched/fair: Sanitize vruntime of entity being migrated

2023-03-30T10:51:42Z

commit a53ce18cacb477dd0513c607f187d16f0fa96f71 upstream. Commit 829c1651e9c4 ("sched/fair: sanitize vruntime of entity being placed") fixes an overflowing bug, but ignore a case that se->exec_start is reset after a migration. For fixing this case, we delay the reset of se->exec_start after placing the entity which se->exec_start to detect long sleeping task. In order to take into account a possible divergence between the clock_task of 2 rqs, we increase the threshold to around 104 days. Fixes: 829c1651e9c4 ("sched/fair: sanitize vruntime of entity being placed") Originally-by: Zhang Qiao Signed-off-by: Vincent Guittot Signed-off-by: Peter Zijlstra (Intel) Tested-by: Zhang Qiao Link: https://lore.kernel.org/r/20230317160810.107988-1-vincent.guittot@linaro.org Signed-off-by: Greg Kroah-Hartman

sched/fair: sanitize vruntime of entity being placed

2023-03-30T10:51:42Z

commit 829c1651e9c4a6f78398d3e67651cef9bb6b42cc upstream. When a scheduling entity is placed onto cfs_rq, its vruntime is pulled to the base level (around cfs_rq->min_vruntime), so that the entity doesn't gain extra boost when placed backwards. However, if the entity being placed wasn't executed for a long time, its vruntime may get too far behind (e.g. while cfs_rq was executing a low-weight hog), which can inverse the vruntime comparison due to s64 overflow. This results in the entity being placed with its original vruntime way forwards, so that it will effectively never get to the cpu. To prevent that, ignore the vruntime of the entity being placed if it didn't execute for much longer than the characteristic sheduler time scale. [rkagan: formatted, adjusted commit log, comments, cutoff value] Signed-off-by: Zhang Qiao Co-developed-by: Roman Kagan Signed-off-by: Roman Kagan Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20230130122216.3555094-1-rkagan@amazon.de Signed-off-by: Greg Kroah-Hartman

dm crypt: avoid accessing uninitialized tasklet

2023-03-30T10:51:42Z

commit d9a02e016aaf5a57fb44e9a5e6da8ccd3b9e2e70 upstream. When neither "no_read_workqueue" nor "no_write_workqueue" are enabled, tasklet_trylock() in crypt_dec_pending() may still return false due to an uninitialized state, and dm-crypt will unnecessarily do io completion in io_queue workqueue instead of current context. Fix this by adding an 'in_tasklet' flag to dm_crypt_io struct and initialize it to false in crypt_io_init(). Set this flag to true in kcryptd_queue_crypt() before calling tasklet_schedule(). If set crypt_dec_pending() will punt io completion to a workqueue. This also nicely avoids the tasklet_trylock/unlock hack when tasklets aren't in use. Fixes: 8e14f610159d ("dm crypt: do not call bio_endio() from the dm-crypt tasklet") Cc: stable@vger.kernel.org Reported-by: Hou Tao Suggested-by: Ignat Korchagin Reviewed-by: Ignat Korchagin Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman

dm crypt: add cond_resched() to dmcrypt_write()

2023-03-30T10:51:42Z

commit fb294b1c0ba982144ca467a75e7d01ff26304e2b upstream. The loop in dmcrypt_write may be running for unbounded amount of time, thus we need cond_resched() in it. This commit fixes the following warning: [ 3391.153255][ C12] watchdog: BUG: soft lockup - CPU#12 stuck for 23s! [dmcrypt_write/2:2897] ... [ 3391.387210][ C12] Call trace: [ 3391.390338][ C12] blk_attempt_bio_merge.part.6+0x38/0x158 [ 3391.395970][ C12] blk_attempt_plug_merge+0xc0/0x1b0 [ 3391.401085][ C12] blk_mq_submit_bio+0x398/0x550 [ 3391.405856][ C12] submit_bio_noacct+0x308/0x380 [ 3391.410630][ C12] dmcrypt_write+0x1e4/0x208 [dm_crypt] [ 3391.416005][ C12] kthread+0x130/0x138 [ 3391.419911][ C12] ret_from_fork+0x10/0x18 Reported-by: yangerkun Fixes: dc2676210c42 ("dm crypt: offload writes to thread") Cc: stable@vger.kernel.org Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman

dm stats: check for and propagate alloc_percpu failure

2023-03-30T10:51:42Z

commit d3aa3e060c4a80827eb801fc448debc9daa7c46b upstream. Check alloc_precpu()'s return value and return an error from dm_stats_init() if it fails. Update alloc_dev() to fail if dm_stats_init() does. Otherwise, a NULL pointer dereference will occur in dm_stats_cleanup() even if dm-stats isn't being actively used. Fixes: fd2ed4d25270 ("dm: add statistics support") Cc: stable@vger.kernel.org Signed-off-by: Jiasheng Jiang Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman

i2c: xgene-slimpro: Fix out-of-bounds bug in xgene_slimpro_i2c_xfer()

2023-03-30T10:51:42Z

commit 92fbb6d1296f81f41f65effd7f5f8c0f74943d15 upstream. The data->block[0] variable comes from user and is a number between 0-255. Without proper check, the variable may be very large to cause an out-of-bounds when performing memcpy in slimpro_i2c_blkwr. Fix this bug by checking the value of writelen. Fixes: f6505fbabc42 ("i2c: add SLIMpro I2C device driver on APM X-Gene platform") Signed-off-by: Wei Chen Cc: stable@vger.kernel.org Reviewed-by: Andi Shyti Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman

bus: imx-weim: fix branch condition evaluates to a garbage value

2023-03-30T10:51:42Z

commit 1adab2922c58e7ff4fa9f0b43695079402cce876 upstream. If bus type is other than imx50_weim_devtype and have no child devices, variable 'ret' in function weim_parse_dt() will not be initialized, but will be used as branch condition and return value. Fix this by initializing 'ret' with 0. This was discovered with help of clang-analyzer, but the situation is quite possible in real life. Fixes: 52c47b63412b ("bus: imx-weim: improve error handling upon child probe-failure") Signed-off-by: Ivan Bornyakov Cc: stable@vger.kernel.org Reviewed-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman

mm/ksm: fix race with VMA iteration and mm_struct teardown

2023-03-30T10:51:41Z

commit 6db504ce55bdbc575723938fc480713c9183f6a2 upstream. exit_mmap() will tear down the VMAs and maple tree with the mmap_lock held in write mode. Ensure that the maple tree is still valid by checking ksm_test_exit() after taking the mmap_lock in read mode, but before the for_each_vma() iterator dereferences a destroyed maple tree. Since the maple tree is destroyed, the flags telling lockdep to check an external lock has been cleared. Skip the for_each_vma() iterator to avoid dereferencing a maple tree without the external lock flag, which would create a lockdep warning. Link: https://lkml.kernel.org/r/20230308220310.3119196-1-Liam.Howlett@oracle.com Fixes: a5f18ba07276 ("mm/ksm: use vma iterators instead of vma linked list") Signed-off-by: Liam R. Howlett Reported-by: Pengfei Xu Link: https://lore.kernel.org/lkml/ZAdUUhSbaa6fHS36@xpf.sh.intel.com/ Reported-by: syzbot+2ee18845e89ae76342c5@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=64a3e95957cd3deab99df7cd7b5a9475af92c93e Acked-by: David Hildenbrand Cc: Matthew Wilcox (Oracle) Cc: Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

soc: qcom: llcc: Fix slice configuration values for SC8280XP

2023-03-30T10:51:41Z

commit 77bf4b3ed42e31d29b255fcd6530fb7a1e217e89 upstream. The slice IDs for CVPFW, CPUSS1 and CPUWHT currently overflow the 32bit LLCC config registers, which means it is writing beyond the upper limit of the ATTR0_CFGn and ATTR1_CFGn range of registers. But the most obvious impact is the fact that the mentioned slices do not get configured at all, which will result in reduced performance. Fix that by using the slice ID values taken from the latest LLCC SC table. Fixes: ec69dfbdc426 ("soc: qcom: llcc: Add sc8180x and sc8280xp configurations") Cc: stable@vger.kernel.org # 5.19+ Signed-off-by: Abel Vesa Tested-by: Juerg Haefliger Reviewed-by: Sai Prakash Ranjan Acked-by: Konrad Dybcio Reviewed-by: Johan Hovold Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20230306135527.509796-1-abel.vesa@linaro.org Signed-off-by: Greg Kroah-Hartman