problems with new the "contigmalloc" routine

[Scott Long]

Brian Fundakowski Feldman wrote:

> On Fri, May 20, 2005 at 01:40:35PM +0200, Hans Petter Selasky wrote:
> 
>>Hi,
>>
>>I just hit some problems with the new "contigmalloc()" routine in 
>>FreeBSD-6-current, which is used by "bus_dmamem_alloc()".
>>
>>Firstly it locks Giant, which cause locking order reversals when allocating 
>>memory from certain contexts. Secondly it sleeps even if flag M_NOWAIT is 
>>passed. Thirdly it does not support flag M_ZERO.
> 
> 
> Read the documentation.  It supports M_ZERO just fine, and it does _not_
> support M_NOWAIT.
> 
> 
>>Can someone explain why these changes have been made?
> 
> 
> Changes?
> 
> 
>>Why doesn't "contigmalloc()" give a warning when an invalid flag is passed?
> 
> 
> The kernel would be significantly larger and almost certainly slower
> if it were to double-check that everywhere any bit fields are used
> that flags that are not defined to have any behavior are unset.
> 
> 
>>Are these bugs in "contigmalloc()"? 
> 
> 
> No.
> 
> 
>>Or does the code using "contigmalloc()" have to be changed?
> 
> 
> Yes.  The i386 bus_dmamem_alloc(), for example, calls it with M_NOWAIT
> which is not a valid flag.  The contigmalloc(9) page is not entirely
> truthful about the fact that it doesn't sleep at all -- it calls those
> routines which can.  They can both be documented to require no locks
> to be held when being called, except for M_NOWAIT specifically in the
> one-page-or-less allocation case.
> 

The amount of colateral damage that has been inflicted on 
bus_dmamem_alloc by your changes to contigmalloc is truly impressive.
Since I've spent the better part of 8 months cleaning it up, please
let me know what else needs to be done so that there are no more 
surprises.  And no, this is not my happy face.

Scott