On Tue, Dec 11, 2001, Oliver Neukum <[EMAIL PROTECTED]> wrote: > > > It's very likely that the type of the controller is not deciding the > > > issue. The question is rather how the architectures allocate the kernel > > > stack. > > > > Yes. My point is that we don't want to do this right now since it's a > > micro optimization and it'll break all of those changes for these > > 'wierd' arches/setups that aren't in the tree now. > > It is not just an optimisation. The way memory is allocated in this function > means that we can deadlock if the function is called with a spinlock held.
GFP_ATOMIC The HC drivers have the same problem. If there's no memory, there's no memory. You have to handle it, but it's rare. > > > Completely fixing this bug requires a change to a lot of api functions. > > > Have a look at, eg. kaweth.c/kaweth_start_xmit(). It can deadlock on > > > smp. > > > There are a lot of drivers doing dma on the stack. I know it's bad, > > > but sometimes a compromise must be reached. > > > > Right. And that's 2.5 fodder that can be backported, yes? > > Only at the cost of breaking all external drivers. I don't think the situation will change for 2.4, but Greg has that call. For 2.5, I still don't think it's worth it. JE _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
