All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philippe Gerum <rpm@xenomai.org>
To: Jan Kiszka <jan.kiszka@domain.hid>
Cc: adeos-main <adeos-main@gna.org>
Subject: Re: [Adeos-main] [pull request] x86: Fix up regs unconditionally on exceptions
Date: Sun, 11 Apr 2010 19:38:51 +0200	[thread overview]
Message-ID: <1271007531.2365.1.camel@domain.hid> (raw)
In-Reply-To: <4BC1FAC9.5040904@domain.hid>

On Sun, 2010-04-11 at 18:37 +0200, Jan Kiszka wrote:
> Jan Kiszka wrote:
> > The following changes since commit 14023bef1806dd640030d3eaf73c26736345bc30:
> >   Philippe Gerum (1):
> >         ipipe-2.6.32.7-x86-2.6-01
> > 
> > are available in the git repository at:
> > 
> >   git://git.kiszka.org/ipipe-2.6 queues/2.6.32-x86
> > 
> > Found while making KVM work over I-pipe/Xenomai. Its hardware
> > activation code triggered a planned #GP in IRQ context.
> > 
> > 
> > Jan Kiszka (1):
> >       x86: Fix up regs unconditionally on exceptions
> > 
> >  arch/x86/kernel/ipipe.c |   24 +++++++++++++-----------
> >  1 files changed, 13 insertions(+), 11 deletions(-)
> > 
> > ------
> > 
> > x86: Fix up regs unconditionally on exceptions
> > 
> > Some Linux exception handlers - at least do_general_protection -
> > evaluate regs->flags, and that on both x86-32 and -64. So we should fix
> > up the flags according to the pipeline state unconditionally.
> 
> Forgotten or intentionally skipped for 2.6-02?

Intentionally left aside for now. This is a touchy code, and I want to
make sure to properly assess the implications of such change before
merging.

> 
> Hmm, I see that even the fixed-up comment in __ipipe_handle_exception is
> not correct anymore. I can push an updated version if you're fine with
> picking this up.
> 
> Jan
> 
> > 
> > Signed-off-by: Jan Kiszka <jan.kiszka@domain.hid>
> > ---
> >  arch/x86/kernel/ipipe.c |   24 +++++++++++++-----------
> >  1 files changed, 13 insertions(+), 11 deletions(-)
> > 
> > diff --git a/arch/x86/kernel/ipipe.c b/arch/x86/kernel/ipipe.c
> > index 36cd591..dfb76ad 100644
> > --- a/arch/x86/kernel/ipipe.c
> > +++ b/arch/x86/kernel/ipipe.c
> > @@ -495,8 +495,6 @@ out:
> >  	local_irq_restore_hw(flags);
> >  }
> >  
> > -#ifdef CONFIG_X86_32
> > -
> >  static inline void __fixup_if(int s, struct pt_regs *regs)
> >  {
> >  	/*
> > @@ -510,6 +508,8 @@ static inline void __fixup_if(int s, struct pt_regs *regs)
> >  		regs->flags |= X86_EFLAGS_IF;
> >  }
> >  
> > +#ifdef CONFIG_X86_32
> > +
> >  /*
> >   * Check the stall bit of the root domain to make sure the existing
> >   * preemption opportunity upon in-kernel resumption could be
> > @@ -571,10 +571,6 @@ asmlinkage void __ipipe_unstall_iret_root(struct pt_regs regs)
> >  
> >  #else /* !CONFIG_X86_32 */
> >  
> > -static inline void __fixup_if(int s, struct pt_regs *regs)
> > -{
> > -}
> > -
> >  #ifdef CONFIG_PREEMPT
> >  
> >  asmlinkage void preempt_schedule_irq(void);
> > @@ -746,11 +742,11 @@ int __ipipe_handle_exception(struct pt_regs *regs, long error_code, int vector)
> >  
> >  	if (likely(ipipe_root_domain_p)) {
> >  		/*
> > -		 * 32-bit: In case we faulted in the iret path, regs.flags do
> > -		 * not match the root domain state as the low-level return
> > -		 * code will evaluate it. Fix this up, either by the root
> > -		 * state sampled on entry or, if we migrated to root, with the
> > -		 * current state.
> > +		 * In case we faulted in the iret path, regs.flags do not
> > +		 * match the root domain state. The fault handler or the
> > +		 * low-level return code may evaluate it. Fix this up, either
> > +		 * by the root state sampled on entry or, if we migrated to
> > +		 * root, with the current state.
> >  		 */
> >  		__fixup_if(root_entry ? raw_irqs_disabled_flags(flags) :
> >  					raw_irqs_disabled(), regs);
> > @@ -876,7 +872,13 @@ int __ipipe_syscall_root(struct pt_regs *regs)
> >  
> >  	local_irq_save_hw(flags);
> >  	p = ipipe_root_cpudom_ptr();
> > +#ifdef CONFIG_X86_32
> > +	/*
> > +	 * Fix-up only required on 32-bit as only here the IRET return code
> > +	 * will evaluate the flags.
> > +	 */
> >  	__fixup_if(test_bit(IPIPE_STALL_FLAG, &p->status), regs);
> > +#endif
> >  	/*
> >  	 * If allowed, sync pending VIRQs before _TIF_NEED_RESCHED is
> >  	 * tested.
> 
> 


-- 
Philippe.




      reply	other threads:[~2010-04-11 17:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-12  9:40 [Adeos-main] [pull request] x86: Fix up regs unconditionally on exceptions Jan Kiszka
2010-04-11 16:37 ` Jan Kiszka
2010-04-11 17:38   ` Philippe Gerum [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1271007531.2365.1.camel@domain.hid \
    --to=rpm@xenomai.org \
    --cc=adeos-main@gna.org \
    --cc=jan.kiszka@domain.hid \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.