Re: [x86] do_arch_prctl

From: Eric Lacombe
Date: Sun Dec 07 2008 - 18:02:41 EST


I'm sorry to insist, but I really want to understand what occurs in this
portion of kernel code. And that's why I resend my previous message with the
hope that someone could enlighten my mind.

Thanks in advance,


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 and thread.fs?
What could be a typical scenario that could induced gs or fs to be modified and
not 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->;
> 839 }


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

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



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at