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# 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(+) Documentation/kernel-parameters.txt, please. > +unsigned int vdso_enabled = 1; __read_mostly.