On Fri, Jan 12, 2018 at 10:45:57PM +0000, Bart Van Assche wrote:
> On Thu, 2018-01-11 at 10:23 +0800, Ming Lei wrote:
> > > not sufficient to prevent .queuecommand() calls from scsi_send_eh_cmnd().
> >
> > Given it is error handling, do we need to prevent the .queuecommand() call
> > in scsi_send_eh_cmnd()? Could you share us what the actual issue
> > observed is from user view?
>
> Please have a look at the kernel bug report in the description of patch 4/4 of
> this series.
Thanks for your mentioning, then I can find the following comment in
srp_queuecommand():
/*
* The SCSI EH thread is the only context from which
srp_queuecommand()
* can get invoked for blocked devices (SDEV_BLOCK /
* SDEV_CREATED_BLOCK). Avoid racing with srp_reconnect_rport()
by
* locking the rport mutex if invoked from inside the SCSI EH.
*/
That means EH request is allowed to send to blocked device.
I also replied in patch 4/4, looks there is one simple one line change
which should address the issue of 'sleep in atomic context', please discuss that
in patch 4/4 thread.
--
Ming
