> -----Original Message----- > From: linux-scsi-owner@xxxxxxxxxxxxxxx > [mailto:linux-scsi-owner@xxxxxxxxxxxxxxx]On Behalf Of Douglas Gilbert > Sent: Tuesday, October 18, 2005 12:55 AM > To: Dailey, Nate > Cc: linux-scsi@xxxxxxxxxxxxxxx > Subject: Re: requesting advice: oops when doing sg_dd IO and device is > removed > > > Nate, > I always suspected that if one really tried hard enough > then unexpectedly closing a file descriptor (e.g. via > control-C on an app) at the same time as there are > outstanding commands could cause problems. Obviously > you have succeeded demonstrating that with your experiment. > > When I fought with this problem in the lk 2.4 series, > someone skilled at finding flaws in locking logic > suggested there was no solution (at least the way > I was doing it) ... > > Waiting a close() call (i.e. sg_release() ), potentially > indefinitely, was very unpopular with application clients. > The sg driver did that in the old days, and I was abused > from several quarters (one name springs to mind). So I > tried to design sg_release() so it wouldn't ever hang > the application client. > > On reflection, I think to allow sg_release() to go > through quickly, another kernel thread is needed that > is passed ownership of unfinished commands. What do > you think? > > > Doug Gilbert Doug, Here are some relevant links regarding related problems in the 2.4 kernels. I am still using 2.4, so I don't know if 2.6 has this problem or not. http://bugme.osdl.org/show_bug.cgi?id=3685 http://marc.theaimsgroup.com/?t=108005442700006&r=1&w=2 Anthony J. Battersby Cybernetics - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
