[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Critical section
On Fri, Nov 28, 2014 at 8:47 AM, Mindaugas Rasiukevicius
> 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
> 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
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
Main Index |
Thread Index |