Re: [patch] sched: unlocked context-switches

[Nick Piggin <nickpiggin@yahoo.com.au>]

On Mon, 2005-04-11 at 18:06 -0700, David Mosberger wrote:

> I had to refresh my memory with a quick Google search that netted [1]
> (look for "Disable interrupts during context switch").  Actually, it
> wasn't really a deadlock, but rather a livelock, since a CPU got stuck
> on an infinite page-not-present loop.
> 
> Fundamentally, the issue was that doing the switch_mm() and
> switch_to() with interrupts enabled opened a window during which you
> could get a call to flush_tlb_mm() (as a result of an IPI).  This, in
> turn, could end up activating the wrong MMU-context, since the action
> of flush_tlb_mm() depends on the value of current->active_mm.  The
> problematic sequence was:
> 
> 1) schedule() calls switch_mm() which calls activate_context() to
>    switch to the new address-space
> 2) IPI comes in and flush_tlb_mm(mm) gets called
> 3) "current" still points to old task and if "current->active_mm == mm",
>    activate_mm() is called for the old address-space, resetting the
>    address-space back to that of the old task
> 
> Now, Ingo says that the order is reversed with his patch, i.e.,
> switch_mm() happens after switch_to().  That means flush_tlb_mm() may
> now see a current->active_mm which hasn't really been activated yet.

If that did bother you, could you keep track of the actually
activated mm in your arch code? Or would that involve more arch
hooks and general ugliness in the scheduler?

Could you alternatively just disable interrupts across the switch?
I guess that would require a bit of #ifdefery in sched.c, which we
are trying to move away from, but it would be pretty minimal. Much
better than what is there now.

> That should be OK since it would just mean that we'd do an early (and
> duplicate) activate_context().  While it does not give me a warm and
> fuzzy feeling to have this inconsistent state be observable by
> interrupt-handlers (and, in particular, IPI-handlers), I don't see any
> problem with it off hand.
> 

IMO it *is* the direction we should move towards. That is,
liberating context switching from scheduler locking, and providing
a single set of semantics for the context switch hooks for all
architectures.

No rush, of course. But it would be good to get it in sooner
or later.

Nick


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/