October 2023 - Linux-stable-mirror

patch "iio: pressure: dps310: Adjust Timeout Settings" 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: pressure: dps310: Adjust Timeout Settings 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 901a293fd96fb9bab843ba4cc7be3094a5aa7c94 Mon Sep 17 00:00:00 2001 From: Lakshmi Yadlapati <lakshmiy(a)us.ibm.com> Date: Tue, 29 Aug 2023 13:02:22 -0500 Subject: iio: pressure: dps310: Adjust Timeout Settings The DPS310 sensor chip has been encountering intermittent errors while reading the sensor device across various system designs. This issue causes the chip to become "stuck," preventing the indication of "ready" status for pressure and temperature measurements in the MEAS_CFG register. To address this issue, this commit fixes the timeout settings to improve sensor stability: - After sending a reset command to the chip, the timeout has been extended from 2.5 ms to 15 ms, aligning with the DPS310 specification. - The read timeout value of the MEAS_CFG register has been adjusted from 20ms to 30ms to match the specification. Signed-off-by: Lakshmi Yadlapati <lakshmiy(a)us.ibm.com> Fixes: 7b4ab4abcea4 ("iio: pressure: dps310: Reset chip after timeout") Link: https://lore.kernel.org/r/20230829180222.3431926-2-lakshmiy@us.ibm.com Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/pressure/dps310.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/iio/pressure/dps310.c b/drivers/iio/pressure/dps310.c index b10dbf5cf494..1ff091b2f764 100644 --- a/drivers/iio/pressure/dps310.c +++ b/drivers/iio/pressure/dps310.c @@ -57,8 +57,8 @@ #define DPS310_RESET_MAGIC 0x09 #define DPS310_COEF_BASE 0x10 -/* Make sure sleep time is <= 20ms for usleep_range */ -#define DPS310_POLL_SLEEP_US(t) min(20000, (t) / 8) +/* Make sure sleep time is <= 30ms for usleep_range */ +#define DPS310_POLL_SLEEP_US(t) min(30000, (t) / 8) /* Silently handle error in rate value here */ #define DPS310_POLL_TIMEOUT_US(rc) ((rc) <= 0 ? 1000000 : 1000000 / (rc)) @@ -402,8 +402,8 @@ static int dps310_reset_wait(struct dps310_data *data) if (rc) return rc; - /* Wait for device chip access: 2.5ms in specification */ - usleep_range(2500, 12000); + /* Wait for device chip access: 15ms in specification */ + usleep_range(15000, 55000); return 0; } -- 2.42.0

1 year, 1 month

1
0
0 0

patch "iio: imu: bno055: Fix missing Kconfig dependencies" 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: imu: bno055: Fix missing Kconfig dependencies 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 c9b9cfe7d342683f624a89c3b617be18aff879e8 Mon Sep 17 00:00:00 2001 From: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Date: Sun, 3 Sep 2023 12:30:52 +0100 Subject: iio: imu: bno055: Fix missing Kconfig dependencies This driver uses IIO triggered buffers so it needs to select them in Kconfig. on riscv-32bit: /opt/crosstool/gcc-13.2.0-nolibc/riscv32-linux/bin/riscv32-linux-ld: drivers/iio/imu/bno055/bno055.o: in function `.L367': bno055.c:(.text+0x2c96): undefined reference to `devm_iio_triggered_buffer_setup_ext' Reported-by: Randy Dunlap <rdunlap(a)infradead.org> Closes: https://lore.kernel.org/linux-next/40566b4b-3950-81fe-ff14-871d8c447627@inf… Fixes: 4aefe1c2bd0c ("iio: imu: add Bosch Sensortec BNO055 core driver") Cc: Andrea Merello <andrea.merello(a)iit.it> Acked-by: Randy Dunlap <rdunlap(a)infradead.org> Tested-by: Randy Dunlap <rdunlap(a)infradead.org> Link: https://lore.kernel.org/r/20230903113052.846298-1-jic23@kernel.org Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/imu/bno055/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iio/imu/bno055/Kconfig b/drivers/iio/imu/bno055/Kconfig index fa79b1ac4f85..83e53acfbe88 100644 --- a/drivers/iio/imu/bno055/Kconfig +++ b/drivers/iio/imu/bno055/Kconfig @@ -2,6 +2,8 @@ config BOSCH_BNO055 tristate + select IIO_BUFFER + select IIO_TRIGGERED_BUFFER config BOSCH_BNO055_SERIAL tristate "Bosch BNO055 attached via UART" -- 2.42.0

