Re: [patch] i386, vdso=[0|1] boot option and/proc/sys/vm/vdso_enabled
From: Andrew Morton
Date: Sat May 20 2006 - 05:34:46 EST
Ingo Molnar <mingo@xxxxxxx> wrote:
> * Linus Torvalds <torvalds@xxxxxxxx> wrote:
> > > Well that patch took a machine from working to non-working. Pretty serious
> > > stuff. We should get to the bottom of the problem so we can assess the
> > > risk and impact, no?
> > Yes. And it would be good to have a way to turn it off - either
> > globally of by some per-process setup (eg off by default, but turn on
> > when doing some magic).
> > The per-process one would be the harder one, because it would require
> > the fixmap entry, but not globally. So I suspect the only practical
> > thing would be to have it be a kernel boot-time option.
> below is a patch that adds the vdso=0 boot option from exec-shield and
> the /proc/sys/vm/vdso_enabled per-system sysctl.
> Andrew, could you try this - do newly started processes work fine if you
> re-enable the vdso after booting with vdso=0?
vmm:/home/akpm# echo 1 > /proc/sys/vm/vdso_enabled
vmm:/home/akpm> ls -l
zsh: segmentation fault ls -l
> That could tell us whether
> it's an init bug or a glibc bug.
It tells us neither. This could be a new kernel bug which only certain old
userspace setups are known to trigger. Until we know exactly why this is
occurring, we don't know where the bug is.
And once we've worked that thing out, and if we determine that the bug is
in userspace then we might be able to craft the patch in such a fashion
that the old userspace continues to work, which would be a win.
> arch/i386/kernel/sysenter.c | 21 +++++++++++++++++++++
> include/linux/sysctl.h | 1 +
> kernel/sysctl.c | 16 ++++++++++++++++
> 3 files changed, 38 insertions(+)
> +unsigned int vdso_enabled = 1;
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/