Re: [linux-usb-devel] [PATCH]fix to synchronous API regardingmemoryallocation
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
Re: [linux-usb-devel] [PATCH]fix to synchronous API regardingmemoryallocation
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. But what happens if the vm subsystem waits for this IO to complete as is entirely legal with GFP_KERNEL allocations ? Regards Oliver --- 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
Re: [linux-usb-devel] [PATCH]fix to synchronous API regardingmemoryallocation
On Tue, 18 Mar 2003, Oliver Neukum wrote: 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. But what happens if the vm subsystem waits for this IO to complete as is entirely legal with GFP_KERNEL allocations ? You mean, what if the VM subsystem is blocked because it can't fulfill the error-handler's GFP_KERNEL allocation request until the I/O is completed and the I/O can't complete until the error-handler fixes things up? I don't know. How do other subsystems handle this? 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
Re: [linux-usb-devel] [PATCH]fix to synchronous API regardingmemoryallocation
On Tue, 18 Mar 2003, Alan Stern wrote: On Tue, 18 Mar 2003, Oliver Neukum wrote: 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. But what happens if the vm subsystem waits for this IO to complete as is entirely legal with GFP_KERNEL allocations ? You mean, what if the VM subsystem is blocked because it can't fulfill the error-handler's GFP_KERNEL allocation request until the I/O is completed and the I/O can't complete until the error-handler fixes things up? I don't know. How do other subsystems handle this? I just went back and re-read the kerneldoc explanation for the memory flags in usb_submit_urb(). You are correct. I withdraw my objection to the patch. 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
