Re: Critical section

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

On Fri, Nov 28, 2014 at 12:20 AM, Taylor R Campbell
<campbell+netbsd-tech-kern%mumble.net@localhost> wrote:
>    Date: Wed, 26 Nov 2014 16:41:01 +0900
>    From: Masao Uebayashi <uebayasi%gmail.com@localhost>
>
>    The problem of kpreempt_*() API is that its meaning is overriden by
>    kernel internal (scheduler, sync primitives, ...).  This change
>    separates the internal use (scheduler disables preeemption) and
>    others (kernel subsystem code executes critical section).  Detect
>    sleep from within critical section in mi_switch().
>
>    The only problem I've seen is, cprng_fast.c calling percpu_getref() in
>    KASSERT(); it's kind of re-entrance.
>
> Generally sounds reasonable to me.  I'm not happy about prohibiting
> nesting, though, and I don't think `critical section' is the right
> word for it, though -- it's too broad.
>
> Are there any uses of kpreempt_disable/kpreempt_enable outside the
> scheduler that intentionally allow voluntary switching?  Are there any
> uses of KPREEMPT_DISABLE/KPREEMPT_ENABLE inside the scheduler that
> require nesting?

It turned out that prohibiting nesting was too strict, and just plain
wrong.  CPU can enter critical section C1, interrupted, and enter C2,
etc.  The cprng_fast.c assertion is OK.  Sorry for confusion.

> If the answer to both is `no', perhaps we could make KPREEMPT_DISABLE
> set a bit, and make kpreempt_disable increment a counter, and make
> mi_switch kassert that the bit is set and the counter is zero.

Both KPREEMPT_* and kpreempt_* increment/decrement different counters.
KPREEMPT_DISABLE can re-enter KPREEMPT_DISABLE, but can't enter
kpreempt_disable, and vice versa.

Now the tree is consistent (but no assertions to check the above rule yet).