All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Lacombe <goretux@gmail.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Arjan van de Ven <arjan@infradead.org>,
	Ingo Molnar <mingo@elte.hu>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
	linux-kernel@vger.kernel.org
Subject: Re: [x86] do_arch_prctl
Date: Mon, 24 Nov 2008 20:28:40 +0100	[thread overview]
Message-ID: <200811242028.40865.goretux@gmail.com> (raw)
In-Reply-To: <492AF0DA.3060702@goop.org>

Le lundi 24 novembre 2008 19:22:18 Jeremy Fitzhardinge, vous avez écrit :
> Eric Lacombe wrote:
> > Hello,
> >
> > Does the "doit case" (line 822 in ARCH_GET_FS, function do_arch_prctl)
> > exist for performance reasons? Else, why "task->thread.fs" (line 824)
> > does not contain the fs base in the "doit case"?
>
> "doit" gets set when you're operating on yourself.  If you're operating
> on another process, then you need to use their task structure values
> rather than the current process's values.  If you're doing it to
> yourself, then the task structure may be out of date because its only
> updated on a context switch.

The task_struct is also updated in sys_arch_prctl (ARCH_SET_FS and 
ARCH_SET_GS), so not just on a context switch.
How the task structure could be out of date wrt thread.gs and thread.fs?
What could be a typical scenario that could induced gs or fs to be modified and 
not thread.gs and thread.fs?

Why we have a difference between ARCH_GET_GS :

> 833                 else if (doit) {
> 834                         asm("movl %%gs,%0" : "=r" (gsindex));
> 835                         if (gsindex)
> 836                                 rdmsrl(MSR_KERNEL_GS_BASE, base);
> 837                         else
> 838                                 base = task->thread.gs;
> 839                 }

and ARCH_GET_FS :

> 821                 else if (doit)
> 822                         rdmsrl(MSR_FS_BASE, base);

If I follow what you say, why can't we have the same optimization with in 
ARCH_GET_FS?

thanks,

	Eric



  reply	other threads:[~2008-11-24 19:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-18 17:35 [x86] do_arch_prctl - bug? Eric Lacombe
2008-11-18 23:44 ` Eric Lacombe
2008-11-19  1:07   ` Jeremy Fitzhardinge
2008-11-19  9:23     ` Eric Lacombe
2008-11-19 21:06       ` Jeremy Fitzhardinge
2008-11-19 23:35         ` [x86] do_arch_prctl Eric Lacombe
2008-11-20  0:07           ` Jeremy Fitzhardinge
2008-11-20  0:22             ` Eric Lacombe
2008-11-24 12:24               ` Eric Lacombe
2008-11-24 18:22                 ` Jeremy Fitzhardinge
2008-11-24 19:28                   ` Eric Lacombe [this message]
  -- strict thread matches above, loose matches on Subject: below --
2008-12-07 23:02 Eric Lacombe
2008-12-08 19:10 ` Jeremy Fitzhardinge
2008-12-08 20:35   ` Andi Kleen

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=200811242028.40865.goretux@gmail.com \
    --to=goretux@gmail.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arjan@infradead.org \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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.