From cd45ea699a3be7d28e13622b6a7ee316b905296c Mon Sep 17 00:00:00 2001 From: James Bottomley Date: Sun, 17 May 2009 09:30:48 -0500 Subject: [PATCH] --- yaml --- r: 148088 b: refs/heads/master c: 91bc31fb3bae4e55832c7c39d4f9c193285e6ab2 h: refs/heads/master v: v3 --- [refs] | 2 +- trunk/drivers/scsi/scsi_error.c | 17 +++++------------ 2 files changed, 6 insertions(+), 13 deletions(-) diff --git a/[refs] b/[refs] index bb37d93e40ec..246631f83600 100644 --- a/[refs] +++ b/[refs] @@ -1,2 +1,2 @@ --- -refs/heads/master: 477e608c03eb2f561a23994bee38a32a9fd3357d +refs/heads/master: 91bc31fb3bae4e55832c7c39d4f9c193285e6ab2 diff --git a/trunk/drivers/scsi/scsi_error.c b/trunk/drivers/scsi/scsi_error.c index a95d2bac0780..a1689353d7fd 100644 --- a/trunk/drivers/scsi/scsi_error.c +++ b/trunk/drivers/scsi/scsi_error.c @@ -1451,28 +1451,21 @@ static void eh_lock_door_done(struct request *req, int uptodate) * @sdev: SCSI device to prevent medium removal * * Locking: - * We must be called from process context; scsi_allocate_request() - * may sleep. + * We must be called from process context. * * Notes: * We queue up an asynchronous "ALLOW MEDIUM REMOVAL" request on the * head of the devices request queue, and continue. - * - * Bugs: - * scsi_allocate_request() may sleep waiting for existing requests to - * be processed. However, since we haven't kicked off any request - * processing for this host, this may deadlock. - * - * If scsi_allocate_request() fails for what ever reason, we - * completely forget to lock the door. */ static void scsi_eh_lock_door(struct scsi_device *sdev) { struct request *req; + /* + * blk_get_request with GFP_KERNEL (__GFP_WAIT) sleeps until a + * request becomes available + */ req = blk_get_request(sdev->request_queue, READ, GFP_KERNEL); - if (!req) - return; req->cmd[0] = ALLOW_MEDIUM_REMOVAL; req->cmd[1] = 0;