[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Critical section
On Fri, Nov 28, 2014 at 12:20 AM, Taylor R Campbell
> 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).
Main Index |
Thread Index |