Re: Critical section

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

On Fri, Nov 28, 2014 at 8:47 AM, Mindaugas Rasiukevicius
<rmind%netbsd.org@localhost> wrote:
> Masao Uebayashi <uebayasi%gmail.com@localhost> wrote:
>> 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.
>
> Why create another interface which is almost the same as the existing one?

For mi_switch() to detect "I don't want to enter scheduler!" threads
entering scheduler.

> What problem are you trying to solve?  Catching the potential bugs when
> context switch may happen while the kernel preemption is enabled and the
> code path does not check for the CPU change?

Can't you see the difference between "I don't want to sleep"
("critical section") and "I'm about to sleep" (== entering scheduler)?

Catching coding error that entering mi_switch() while kernel
preemption is disabled.  This question arose while learning
pserialize(9); what happens when threads enter mi_switch() between
pserialize_read_{enter,exit}()?

Honestly I'm not sure the definition of "critical section".  This may
not be what it usually means.  (Should be corrected by
researcher-types, not me.)  The point is, there was/is big ambiguity
around KPREEMPT_*/kpreempt_* in the tree, half of which I've already
fixed yesterday.