March 2023 - Linux-stable-mirror

patch "iio: adc: qcom-spmi-adc5: Fix the channel name" added to char-misc-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: adc: qcom-spmi-adc5: Fix the channel name to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. From 701c875aded880013aacac608832995c4b052257 Mon Sep 17 00:00:00 2001 From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Date: Wed, 18 Jan 2023 12:06:23 +0200 Subject: iio: adc: qcom-spmi-adc5: Fix the channel name The node name can contain an address part which is unused by the driver. Moreover, this string is propagated into the userspace label, sysfs filenames *and breaking ABI*. Cut the address part out before assigning the channel name. Fixes: 4f47a236a23d ("iio: adc: qcom-spmi-adc5: convert to device properties") Reported-by: Marijn Suijten <marijn.suijten(a)somainline.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Reviewed-by: Marijn Suijten <marijn.suijten(a)somainline.org> Link: https://lore.kernel.org/r/20230118100623.42255-1-andriy.shevchenko@linux.in… Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/qcom-spmi-adc5.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/iio/adc/qcom-spmi-adc5.c b/drivers/iio/adc/qcom-spmi-adc5.c index 821fee60a765..d1b86570768a 100644 --- a/drivers/iio/adc/qcom-spmi-adc5.c +++ b/drivers/iio/adc/qcom-spmi-adc5.c @@ -626,12 +626,20 @@ static int adc5_get_fw_channel_data(struct adc5_chip *adc, struct fwnode_handle *fwnode, const struct adc5_data *data) { - const char *name = fwnode_get_name(fwnode), *channel_name; + const char *channel_name; + char *name; u32 chan, value, varr[2]; u32 sid = 0; int ret; struct device *dev = adc->dev; + name = devm_kasprintf(dev, GFP_KERNEL, "%pfwP", fwnode); + if (!name) + return -ENOMEM; + + /* Cut the address part */ + name[strchrnul(name, '@') - name] = '\0'; + ret = fwnode_property_read_u32(fwnode, "reg", &chan); if (ret) { dev_err(dev, "invalid channel number %s\n", name); -- 2.40.0

1 year, 7 months

1
0
0 0

[PATCH 4/5] usb: dwc3: qcom: Clear pending interrupt before enabling wake interrupt

by Manivannan Sadhasivam

It is possible that there may be a pending interrupt logged into the dwc IP while the interrupts were disabled in the driver. And when the wakeup interrupt is enabled, the pending interrupt might fire which is not required to be serviced by the driver. So always clear the pending interrupt before enabling wake interrupt. Cc: stable(a)vger.kernel.org # 5.20 Fixes: 360e8230516d ("usb: dwc3: qcom: Add helper functions to enable,disable wake irqs") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org> --- drivers/usb/dwc3/dwc3-qcom.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c index bbf67f705d0d..f1059dfcb0e8 100644 --- a/drivers/usb/dwc3/dwc3-qcom.c +++ b/drivers/usb/dwc3/dwc3-qcom.c @@ -346,6 +346,8 @@ static void dwc3_qcom_enable_wakeup_irq(int irq, unsigned int polarity) if (!irq) return; + irq_set_irqchip_state(irq, IRQCHIP_STATE_PENDING, 0); + if (polarity) irq_set_irq_type(irq, polarity); -- 2.25.1

1 year, 7 months

2
2
0 0

[PATCH v2] ext4: fix race between writepages and remount

by Baokun Li

