2011-06-03 15:20:40

by Dave Anderson

[permalink] [raw]
Subject: [PATCH] x86-64: Prevent gcc from optimizing away venosys_1()

One of the changes in commit a4928cffe6435caf427ae673131a633c1329dbf3
made the venosys_1() system call static, which causes it to be
optimized out of the kernel:

Author: Ingo Molnar <[email protected]>
Date: Wed Apr 23 13:20:56 2008 +0200

"make namespacecheck" fixes

Signed-off-by: Ingo Molnar <[email protected]>

Commit 2e8ad43ec07545780ce7992cb18e2d82c7abd24c had originally
changed all vsyscalls from being static for the same reason:

Author: Andi Kleen <[email protected]>
Date: Mon Sep 12 18:49:24 2005 +0200

[PATCH] x86-64: Prevent gcc 4 from optimizing away vsyscalls

They were previously static.

Signed-off-by: Andi Kleen <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

Reported-by: Jan Stancek <[email protected]>
Signed-off-by: Dave Anderson <[email protected]>

---

diff --git a/arch/x86/kernel/vsyscall_64.c b/arch/x86/kernel/vsyscall_64.c
index 3e68218..60a34af 100644
--- a/arch/x86/kernel/vsyscall_64.c
+++ b/arch/x86/kernel/vsyscall_64.c
@@ -222,7 +222,7 @@ vgetcpu(unsigned *cpu, unsigned *node, struct getcpu_cache *tcache)
return 0;
}

-static long __vsyscall(3) venosys_1(void)
+long __vsyscall(3) venosys_1(void)
{
return -ENOSYS;
}


2011-06-03 20:48:51

by Andi Kleen

[permalink] [raw]
Subject: Re: [PATCH] x86-64: Prevent gcc from optimizing away venosys_1()

> return 0;
> }
>
> -static long __vsyscall(3) venosys_1(void)
> +long __vsyscall(3) venosys_1(void)

Better add a __used too. Otherwise it can be optimized out again
in some builds e.g. when someone enables gc-sections for the linker.

-Andi
--
[email protected] -- Speaking for myself only.

2011-06-03 21:32:15

by Dave Anderson

[permalink] [raw]
Subject: Re: [PATCH] x86-64: Prevent gcc from optimizing away venosys_1()



----- Original Message -----
> > return 0;
> > }
> >
> > -static long __vsyscall(3) venosys_1(void)
> > +long __vsyscall(3) venosys_1(void)
>
> Better add a __used too. Otherwise it can be optimized out again
> in some builds e.g. when someone enables gc-sections for the linker.

Considering that all of the vsyscall prototypes have this attribute:

#define __vsyscall(nr) \
__attribute__ ((unused, __section__(".vsyscall_" #nr))) notrace

How would any of them work?

Dave

>
> -Andi
> --
> [email protected] -- Speaking for myself only.

2011-06-03 21:37:16

by Andi Kleen

[permalink] [raw]
Subject: Re: [PATCH] x86-64: Prevent gcc from optimizing away venosys_1()

On Fri, Jun 03, 2011 at 05:32:06PM -0400, Dave Anderson wrote:
>
>
> ----- Original Message -----
> > > return 0;
> > > }
> > >
> > > -static long __vsyscall(3) venosys_1(void)
> > > +long __vsyscall(3) venosys_1(void)
> >
> > Better add a __used too. Otherwise it can be optimized out again
> > in some builds e.g. when someone enables gc-sections for the linker.
>
> Considering that all of the vsyscall prototypes have this attribute:
>
> #define __vsyscall(nr) \
> __attribute__ ((unused, __section__(".vsyscall_" #nr))) notrace
>
> How would any of them work?

unused is just to prevent warnings I think. used stops the optimizer
from throwing it away.

It would make more sense to drop the unused and add an used. I think
used prevents the warnings too.

-Andi

--
[email protected] -- Speaking for myself only.

2011-06-06 17:22:22

by Ingo Molnar

[permalink] [raw]
Subject: Re: [PATCH] x86-64: Prevent gcc from optimizing away venosys_1()


* Dave Anderson <[email protected]> wrote:

> One of the changes in commit a4928cffe6435caf427ae673131a633c1329dbf3
> made the venosys_1() system call static, which causes it to be
> optimized out of the kernel:
>
> Author: Ingo Molnar <[email protected]>
> Date: Wed Apr 23 13:20:56 2008 +0200
>
> "make namespacecheck" fixes
>
> Signed-off-by: Ingo Molnar <[email protected]>

Andy noticed this recently, so we got rid of that broken (and unused)
syscall in:

bb5fe2f78ead: x86-64: Remove vsyscall number 3 (venosys)

which is in the tip:x86/vdso branch at:

http://people.redhat.com/mingo/tip.git/README

Thanks,

Ingo