Am Dienstag, 11. Dezember 2001 22:32 schrieb Alan Cox:
> > 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. Which architectures are hit ?
>
> If you are doing DMA off the stack your code will not work on anything but
> x86 and maybe alpha in some cases.
OK, that kills the idea.
> > 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.
>
> I disagree, a great deal in fact. Anywhere the object is on the stack you
> could kmalloc or better yet pci_alloc_* it. Yes its a bit slower and
> eventually you want to propogate sanity outwards but there isn't any excuse
> for dumping stuff on the stack instead of kmalloc/kfree
Then we need a gfp parameter in virtually all api functions and the
api for host controllers. (Or do a lot of GFP_ATOMIC/GFP_NOIO. I mention this only
for completeness' sake.)
How deadlockproof is nfs ? Must anything that might be used for nfs stuff
use GFP_NOFS ? I hope not, but I better ask.
Greg, Alan, what is to be done ?
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
