On Tue, Dec 11, 2001 at 10:16:32PM +0100, Oliver Neukum wrote: > Am Dienstag, 11. Dezember 2001 21:53 schrieb Tom Rini: > > On Tue, Dec 11, 2001 at 09:42:02PM +0100, Oliver Neukum wrote: > > > > IMHO, since the only safe thing to do across all architectures is to > > > > kmalloc the devrequest structure, anything other than that is > > > > essentially micro optimization that's not worth it. > > > > > > On the other hand it makes using that function in the block IO path safe. > > > Thus, if there's really no risk in terms of dma in 2.4, I'd consider it > > > for 2.4. > > > > Er, but don't forget that people will be using 2.4 and adding in their > > non-pci and whatnot USB controllers to 2.4 for a while yet. So perhaps > > we shouldn't do anything to 2.4 and backport what 2.5 has when it's > > stable. > > 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. > Which architectures are hit ? I'm not sure. > 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? -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