We got a WARNING in ext4_add_complete_io: ================================================================== WARNING: at fs/ext4/page-io.c:231 ext4_put_io_end_defer+0x182/0x250 CPU: 10 PID: 77 Comm: ksoftirqd/10 Tainted: 6.3.0-rc2 #85 RIP: 0010:ext4_put_io_end_defer+0x182/0x250 [ext4] [...] Call Trace: <TASK> ext4_end_bio+0xa8/0x240 [ext4] bio_endio+0x195/0x310 blk_update_request+0x184/0x770 scsi_end_request+0x2f/0x240 scsi_io_completion+0x75/0x450 scsi_finish_command+0xef/0x160 scsi_complete+0xa3/0x180 blk_complete_reqs+0x60/0x80 blk_done_softirq+0x25/0x40 __do_softirq+0x119/0x4c8 run_ksoftirqd+0x42/0x70 smpboot_thread_fn+0x136/0x3c0 kthread+0x140/0x1a0 ret_from_fork+0x2c/0x50 ================================================================== Above issue may happen as follows: cpu1 cpu2 ----------------------------|---------------------------- mount -o dioread_lock ext4_writepages ext4_do_writepages *if (ext4_should_dioread_nolock(inode))* // rsv_blocks is not assigned here mount -o remount,dioread_nolock ext4_journal_start_with_reserve __ext4_journal_start __ext4_journal_start_sb jbd2__journal_start *if (rsv_blocks)* // h_rsv_handle is not initialized here mpage_map_and_submit_extent mpage_map_one_extent dioread_nolock = ext4_should_dioread_nolock(inode) if (dioread_nolock && (map->m_flags & EXT4_MAP_UNWRITTEN)) mpd->io_submit.io_end->handle = handle->h_rsv_handle ext4_set_io_unwritten_flag io_end->flag |= EXT4_IO_END_UNWRITTEN // now io_end->handle is NULL but has EXT4_IO_END_UNWRITTEN flag scsi_finish_command scsi_io_completion scsi_io_completion_action scsi_end_request blk_update_request req_bio_endio bio_endio bio->bi_end_io > ext4_end_bio ext4_put_io_end_defer ext4_add_complete_io // trigger WARN_ON(!io_end->handle && sbi->s_journal); The immediate cause of this problem is that ext4_should_dioread_nolock() function returns inconsistent values in the ext4_do_writepages() and mpage_map_one_extent(). There are four conditions in this function that can be changed at mount time to cause this problem. These four conditions can be divided into two categories: (1) journal_data and EXT4_EXTENTS_FL, which can be changed by ioctl (2) DELALLOC and DIOREAD_NOLOCK, which can be changed by remount The two in the first category have been fixed by commit c8585c6fcaf2 ("ext4: fix races between changing inode journal mode and ext4_writepages") and commit cb85f4d23f79 ("ext4: fix race between writepages and enabling EXT4_EXTENTS_FL") respectively. Two cases in the other category have not yet been fixed, and the above issue is caused by this situation. We refer to the fix for the first category, when applying options during remount, we grab s_writepages_rwsem to avoid racing with writepages ops to trigger this problem. Fixes: 6b523df4fb5a ("ext4: use transaction reservation for extent conversion in ext4_end_io") Cc: stable(a)vger.kernel.org Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- V1->V2: Grab s_writepages_rwsem unconditionally during remount. Remove patches 1,2 that are no longer needed. fs/ext4/ext4.h | 3 ++- fs/ext4/super.c | 9 +++++++++ 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h index 9b2cfc32cf78..5f5ee0c20673 100644 --- a/fs/ext4/ext4.h +++ b/fs/ext4/ext4.h @@ -1703,7 +1703,8 @@ struct ext4_sb_info { /* * Barrier between writepages ops and changing any inode's JOURNAL_DATA - * or EXTENTS flag. + * or EXTENTS flag or between writepages ops and changing DELALLOC or + * DIOREAD_NOLOCK mount options on remount. */ struct percpu_rw_semaphore s_writepages_rwsem; struct dax_device *s_daxdev; diff --git a/fs/ext4/super.c b/fs/ext4/super.c index e6d84c1e34a4..607ebf2a008b 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -6403,7 +6403,16 @@ static int __ext4_remount(struct fs_context *fc, struct super_block *sb) } + /* + * Changing the DIOREAD_NOLOCK or DELALLOC mount options may cause + * two calls to ext4_should_dioread_nolock() to return inconsistent + * values, triggering WARN_ON in ext4_add_complete_io(). we grab + * here s_writepages_rwsem to avoid race between writepages ops and + * remount. + */ + percpu_down_write(&sbi->s_writepages_rwsem); ext4_apply_options(fc, sb); + percpu_up_write(&sbi->s_writepages_rwsem); if ((old_opts.s_mount_opt & EXT4_MOUNT_JOURNAL_CHECKSUM) ^ test_opt(sb, JOURNAL_CHECKSUM)) { -- 2.31.1

1 year, 7 months

2
1
0 0

Napływ Klientów ze strony

by Wiktor Nurek

Dzień dobry, chciałbym poinformować Państwa o możliwości pozyskania nowych zleceń ze strony www. Widzimy zainteresowanie potencjalnych Klientów Państwa firmą, dlatego chętnie pomożemy Państwu dotrzeć z ofertą do większego grona odbiorców poprzez efektywne metody pozycjonowania strony w Google. Czy mógłbym liczyć na kontakt zwrotny? Pozdrawiam serdecznie, Wiktor Nurek

1 year, 7 months

1
0
0 0

[PATCH net 1/2] can: j1939: prevent deadlock by moving j1939_sk_errqueue()

by Marc Kleine-Budde

From: Oleksij Rempel <o.rempel(a)pengutronix.de> This commit addresses a deadlock situation that can occur in certain scenarios, such as when running data TP/ETP transfer and subscribing to the error queue while receiving a net down event. The deadlock involves locks in the following order: 3 j1939_session_list_lock -> active_session_list_lock j1939_session_activate ... j1939_sk_queue_activate_next -> sk_session_queue_lock ... j1939_xtp_rx_eoma_one 2 j1939_sk_queue_drop_all -> sk_session_queue_lock ... j1939_sk_netdev_event_netdown -> j1939_socks_lock j1939_netdev_notify 1 j1939_sk_errqueue -> j1939_socks_lock __j1939_session_cancel -> active_session_list_lock j1939_tp_rxtimer CPU0 CPU1 ---- ---- lock(&priv->active_session_list_lock); lock(&jsk->sk_session_queue_lock); lock(&priv->active_session_list_lock); lock(&priv->j1939_socks_lock); The solution implemented in this commit is to move the j1939_sk_errqueue() call out of the active_session_list_lock context, thus preventing the deadlock situation. Reported-by: syzbot+ee1cd780f69483a8616b(a)syzkaller.appspotmail.com Fixes: 5b9272e93f2e ("can: j1939: extend UAPI to notify about RX status") Co-developed-by: Hillf Danton <hdanton(a)sina.com> Signed-off-by: Hillf Danton <hdanton(a)sina.com> Signed-off-by: Oleksij Rempel <o.rempel(a)pengutronix.de> Link: https://lore.kernel.org/all/20230324130141.2132787-1-o.rempel@pengutronix.de Cc: stable(a)vger.kernel.org Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> --- net/can/j1939/transport.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/net/can/j1939/transport.c b/net/can/j1939/transport.c index fce9b9ebf13f..fb92c3609e17 100644 --- a/net/can/j1939/transport.c +++ b/net/can/j1939/transport.c @@ -1124,8 +1124,6 @@ static void __j1939_session_cancel(struct j1939_session *session, if (session->sk) j1939_sk_send_loop_abort(session->sk, session->err); - else - j1939_sk_errqueue(session, J1939_ERRQUEUE_RX_ABORT); } static void j1939_session_cancel(struct j1939_session *session, @@ -1140,6 +1138,9 @@ static void j1939_session_cancel(struct j1939_session *session, } j1939_session_list_unlock(session->priv); + + if (!session->sk) + j1939_sk_errqueue(session, J1939_ERRQUEUE_RX_ABORT); } static enum hrtimer_restart j1939_tp_txtimer(struct hrtimer *hrtimer) @@ -1253,6 +1254,9 @@ static enum hrtimer_restart j1939_tp_rxtimer(struct hrtimer *hrtimer) __j1939_session_cancel(session, J1939_XTP_ABORT_TIMEOUT); } j1939_session_list_unlock(session->priv); + + if (!session->sk) + j1939_sk_errqueue(session, J1939_ERRQUEUE_RX_ABORT); } j1939_session_put(session); base-commit: 45977e58ce65ed0459edc9a0466d9dfea09463f5 -- 2.39.2

