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>,
linux-kernel@vger.kernel.org
Subject: Re: [x86] do_arch_prctl
Date: Thu, 20 Nov 2008 01:22:07 +0100 [thread overview]
Message-ID: <200811200122.07694.goretux@gmail.com> (raw)
In-Reply-To: <4924AA4E.4090001@goop.org>
Le jeudi 20 novembre 2008 01:07:42 Jeremy Fitzhardinge, vous avez écrit :
> Eric Lacombe wrote:
> > Thanks for your answer, I've got one last question ;)
> > In the ARCH_GET_GS, can you explain the line 834 to 838?
> >
> > In fact, at first sight I thought that just the line 836 was sufficient,
> > but I obviously miss the case where MSR_KERNEL_GS_BASE does not reflect
> > the value requested, hence my question.
>
> I think the rationale is that rdmsr is slow, so reading the value from
> the task context is faster where possible.
But in this case why not doing instead:
828 case ARCH_GET_GS: {
829 unsigned long base;
830 unsigned gsindex;
831 if (task->thread.gsindex == GS_TLS_SEL)
832 base = read_32bit_tls(task, GS_TLS);
840 else
841 base = task->thread.gs;
> > 828 case ARCH_GET_GS: {
> > 829 unsigned long base;
> > 830 unsigned gsindex;
> > 831 if (task->thread.gsindex == GS_TLS_SEL)
> > 832 base = read_32bit_tls(task, GS_TLS);
> > 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 }
> > 840 else
> > 841 base = task->thread.gs;
and as I see with ARCH_GET_FS we have :
817 case ARCH_GET_FS: {
818 unsigned long base;
819 if (task->thread.fsindex == FS_TLS_SEL)
820 base = read_32bit_tls(task, FS_TLS);
821 else if (doit)
822 rdmsrl(MSR_FS_BASE, base);
823 else
824 base = task->thread.fs;
825 ret = put_user(base, (unsigned long __user *)addr);
826 break;
827 }
So it seems that the "rdmsrl(MSR_FS_BASE, base);" could be faster than an
access to the memory, else why bother with the "doit" case?
Regards,
Eric
next prev parent reply other threads:[~2008-11-20 0:22 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 [this message]
2008-11-24 12:24 ` Eric Lacombe
2008-11-24 18:22 ` Jeremy Fitzhardinge
2008-11-24 19:28 ` Eric Lacombe
-- 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=200811200122.07694.goretux@gmail.com \
--to=goretux@gmail.com \
--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.