Messages in this thread | | | Subject | RE: [PATCH 1/1] cciss: scsi error handling | Date | Fri, 11 Nov 2005 13:38:47 -0600 | From | "Cameron, Steve" <> |
| |
Jeff Garzik wrote:
> Two comments: > > 1) CONFIG_CISS_SCSI_TAPE should be CONFIG_CCISS_SCSI_TAPE, IMO > > 2) is any locking needed in your scsi eh reset handlers? recent > kernels eliminate the lock that's been traditionally held around > the handlers.
About the locking first,
So, there's one part that I was a little worried about, where it does this in a couple places:
c = (ctlr_info_t **) &scsicmd->device->host->hostdata[0];
(gets our adapter structure by following pointers in the scsi command)
So, if that pointer chain can change suddenly, then my code is bad.
Can doing "echo scsi remove-single-device . . . > /proc/scsi/scsi" cause that pointer chain to break? I noticed I can yank a disk out from under a mounted filesystem with "echo scsi remove-single-device" It wasn't obvious to me whether doing that would affect that pointer chain though, though I could imagine it might.
Or am I barking up the wrong tree worrying about the scsicmd->device->host->hostdata pointer chain getting yanked out from under me?
Apart from possibly the two places where I do that, I think it's ok.
About the CONFIG_CISS_SCSI_TAPE, we can change that, although it's been that way for years, and was following the BLK_CPQ_CISS_DA which was there since the drivers inception. Does it unnecessarily break people's existing .config files? (not badly of course.)
-- steve
-----Original Message----- From: Jeff Garzik [mailto:jgarzik@pobox.com] Sent: Fri 11/11/2005 5:36 AM To: Miller, Mike (OS Dev) Cc: axboe@suse.de; linux-kernel@vger.kernel.org; linux-scsi@vger.kernel.org; Cameron, Steve Subject: Re: [PATCH 1/1] cciss: scsi error handling mike.miller@hp.com wrote: > PATCH 1 of 1 > > This patch adds SCSI error handling code to the SCSI portion > of the cciss driver. > > Signed-off-by: Stephen M. Cameron <steve.cameron@hp.com> > Acked-by: Mike Miller <mike.miller@hp.com>
> +#ifdef CONFIG_CISS_SCSI_TAPE
Two comments:
1) CONFIG_CISS_SCSI_TAPE should be CONFIG_CCISS_SCSI_TAPE, IMO
2) is any locking needed in your scsi eh reset handlers? recent kernels eliminate the lock that's been traditionally held around the handlers.
Jeff
- 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/
| |