On Tue, 26 Jan 2016, Oliver Neukum wrote:
> > > --- a/drivers/usb/storage/uas.c
> > > +++ b/drivers/usb/storage/uas.c
> > > @@ -54,6 +54,7 @@ struct uas_dev_info {
> > > struct scsi_cmnd *cmnd[MAX_CMNDS];
> > > spinlock_t lock;
> > > struct work_struct work;
> > > + struct mutex management_mutex;
> > > };
> > >
> > > enum {
> > > @@ -732,6 +733,7 @@ static int uas_eh_abort_handler(struct scsi_cmnd *cmnd)
> > > /* Ensure that try_complete does not call scsi_done */
> > > cmdinfo->state |= COMMAND_ABORTED;
> > >
> > > + mutex_lock(&devinfo->management_mutex);
> >
> > You cannot lock a mutex while holding a spinlock, and you're holding
>
> That is problematic. The ABORT_TMF does need IO for which we need
> to wait. And if we just submit and pretend the abort worked, the tag
> will be reused.
> Perhaps we could drop the spinlock. I think it is time to talk to
> the SCSI people.
The abort handler doesn't have to wait for the command to terminate.
It merely has to initiate an abort and return. The SCSI layer gets
notified via the usual mechanism when the command eventually finishes,
whether it was successful or not.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