1 year, 7 months

2
1
0 0

[Syzkaller & bisect] There is "io_poll_remove_entries" NULL pointer BUG in v6.3-rc4 kernel

by Pengfei Xu

Hi Jens Axboe and kernel experts, Platform: x86 platforms There is "io_poll_remove_entries" NULL pointer BUG in v6.3-rc4 kernel. All detailed log: https://github.com/xupengfe/syzkaller_logs/tree/main/230327_041425_io_poll_… Syzkaller reproduced code: https://github.com/xupengfe/syzkaller_logs/blob/main/230327_041425_io_poll_… Syzkaller analysis report0: https://github.com/xupengfe/syzkaller_logs/blob/main/230327_041425_io_poll_… Syzkaller analysis status: https://github.com/xupengfe/syzkaller_logs/blob/main/230327_041425_io_poll_… v6.3-rc4 issue dmesg: https://github.com/xupengfe/syzkaller_logs/blob/main/230327_041425_io_poll_… Kconfig: https://github.com/xupengfe/syzkaller_logs/blob/main/230327_041425_io_poll_… Bisect info: https://github.com/xupengfe/syzkaller_logs/blob/main/230327_041425_io_poll_… It could be reproduced in v6.3-rc3 and v6.3-rc4 kernel, and bisected between v6.3-rc3 and v5.11 kernel, bad commit was: " c16bda37594f83147b167d381d54c010024efecf io_uring/poll: allow some retries for poll triggering spuriously " After reverted above commit on top of v6.3-rc3 kernel, this issue was gone. " [ 67.196537] BUG: kernel NULL pointer dereference, address: 0000000000000008 [ 67.197176] #PF: supervisor read access in kernel mode [ 67.197638] #PF: error_code(0x0000) - not-present page [ 67.198100] PGD 1204e067 P4D 1204e067 PUD 12211067 PMD 0 [ 67.198588] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 67.198987] CPU: 1 PID: 393 Comm: repro Not tainted 6.3.0-rc4-kvmmainline #2 [ 67.199615] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 [ 67.200324] RIP: 0010:io_poll_remove_entries.part.16+0x14a/0x310 [ 67.200871] Code: 06 00 00 00 89 de e8 75 2f 59 ff 80 fb 06 0f 84 c5 01 00 00 e8 07 2e 59 ff 49 8b 84 24 a8 00 00 00 48 8b 58 40 e8 f6 2d 59 ff <4c> 8b 63 08 4d 85 e4 74 38 e8 e8 2d 59 ff 4c 89 e7 e8 a0 1f 27 01 [ 67.202490] RSP: 0018:ffffc900010b3b78 EFLAGS: 00010246 [ 67.202963] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff81d4356b [ 67.203597] RDX: 0000000000000000 RSI: ffff888004ecc680 RDI: 0000000000000002 [ 67.204230] RBP: ffffc900010b3b90 R08: 000000000000001c R09: 0000000000000001 [ 67.204867] R10: ffff888004ecd418 R11: 0000000000000000 R12: ffff8880044d6e00 [ 67.205502] R13: 0000000000000000 R14: 0000000000000059 R15: 0000000001000000 [ 67.206137] FS: 00007fd010a36740(0000) GS:ffff88807ed00000(0000) knlGS:0000000000000000 [ 67.206850] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 67.207383] CR2: 0000000000000008 CR3: 0000000005efe004 CR4: 0000000000770ee0 [ 67.208037] PKRU: 55555554 [ 67.208298] Call Trace: [ 67.208535] <TASK> [ 67.208746] __io_arm_poll_handler+0x30c/0x520 [ 67.209170] io_arm_poll_handler+0x2cf/0x530 [ 67.209577] ? __pfx_io_async_queue_proc+0x10/0x10 [ 67.210030] io_queue_async+0x88/0x2f0 [ 67.210394] io_req_task_submit+0x122/0x140 [ 67.210794] io_poll_task_func+0x4c6/0x700 [ 67.211182] tctx_task_work+0x1d3/0x650 [ 67.211554] task_work_run+0xb6/0x120 [ 67.211910] get_signal+0xd6b/0x14a0 [ 67.212259] ? __tty_hangup.part.29+0x32a/0x3a0 [ 67.212709] arch_do_signal_or_restart+0x33/0x280 [ 67.213159] ? exit_to_user_mode_prepare+0x100/0x210 [ 67.213631] ? __this_cpu_preempt_check+0x20/0x30 [ 67.214083] exit_to_user_mode_prepare+0x13b/0x210 [ 67.214540] syscall_exit_to_user_mode+0x2d/0x60 [ 67.214981] do_syscall_64+0x4a/0x90 [ 67.215335] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 67.215818] RIP: 0033:0x7fd010b5b59d [ 67.216163] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d d3 08 0d 00 f7 d8 64 89 01 48 [ 67.217852] RSP: 002b:00007ffc0d005148 EFLAGS: 00000206 ORIG_RAX: 0000000000000010 [ 67.218553] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00007fd010b5b59d [ 67.219214] RDX: 0000000000000000 RSI: 0000000000005437 RDI: 0000000000000003 [ 67.219884] RBP: 00007ffc0d005160 R08: 0000000000000000 R09: 00007ffc0d005240 [ 67.220551] R10: 0000000000000000 R11: 0000000000000206 R12: 00000000004010b0 [ 67.221219] R13: 00007ffc0d005240 R14: 0000000000000000 R15: 0000000000000000 [ 67.221891] </TASK> [ 67.222112] Modules linked in: [ 67.222414] CR2: 0000000000000008 [ 67.222738] ---[ end trace 0000000000000000 ]--- [ 67.261809] RIP: 0010:io_poll_remove_entries.part.16+0x14a/0x310 [ 67.262406] Code: 06 00 00 00 89 de e8 75 2f 59 ff 80 fb 06 0f 84 c5 01 00 00 e8 07 2e 59 ff 49 8b 84 24 a8 00 00 00 48 8b 58 40 e8 f6 2d 59 ff <4c> 8b 63 08 4d 85 e4 74 38 e8 e8 2d 59 ff 4c 89 e7 e8 a0 1f 27 01 [ 67.264185] RSP: 0018:ffffc900010b3b78 EFLAGS: 00010246 [ 67.264704] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff81d4356b [ 67.265399] RDX: 0000000000000000 RSI: ffff888004ecc680 RDI: 0000000000000002 [ 67.266094] RBP: ffffc900010b3b90 R08: 000000000000001c R09: 0000000000000001 [ 67.266790] R10: ffff888004ecd418 R11: 0000000000000000 R12: ffff8880044d6e00 [ 67.267484] R13: 0000000000000000 R14: 0000000000000059 R15: 0000000001000000 [ 67.268179] FS: 00007fd010a36740(0000) GS:ffff88807ed00000(0000) knlGS:0000000000000000 [ 67.268964] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 67.269530] CR2: 0000000000000008 CR3: 0000000005efe004 CR4: 0000000000770ee0 [ 67.270228] PKRU: 55555554 [ 67.270506] note: repro[393] exited with irqs disabled [ 67.271058] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580 [ 67.271874] in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 393, name: repro [ 67.272623] preempt_count: 0, expected: 0 [ 67.273025] RCU nest depth: 1, expected: 0 [ 67.273431] INFO: lockdep is turned off. [ 67.273858] CPU: 1 PID: 393 Comm: repro Tainted: G D 6.3.0-rc4-kvmmainline #2 [ 67.274688] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 [ 67.275468] Call Trace: [ 67.275721] <TASK> [ 67.275950] dump_stack_lvl+0xe0/0x110 [ 67.276344] dump_stack+0x19/0x20 [ 67.276702] __might_resched+0x1c2/0x2e0 [ 67.277111] __might_sleep+0x46/0x70 [ 67.277486] __mutex_lock+0x54/0xcb0 [ 67.277862] ? debug_smp_processor_id+0x20/0x30 [ 67.278328] ? rcu_is_watching+0x15/0x50 [ 67.278737] ? io_uring_del_tctx_node+0x84/0x110 [ 67.279210] ? lock_release+0x1f4/0x290 [ 67.279611] mutex_lock_nested+0x1f/0x30 [ 67.280016] ? mutex_lock_nested+0x1f/0x30 [ 67.280435] io_uring_del_tctx_node+0x84/0x110 [ 67.280906] io_uring_clean_tctx+0x74/0xf0 [ 67.281328] io_uring_cancel_generic+0x452/0x4e0 [ 67.281814] ? __pfx_autoremove_wake_function+0x10/0x10 [ 67.282356] __io_uring_cancel+0x1f/0x30 [ 67.282774] do_exit+0x227/0x12b0 [ 67.283129] ? write_comp_data+0x2f/0x90 [ 67.283549] make_task_dead+0x100/0x290 [ 67.283951] rewind_stack_and_make_dead+0x17/0x20 [ 67.284446] RIP: 0033:0x7fd010b5b59d [ 67.284823] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d d3 08 0d 00 f7 d8 64 89 01 48 [ 67.286656] RSP: 002b:00007ffc0d005148 EFLAGS: 00000206 ORIG_RAX: 0000000000000010 [ 67.287419] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00007fd010b5b59d [ 67.288140] RDX: 0000000000000000 RSI: 0000000000005437 RDI: 0000000000000003 [ 67.288862] RBP: 00007ffc0d005160 R08: 0000000000000000 R09: 00007ffc0d005240 [ 67.289582] R10: 0000000000000000 R11: 0000000000000206 R12: 00000000004010b0 [ 67.290298] R13: 00007ffc0d005240 R14: 0000000000000000 R15: 0000000000000000 [ 67.291020] </TASK> [ 67.364809] ------------[ cut here ]------------ [ 67.365494] Voluntary context switch within RCU read-side critical section! [ 67.365535] WARNING: CPU: 1 PID: 393 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x4f0/0x5b0 [ 67.367522] Modules linked in: [ 67.367898] CPU: 1 PID: 393 Comm: repro Tainted: G D W 6.3.0-rc4-kvmmainline #2 [ 67.368885] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 [ 67.369741] RIP: 0010:rcu_note_context_switch+0x4f0/0x5b0 [ 67.370360] Code: 9c d7 01 85 c0 75 02 0f 0b 49 8b 4c 24 58 48 8b 53 20 e9 6f fd ff ff 48 c7 c7 a0 f8 99 83 c6 05 a4 6c dd 02 01 e8 a0 bf ef ff <0f> 0b e9 a4 fb ff ff a9 ff ff ff 7f 0f 84 0c fc ff ff 65 48 8b 3c [ 67.372260] RSP: 0018:ffffc900010b3bf8 EFLAGS: 00010082 [ 67.372800] RAX: 0000000000000000 RBX: ffff88807ed36180 RCX: ffffffff8111743b [ 67.373524] RDX: 0000000000000000 RSI: ffff888004ecc680 RDI: 0000000000000002 [ 67.374249] RBP: ffffc900010b3c20 R08: 0000000000000000 R09: 0000000000000000 [ 67.374972] R10: 000000002d2d2d2d R11: 000000002d2d2d2d R12: ffff88807ed352c0 [ 67.375698] R13: ffff888004ecc680 R14: 0000000000000000 R15: ffff888004ecc680 [ 67.376425] FS: 00007fd010a36740(0000) GS:ffff88807ed00000(0000) knlGS:0000000000000000 [ 67.377244] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 67.377836] CR2: 0000000000000008 CR3: 0000000005efe004 CR4: 0000000000770ee0 [ 67.378565] PKRU: 55555554 [ 67.378854] Call Trace: [ 67.379117] <TASK> [ 67.379350] __schedule+0xe1/0xc30 [ 67.379725] schedule+0x5b/0xe0 [ 67.380072] schedule_preempt_disabled+0x1c/0x30 [ 67.380563] __mutex_lock+0xad4/0xcb0 [ 67.380959] ? debug_smp_processor_id+0x20/0x30 [ 67.381444] ? rcu_is_watching+0x15/0x50 [ 67.381869] ? io_uring_del_tctx_node+0x84/0x110 [ 67.382362] ? lock_release+0x1f4/0x290 [ 67.382780] mutex_lock_nested+0x1f/0x30 [ 67.383201] ? mutex_lock_nested+0x1f/0x30 [ 67.383638] io_uring_del_tctx_node+0x84/0x110 [ 67.384114] io_uring_clean_tctx+0x74/0xf0 [ 67.384551] io_uring_cancel_generic+0x452/0x4e0 [ 67.385057] ? __pfx_autoremove_wake_function+0x10/0x10 [ 67.385612] __io_uring_cancel+0x1f/0x30 [ 67.386039] do_exit+0x227/0x12b0 [ 67.386402] ? write_comp_data+0x2f/0x90 [ 67.386830] make_task_dead+0x100/0x290 [ 67.387243] rewind_stack_and_make_dead+0x17/0x20 [ 67.387750] RIP: 0033:0x7fd010b5b59d [ 67.388137] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d d3 08 0d 00 f7 d8 64 89 01 48 [ 67.390025] RSP: 002b:00007ffc0d005148 EFLAGS: 00000206 ORIG_RAX: 0000000000000010 [ 67.390805] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00007fd010b5b59d [ 67.391541] RDX: 0000000000000000 RSI: 0000000000005437 RDI: 0000000000000003 [ 67.392279] RBP: 00007ffc0d005160 R08: 0000000000000000 R09: 00007ffc0d005240 [ 67.393021] R10: 0000000000000000 R11: 0000000000000206 R12: 00000000004010b0 [ 67.393758] R13: 00007ffc0d005240 R14: 0000000000000000 R15: 0000000000000000 [ 67.394499] </TASK> [ 67.394741] irq event stamp: 4450 [ 67.395097] hardirqs last enabled at (4449): [<ffffffff82fb58db>] _raw_spin_unlock_irq+0x2b/0x60 [ 67.396014] hardirqs last disabled at (4450): [<ffffffff82f9476e>] exc_page_fault+0x4e/0x3b0 [ 67.396897] softirqs last enabled at (1580): [<ffffffff8107aa91>] fpu_flush_thread+0xd1/0x130 [ 67.397787] softirqs last disabled at (1578): [<ffffffff8107a9c9>] fpu_flush_thread+0x9/0x130 [ 67.398671] ---[ end trace 0000000000000000 ]--- " I hope it's helpful. --- If you don't need the following environment to reproduce the problem or if you already have one, please ignore the following information. How to reproduce: git clone https://gitlab.com/xupengfe/repro_vm_env.git cd repro_vm_env tar -xvf repro_vm_env.tar.gz cd repro_vm_env; ./start3.sh // it needs qemu-system-x86_64 and I used v7.1.0 // start3.sh will load bzImage_2241ab53cbb5cdb08a6b2d4688feb13971058f65 v6.2-rc5 kernel // You could change the bzImage_xxx as you want You could use below command to log in, there is no password for root. ssh -p 10023 root@localhost After login vm(virtual machine) successfully, you could transfer reproduced binary to the vm by below way, and reproduce the problem in vm: gcc -pthread -o repro repro.c scp -P 10023 repro root@localhost:/root/ Get the bzImage for target kernel: Please use target kconfig and copy it to kernel_src/.config make olddefconfig make -jx bzImage //x should equal or less than cpu num your pc has Fill the bzImage file into above start3.sh to load the target kernel in vm. Tips: If you already have qemu-system-x86_64, please ignore below info. If you want to install qemu v7.1.0 version: git clone https://github.com/qemu/qemu.git cd qemu git checkout -f v7.1.0 mkdir build cd build yum install -y ninja-build.x86_64 ../configure --target-list=x86_64-softmmu --enable-kvm --enable-vnc --enable-gtk --enable-sdl make make install Thanks! BR.

