Re: CPU lock-ups with 4.12.0+ kernels related to usb_storage

[Arthur Marsh <arthur.marsh@xxxxxxxxxxxxxxxx>]

Alan Stern wrote on 14/07/17 02:30:

> All right.  In the meantime, changing usb-storage won't hurt.
> Arthur, can you test the patch below?
>
> Alan Stern
>
>
>
> Index: usb-4.x/drivers/usb/storage/usb.c
> ===================================================================
> --- usb-4.x.orig/drivers/usb/storage/usb.c
> +++ usb-4.x/drivers/usb/storage/usb.c
> @@ -315,6 +315,7 @@ static int usb_stor_control_thread(void
>   {
>   	struct us_data *us = (struct us_data *)__us;
>   	struct Scsi_Host *host = us_to_host(us);
> +	struct scsi_cmnd *srb;
>   
>   	for (;;) {
>   		usb_stor_dbg(us, "*** thread sleeping\n");
> @@ -330,6 +331,7 @@ static int usb_stor_control_thread(void
>   		scsi_lock(host);
>   
>   		/* When we are called with no command pending, we're done */
> +		srb = us->srb;
>   		if (us->srb == NULL) {
>   			scsi_unlock(host);
>   			mutex_unlock(&us->dev_mutex);
> @@ -398,14 +400,11 @@ static int usb_stor_control_thread(void
>   		/* lock access to the state */
>   		scsi_lock(host);
>   
> -		/* indicate that the command is done */
> -		if (us->srb->result != DID_ABORT << 16) {
> -			usb_stor_dbg(us, "scsi cmd done, result=0x%x\n",
> -				     us->srb->result);
> -			us->srb->scsi_done(us->srb);
> -		} else {
> +		/* was the command aborted? */
> +		if (us->srb->result == DID_ABORT << 16) {
>   SkipForAbort:
>   			usb_stor_dbg(us, "scsi command aborted\n");
> +			srb = NULL;	/* Don't call srb->scsi_done() */
>   		}
>   
>   		/*
> @@ -429,6 +428,13 @@ SkipForAbort:
>   
>   		/* unlock the device pointers */
>   		mutex_unlock(&us->dev_mutex);
> +
> +		/* now that the locks are released, notify the SCSI core */
> +		if (srb) {
> +			usb_stor_dbg(us, "scsi cmd done, result=0x%x\n",
> +					srb->result);
> +			srb->scsi_done(srb);
> +		}
>   	} /* for (;;) */
>   
>   	/* Wait until we are told to stop */

Thanks for the patch!

I have applied it and am running the resulting kernel.

As I didn't have a reproducible way to trigger the problem on demand, 
I'll just have to see that there isn't a lock-up that looks related over 
the next several days.

Arthur.