1 year, 1 month

1
0
0 0

patch "iio: adc: imx8qxp: Fix address for command buffer registers" 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: imx8qxp: Fix address for command buffer registers 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 850101b3598277794f92a9e363a60a66e0d42890 Mon Sep 17 00:00:00 2001 From: Philipp Rossak <embed3d(a)gmail.com> Date: Tue, 5 Sep 2023 00:02:04 +0200 Subject: iio: adc: imx8qxp: Fix address for command buffer registers The ADC Command Buffer Register high and low are currently pointing to the wrong address and makes it impossible to perform correct ADC measurements over all channels. According to the datasheet of the imx8qxp the ADC_CMDL register starts at address 0x100 and the ADC_CMDH register starts at address 0x104. This bug seems to be in the kernel since the introduction of this driver. This can be observed by checking all raw voltages of the adc and they are all nearly identical: cat /sys/bus/iio/devices/iio\:device0/in_voltage*_raw 3498 3494 3491 3491 3489 3490 3490 3490 Fixes: 1e23dcaa1a9fa ("iio: imx8qxp-adc: Add driver support for NXP IMX8QXP ADC") Signed-off-by: Philipp Rossak <embed3d(a)gmail.com> Acked-by: Haibo Chen <haibo.chen(a)nxp.com> Link: https://lore.kernel.org/r/20230904220204.23841-1-embed3d@gmail.com Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/imx8qxp-adc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/iio/adc/imx8qxp-adc.c b/drivers/iio/adc/imx8qxp-adc.c index f5a0fc9e64c5..fff6e5a2d956 100644 --- a/drivers/iio/adc/imx8qxp-adc.c +++ b/drivers/iio/adc/imx8qxp-adc.c @@ -38,8 +38,8 @@ #define IMX8QXP_ADR_ADC_FCTRL 0x30 #define IMX8QXP_ADR_ADC_SWTRIG 0x34 #define IMX8QXP_ADR_ADC_TCTRL(tid) (0xc0 + (tid) * 4) -#define IMX8QXP_ADR_ADC_CMDH(cid) (0x100 + (cid) * 8) -#define IMX8QXP_ADR_ADC_CMDL(cid) (0x104 + (cid) * 8) +#define IMX8QXP_ADR_ADC_CMDL(cid) (0x100 + (cid) * 8) +#define IMX8QXP_ADR_ADC_CMDH(cid) (0x104 + (cid) * 8) #define IMX8QXP_ADR_ADC_RESFIFO 0x300 #define IMX8QXP_ADR_ADC_TST 0xffc -- 2.42.0

1 year, 1 month

1
0
0 0

patch "iio: admv1013: add mixer_vgate corner cases" 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: admv1013: add mixer_vgate corner cases 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 287d998af24326b009ae0956820a3188501b34a0 Mon Sep 17 00:00:00 2001 From: Antoniu Miclaus <antoniu.miclaus(a)analog.com> Date: Mon, 7 Aug 2023 17:38:05 +0300 Subject: iio: admv1013: add mixer_vgate corner cases Include the corner cases in the computation of the MIXER_VGATE register value. According to the datasheet: The MIXER_VGATE values follows the VCM such as, that for a 0V to 1.8V VCM, MIXER_VGATE = 23.89 VCM + 81, and for a > 1.8V to 2.6V VCM, MIXER_VGATE = 23.75 VCM + 1.25. Fixes: da35a7b526d9 ("iio: frequency: admv1013: add support for ADMV1013") Signed-off-by: Antoniu Miclaus <antoniu.miclaus(a)analog.com> Reviewed-by: Nuno Sa <nuno.sa(a)analog.com> Link: https://lore.kernel.org/r/20230807143806.6954-1-antoniu.miclaus@analog.com Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/frequency/admv1013.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/iio/frequency/admv1013.c b/drivers/iio/frequency/admv1013.c index 6355c1f28423..92923074f930 100644 --- a/drivers/iio/frequency/admv1013.c +++ b/drivers/iio/frequency/admv1013.c @@ -351,9 +351,9 @@ static int admv1013_update_mixer_vgate(struct admv1013_state *st) if (vcm < 0) return vcm; - if (vcm < 1800000) + if (vcm <= 1800000) mixer_vgate = (2389 * vcm / 1000000 + 8100) / 100; - else if (vcm > 1800000 && vcm < 2600000) + else if (vcm > 1800000 && vcm <= 2600000) mixer_vgate = (2375 * vcm / 1000000 + 125) / 100; else return -EINVAL; -- 2.42.0

