Masao Uebayashi <[email protected]> wrote: > On Fri, Nov 28, 2014 at 8:47 AM, Mindaugas Rasiukevicius > <[email protected]> wrote: > > Masao Uebayashi <[email protected]> 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
