diff mbox series

scsi: target: iblock: Fix smp_processor_id BUG messages

Message ID 20210519222640.5153-1-michael.christie@oracle.com
State New
Headers show
Series scsi: target: iblock: Fix smp_processor_id BUG messages | expand

Commit Message

Mike Christie May 19, 2021, 10:26 p.m. UTC
This has us use raw_smp_processor_id in iblock's plug_device callout.
smp_processor_id is not needed here, because we are running from a per CPU
work item that is also queued to run on a worker thread that is normally
bound to a specific CPU. If the worker thread did end up switching CPUs
then it's handled the same way we handle when the work got moved to a
different CPU's worker thread, where we will just end up sending IO from
the new CPU.

Fixes: 415ccd9811da ("scsi: target: iblock: Add backend plug/unplug
callouts")
Signed-off-by: Mike Christie <michael.christie@oracle.com>

---
 drivers/target/target_core_iblock.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Comments

Shin'ichiro Kawasaki May 20, 2021, 1:12 p.m. UTC | #1
On May 19, 2021 / 17:26, Mike Christie wrote:
> This has us use raw_smp_processor_id in iblock's plug_device callout.

> smp_processor_id is not needed here, because we are running from a per CPU

> work item that is also queued to run on a worker thread that is normally

> bound to a specific CPU. If the worker thread did end up switching CPUs

> then it's handled the same way we handle when the work got moved to a

> different CPU's worker thread, where we will just end up sending IO from

> the new CPU.

> 

> Fixes: 415ccd9811da ("scsi: target: iblock: Add backend plug/unplug

> callouts")

> Signed-off-by: Mike Christie <michael.christie@oracle.com>


Thanks Mike. To confirm this patch, I tried to trigger the BUG message using
block backstore on kernel configured with DEBUG_PREEMPT, but I was not able to
trigger it. Having said that, I think this change prevents the potential BUG
message with the same reasoning as the other fix in target_core_transport [1].
As far as I read through the code, the code should work even when CPU switches.

[1] https://marc.info/?l=linux-scsi&m=162106219905019

-- 
Best Regards,
Shin'ichiro Kawasaki
Martin K. Petersen May 22, 2021, 4:40 a.m. UTC | #2
On Wed, 19 May 2021 17:26:40 -0500, Mike Christie wrote:

> This has us use raw_smp_processor_id in iblock's plug_device callout.

> smp_processor_id is not needed here, because we are running from a per CPU

> work item that is also queued to run on a worker thread that is normally

> bound to a specific CPU. If the worker thread did end up switching CPUs

> then it's handled the same way we handle when the work got moved to a

> different CPU's worker thread, where we will just end up sending IO from

> the new CPU.


Applied to 5.13/scsi-fixes, thanks!

[1/1] scsi: target: iblock: Fix smp_processor_id BUG messages
      https://git.kernel.org/mkp/scsi/c/5aaeca258f55

-- 
Martin K. Petersen	Oracle Linux Engineering
diff mbox series

Patch

diff --git a/drivers/target/target_core_iblock.c b/drivers/target/target_core_iblock.c
index d6fdd1c61f90..a526f9678c34 100644
--- a/drivers/target/target_core_iblock.c
+++ b/drivers/target/target_core_iblock.c
@@ -204,11 +204,11 @@  static struct se_dev_plug *iblock_plug_device(struct se_device *se_dev)
 	struct iblock_dev_plug *ib_dev_plug;
 
 	/*
-	 * Each se_device has a per cpu work this can be run from. Wwe
+	 * Each se_device has a per cpu work this can be run from. We
 	 * shouldn't have multiple threads on the same cpu calling this
 	 * at the same time.
 	 */
-	ib_dev_plug = &ib_dev->ibd_plug[smp_processor_id()];
+	ib_dev_plug = &ib_dev->ibd_plug[raw_smp_processor_id()];
 	if (test_and_set_bit(IBD_PLUGF_PLUGGED, &ib_dev_plug->flags))
 		return NULL;