1 year, 1 month

1
0
0 0

patch "iio: dac: ad3552r: Correct device IDs" 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: dac: ad3552r: Correct device IDs 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 9a85653ed3b9a9b7b31d95a34b64b990c3d33ca1 Mon Sep 17 00:00:00 2001 From: Marcelo Schmitt <marcelo.schmitt1(a)gmail.com> Date: Thu, 3 Aug 2023 16:56:23 -0300 Subject: iio: dac: ad3552r: Correct device IDs Device IDs for AD3542R and AD3552R were swapped leading to unintended collection of DAC output ranges being used for each design. Change device ID values so they are correct for each DAC chip. Fixes: 8f2b54824b28 ("drivers:iio:dac: Add AD3552R driver support") Signed-off-by: Marcelo Schmitt <marcelo.schmitt1(a)gmail.com> Reported-by: Chandrakant Minajigi <Chandrakant.Minajigi(a)analog.com> Link: https://lore.kernel.org/r/011f480220799fbfabdd53896f8a2f251ad995ad.16910913… Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/dac/ad3552r.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/iio/dac/ad3552r.c b/drivers/iio/dac/ad3552r.c index d5ea1a1be122..a492e8f2fc0f 100644 --- a/drivers/iio/dac/ad3552r.c +++ b/drivers/iio/dac/ad3552r.c @@ -140,8 +140,8 @@ enum ad3552r_ch_vref_select { }; enum ad3542r_id { - AD3542R_ID = 0x4008, - AD3552R_ID = 0x4009, + AD3542R_ID = 0x4009, + AD3552R_ID = 0x4008, }; enum ad3552r_ch_output_range { -- 2.42.0

1 year, 1 month

1
0
0 0

[PATCH] HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect

by Hans de Goede

hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU) races when it races with itself. hidpp_connect_event() primarily runs from a workqueue but it also runs on probe() and if a "device-connected" packet is received by the hw when the thread running hidpp_connect_event() from probe() is waiting on the hw, then a second thread running hidpp_connect_event() will be started from the workqueue. This opens the following races (note the below code is simplified): 1. Retrieving + printing the protocol (harmless race): if (!hidpp->protocol_major) { hidpp_root_get_protocol_version() hidpp->protocol_major = response.rap.params[0]; } We can actually see this race hit in the dmesg in the abrt output attached to rhbz#2227968: [ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. [ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. Testing with extra logging added has shown that after this the 2 threads take turn grabbing the hw access mutex (send_mutex) so they ping-pong through all the other TOCTOU cases managing to hit all of them: 2. Updating the name to the HIDPP name (harmless race): if (hidpp->name == hdev->name) { ... hidpp->name = new_name; } 3. Initializing the power_supply class for the battery (problematic!): hidpp_initialize_battery() { if (hidpp->battery.ps) return 0; probe_battery(); /* Blocks, threads take turns executing this */ hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); } 4. Creating delayed input_device (potentially problematic): if (hidpp->delayed_input) return; hidpp->delayed_input = hidpp_allocate_input(hdev); The really big problem here is 3. Hitting the race leads to the following sequence: hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); ... hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); So now we have registered 2 power supplies for the same battery, which looks a bit weird from userspace's pov but this is not even the really big problem. Notice how: 1. This is all devm-maganaged 2. The hidpp->battery.desc struct is shared between the 2 power supplies 3. hidpp->battery.desc points to the result from the second devm_kmemdup() This causes a use after free scenario on USB disconnect of the receiver: 1. The last registered power supply class device gets unregistered 2. The memory from the last devm_kmemdup() call gets freed, hidpp->battery.desc.properties now points to freed memory 3. The first registered power supply class device gets unregistered, this involves sending a remove uevent to userspace which invokes power_supply_uevent() to fill the uevent data 4. power_supply_uevent() uses hidpp->battery.desc.properties which now points to freed memory leading to backtraces like this one: Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08 ... Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0 ... Sep 22 20:01:35 eric kernel: ? asm_exc_page_fault+0x26/0x30 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0xee/0x1d0 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0x10d/0x1d0 Sep 22 20:01:35 eric kernel: dev_uevent+0x10f/0x2d0 Sep 22 20:01:35 eric kernel: kobject_uevent_env+0x291/0x680 Sep 22 20:01:35 eric kernel: power_supply_unregister+0x8e/0xa0 Sep 22 20:01:35 eric kernel: release_nodes+0x3d/0xb0 Sep 22 20:01:35 eric kernel: devres_release_group+0xfc/0x130 Sep 22 20:01:35 eric kernel: hid_device_remove+0x56/0xa0 Sep 22 20:01:35 eric kernel: device_release_driver_internal+0x19f/0x200 Sep 22 20:01:35 eric kernel: bus_remove_device+0xc6/0x130 Sep 22 20:01:35 eric kernel: device_del+0x15c/0x3f0 Sep 22 20:01:35 eric kernel: ? __queue_work+0x1df/0x440 Sep 22 20:01:35 eric kernel: hid_destroy_device+0x4b/0x60 Sep 22 20:01:35 eric kernel: logi_dj_remove+0x9a/0x100 [hid_logitech_dj 5c91534a0ead2b65e04dd799a0437e3b99b21bc4] Sep 22 20:01:35 eric kernel: hid_device_remove+0x44/0xa0 Sep 22 20:01:35 eric kernel: device_release_driver_internal+0x19f/0x200 Sep 22 20:01:35 eric kernel: bus_remove_device+0xc6/0x130 Sep 22 20:01:35 eric kernel: device_del+0x15c/0x3f0 Sep 22 20:01:35 eric kernel: ? __queue_work+0x1df/0x440 Sep 22 20:01:35 eric kernel: hid_destroy_device+0x4b/0x60 Sep 22 20:01:35 eric kernel: usbhid_disconnect+0x47/0x60 [usbhid 727dcc1c0b94e6b4418727a468398ac3bca492f3] Sep 22 20:01:35 eric kernel: usb_unbind_interface+0x90/0x270 Sep 22 20:01:35 eric kernel: device_release_driver_internal+0x19f/0x200 Sep 22 20:01:35 eric kernel: bus_remove_device+0xc6/0x130 Sep 22 20:01:35 eric kernel: device_del+0x15c/0x3f0 Sep 22 20:01:35 eric kernel: ? kobject_put+0xa0/0x1d0 Sep 22 20:01:35 eric kernel: usb_disable_device+0xcd/0x1e0 Sep 22 20:01:35 eric kernel: usb_disconnect+0xde/0x2c0 Sep 22 20:01:35 eric kernel: usb_disconnect+0xc3/0x2c0 Sep 22 20:01:35 eric kernel: hub_event+0xe80/0x1c10 There have been quite a few bug reports (see Link tags) about this crash. Fix all the TOCTOU issues, including the really bad power-supply related system crash on USB disconnect, by making probe() use the workqueue for running hidpp_connect_event() too, so that it can never run more then once. Link: https://bugzilla.redhat.com/show_bug.cgi?id=2227221 Link: https://bugzilla.redhat.com/show_bug.cgi?id=2227968 Link: https://bugzilla.redhat.com/show_bug.cgi?id=2227968 Link: https://bugzilla.redhat.com/show_bug.cgi?id=2242189 Link: https://bugzilla.kernel.org/show_bug.cgi?id=217412#c58 Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- drivers/hid/hid-logitech-hidpp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c index ff077df0babf..a209d51bd247 100644 --- a/drivers/hid/hid-logitech-hidpp.c +++ b/drivers/hid/hid-logitech-hidpp.c @@ -4515,7 +4515,8 @@ static int hidpp_probe(struct hid_device *hdev, const struct hid_device_id *id) goto hid_hw_init_fail; } - hidpp_connect_event(hidpp); + schedule_work(&hidpp->work); + flush_work(&hidpp->work); if (will_restart) { /* Reset the HID node state */ -- 2.41.0

