From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755138Ab1EYTOg (ORCPT ); Wed, 25 May 2011 15:14:36 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:50524 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754947Ab1EYTOf (ORCPT ); Wed, 25 May 2011 15:14:35 -0400 MIME-Version: 1.0 In-Reply-To: <4DDD5240.2060308@fusionio.com> References: <4DDB8BF6.2000304@fusionio.com> <4DDCB1C8.7040708@fusionio.com> <4DDD5240.2060308@fusionio.com> From: Linus Torvalds Date: Wed, 25 May 2011 12:13:44 -0700 Message-ID: Subject: Re: [PATCH] SCSI IOCTL: Check for device deletion [was Re: __elv_add_request OOPS] To: Jens Axboe Cc: Parag Warudkar , "linux-kernel@vger.kernel.org" , "James.Bottomley@hansenpartnership.com" , "akpm@linux-foundation.org" , Linux SCSI List Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 25, 2011 at 12:02 PM, Jens Axboe wrote: > > This is before you get that far, it's actually oopsing on inserting the > request on sdev->sdev_queue that is now NULL. The prep state checking > happens when sr/sd pulls the request off the queue for processing. Ok, please just add a "sdev_alive(sdev)" helper that checks for sdev && sdev->sdev_queue. Apparently the issue isn't "this device is SDEV_DEL, so don't send commands". Apparently the issue is literally "don't oops". Or maybe the prep state checking could be moved earlier. It seems stupid to have a "can I do this command" function that is run too late to actually catch the problems.. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: [PATCH] SCSI IOCTL: Check for device deletion [was Re: __elv_add_request OOPS] Date: Wed, 25 May 2011 12:13:44 -0700 Message-ID: References: <4DDB8BF6.2000304@fusionio.com> <4DDCB1C8.7040708@fusionio.com> <4DDD5240.2060308@fusionio.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Return-path: Received: from smtp1.linux-foundation.org ([140.211.169.13]:50524 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754947Ab1EYTOf (ORCPT ); Wed, 25 May 2011 15:14:35 -0400 In-Reply-To: <4DDD5240.2060308@fusionio.com> Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: Jens Axboe Cc: Parag Warudkar , "linux-kernel@vger.kernel.org" , "James.Bottomley@hansenpartnership.com" , "akpm@linux-foundation.org" , Linux SCSI List On Wed, May 25, 2011 at 12:02 PM, Jens Axboe wrote: > > This is before you get that far, it's actually oopsing on inserting the > request on sdev->sdev_queue that is now NULL. The prep state checking > happens when sr/sd pulls the request off the queue for processing. Ok, please just add a "sdev_alive(sdev)" helper that checks for sdev && sdev->sdev_queue. Apparently the issue isn't "this device is SDEV_DEL, so don't send commands". Apparently the issue is literally "don't oops". Or maybe the prep state checking could be moved earlier. It seems stupid to have a "can I do this command" function that is run too late to actually catch the problems.. Linus