From: David Decotigny <[email protected]>
With some spi devices, the heavy cpu usage due to polling the spi
registers may lead to netdev timeouts, RCU complaints, etc. This can
be acute in the absence of CONFIG_PREEMPT. This patch allows to give
enough breathing room to avoid those false positives.
Signed-off-by: David Decotigny <[email protected]>
---
I tested this on a 5.10 base (lockdep).
drivers/mtd/mtd_blkdevs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c
index 243f28a3206b4..64d2b093f114b 100644
--- a/drivers/mtd/mtd_blkdevs.c
+++ b/drivers/mtd/mtd_blkdevs.c
@@ -158,6 +158,7 @@ static void mtd_blktrans_work(struct mtd_blktrans_dev *dev)
}
background_done = 0;
+ cond_resched();
spin_lock_irq(&dev->queue_lock);
}
}
--
2.35.0.rc0.227.g00780c9af4-goog
David,
----- Ursprüngliche Mail -----
> Von: "David Decotigny" <[email protected]>
> An: "linux-kernel" <[email protected]>
> CC: "Miquel Raynal" <[email protected]>, "richard" <[email protected]>, "Vignesh Raghavendra" <[email protected]>,
> "linux-mtd" <[email protected]>, "David Decotigny" <[email protected]>
> Gesendet: Mittwoch, 26. Januar 2022 09:57:35
> Betreff: [PATCH RFC v1 1/1] mtd_blkdevs: avoid soft lockups with some mtd/spi devices
> From: David Decotigny <[email protected]>
>
> With some spi devices, the heavy cpu usage due to polling the spi
> registers may lead to netdev timeouts, RCU complaints, etc. This can
> be acute in the absence of CONFIG_PREEMPT. This patch allows to give
> enough breathing room to avoid those false positives.
is the problem real or not? From your description it is not clear to me.
Please include lockdep splats and/or hung-task logs in the commit message.
I have no problem with adding a cond_resched() but first we need to
understand the issue a little better.
Thanks,
//richard
----- Ursprüngliche Mail -----
> Von: "David Decotigny" <[email protected]>
> Yes, it is a real problem for us, sent v2 with splat in the commit description.
> The most annoying for us is not the RCU splat per-se, it's the netdev timeout,
> but the trace is not relevant (detected on another core).
Okay. But then it isn't a false positive as you write in the commit message.
Thanks,
//richard