On 2020-03-09 4:49 p.m., Ewan D. Milne wrote:
On Mon, 2020-03-09 at 12:05 -0700, James Bottomley wrote:
On Mon, 2020-03-09 at 14:14 -0400, Ewan D. Milne wrote:
Large queues of I/O to offline devices that are eventually
submitted when devices are unblocked result in a many repeated
"rejecting I/O to offline device" messages. These messages
can fill up the dmesg buffer in crash dumps so no useful
prior messages remain. In addition, if a serial console
is used, the flood of messages can cause a hard lockup in
the console code.
Introduce a flag indicating the message has already been logged
for the device, and reset the flag when scsi_device_set_state()
changes the device state.
Signed-off-by: Ewan D. Milne <emilne@xxxxxxxxxx>
---
drivers/scsi/scsi_lib.c | 8 ++++++--
include/scsi/scsi_device.h | 2 ++
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 610ee41..d3a6d97 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1240,8 +1240,11 @@ scsi_prep_state_check(struct scsi_device
*sdev, struct request *req)
* commands. The device must be brought online
* before trying any recovery commands.
*/
- sdev_printk(KERN_ERR, sdev,
- "rejecting I/O to offline device\n");
+ if (!sdev->offline_already) {
+ sdev->offline_already = 1;
+ sdev_printk(KERN_ERR, sdev,
+ "rejecting I/O to offline
device\n");
+ }
Offline->online is a legal transition, so you'll need to clear this
flag when that happens so we get another offline message if it goes
offline again.
James
That's what resetting the flag in scsi_device_set_state() does.
The only thing that worries me is if some driver manipulates the
sdev->sdev_state value directly.
Perhaps they could sneak in some c++isms and allow the definition
of struct fields to be preceded by [[protected]]. The idea would be
to complain loudly if that field is directly accessed. The accessor
functions might need something similar (or the same decoration) to
defeat that noise.
In the meantime:
Reviewed-by: Douglas Gilbert <dgilbert@xxxxxxxxxxxx>