1 year, 7 months

2
2
0 0

Work from Home, COMPANY REP NEEDED !

by Bleiholder Novak

Hello, I am reaching out to provide awareness for a part-time career. We are currently sourcing for representatives in Europe to work from home to act as our company's regional business representative in that region. It will by no means interfere with your current job or business. Kindly email me for detailed information. Regards, Bleiholder Novak

1 year, 7 months

1
0
0 0

[PATCH v3] mm/hugetlb: Fix uffd wr-protection for CoW optimization path

by Peter Xu

This patch fixes an issue that a hugetlb uffd-wr-protected mapping can be writable even with uffd-wp bit set. It only happens with hugetlb private mappings, when someone firstly wr-protects a missing pte (which will install a pte marker), then a write to the same page without any prior access to the page. Userfaultfd-wp trap for hugetlb was implemented in hugetlb_fault() before reaching hugetlb_wp() to avoid taking more locks that userfault won't need. However there's one CoW optimization path that can trigger hugetlb_wp() inside hugetlb_no_page(), which will bypass the trap. This patch skips hugetlb_wp() for CoW and retries the fault if uffd-wp bit is detected. The new path will only trigger in the CoW optimization path because generic hugetlb_fault() (e.g. when a present pte was wr-protected) will resolve the uffd-wp bit already. Also make sure anonymous UNSHARE won't be affected and can still be resolved, IOW only skip CoW not CoR. This patch will be needed for v5.19+ hence copy stable. Reported-by: Muhammad Usama Anjum <usama.anjum(a)collabora.com> Cc: linux-stable <stable(a)vger.kernel.org> Fixes: 166f3ecc0daf ("mm/hugetlb: hook page faults for uffd write protection") Signed-off-by: Peter Xu <peterx(a)redhat.com> --- Notes: v2 is not on the list but in an attachment in the reply; this v3 is mostly to make sure it's not the same as the patch used to be attached. Sorry Andrew, we need to drop the queued one as I rewrote the commit message. Muhammad, I didn't attach your T-b because of the slight functional change. Please feel free to re-attach if it still works for you (which I believe should). thanks, --- mm/hugetlb.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 8bfd07f4c143..a58b3739ed4b 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -5478,7 +5478,7 @@ static vm_fault_t hugetlb_wp(struct mm_struct *mm, struct vm_area_struct *vma, struct folio *pagecache_folio, spinlock_t *ptl) { const bool unshare = flags & FAULT_FLAG_UNSHARE; - pte_t pte; + pte_t pte = huge_ptep_get(ptep); struct hstate *h = hstate_vma(vma); struct page *old_page; struct folio *new_folio; @@ -5487,6 +5487,17 @@ static vm_fault_t hugetlb_wp(struct mm_struct *mm, struct vm_area_struct *vma, unsigned long haddr = address & huge_page_mask(h); struct mmu_notifier_range range; + /* + * Never handle CoW for uffd-wp protected pages. It should be only + * handled when the uffd-wp protection is removed. + * + * Note that only the CoW optimization path (in hugetlb_no_page()) + * can trigger this, because hugetlb_fault() will always resolve + * uffd-wp bit first. + */ + if (!unshare && huge_pte_uffd_wp(pte)) + return 0; + /* * hugetlb does not support FOLL_FORCE-style write faults that keep the * PTE mapped R/O such as maybe_mkwrite() would do. @@ -5500,7 +5511,6 @@ static vm_fault_t hugetlb_wp(struct mm_struct *mm, struct vm_area_struct *vma, return 0; } - pte = huge_ptep_get(ptep); old_page = pte_page(pte); delayacct_wpcopy_start(); -- 2.39.1