1 year, 1 month

2
6
0 0

[PATCH for 5.10-6.1 0/4] rbd: fix a deadlock around header_rwsem and lock_rwsem

by Ilya Dryomov

Hello, Patch 1/4 needed a trivial adjustment, the rest were taken verbatim and included here just for convenience. Thanks, Ilya Ilya Dryomov (4): rbd: move rbd_dev_refresh() definition rbd: decouple header read-in from updating rbd_dev->header rbd: decouple parent info read-in from updating rbd_dev rbd: take header_rwsem in rbd_dev_refresh() only when updating drivers/block/rbd.c | 412 ++++++++++++++++++++++++-------------------- 1 file changed, 225 insertions(+), 187 deletions(-) -- 2.41.0

1 year, 1 month

2
5
0 0

Re: [PATCH 1/2] Revert "NFSv4: Retry LOCK on OLD_STATEID during delegation return"

by Anna Schumaker

Hi Stable Kernel Team, Can this patch be backported to v6.1+ kernels? The commit id is 5b4a82a0724a and has been upstream since v6.5. As was mentioned in the original patch description (below), the commit being reverted by this patch breaks state recovery in a way that is worse than the initial bug that it was attempting to fix. Thanks, Anna On Tue, Jun 27, 2023 at 2:31 PM Benjamin Coddington <bcodding(a)redhat.com> wrote: > > Olga Kornievskaia reports that this patch breaks NFSv4.0 state recovery. > It also introduces additional complexity in the error paths for cases not > related to the original problem. Let's revert it for now, and address the > original problem in another manner. > > This reverts commit f5ea16137a3fa2858620dc9084466491c128535f. > > Fixes: f5ea16137a3f ("NFSv4: Retry LOCK on OLD_STATEID during delegation return") > Reported-by: Kornievskaia, Olga <Olga.Kornievskaia(a)netapp.com> > Signed-off-by: Benjamin Coddington <bcodding(a)redhat.com> > --- > fs/nfs/nfs4proc.c | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c > index d3665390c4cb..6bb14f6cfbc0 100644 > --- a/fs/nfs/nfs4proc.c > +++ b/fs/nfs/nfs4proc.c > @@ -7159,7 +7159,6 @@ static void nfs4_lock_done(struct rpc_task *task, void *calldata) > { > struct nfs4_lockdata *data = calldata; > struct nfs4_lock_state *lsp = data->lsp; > - struct nfs_server *server = NFS_SERVER(d_inode(data->ctx->dentry)); > > if (!nfs4_sequence_done(task, &data->res.seq_res)) > return; > @@ -7167,7 +7166,8 @@ static void nfs4_lock_done(struct rpc_task *task, void *calldata) > data->rpc_status = task->tk_status; > switch (task->tk_status) { > case 0: > - renew_lease(server, data->timestamp); > + renew_lease(NFS_SERVER(d_inode(data->ctx->dentry)), > + data->timestamp); > if (data->arg.new_lock && !data->cancelled) { > data->fl.fl_flags &= ~(FL_SLEEP | FL_ACCESS); > if (locks_lock_inode_wait(lsp->ls_state->inode, &data->fl) < 0) > @@ -7188,8 +7188,6 @@ static void nfs4_lock_done(struct rpc_task *task, void *calldata) > if (!nfs4_stateid_match(&data->arg.open_stateid, > &lsp->ls_state->open_stateid)) > goto out_restart; > - else if (nfs4_async_handle_error(task, server, lsp->ls_state, NULL) == -EAGAIN) > - goto out_restart; > } else if (!nfs4_stateid_match(&data->arg.lock_stateid, > &lsp->ls_stateid)) > goto out_restart; > -- > 2.40.1 >

1 year, 1 month

2
1
0 0

[5.15,6.1] Please apply a89c6bcdac22bec1bfbe6e64060b4cf5838d4f47

by Luiz Capitulino

