Why is get_current() not const function?

Why is get_current() not const function?

[Jakub Jelinek]

Hi!

E.g. on x86-64,
        NEW_AUX_ENT(AT_UID, (elf_addr_t) current->uid);
        NEW_AUX_ENT(AT_EUID, (elf_addr_t) current->euid);
        NEW_AUX_ENT(AT_GID, (elf_addr_t) current->gid);
        NEW_AUX_ENT(AT_EGID, (elf_addr_t) current->egid);
results in 4 movq %gs:0,%rax instructions while one is completely
enough.
Anyone remembers why get_current function (on arches which define
current to get_current()) is not const and why on x86-64
the movq %%gs:0, %0 inline asm is volatile with "memory" clobber?
AFAIK current ought to be constant in any function with the exception of
schedule.
If the reason is kernel/sched.c, then IMHO it is certainly
worth making get_current const everywhere but in kernel/sched.c
(e.g. through special define in sched.c before any includes).

	Jakub

Re: Why is get_current() not const function?

[Linus Torvalds]

In article <20030313061926.S3910@devserv.devel.redhat.com>,
Jakub Jelinek  <jakub@redhat.com> wrote:
>
>Anyone remembers why get_current function (on arches which define
>current to get_current()) is not const

Because it makes no difference at all on x86, since gcc will ignore
"const" for inline functions. At least that used to be true.

>					 and why on x86-64
>the movq %%gs:0, %0 inline asm is volatile with "memory" clobber?

Can't help you on that one, but it looks like it uses various helper
functions for doing the x86-64 per-processor data structures, and I bet
those helper functions are shared by _other_ users who definitely want
to have their data properly re-read. Ie "current()" may be constant in
process context, but that sure isn't true about a lot of other things in
the per-processor data structures.

		Linus

Re: Why is get_current() not const function?

[Andi Kleen]

Jakub Jelinek <jakub@redhat.com> writes:

> E.g. on x86-64,
>         NEW_AUX_ENT(AT_UID, (elf_addr_t) current->uid);
>         NEW_AUX_ENT(AT_EUID, (elf_addr_t) current->euid);
>         NEW_AUX_ENT(AT_GID, (elf_addr_t) current->gid);
>         NEW_AUX_ENT(AT_EGID, (elf_addr_t) current->egid);
> results in 4 movq %gs:0,%rax instructions while one is completely
> enough.
> Anyone remembers why get_current function (on arches which define
> current to get_current()) is not const and why on x86-64

I tried it once. Then spent a day in fixing all the obvious problems
(addings lots of compile barriers to early bootup and the scheduler 
to make it boot again etc.)

In the end I gave up because there were some weird crashes left
and I ran out of time on this one.

Feel free to retry it, but it'll be lots of work I suspect.

-Andi

Re: Why is get_current() not const function?

[Andi Kleen]

torvalds@transmeta.com (Linus Torvalds) writes:

>>					 and why on x86-64
>>the movq %%gs:0, %0 inline asm is volatile with "memory" clobber?
>
> Can't help you on that one, but it looks like it uses various helper
> functions for doing the x86-64 per-processor data structures, and I bet
> those helper functions are shared by _other_ users who definitely want
> to have their data properly re-read. Ie "current()" may be constant in
> process context, but that sure isn't true about a lot of other things in
> the per-processor data structures.

Yes, that's the big issue. const current requires non volatile read_pda()
and making read_pda non volatile breaks lots of code currently and probably
needs an audit over all users.

-Andi

Re: Why is get_current() not const function?

[Jakub Jelinek]

On Mon, Mar 17, 2003 at 06:26:05PM +0100, Andi Kleen wrote:
> torvalds@transmeta.com (Linus Torvalds) writes:
> 
> >>					 and why on x86-64
> >>the movq %%gs:0, %0 inline asm is volatile with "memory" clobber?
> >
> > Can't help you on that one, but it looks like it uses various helper
> > functions for doing the x86-64 per-processor data structures, and I bet
> > those helper functions are shared by _other_ users who definitely want
> > to have their data properly re-read. Ie "current()" may be constant in
> > process context, but that sure isn't true about a lot of other things in
> > the per-processor data structures.
> 
> Yes, that's the big issue. const current requires non volatile read_pda()
> and making read_pda non volatile breaks lots of code currently and probably
> needs an audit over all users.

Well, that's one that is not particularly hard to fix.
Either a new set of pda access macros without volatile and memory clobber
can be written, or just get_current can use its own asm, ie.
static inline struct task_struct *get_current(void)
{
	struct task_struct *t;
	asm ("movq %%gs:%c1,%0" : "=r" (t) : "i"(pda_offset(pcurrent)));
	return t;
}

	Jakub

Re: Why is get_current() not const function?

[Manfred Spraul]

[-- Attachment #1: Type: text/plain, Size: 319 bytes --]

Is it possible to use __attribute__((const) with inline functions?
I tried that, but it seems that gcc ignores __attribute__((const) and 
looks at the contents of the function instead.

I've tried the attached test app: With gcc-3.2.1 (gcc -O3), and 
"inlconst" was called 10 times, constfnc only once.

--
    Manfred

[-- Attachment #2: consttest.c --]
[-- Type: text/plain, Size: 460 bytes --]

#include <stdio.h>
#include <stdlib.h>

static int constfnc(int x) __attribute__((const));

static inline int inlconst(int x) __attribute__((const));

static void dummy(int i);

static inline int inlconst(int x)
{
	printf("in inlconst.\n");
	return 2;
}

int main(void)
{
	int i;
	for(i=0;i<10;i++) {
		dummy(constfnc(0));
	}
	for (i=0;i<10;i++) {
		dummy(inlconst(0));
	}
}

int constfnc(int x)
{
	printf("in const.\n");
	return 1;
}


void dummy(int i)
{
}