1 year, 7 months

4
6
0 0

+ nilfs2-fix-potential-uaf-of-struct-nilfs_sc_info-in-nilfs_segctor_thread.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: nilfs2: fix potential UAF of struct nilfs_sc_info in nilfs_segctor_thread() has been added to the -mm mm-hotfixes-unstable branch. Its filename is nilfs2-fix-potential-uaf-of-struct-nilfs_sc_info-in-nilfs_segctor_thread.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Subject: nilfs2: fix potential UAF of struct nilfs_sc_info in nilfs_segctor_thread() Date: Tue, 28 Mar 2023 02:53:18 +0900 The finalization of nilfs_segctor_thread() can race with nilfs_segctor_kill_thread() which terminates that thread, potentially causing a use-after-free BUG as KASAN detected. At the end of nilfs_segctor_thread(), it assigns NULL to "sc_task" member of "struct nilfs_sc_info" to indicate the thread has finished, and then notifies nilfs_segctor_kill_thread() of this using waitqueue "sc_wait_task" on the struct nilfs_sc_info. However, here, immediately after the NULL assignment to "sc_task", it is possible that nilfs_segctor_kill_thread() will detect it and return to continue the deallocation, freeing the nilfs_sc_info structure before the thread does the notification. This fixes the issue by protecting the NULL assignment to "sc_task" and its notification, with spinlock "sc_state_lock" of the struct nilfs_sc_info. Since nilfs_segctor_kill_thread() does a final check to see if "sc_task" is NULL with "sc_state_lock" locked, this can eliminate the race. Link: https://lkml.kernel.org/r/20230327175318.8060-1-konishi.ryusuke@gmail.com Reported-by: syzbot+b08ebcc22f8f3e6be43a(a)syzkaller.appspotmail.com Link: https://lkml.kernel.org/r/00000000000000660d05f7dfa877@google.com Signed-off-by: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/nilfs2/segment.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/fs/nilfs2/segment.c~nilfs2-fix-potential-uaf-of-struct-nilfs_sc_info-in-nilfs_segctor_thread +++ a/fs/nilfs2/segment.c @@ -2609,11 +2609,10 @@ static int nilfs_segctor_thread(void *ar goto loop; end_thread: - spin_unlock(&sci->sc_state_lock); - /* end sync. */ sci->sc_task = NULL; wake_up(&sci->sc_wait_task); /* for nilfs_segctor_kill_thread() */ + spin_unlock(&sci->sc_state_lock); return 0; } _ Patches currently in -mm which might be from konishi.ryusuke(a)gmail.com are nilfs2-fix-potential-uaf-of-struct-nilfs_sc_info-in-nilfs_segctor_thread.patch

