- Linux-stable-mirror - lists.linaro.org

patch "iio: buffer: correctly return bytes written in output buffers" 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: buffer: correctly return bytes written in output buffers 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 b5184a26a28fac1d708b0bfeeb958a9260c2924c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Nuno=20S=C3=A1?= <nuno.sa(a)analog.com> Date: Thu, 16 Feb 2023 11:14:50 +0100 Subject: iio: buffer: correctly return bytes written in output buffers MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit If for some reason 'rb->access->write()' does not write the full requested data and the O_NONBLOCK is set, we would return 'n' to userspace which is not really truth. Hence, let's return the number of bytes we effectively wrote. Fixes: 9eeee3b0bf190 ("iio: Add output buffer support") Signed-off-by: Nuno Sá <nuno.sa(a)analog.com> Reviewed-by: Lars-Peter Clausen <lars(a)metafoo.de> Link: https://lore.kernel.org/r/20230216101452.591805-2-nuno.sa@analog.com Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/industrialio-buffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/industrialio-buffer.c b/drivers/iio/industrialio-buffer.c index 80c78bd6bbef..6340d8e1430b 100644 --- a/drivers/iio/industrialio-buffer.c +++ b/drivers/iio/industrialio-buffer.c @@ -220,7 +220,7 @@ static ssize_t iio_buffer_write(struct file *filp, const char __user *buf, } while (ret == 0); remove_wait_queue(&rb->pollq, &wait); - return ret < 0 ? ret : n; + return ret < 0 ? ret : written; } /** -- 2.40.0

2 years, 7 months

1
0
0 0

patch "iio: light: vcnl4000: Fix WARN_ON on uninitialized lock" 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: light: vcnl4000: Fix WARN_ON on uninitialized lock 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 42ec40b0883c1cce58b06e8fa82049a61033151c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?M=C3=A5rten=20Lindahl?= <marten.lindahl(a)axis.com> Date: Tue, 31 Jan 2023 15:01:09 +0100 Subject: iio: light: vcnl4000: Fix WARN_ON on uninitialized lock MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit There are different init functions for the sensors in this driver in which only one initializes the generic vcnl4000_lock. With commit e21b5b1f2669 ("iio: light: vcnl4000: Preserve conf bits when toggle power") the vcnl4040 sensor started to depend on the lock, but it was missed to initialize it in vcnl4040's init function. This has not been visible until we run lockdep on it: DEBUG_LOCKS_WARN_ON(lock->magic != lock) at kernel/locking/mutex.c:575 __mutex_lock+0x4f8/0x890 Call trace: __mutex_lock mutex_lock_nested vcnl4200_set_power_state vcnl4200_init vcnl4000_probe Fix this by initializing the lock in the probe function instead of doing it in the chip specific init functions. Fixes: e21b5b1f2669 ("iio: light: vcnl4000: Preserve conf bits when toggle power") Signed-off-by: Mårten Lindahl <marten.lindahl(a)axis.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Link: https://lore.kernel.org/r/20230131140109.2067577-1-marten.lindahl@axis.com Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/light/vcnl4000.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/iio/light/vcnl4000.c b/drivers/iio/light/vcnl4000.c index cc1a2062e76d..69c5bc987e26 100644 --- a/drivers/iio/light/vcnl4000.c +++ b/drivers/iio/light/vcnl4000.c @@ -199,7 +199,6 @@ static int vcnl4000_init(struct vcnl4000_data *data) data->rev = ret & 0xf; data->al_scale = 250000; - mutex_init(&data->vcnl4000_lock); return data->chip_spec->set_power_state(data, true); }; @@ -1197,6 +1196,8 @@ static int vcnl4000_probe(struct i2c_client *client) data->id = id->driver_data; data->chip_spec = &vcnl4000_chip_spec_cfg[data->id]; + mutex_init(&data->vcnl4000_lock); + ret = data->chip_spec->init(data); if (ret < 0) return ret; -- 2.40.0

2 years, 7 months

1
0
0 0

