tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

A small improvement for LOCKDEBUG



We a set of adaptive mutexes and rwlocks in the kernel that are subject to
constraints that are not well documented. Some examples:

- can be acquired by the VM system, like proc::p_lock, bufcache_lock.
- can be acquired from soft interrupts.
- must not be held "long term" for other reasons.

So allocating memory or waiting long term with these locks held can cause
deadlock.

        p = curproc;
        mutex_enter(p->p_lock);
        /* this can recurse on p_lock or stall callout processing, etc */
        x = kmem_alloc(sizeof(*x), KM_SLEEP);
        mutex_exit(p->p_lock);

We don't have good runtime checks to catch this. An idea that occured to me
was to add a mutex type (and rwlock type) that says one must not sleep long
term with the lock held. The type would only be of interest to the LOCKDEBUG
code, which then watch out for ugly situations like the above.

Thoughts?


Home | Main Index | Thread Index | Old Index