From: Andy Lutomirski <luto@amacapital.net> To: x86@kernel.org, Andrew Morton <akpm@linux-foundation.org>, Sasha Levin <sasha.levin@oracle.com>, "linux-mm@kvack.org" <linux-mm@kvack.org>, Dave Jones <davej@redhat.com> Cc: LKML <linux-kernel@vger.kernel.org>, Cyrill Gorcunov <gorcunov@gmail.com>, Pavel Emelyanov <xemul@parallels.com>, "H. Peter Anvin" <hpa@zytor.com>, Andy Lutomirski <luto@amacapital.net> Subject: [PATCH 0/4] x86,mm: vdso fixes for an OOPS and /proc/PID/maps Date: Mon, 19 May 2014 15:58:30 -0700 [thread overview] Message-ID: <cover.1400538962.git.luto@amacapital.net> (raw) [This applies to tip/x86/vdso. Patch 1/4 is a resend.] This fixes an OOPS on systems without an HPET and incomplete information in /proc/PID/maps. The latter is done by adding a new vm_ops callback to replace arch_vma_name, which is inflexible and awkward to use correctly. With this series applied, calling mremap on the vdso results in sensible output in /proc/PID/maps and the vvar area shows up correctly. I don't want to guarantee that mremap on the vdso will do anything sensible right now, but that's unchanged from before. In fact, I suspect that mremapping the vdso on 32-bit tasks is rather broken right now due to sigreturn. In current kernels, mremapping the vdso blows away the name: badc0de0000-badc0de2000 r-xp 00000000 00:00 0 Now it doesn't: badc0de0000-badc0de1000 r-xp 00000000 00:00 0 [vdso] As a followup, it might pay to replace install_special_mapping with a new install_vdso_mapping function that hardcodes the "[vdso]" name, to separately fix all the other arch_vma_name users (maybe just ARM?) and then kill arch_vma_name completely. NB: This touches core mm code. I'd appreciate some review by the mm folks. Andy Lutomirski (4): x86,vdso: Fix an OOPS accessing the hpet mapping w/o an hpet mm,fs: Add vm_ops->name as an alternative to arch_vma_name x86,mm: Improve _install_special_mapping and fix x86 vdso naming x86,mm: Replace arch_vma_name with vm_ops->name for vsyscalls arch/x86/include/asm/vdso.h | 6 ++- arch/x86/mm/init_64.c | 20 +++++----- arch/x86/vdso/vdso2c.h | 5 ++- arch/x86/vdso/vdso32-setup.c | 7 ---- arch/x86/vdso/vma.c | 26 ++++++++----- fs/binfmt_elf.c | 8 ++++ fs/proc/task_mmu.c | 6 +++ include/linux/mm.h | 10 ++++- include/linux/mm_types.h | 6 +++ mm/mmap.c | 89 +++++++++++++++++++++++++++++--------------- 10 files changed, 124 insertions(+), 59 deletions(-) -- 1.9.0
WARNING: multiple messages have this Message-ID (diff)
From: Andy Lutomirski <luto@amacapital.net> To: x86@kernel.org, Andrew Morton <akpm@linux-foundation.org>, Sasha Levin <sasha.levin@oracle.com>, "linux-mm@kvack.org" <linux-mm@kvack.org>, Dave Jones <davej@redhat.com> Cc: LKML <linux-kernel@vger.kernel.org>, Cyrill Gorcunov <gorcunov@gmail.com>, Pavel Emelyanov <xemul@parallels.com>, "H. Peter Anvin" <hpa@zytor.com>, Andy Lutomirski <luto@amacapital.net> Subject: [PATCH 0/4] x86,mm: vdso fixes for an OOPS and /proc/PID/maps Date: Mon, 19 May 2014 15:58:30 -0700 [thread overview] Message-ID: <cover.1400538962.git.luto@amacapital.net> (raw) [This applies to tip/x86/vdso. Patch 1/4 is a resend.] This fixes an OOPS on systems without an HPET and incomplete information in /proc/PID/maps. The latter is done by adding a new vm_ops callback to replace arch_vma_name, which is inflexible and awkward to use correctly. With this series applied, calling mremap on the vdso results in sensible output in /proc/PID/maps and the vvar area shows up correctly. I don't want to guarantee that mremap on the vdso will do anything sensible right now, but that's unchanged from before. In fact, I suspect that mremapping the vdso on 32-bit tasks is rather broken right now due to sigreturn. In current kernels, mremapping the vdso blows away the name: badc0de0000-badc0de2000 r-xp 00000000 00:00 0 Now it doesn't: badc0de0000-badc0de1000 r-xp 00000000 00:00 0 [vdso] As a followup, it might pay to replace install_special_mapping with a new install_vdso_mapping function that hardcodes the "[vdso]" name, to separately fix all the other arch_vma_name users (maybe just ARM?) and then kill arch_vma_name completely. NB: This touches core mm code. I'd appreciate some review by the mm folks. Andy Lutomirski (4): x86,vdso: Fix an OOPS accessing the hpet mapping w/o an hpet mm,fs: Add vm_ops->name as an alternative to arch_vma_name x86,mm: Improve _install_special_mapping and fix x86 vdso naming x86,mm: Replace arch_vma_name with vm_ops->name for vsyscalls arch/x86/include/asm/vdso.h | 6 ++- arch/x86/mm/init_64.c | 20 +++++----- arch/x86/vdso/vdso2c.h | 5 ++- arch/x86/vdso/vdso32-setup.c | 7 ---- arch/x86/vdso/vma.c | 26 ++++++++----- fs/binfmt_elf.c | 8 ++++ fs/proc/task_mmu.c | 6 +++ include/linux/mm.h | 10 ++++- include/linux/mm_types.h | 6 +++ mm/mmap.c | 89 +++++++++++++++++++++++++++++--------------- 10 files changed, 124 insertions(+), 59 deletions(-) -- 1.9.0 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next reply other threads:[~2014-05-19 22:58 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-05-19 22:58 Andy Lutomirski [this message] 2014-05-19 22:58 ` [PATCH 0/4] x86,mm: vdso fixes for an OOPS and /proc/PID/maps Andy Lutomirski 2014-05-19 22:58 ` [PATCH 1/4] x86,vdso: Fix an OOPS accessing the hpet mapping w/o an hpet Andy Lutomirski 2014-05-19 22:58 ` Andy Lutomirski 2014-05-21 23:21 ` [tip:x86/vdso] x86, vdso: Fix an OOPS accessing the HPET mapping w/o an HPET tip-bot for Andy Lutomirski 2014-05-19 22:58 ` [PATCH 2/4] mm,fs: Add vm_ops->name as an alternative to arch_vma_name Andy Lutomirski 2014-05-19 22:58 ` Andy Lutomirski 2014-05-21 23:21 ` [tip:x86/vdso] mm, fs: Add vm_ops-> name " tip-bot for Andy Lutomirski 2014-05-19 22:58 ` [PATCH 3/4] x86,mm: Improve _install_special_mapping and fix x86 vdso naming Andy Lutomirski 2014-05-19 22:58 ` Andy Lutomirski 2014-05-20 17:21 ` Cyrill Gorcunov 2014-05-20 17:21 ` Cyrill Gorcunov 2014-05-20 17:24 ` Andy Lutomirski 2014-05-20 17:24 ` Andy Lutomirski 2014-05-20 17:47 ` Cyrill Gorcunov 2014-05-20 17:47 ` Cyrill Gorcunov 2014-05-20 17:52 ` Andy Lutomirski 2014-05-20 17:52 ` Andy Lutomirski 2014-05-20 18:01 ` Cyrill Gorcunov 2014-05-20 18:01 ` Cyrill Gorcunov 2014-05-20 18:18 ` H. Peter Anvin 2014-05-20 18:18 ` H. Peter Anvin 2014-05-20 18:24 ` Andy Lutomirski 2014-05-20 18:24 ` Andy Lutomirski 2014-05-20 18:27 ` H. Peter Anvin 2014-05-20 18:27 ` H. Peter Anvin 2014-05-20 18:38 ` Andy Lutomirski 2014-05-20 18:38 ` Andy Lutomirski 2014-05-20 18:39 ` Cyrill Gorcunov 2014-05-20 18:39 ` Cyrill Gorcunov 2014-05-20 18:37 ` H. Peter Anvin 2014-05-20 18:37 ` H. Peter Anvin 2014-05-21 23:21 ` [tip:x86/vdso] x86, mm: " tip-bot for Andy Lutomirski 2014-05-19 22:58 ` [PATCH 4/4] x86,mm: Replace arch_vma_name with vm_ops->name for vsyscalls Andy Lutomirski 2014-05-19 22:58 ` Andy Lutomirski 2014-05-21 23:22 ` [tip:x86/vdso] x86, mm: Replace arch_vma_name with vm_ops-> name " tip-bot for Andy Lutomirski
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=cover.1400538962.git.luto@amacapital.net \ --to=luto@amacapital.net \ --cc=akpm@linux-foundation.org \ --cc=davej@redhat.com \ --cc=gorcunov@gmail.com \ --cc=hpa@zytor.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=sasha.levin@oracle.com \ --cc=x86@kernel.org \ --cc=xemul@parallels.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.