patch "iio: adis16480: select CONFIG_CRC32" 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: adis16480: select CONFIG_CRC32 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 d9b540ee461cca7edca0dd2c2a42625c6b9ffb8f Mon Sep 17 00:00:00 2001 From: Arnd Bergmann <arnd(a)arndb.de> Date: Tue, 31 Jan 2023 10:46:11 +0100 Subject: iio: adis16480: select CONFIG_CRC32 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit In rare randconfig builds, the missing CRC32 helper causes a link error: ld.lld: error: undefined symbol: crc32_le >>> referenced by usercopy_64.c >>> vmlinux.o:(adis16480_trigger_handler) Fixes: 941f130881fa ("iio: adis16480: support burst read function") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Reviewed-by: Nuno Sá <nuno.sa(a)analog.com> Link: https://lore.kernel.org/r/20230131094616.130238-1-arnd@kernel.org Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/imu/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iio/imu/Kconfig b/drivers/iio/imu/Kconfig index f1d7d4b5e222..c2f97629e9cd 100644 --- a/drivers/iio/imu/Kconfig +++ b/drivers/iio/imu/Kconfig @@ -47,6 +47,7 @@ config ADIS16480 depends on SPI select IIO_ADIS_LIB select IIO_ADIS_LIB_BUFFER if IIO_BUFFER + select CRC32 help Say yes here to build support for Analog Devices ADIS16375, ADIS16480, ADIS16485, ADIS16488 inertial sensors. -- 2.40.0

2 years, 7 months

1
0
0 0

patch "drivers: iio: adc: ltc2497: fix LSB shift" 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 drivers: iio: adc: ltc2497: fix LSB shift 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 6327a930ab7bfa1ab33bcdffd5f5f4b1e7131504 Mon Sep 17 00:00:00 2001 From: Ian Ray <ian.ray(a)ge.com> Date: Fri, 27 Jan 2023 14:57:14 +0200 Subject: drivers: iio: adc: ltc2497: fix LSB shift Correct the "sub_lsb" shift for the ltc2497 and drop the sub_lsb element which is now constant. An earlier version of the code shifted by 14 but this was a consequence of reading three bytes into a __be32 buffer and using be32_to_cpu(), so eight extra bits needed to be skipped. Now we use get_unaligned_be24() and thus the additional skip is wrong. Fixes: 2187cfeb3626 ("drivers: iio: adc: ltc2497: LTC2499 support") Signed-off-by: Ian Ray <ian.ray(a)ge.com> Link: https://lore.kernel.org/r/20230127125714.44608-1-ian.ray@ge.com Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/ltc2497.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/iio/adc/ltc2497.c b/drivers/iio/adc/ltc2497.c index 17370c5eb6fe..ec198c6f13d6 100644 --- a/drivers/iio/adc/ltc2497.c +++ b/drivers/iio/adc/ltc2497.c @@ -28,7 +28,6 @@ struct ltc2497_driverdata { struct ltc2497core_driverdata common_ddata; struct i2c_client *client; u32 recv_size; - u32 sub_lsb; /* * DMA (thus cache coherency maintenance) may require the * transfer buffers to live in their own cache lines. @@ -65,10 +64,10 @@ static int ltc2497_result_and_measure(struct ltc2497core_driverdata *ddata, * equivalent to a sign extension. */ if (st->recv_size == 3) { - *val = (get_unaligned_be24(st->data.d8) >> st->sub_lsb) + *val = (get_unaligned_be24(st->data.d8) >> 6) - BIT(ddata->chip_info->resolution + 1); } else { - *val = (be32_to_cpu(st->data.d32) >> st->sub_lsb) + *val = (be32_to_cpu(st->data.d32) >> 6) - BIT(ddata->chip_info->resolution + 1); } @@ -122,7 +121,6 @@ static int ltc2497_probe(struct i2c_client *client) st->common_ddata.chip_info = chip_info; resolution = chip_info->resolution; - st->sub_lsb = 31 - (resolution + 1); st->recv_size = BITS_TO_BYTES(resolution) + 1; return ltc2497core_probe(dev, indio_dev); -- 2.40.0

2 years, 7 months

1
0
0 0

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

2 years, 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

2 years, 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

2 years, 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

2 years, 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

2 years, 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.

2 years, 7 months

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror