Messages in this thread | | | Date | Mon, 08 Dec 2008 11:10:15 -0800 | From | Jeremy Fitzhardinge <> | Subject | Re: [x86] do_arch_prctl |
| |
Eric Lacombe wrote: > 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. >
Well, its quite possible there are no good answers beyond "it needs a cleanup". > Thanks in advance, > > Eric > > 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? >
Not sure. It could just be redundant.
> 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 in > ARCH_GET_FS? >
I haven't looked into it very closely, but its possible the asymmetry comes from the fact that there's no swapfs, and so the kernel and userspace aren't sharing %fs.
J -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |