:Hmm. In net/bridge/if_bridge.c, kmalloc is called with just M_RNOWAIT,
:then it checks whether bif is NULL. This seems a bit bogus, because then
:it should rather use M_RNOWAIT|M_NULLOK. Even then, I don't see any
:problem in the code blocking here, why doesn't it use M_WAITOK instead?
:
:Also, in kmem_slab_alloc, if I read things right, none of
:VM_ALLOC_NORMAL, VM_ALLOC_INTERRUPT and VM_ALLOC_SYSTEM are set, thereby
:triggering the KKASSERT in vm_page_alloc? Could you try just adjusting
:the kmalloc flags in if_bridge.c:bridge_ioctl_add() from
:M_RNOWAIT|M_ZERO to M_NOWAIT|M_ZERO?
:
:Cheers,
:--
: Thomas E. Spanjaard
: [EMAIL PROTECTED]
Good catch, Thomas. Those allocation calls are seriously broken.
No code is supposed to use M_RNOWAIT ... it is supposed to be an internal
flag used only by the other #define M_* macros. Without M_NULLOK the
kmalloc() will panic. Without any M_USE_* flags any RNOWAIT will
cause the underlying VM system to be called without the correct VM
allocation flags, and crash precisely due to the reason you cited.
I also agree that M_*NOWAIT should not be used at al lthere. This is
probably a left-over from FreeBSD, which used M_NOWAIT freely in
initialization code with the expectation that the malloc would only
ever fail due to a lack of resources. In DragonFly, M_NOWAIT really
does mean no-waiting... any blocking condition will cause it to fail.
All of those calls should probably be M_WAITOK. Please go ahead and
make that commit now.
-Matt
