[discuss] Re: preempt_conditional_{sti,cli} use

John Blackwood john.blackwood at ccur.com
Tue May 9 15:54:58 CEST 2006

 > Subject: Re: [discuss] Re: preempt_conditional_{sti,cli} use
 > From: Andi Kleen <ak at suse.de>
 > Date: Tue, 9 May 2006 15:16:04 +0200
 > To: discuss at x86-64.org
 > CC: "Jan Beulich" <jbeulich at novell.com>, john.blackwood at ccur.com
 > On Tuesday 09 May 2006 14:45, Jan Beulich wrote:
 > >> One question though - would you then want to use this unconditionally
 > >> in do_trap(), or would you want this to be done only when in fact
 > >> running on an IST stack? Jan
 > Only on an IST stack to keep interrupt off times short.
 > Also I'm pondering if a preempt disable alone isn't enough. cli is 
 > not even needed.
 > -Andi

Hi Andi and Jan,

Sorry that I only patched the do_debug() case... it was the only
case that we giving us grief, so I didn't want to risk breaking
some other case.

As far as the 'cli' goes, here's my non-expert opinion...

One thing that I did notice when looking into the do_debug() case was
that when we take an interrupt and come out of processing that interrupt
in the 'retint_kernel' code in entry.S, we would sometimes end up calling
preempt_schedule_irq() -- when the current task did not have preemptions
disabled, of course.

My point is that I think that you still have to be careful when exiting
a trap routine with interrupts enabled and you have re-enabled preemptions.
I THINK that you need to disable interrupts, before reenable-ing
premptions before returning back to the entry.S code.

Or... maybe you could leave preemptions disabled and drop back into
the entry.S code and then reenable preemptions once the interrupts are
disabled in entry.S.

Otherwise, there would still be a small window where an interrupt could
come in and decide when exiting that interrupt that we want to preempt
the current task in 'retint_kernel', since it is no longer preempt

Please excuse me if I'm "out to lunch" on this.

More information about the discuss mailing list