From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Bottomley Subject: Re: [BUG] 2.6.39.1 crash in scsi_dispatch_cmd() Date: Fri, 08 Jul 2011 15:41:31 -0500 Message-ID: <1310157693.3282.101.camel@mulgrave> References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: Received: from bedivere.hansenpartnership.com ([66.63.167.143]:50171 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750828Ab1GHUlj (ORCPT ); Fri, 8 Jul 2011 16:41:39 -0400 In-Reply-To: Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: Alan Stern Cc: Roland Dreier , Heiko Carstens , Jens Axboe , linux-scsi@vger.kernel.org, Steffen Maier , "Manvanthara B. Puttashankar" , Tarak Reddy , "Seshagiri N. Ippili" On Fri, 2011-07-08 at 15:43 -0400, Alan Stern wrote: > On Fri, 8 Jul 2011, James Bottomley wrote: > > > However, that does beg the question of why sr is using the device after > > sr_remove() has completed. That seems to be because of the block ops > > being the dominant structure, so we try to do cleanup when we get the > > block release rather than the driver release ... that looks to be the > > root cause to me. > > Hmmm. What happens if I use sysfs to unbind the scsi_device from sr > while it is still mounted, and then quickly rebind it again? Until the > filesystem is unmounted and the block release is complete, would both > instances end up sending commands to the device concurrently? The device will go into CANCEL or DEL and resurrection is impossible ... it should give an error when you attempt the rebind. James