linux-kernel - Re: Strange block/scsi/workqueue issue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20110531100511.7145c545@table.home>
Date:	Tue, 31 May 2011 10:05:11 +0400
From:	"Anton V. Boyarshinov" <boyarsh@...linux.org>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
Cc:	Steven Whitehouse <swhiteho@...hat.com>, Tejun Heo <tj@...nel.org>,
	linux-kernel@...r.kernel.org, Jens Axboe <jaxboe@...ionio.com>
Subject: Re: Strange block/scsi/workqueue issue

Hi

> While you still have the problematic system, can you try this patch?
It seems that a scsi_sysfs.c half of this patch there is in 2.6.39, but
not blk.h part. Now we have frequent panics caused NULL in
q->elevator->ops in block/blk.h.

Panic is triggered by connecting USB Storage device without medium
(card reader, android phone). We saw it on different computers with
different kernel builds. Most frequent panics have seen on kernel build
with forsed preemption under relatively havy load (for example, boot).

Regards, Anton

> It avoids changing anything in block (other than to add a missing
> state guard for the elv_next_request).  If it works, we can defer the
> sync vs async discussion and use it for a -stable fix.
> 
> Thanks,
> 
> James
> 
> ---
> 
> diff --git a/block/blk.h b/
> index c8db371..11d0d25 100644
> --- a/block/blk.h
> +++ b/block/blk.h
> @@ -62,7 +62,8 @@ static inline struct request
> *__elv_next_request(struct request_queue *q) return rq;
>  		}
>  
> -		if (!q->elevator->ops->elevator_dispatch_fn(q, 0))
> +		if (test_bit(QUEUE_FLAG_DEAD, &q->queue_flags) ||
> +		    !q->elevator->ops->elevator_dispatch_fn(q, 0))
>  			return NULL;
>  	}
>  }
> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> index e44ff64..5aa4246 100644
> --- a/drivers/scsi/scsi_sysfs.c
> +++ b/drivers/scsi/scsi_sysfs.c
> @@ -322,14 +322,9 @@ static void
> scsi_device_dev_release_usercontext(struct work_struct *work)
> kfree(evt); }
>  
> -	if (sdev->request_queue) {
> -		sdev->request_queue->queuedata = NULL;
> -		/* user context needed to free queue */
> -		scsi_free_queue(sdev->request_queue);
> -		/* temporary expedient, try to catch use of queue
> lock
> -		 * after free of sdev */
> -		sdev->request_queue = NULL;
> -	}
> +	/* temporary expedient, try to catch use of queue lock after
> +	 * free of sdev */
> +	sdev->request_queue = NULL;
>  
>  	scsi_target_reap(scsi_target(sdev));
>  
> @@ -937,6 +932,11 @@ void __scsi_remove_device(struct scsi_device
> *sdev) if (sdev->host->hostt->slave_destroy)
>  		sdev->host->hostt->slave_destroy(sdev);
>  	transport_destroy_device(dev);
> +	/* Setting this to NULL causes the request function to reject
> +	 * any I/O requests */
> +	sdev->request_queue->queuedata = NULL;
> +	/* Freeing the queue signals to block that we're done */
> +	scsi_free_queue(sdev->request_queue);
>  	put_device(dev);
>  }
>  
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/