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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox