Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755878Ab1EYUmW (ORCPT ); Wed, 25 May 2011 16:42:22 -0400 Received: from mail-yw0-f46.google.com ([209.85.213.46]:42128 "EHLO mail-yw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932264Ab1EYUmT (ORCPT ); Wed, 25 May 2011 16:42:19 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type; b=bBnM2VEo3isMsaoLW3uXa7xv9TTI1w3ghuhtG2pPedeOQVLqYPhKD3lzBQZjvfC8Cp gELH4aFumxrn5pb6eBox7dPtIBAoVycu4AN6A/TBoBDkrQrafo2nOLtgwigmlLTRJjiS Gkxvp3Xgs//aWi3sXrx/5UEYNV8n4m8eFFxtw= Date: Wed, 25 May 2011 16:42:15 -0400 (EDT) From: Parag Warudkar X-X-Sender: parag@ubuntu-natty To: Linus Torvalds cc: Parag Warudkar , Jens Axboe , "linux-kernel@vger.kernel.org" , "James.Bottomley@hansenpartnership.com" , "akpm@linux-foundation.org" , Linux SCSI List Subject: Re: [PATCH] SCSI IOCTL: Check for device deletion [was Re: __elv_add_request OOPS] In-Reply-To: Message-ID: References: <4DDB8BF6.2000304@fusionio.com> <4DDCB1C8.7040708@fusionio.com> <4DDD5240.2060308@fusionio.com> <4DDD55D6.1080909@fusionio.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1854863386-1306356137=:8972" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1315 Lines: 34 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1854863386-1306356137=:8972 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Wed, 25 May 2011, Linus Torvalds wrote: > On Wed, May 25, 2011 at 1:18 PM, Parag Warudkar wrote: > > ? ? ? ?SDEV_OFFLINE, ? ? ? ? ? /* Device offlined (by error handling or > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? * user request */ > > So how do you fix the error or online it again? No chance it should > have commands passed to it to do that? Yeah - that makes sense. By that logic, looks like we can only disallow for SDEV_DEL (if we decide to do that check here). > I don't know. My point is that I don't see why we should look at the > state at this point at all. We do that _later_. If we can do it later, well and good. I just didn't think it would hurt to check upfront in ioctl if we are dealing with a dead device. Parag --8323329-1854863386-1306356137=:8972-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/