Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754891AbYCKSHp (ORCPT ); Tue, 11 Mar 2008 14:07:45 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753580AbYCKSHR (ORCPT ); Tue, 11 Mar 2008 14:07:17 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:53767 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1753462AbYCKSHQ (ORCPT ); Tue, 11 Mar 2008 14:07:16 -0400 Date: Tue, 11 Mar 2008 14:07:15 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Boaz Harrosh cc: James Bottomley , Matthew Dharm , Sven Schnelle , , linux-scsi , FUJITA Tomonori , Andrew Morton Subject: Re: [PATCH] [SCSI] gdth: Allocate sense_buffer to prevent NULL pointer dereference In-Reply-To: <47D6B050.7070803@panasas.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1951 Lines: 42 On Tue, 11 Mar 2008, Boaz Harrosh wrote: > I would like to fix this better by calling scsi_get/put_command but there is > something fundamental that bothers me with isd200 driver. I can see that > an isd200_info struct is allocated and put on a struct us_data->extra. But > as I understand the code, the struct us_data is associated with a scsi_host > not a scsi_device. Are we guarantied that we have only one scsi_device > per host at all times? > > If not than the resources in isd200_info that are related to a request_queue > and are used from a .queuecommand code-path are not thread safe. (Like the > srb member) > > If Yes, then where in the code initialization sequence is the earliest place I > can get to a scsi_device. I could do that on first call to .queuecommand but > I would rather do it in a place that I could use GFP_KERNEL for allocation > of the extra command? (Same question on the tear down of the scsi_device) You can first get to the scsi_device in isd200_ata_command(). The last place you can get to the scsi_device (if one exists!) is quiesce_and_remove_host() -- but that's part of the core, not specific to isd200. > (And one more stupid question. Why does isd200_init_info allocates the info > structure but the isd200_free_info_ptrs does not free it, it kind of > limits the way it can be allocated, no?) Not at all. isd200_free_info_ptrs() frees everything pointed to by the info structure, and the info structure itself is freed later on by the usb-storage core in usb_stor_release_resources(). If you wanted to free it in isd200_free_info_ptrs() you could; just make sure to set us->extra to NULL when you do, to avoid a double-free error. Alan Stern -- 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/