1 year, 7 months

1
0
0 0

Re: [PATCH 5/8] maple_tree: fix write memory barrier of nodes once dead for RCU mode

by Liam R. Howlett

I forgot to drop the S-O-B and add cc stable to this one. Please use this version. Thanks, Liam From 19dcf05adcdd983af6c9618bdd9a49a2c40260f1 Mon Sep 17 00:00:00 2001 From: "Liam R. Howlett" <Liam.Howlett(a)oracle.com> Date: Mon, 27 Feb 2023 09:36:04 -0800 Subject: [PATCH v2 5/8] maple_tree: fix write memory barrier of nodes once dead for RCU mode During the development of the maple tree, the strategy of freeing multiple nodes changed and, in the process, the pivots were reused to store pointers to dead nodes. To ensure the readers see accurate pivots, the writers need to mark the nodes as dead and call smp_wmb() to ensure any readers can identify the node as dead before using the pivot values. There were two places where the old method of marking the node as dead without smp_wmb() were being used, which resulted in RCU readers seeing the wrong pivot value before seeing the node was dead. Fix this race condition by using mte_set_node_dead() which has the smp_wmb() call to ensure the race is closed. Add a WARN_ON() to the ma_free_rcu() call to ensure all nodes being freed are marked as dead to ensure there are no other call paths besides the two updated paths. This is necessary for the RCU mode of the maple tree. Link: https://lkml.kernel.org/r/20230227173632.3292573-6-surenb@google.com Fixes: 54a611b60590 ("Maple Tree: add new data structure") Cc: stable(a)vger.kernel.org Signed-off-by: Liam R. Howlett <Liam.Howlett(a)oracle.com> --- lib/maple_tree.c | 7 +++++-- tools/testing/radix-tree/maple.c | 16 ++++++++++++++++ 2 files changed, 21 insertions(+), 2 deletions(-) diff --git a/lib/maple_tree.c b/lib/maple_tree.c index 3d5ab02f981a..6b6eddadd9d2 100644 --- a/lib/maple_tree.c +++ b/lib/maple_tree.c @@ -185,7 +185,7 @@ static void mt_free_rcu(struct rcu_head *head) */ static void ma_free_rcu(struct maple_node *node) { - node->parent = ma_parent_ptr(node); + WARN_ON(node->parent != ma_parent_ptr(node)); call_rcu(&node->rcu, mt_free_rcu); } @@ -1778,8 +1778,10 @@ static inline void mas_replace(struct ma_state *mas, bool advanced) rcu_assign_pointer(slots[offset], mas->node); } - if (!advanced) + if (!advanced) { + mte_set_node_dead(old_enode); mas_free(mas, old_enode); + } } /* @@ -4218,6 +4220,7 @@ static inline bool mas_wr_node_store(struct ma_wr_state *wr_mas) done: mas_leaf_set_meta(mas, newnode, dst_pivots, maple_leaf_64, new_end); if (in_rcu) { + mte_set_node_dead(mas->node); mas->node = mt_mk_node(newnode, wr_mas->type); mas_replace(mas, false); } else { diff --git a/tools/testing/radix-tree/maple.c b/tools/testing/radix-tree/maple.c index 958ee9bdb316..4c89ff333f6f 100644 --- a/tools/testing/radix-tree/maple.c +++ b/tools/testing/radix-tree/maple.c @@ -108,6 +108,7 @@ static noinline void check_new_node(struct maple_tree *mt) MT_BUG_ON(mt, mn->slot[1] != NULL); MT_BUG_ON(mt, mas_allocated(&mas) != 0); + mn->parent = ma_parent_ptr(mn); ma_free_rcu(mn); mas.node = MAS_START; mas_nomem(&mas, GFP_KERNEL); @@ -160,6 +161,7 @@ static noinline void check_new_node(struct maple_tree *mt) MT_BUG_ON(mt, mas_allocated(&mas) != i); MT_BUG_ON(mt, !mn); MT_BUG_ON(mt, not_empty(mn)); + mn->parent = ma_parent_ptr(mn); ma_free_rcu(mn); } @@ -192,6 +194,7 @@ static noinline void check_new_node(struct maple_tree *mt) MT_BUG_ON(mt, not_empty(mn)); MT_BUG_ON(mt, mas_allocated(&mas) != i - 1); MT_BUG_ON(mt, !mn); + mn->parent = ma_parent_ptr(mn); ma_free_rcu(mn); } @@ -210,6 +213,7 @@ static noinline void check_new_node(struct maple_tree *mt) mn = mas_pop_node(&mas); MT_BUG_ON(mt, not_empty(mn)); MT_BUG_ON(mt, mas_allocated(&mas) != j - 1); + mn->parent = ma_parent_ptr(mn); ma_free_rcu(mn); } MT_BUG_ON(mt, mas_allocated(&mas) != 0); @@ -233,6 +237,7 @@ static noinline void check_new_node(struct maple_tree *mt) MT_BUG_ON(mt, mas_allocated(&mas) != i - j); mn = mas_pop_node(&mas); MT_BUG_ON(mt, not_empty(mn)); + mn->parent = ma_parent_ptr(mn); ma_free_rcu(mn); MT_BUG_ON(mt, mas_allocated(&mas) != i - j - 1); } @@ -269,6 +274,7 @@ static noinline void check_new_node(struct maple_tree *mt) mn = mas_pop_node(&mas); /* get the next node. */ MT_BUG_ON(mt, mn == NULL); MT_BUG_ON(mt, not_empty(mn)); + mn->parent = ma_parent_ptr(mn); ma_free_rcu(mn); } MT_BUG_ON(mt, mas_allocated(&mas) != 0); @@ -294,6 +300,7 @@ static noinline void check_new_node(struct maple_tree *mt) mn = mas_pop_node(&mas2); /* get the next node. */ MT_BUG_ON(mt, mn == NULL); MT_BUG_ON(mt, not_empty(mn)); + mn->parent = ma_parent_ptr(mn); ma_free_rcu(mn); } MT_BUG_ON(mt, mas_allocated(&mas2) != 0); @@ -334,10 +341,12 @@ static noinline void check_new_node(struct maple_tree *mt) MT_BUG_ON(mt, mas_allocated(&mas) != MAPLE_ALLOC_SLOTS + 2); mn = mas_pop_node(&mas); MT_BUG_ON(mt, not_empty(mn)); + mn->parent = ma_parent_ptr(mn); ma_free_rcu(mn); for (i = 1; i <= MAPLE_ALLOC_SLOTS + 1; i++) { mn = mas_pop_node(&mas); MT_BUG_ON(mt, not_empty(mn)); + mn->parent = ma_parent_ptr(mn); ma_free_rcu(mn); } MT_BUG_ON(mt, mas_allocated(&mas) != 0); @@ -375,6 +384,7 @@ static noinline void check_new_node(struct maple_tree *mt) mas_node_count(&mas, i); /* Request */ mas_nomem(&mas, GFP_KERNEL); /* Fill request */ mn = mas_pop_node(&mas); /* get the next node. */ + mn->parent = ma_parent_ptr(mn); ma_free_rcu(mn); mas_destroy(&mas); @@ -382,10 +392,13 @@ static noinline void check_new_node(struct maple_tree *mt) mas_node_count(&mas, i); /* Request */ mas_nomem(&mas, GFP_KERNEL); /* Fill request */ mn = mas_pop_node(&mas); /* get the next node. */ + mn->parent = ma_parent_ptr(mn); ma_free_rcu(mn); mn = mas_pop_node(&mas); /* get the next node. */ + mn->parent = ma_parent_ptr(mn); ma_free_rcu(mn); mn = mas_pop_node(&mas); /* get the next node. */ + mn->parent = ma_parent_ptr(mn); ma_free_rcu(mn); mas_destroy(&mas); } @@ -35369,6 +35382,7 @@ static noinline void check_prealloc(struct maple_tree *mt) MT_BUG_ON(mt, allocated != 1 + height * 3); mn = mas_pop_node(&mas); MT_BUG_ON(mt, mas_allocated(&mas) != allocated - 1); + mn->parent = ma_parent_ptr(mn); ma_free_rcu(mn); MT_BUG_ON(mt, mas_preallocate(&mas, GFP_KERNEL) != 0); mas_destroy(&mas); @@ -35386,6 +35400,7 @@ static noinline void check_prealloc(struct maple_tree *mt) mas_destroy(&mas); allocated = mas_allocated(&mas); MT_BUG_ON(mt, allocated != 0); + mn->parent = ma_parent_ptr(mn); ma_free_rcu(mn); MT_BUG_ON(mt, mas_preallocate(&mas, GFP_KERNEL) != 0); @@ -35756,6 +35771,7 @@ void farmer_tests(void) tree.ma_root = mt_mk_node(node, maple_leaf_64); mt_dump(&tree); + node->parent = ma_parent_ptr(node); ma_free_rcu(node); /* Check things that will make lockdep angry */ -- 2.39.2

1 year, 7 months

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2023