Hi, We found that commits 46bdb4277f98 and 0388f9c74330 (merged in v5.12) introduced more than 40% performance regression in UnixBench's process creation benchmark when comparing 5.10 with 5.15 and 6.1 on AWS' virtualized Graviton instances. This has been mostly fixed by the following upstream commit: """ commit a89c6bcdac22bec1bfbe6e64060b4cf5838d4f47 Author: Gabriel Krisman Bertazi <krisman(a)suse.de> Date: Mon Jan 9 12:19:55 2023 -0300 arm64: Avoid repeated AA64MMFR1_EL1 register read on pagefault path """ (This is merged in v6.3 and applies cleanly in 5.15 and 6.1). We performed functional and performance regression tests on both 5.15 and 6.1 with this patch applied. We can also observe 10% improvement in system time in other benchmarks. Just to be transparent, we initially observed 5% degradation in a benchmark we have with fio randwrite on EBS volumes with our 6.1 downstream kernel but this doesn't seem reproducible and we don't think this patch would cause it. Here's some quick UnixBench process creation measurements on m7gd.16xlarge instance type. All results are the average of 5 consecutive runs with a single process: * 5.10.197: 9886.68 lps (baseline) * 6.1.55: 5531.24 lps (unfixed - 44% degradation) * 5.15.133: 5960.12 lps (unfixed - 39% degradation) * 5.15.133: 10306.4 lps (fixed - actually better than baseline) * 6.1.55: 9393.42 lps (fixed - degradation reduced to 5%) - Luiz

1 year, 1 month

2
1
0 0

Re: [PATCH] nvmet-tcp: Fix a possible UAF in queue intialization setup

by sj＠kernel.org

Hello, On Mon, 2 Oct 2023 13:54:28 +0300 Sagi Grimberg <sagi(a)grimberg.me> wrote: > From Alon: > "Due to a logical bug in the NVMe-oF/TCP subsystem in the Linux kernel, > a malicious user can cause a UAF and a double free, which may lead to > RCE (may also lead to an LPE in case the attacker already has local > privileges)." > > Hence, when a queue initialization fails after the ahash requests are > allocated, it is guaranteed that the queue removal async work will be > called, hence leave the deallocation to the queue removal. > > Also, be extra careful not to continue processing the socket, so set > queue rcv_state to NVMET_TCP_RECV_ERR upon a socket error. > > Reported-by: Alon Zahavi <zahavi.alon(a)gmail.com> > Tested-by: Alon Zahavi <zahavi.alon(a)gmail.com> > Signed-off-by: Sagi Grimberg <sagi(a)grimberg.me> Would it be better to add Fixes: and Cc: stable lines? Thanks, SJ > --- > drivers/nvme/target/tcp.c | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/nvme/target/tcp.c b/drivers/nvme/target/tcp.c > index 97d07488072d..d840f996eb82 100644 > --- a/drivers/nvme/target/tcp.c > +++ b/drivers/nvme/target/tcp.c > @@ -372,6 +372,7 @@ static void nvmet_tcp_fatal_error(struct nvmet_tcp_queue *queue) > > static void nvmet_tcp_socket_error(struct nvmet_tcp_queue *queue, int status) > { > + queue->rcv_state = NVMET_TCP_RECV_ERR; > if (status == -EPIPE || status == -ECONNRESET) > kernel_sock_shutdown(queue->sock, SHUT_RDWR); > else > @@ -910,15 +911,11 @@ static int nvmet_tcp_handle_icreq(struct nvmet_tcp_queue *queue) > iov.iov_len = sizeof(*icresp); > ret = kernel_sendmsg(queue->sock, &msg, &iov, 1, iov.iov_len); > if (ret < 0) > - goto free_crypto; > + return ret; /* queue removal will cleanup */ > > queue->state = NVMET_TCP_Q_LIVE; > nvmet_prepare_receive_pdu(queue); > return 0; > -free_crypto: > - if (queue->hdr_digest || queue->data_digest) > - nvmet_tcp_free_crypto(queue); > - return ret; > } > > static void nvmet_tcp_handle_req_failure(struct nvmet_tcp_queue *queue, > -- > 2.41.0 > >

1 year, 1 month

5
5
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2023