Re: contigmalloc(9) doesn't honour M_NOWAIT.

Peter Jeremy wrote:
> On Tue, 2006-May-09 16:03:12 +0200, Pawel Jakub Dawidek wrote:
> 
>>Using a USB pendrive can lead to kernel panic because of the issue
>>mentioned in the subject.
> 
> 
> See kern/78179.  Mark Tinguely and I have spent a far amount of time
> fighting it.  We have made some improvement - bus_dmamem_alloc()
> correctly supports BUS_DMA_NOWAIT so you get a runtime error instead
> of a panic.  At this stage, the umass device needs to be re-written so
> that it doesn't issue large contiguous mallocs at interrupt level.
> The way forward would seem to be to make the USB subsystem support
> scatter-gather (skeleton code already exists) to avoid the need for
> contigmalloc().

Yes, this is the correct solution.  Unfortunately, it looks to require a
significant amount of code for UHCI controllers.  But then, the whole 
point of UHCI is to have the OS do all the work anyways =-/

I need to look at your PR some, but I'm not sure that I want to
encourage bad practices with bus_dmamem_alloc and contigmalloc.  I
know that this doesn't help you solve the problem.  A possible
workaround might be to pre-allocate a pool of buffers and tell CAM
to limit the number of outstanding transactions to that number of
buffers.  You could also just set the max transfer size to PAGE_SIZE
and let the block layer split the i/o's up for you.  Page sized
allocations use malloc instead of contigmalloc (though there are
problems with this when dealing with restrictive dma tags, don't get
me started on how half-assed some of the busdma implementation still
is).  Pre-allocating a pool is what I would do.

> 
> Note that there are lots of other drivers that assume bus_dmamem_alloc()
> can't fail, even when called with BUS_DMA_NOWAIT.

The common case is for drivers to load either at boot or shortly after
boot, and thus contig memory should always be available.  The 
bus_dmamem_alloc API certainly was not meant to be used within normal 
I/O paths, just at driver initialization.  Not checking return values
is obviously an error, but in practice it's rarely a problem.


Scott