DragonFly bugs List (threaded) for 2006-11
Re: ATA identify retries exceeded - kernel panic
:Fwiw, I haven't seen such yet with the new ATA code, except in the case
:when I forgot to zero the structs I pulled out of my objcache. It might
:be nice to have objcache_get() look at oc_flags and zero if & M_ZERO.
:In any case, I got that panic because I didn't have a zeroed struct, so
:a certain variable was set where it shouldn't have been, resulting in
:other code kfree()-ing another struct, thereby making a pointer in that
:struct point to 0xdeadc0de (the slab alloc does this). If that's the
:case, we need to look for inadvertent frees.
: Thomas E. Spanjaard
I agree that we should make M_ZERO semantics work more as expected...
or at least panic() if they aren't allowed.
Here's the issue... The objcache has two layers... it has a freelist
caching layer and it has an actual allocation and disposal layer.
The idea behind the freelist caching layer is to be able to hold the
structures in a form that reduces the amount of initialization required.
This is primarily used by the mbuf system, where certain associations
(such as mbufs with mbuf cluster buffers) are retained in the freelist
caching layer and only disentangled in the allocation and dispoal layer.
So we can't just unconditionally bzero() in objcache_get() if M_ZERO is
set because it would destroy these associations. I think what we need
to do is give the objcache some indication that M_ZERO is allowed, then
either bzero() or panic.
Since bzero is a procedure call, perhaps the solution here is to add
another function pointer for 'zeroing' a structure when M_ZERO is
specified. This function would be specified in objcache_create() and
default to a bzero if NULL. This way M_ZERO will work as expected with
simple objcache setups, and panic the system if someone tries to use
it with more complex objcache setups (like mbufs).