contigmalloc(9) doesn't honour M_NOWAIT.
Scott Long
scottl at samsco.org
Tue May 9 19:36:36 UTC 2006
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
More information about the freebsd-current
mailing list