Re: Critical section

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Masao Uebayashi <uebayasi%gmail.com@localhost> wrote:
> 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)?

But this is not what "disable kernel preemption" for the "critical path"
means.  It literally just means "do not preempt this path" and nothing is
said about voluntary context switching or sleeping (i.e. an action taken
by the critical path itself).

> Catching coding error that entering mi_switch() while kernel
> preemption is disabled.  <...>

We are talking about the same thing.  As I wrote, instead of creating a
new interface, we can make kpreempt(9) more restrictive to mean "do not
preempt this path *and* crash if it context switches".  That would help
us catch the bugs, yes.

AFAIK, the only intended difference between kpreempt_ and KPREEMPT_ was
that the latter macro is provided for performance sensitive paths, but
we can change that.

-- 
Mindaugas