On Tue, 18 Mar 2003, Oliver Neukum wrote: > Am Dienstag, 18. März 2003 16:12 schrieb Alan Stern: > > On Tue, 18 Mar 2003, Oliver Neukum wrote: > > > Hi, > > > > > > some part of the synchronous API is used in the block io error handling > > > code paths. Therefore it may use only GFP_NOIO, not GFP_KERNEL. > > > Greg, please apply. > > > > Oliver, is this meant to refer to the usb-storage module or to something > > else? For usb-storage it's true that the synchronous API is used in the > > Mainly usb-storage, but there's no reason a network driver used by nfs > might not suffer from a stall needing to be cleared.
I suppose that it might. But if the network driver isn't executing in a context where it can sleep then it shouldn't be using the synchronous API in the first place. In short, since the synchronous calls are allowed and expected to block, there's no reason for them not to use GFP_KERNEL. > > I/O error handling code paths. But those code paths always execute in the > > context of a kernel thread -- the SCSI error-handler thread -- with no > > semaphores held, so it's perfectly okay for them to use GFP_KERNEL. > > How can that be? The SCSI layer guarantees that no further requests are > issued while the error handler is running. Yes. The synchronous API calls you are concerned about are made from a subroutine that is called directly by the error handler and that runs in the context of the error handler thread. During the time this happens, the SCSI layer guarantees that no further requests are issued, either for block I/O or other error-handler stuff. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
