When sd_init_command() get's a with a unknown req_op() it crashes the
system via BUG().
This makes debugging the actual reason for the broken request
cmd_flags pretty hard as the system is down before it's able to write
out debugging data on the serial console or the trace buffer.
Change the BUG() to a WARN_ON() and return BLKPREP_KILL to fail
gracefully and return an I/O error to the producer of the request.
Signed-off-by: Johannes Thumshirn <[email protected]>
Cc: Hannes Reinecke <[email protected]>
Cc: Bart Van Assche <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
---
Changes since v1:
- Use WARN_ON_ONCE() (Bart)
---
drivers/scsi/sd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index b79b366a94f7..f2e41f04e40b 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -1276,7 +1276,8 @@ static int sd_init_command(struct scsi_cmnd *cmd)
case REQ_OP_ZONE_RESET:
return sd_zbc_setup_reset_cmnd(cmd);
default:
- BUG();
+ WARN_ON_ONCE(1);
+ return BLKPREP_KILL;
}
}
--
2.16.4
On 9/21/18 12:01 AM, Johannes Thumshirn wrote:
> When sd_init_command() get's a with a unknown req_op() it crashes the
> system via BUG().
>
> This makes debugging the actual reason for the broken request
> cmd_flags pretty hard as the system is down before it's able to write
> out debugging data on the serial console or the trace buffer.
>
> Change the BUG() to a WARN_ON() and return BLKPREP_KILL to fail
> gracefully and return an I/O error to the producer of the request.
Reviewed-by: Bart Van Assche <[email protected]>
Johannes,
> When sd_init_command() get's a with a unknown req_op() it crashes the
> system via BUG().
>
> This makes debugging the actual reason for the broken request
> cmd_flags pretty hard as the system is down before it's able to write
> out debugging data on the serial console or the trace buffer.
>
> Change the BUG() to a WARN_ON() and return BLKPREP_KILL to fail
> gracefully and return an I/O error to the producer of the request.
Looks like a bunch of my merge mails didn't make it out last week.
For the record, I did merge this into 4.19/scsi-fixes and it has made
its way upstream.
--
Martin K. Petersen Oracle Linux Engineering
On Tue, Sep 25, 2018 at 08:52:58PM -0400, Martin K. Petersen wrote:
> Looks like a bunch of my merge mails didn't make it out last week.
>
> For the record, I did merge this into 4.19/scsi-fixes and it has made
> its way upstream.
Thanks for the info.
Byte,
Johannes
--
Johannes Thumshirn Storage
[email protected] +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N?rnberg
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850