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

From: Scott Long <scottl_at_samsco.org>
Date: Tue, 09 May 2006 13:43:28 -0600
Scott Long wrote:
> 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.
> 

One thing I forgot to mention about this is that I still firmly believe
that the umass SIM should be a per-USB bus entity, not a per-USB device
entity.  I.e. when you load umass.ko, it should create a SIM for every
USB bus.  Then when umass devices are plugged in, they should just
attach as periph devices on the appropriate SIM.  The current practice
of treating a umass device as a per-instance SIM definitely complicates
memory handling like this.

Scott
Received on Tue May 09 2006 - 17:43:41 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:55 UTC