Re: ATA identify retries exceeded - kernel panic

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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.
:
:Cheers,
:-- 
:         Thomas E. Spanjaard
:         tgen@xxxxxxxxxxxxx

    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).
   
					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>