Re: kthread with kpause or callout

[Andrew Doran <ad%NetBSD.org@localhost>]

On Mon, Feb 08, 2010 at 03:04:07PM +0100, Frank Wille wrote:
> On Mon, 8 Feb 2010 11:29:51 +0100
> Martin Husemann <martin%duskware.de@localhost> wrote:
> 
> > On Mon, Feb 08, 2010 at 11:11:04AM +0100, Frank Wille wrote:
> > > - Running a kthread and calling kpause() between the polls.
> > > - Using a callout which reschedules itself after the poll.
> > 
> > The thread is quite a bit more heavyweight, but you have full freedom
> > to do what you want. The callout is pretty lightweight but you are
> > still subject of "interrupt context" rules.
> 
> Ok, thanks. Then the callout should be fine for me.
> 
> I'm just unsure about using mutexes during the callout. I have an
> IPL_NONE-kmutex which locks register access (my chip supports several
> register banks, so I need to make sure they are not switched). May I
> acquire this mutex during a callout (which is a softint, as I understand)?
> Will the softint sleep or busy-wait?

Yes, you can take an IPL_NONE (adaptive) mutex from a softint / callout.
Whether it sleeps or spins is a decision that the kernel makes at runtime.
It tries to spin. If that would deadlock the system, it sleeps.
This is the only time a callout/softint can sleep - for a mutex/rwlock.
You have to be careful with such mutexes.
For example, you have my_lock which is an IPL_NONE mutex.
You can grab this from a softint, no problem.
But you must NOT do something like this from thread context once that
lock is known to be taken from a softint.

        mutex_enter(&my_lock);
        blargh = kmem_alloc(1024, KM_SLEEP);
        mutex_exit(&my_lock);

.. as then you can cause the softint to wait on your memory allocation,
simply because it wants the lock that you hold.
This can deadlock the system in short order.
See the various manual pages for a bit more discussion.

FYI there is no difference between an IPL_NONE and IPL_SOFT* mutex.
In this case the name is only a sprinkling of sugar.