LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Davide Libenzi <davidel@xmailserver.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Arjan van de Ven <arjan@infradead.org>,
	Christoph Hellwig <hch@infradead.org>,
	Andrew Morton <akpm@zip.com.au>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Ulrich Drepper <drepper@redhat.com>,
	Zach Brown <zach.brown@oracle.com>,
	Evgeniy Polyakov <johnpol@2ka.mipt.ru>,
	"David S. Miller" <davem@davemloft.net>,
	Suparna Bhattacharya <suparna@in.ibm.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [patch 09/14] syslets: x86, add move_user_context() method
Date: Thu, 15 Feb 2007 19:15:24 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0702151904570.11064@alien.or.mcafeemobile.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0702151058040.11064@alien.or.mcafeemobile.com>

On Thu, 15 Feb 2007, Davide Libenzi wrote:

> On Thu, 15 Feb 2007, Ingo Molnar wrote:
> 
> >  /*
> > + * Move user-space context from one kernel thread to another.
> > + * This includes registers and FPU state. Callers must make
> > + * sure that neither task is running user context at the moment:
> > + */
> > +void
> > +move_user_context(struct task_struct *new_task, struct task_struct *old_task)
> > +{
> > +	struct pt_regs *old_regs = task_pt_regs(old_task);
> > +	struct pt_regs *new_regs = task_pt_regs(new_task);
> > +	union i387_union *tmp;
> > +
> > +	*new_regs = *old_regs;
> > +	/*
> > +	 * Flip around the FPU state too:
> > +	 */
> > +	tmp = new_task->thread.i387;
> > +	new_task->thread.i387 = old_task->thread.i387;
> > +	old_task->thread.i387 = tmp;
> > +}
> 
> Let's say that old_task ("prev" at the incoming schedule) has TS_USEDFPU 
> set. Its context gets moved to the new_task (the one returning to 
> userspace) *before* the __unlazy_fpu() done in __switch_to(). The 
> __unlazy_fpu() at the following schedule will save the state to the old 
> new_task context, and that fine as far as the going-to-sleep task goes.
> The next fault happening in new_task (return to userspace one) will reload 
> a non up2date context (the one we got from old_task, but never hit by 
> the __unlazy_fpu() flush). Right?

Yeah. Given TS_USEDFPU set, before move_user_context():

CPU  => FPUc
NTSK => FPUn
OTSK => FPUo

After move_user_context():

CPU  => FPUc
NTSK => FPUo
OTSK => FPUn

After the incoming __unlazy_fpu() in __switch_to():

CPU  => FPUc
NTSK => FPUo
OTSK => FPUc

After the first fault in NTSK:

CPU  => FPUo
NTSK => FPUo
OTSK => FPUc

So NTSK loads a non up2date FPUo, instead of the FPUc that was the "dirty" 
context to migrate (since TS_USEDFPU was set).
I think you need an early __unlazy_fpu() in that case.




- Davide



      reply	other threads:[~2007-02-16  3:15 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-15 16:52 Ingo Molnar
2007-02-15 19:07 ` Davide Libenzi
2007-02-16  3:15   ` Davide Libenzi [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=Pine.LNX.4.64.0702151904570.11064@alien.or.mcafeemobile.com \
    --to=davidel@xmailserver.org \
    --cc=akpm@zip.com.au \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arjan@infradead.org \
    --cc=davem@davemloft.net \
    --cc=drepper@redhat.com \
    --cc=hch@infradead.org \
    --cc=johnpol@2ka.mipt.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=suparna@in.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=zach.brown@oracle.com \
    --subject='Re: [patch 09/14] syslets: x86, add move_user_context() method' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).