From: Ard Biesheuvel <ardb@kernel.org> To: Peter Zijlstra <peterz@infradead.org> Cc: Catalin Marinas <catalin.marinas@arm.com>, Kefeng Wang <wangkefeng.wang@huawei.com>, Paul Mackerras <paulus@samba.org>, Zong Li <zong.li@sifive.com>, Andi Kleen <ak@linux.intel.com>, Paul Burton <paulburton@kernel.org>, Michael Ellerman <mpe@ellerman.id.au>, Vincent Whitchurch <vincent.whitchurch@axis.com>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Petr Mladek <pmladek@suse.com>, Brian Gerst <brgerst@gmail.com>, Andy Lutomirski <luto@kernel.org>, Thomas Gleixner <tglx@linutronix.de>, Jiri Kosina <jkosina@suse.cz>, Anup Patel <anup.patel@wdc.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Philipp Rudo <prudo@linux.ibm.com>, Torsten Duwe <duwe@lst.de>, Masami Hiramatsu <mhiramat@kernel.org>, Andrew Morton <akpm@linux-foundation.org>, Mark Rutland <mark.rutland@arm.com>, "James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>, Vincent Chen <deanbo422@gmail.com>, Omar Sandoval <osandov@fb.com>, "open list:S390" <linux-s390@vger.kernel.org>, Joe Lawrence <joe.lawrence@redhat.com>, Helge Deller <deller@gmx.de>, John Fastabend <john.fastabend@gmail.com>, Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>, Yonghong Song <yhs@fb.com>, Iurii Zaikin <yzaikin@google.com>, Andrii Nakryiko <andriin@fb.com>, Thomas Huth <thuth@redhat.com>, Vasily Gorbik <gor@linux.ibm.com>, "moderated list:ARM PORT" <linux-arm-kernel@lists.infradead.org>, Daniel Axtens <dja@axtens.net>, Damien Le Moal <damien.lemoal@wdc.com>, Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>, Paul Walmsley <paul.walmsley@sifive.com>, Heiko Carstens <heiko.carstens@de.ibm.com>, Alexei Starovoitov <ast@kernel.org>, Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>, Atish Patra <atish.patra@wdc.com>, Will Deacon <will@kernel.org>, Daniel Borkmann <daniel@iogearbox.net>, Masahiro Yamada <masahiroy@kernel.org>, Nayna Jain <nayna@linux.ibm.com>, Ley Foon Tan <ley.foon.tan@intel.com>, Christian Borntraeger <borntraeger@de.ibm.com>, Sami Tolvanen <samitolvanen@google.com>, "Naveen N. Rao" <naveen.n.rao@linux.ibm.com>, Mao Han <han_mao@c-sky.com>, Marco Elver <elver@google.com>, Steven Rostedt <rostedt@goodmis.org>, Babu Moger <Babu.Moger@amd.com>, Borislav Petkov <bp@alien8.de>, Greentime Hu <green.hu@gmail.com>, Ben Dooks <ben-linux@fluff.org>, Guan Xuetao <gxt@pku.edu.cn>, Thomas Bogendoerfer <tsbogend@alpha.franken.de>, "open list:PARISC ARCHITECTURE" <linux-parisc@vger.kernel.org>, Jessica Yu <jeyu@kernel.org>, "open list:BPF JIT for MIPS \(32-BIT AND 64-BIT\)" <bpf@vger.kernel.org>, "David S. Miller" <davem@davemloft.net>, Thiago Jung Bauermann <bauerman@linux.ibm.com>, David Howells <dhowells@redhat.com>, "open list:SPARC + UltraSPARC \(sparc/sparc64\)" <sparclinux@vger.kernel.org>, Sandipan Das <sandipan@linux.ibm.com>, "H. Peter Anvin" <hpa@zytor.com>, Amit Daniel Kachhap <amit.kachhap@arm.com>, Tiezhu Yang <yangtiezhu@loongson.cn>, Miroslav Benes <mbenes@suse.cz>, Jiri Olsa <jolsa@redhat.com>, "open list:RISC-V ARCHITECTURE" <linux-riscv@lists.infradead.org>, Vincenzo Frascino <vincenzo.frascino@arm.com>, Anders Roxell <anders.roxell@linaro.org>, Sven Schnelle <svens@stackframe.org>, "maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" <x86@kernel.org>, Russell King <linux@armlinux.org.uk>, Mike Rapoport <rppt@linux.ibm.com>, Ingo Molnar <mingo@redhat.com>, Albert Ou <aou@eecs.berkeley.edu>, "Paul E. McKenney" <paulmck@kernel.org>, Josh Poimboeuf <jpoimboe@redhat.com>, KP Singh <kpsingh@chromium.org>, Dmitry Vyukov <dvyukov@google.com>, Nick Hu <nickhu@andestech.com>, "open list:BPF JIT for MIPS \(32-BIT AND 64-BIT\)" <netdev@vger.kernel.org>, "open list:MIPS" <linux-mips@vger.kernel.org>, Palmer Dabbelt <palmer@dabbelt.com>, "open list:LINUX FOR POWERPC \(32-BIT AND 64-BIT\)" <linuxppc-dev@lists.ozlabs.org> Subject: Re: [PATCH v2 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper Date: Tue, 14 Jul 2020 15:19:24 +0300 [thread overview] Message-ID: <CAMj1kXGG4vxWrp1de1FxdU=8F4Jof00=T1x-7e+BW7_HP-oZMQ@mail.gmail.com> (raw) In-Reply-To: <20200714112927.GV10769@hirez.programming.kicks-ass.net> On Tue, 14 Jul 2020 at 14:31, Peter Zijlstra <peterz@infradead.org> wrote: > > On Tue, Jul 14, 2020 at 11:28:27AM +0100, Will Deacon wrote: > > > As Ard says, module_alloc() _is_ special, in the sense that the virtual > > memory it allocates wants to be close to the kernel text, whereas the > > concept of allocating executable memory is broader and doesn't have these > > restrictions. So, while I'm in favour of having a text_alloc() interface > > that can be used by callers which only require an executable mapping, I'd > > much prefer for the module_alloc() code to remain for, err, modules. > > So on x86 all those things (kprobes, bpf, ftrace) require that same > closeness. > > An interface like the late vmalloc_exec() will simply not work for us. > Fair enough. So for x86, implementing text_alloc() as an alias of module_alloc() makes sense. But that is not the case in general. > We recently talked about arm64-kprobes and how you're not doing any of > the optimizations and fully rely on the exception return. And I see > you're one of the few archs that has bpf_jit_alloc_exec() (also, > shouldn't you be using PAGE_KERNEL_EXEC there?). But the BPF core seems > to use module_alloc() as a default means of allocating text. > Indeed. Which means it uses up module space which may be scarce, especially on 32-bit ARM, and gets backed by kasan shadow pages, which only makes sense for modules (if CONFIG_KASAN=y) > > So what should this look like? Have a text_alloc() with an argument that > indicates where? But then I suppose we also need a means to manage PLT > entries. Otherwise I don't exactly see how you're going to call BPF > code, or how that BPF stuff is going to call back into its helpers. > If x86 chooses to back its implementation of text_alloc() by module_alloc(), that is absolutely fine. But arm64 has no use for text_alloc() at all today (bpf and kprobes don't use module_alloc(), and ftrace does not implement dynamic trampoline allocation), and in the general case, bpf, kprobes, ftrace and the module loader all have different requirements that deviate subtly between architectures. So perhaps the answer is to have text_alloc() not with a 'where' argument but with a 'why' argument. Or more simply, just have separate alloc/free APIs for each case, with generic versions that can be overridden by the architecture. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Ard Biesheuvel <ardb@kernel.org> To: Peter Zijlstra <peterz@infradead.org> Cc: Catalin Marinas <catalin.marinas@arm.com>, Kefeng Wang <wangkefeng.wang@huawei.com>, Paul Mackerras <paulus@samba.org>, Zong Li <zong.li@sifive.com>, Andi Kleen <ak@linux.intel.com>, Paul Burton <paulburton@kernel.org>, Vincent Whitchurch <vincent.whitchurch@axis.com>, Petr Mladek <pmladek@suse.com>, Brian Gerst <brgerst@gmail.com>, Andy Lutomirski <luto@kernel.org>, Thomas Gleixner <tglx@linutronix.de>, Jiri Kosina <jkosina@suse.cz>, Anup Patel <anup.patel@wdc.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Philipp Rudo <prudo@linux.ibm.com>, Torsten Duwe <duwe@lst.de>, Masami Hiramatsu <mhiramat@kernel.org>, Andrew Morton <akpm@linux-foundation.org>, Mark Rutland <mark.rutland@arm.com>, "James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>, Vincent Chen <deanbo422@gmail.com>, Omar Sandoval <osandov@fb.com>, "open list:S390" <linux-s390@vger.kernel.org>, Joe Lawrence <joe.lawrence@redhat.com>, Helge Deller <deller@gmx.de>, John Fastabend <john.fastabend@gmail.com>, Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>, Yonghong Song <yhs@fb.com>, Iurii Zaikin <yzaikin@google.com>, Andrii Nakryiko <andriin@fb.com>, Thomas Huth <thuth@redhat.com>, Vasily Gorbik <gor@linux.ibm.com>, "moderated list:ARM PORT" <linux-arm-kernel@lists.infradead.org>, Daniel Axtens <dja@axtens.net>, Damien Le Moal <damien.lemoal@wdc.com>, Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>, Paul Walmsley <paul.walmsley@sifive.com>, Heiko Carstens <heiko.carstens@de.ibm.com>, Alexei Starovoitov <ast@kernel.org>, Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>, Atish Patra <atish.patra@wdc.com>, Will Deacon <will@kernel.org>, Daniel Borkmann <daniel@iogearbox.net>, Masahiro Yamada <masahiroy@kernel.org>, Nayna Jain <nayna@linux.ibm.com>, Ley Foon Tan <ley.foon.tan@intel.com>, Christian Borntraeger <borntraeger@de.ibm.com>, Sami Tolvanen <samitolvanen@google.com>, "Naveen N. Rao" <naveen.n.rao@linux.ibm.com>, Mao Han <han_mao@c-sky.com>, Marco Elver <elver@google.com>, Steven Rostedt <rostedt@goodmis.org>, Babu Moger <Babu.Moger@amd.com>, Borislav Petkov <bp@alien8.de>, Greentime Hu <green.hu@gmail.com>, Ben Dooks <ben-linux@fluff.org>, Guan Xuetao <gxt@pku.edu.cn>, Thomas Bogendoerfer <tsbogend@alpha.franken.de>, "open list:PARISC ARCHITECTURE" <linux-parisc@vger.kernel.org>, Jessica Yu <jeyu@kernel.org>, "open list:BPF JIT for MIPS \(32-BIT AND 64-BIT\)" <bpf@vger.kernel.org>, "David S. Miller" <davem@davemloft.net>, Thiago Jung Bauermann <bauerman@linux.ibm.com>, David Howells <dhowells@redhat.com>, "open list:SPARC + UltraSPARC \(sparc/sparc64\)" <sparclinux@vger.kernel.org>, Sandipan Das <sandipan@linux.ibm.com>, "H. Peter Anvin" <hpa@zytor.com>, Amit Daniel Kachhap <amit.kachhap@arm.com>, Tiezhu Yang <yangtiezhu@loongson.cn>, Miroslav Benes <mbenes@suse.cz>, Jiri Olsa <jolsa@redhat.com>, "open list:RISC-V ARCHITECTURE" <linux-riscv@lists.infradead.org>, Vincenzo Frascino <vincenzo.frascino@arm.com>, Anders Roxell <anders.roxell@linaro.org>, Sven Schnelle <svens@stackframe.org>, "maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" <x86@kernel.org>, Russell King <linux@armlinux.org.uk>, Mike Rapoport <rppt@linux.ibm.com>, Ingo Molnar <mingo@redhat.com>, Albert Ou <aou@eecs.berkeley.edu>, "Paul E. McKenney" <paulmck@kernel.org>, Josh Poimboeuf <jpoimboe@redhat.com>, KP Singh <kpsingh@chromium.org>, Dmitry Vyukov <dvyukov@google.com>, Nick Hu <nickhu@andestech.com>, "open list:BPF JIT for MIPS \(32-BIT AND 64-BIT\)" <netdev@vger.kernel.org>, "open list:MIPS" <linux-mips@vger.kernel.org>, Palmer Dabbelt <palmer@dabbelt.com>, "open list:LINUX FOR POWERPC \(32-BIT AND 64-BIT\)" <linuxppc-dev@lists.ozlabs.org> Subject: Re: [PATCH v2 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper Date: Tue, 14 Jul 2020 15:19:24 +0300 [thread overview] Message-ID: <CAMj1kXGG4vxWrp1de1FxdU=8F4Jof00=T1x-7e+BW7_HP-oZMQ@mail.gmail.com> (raw) In-Reply-To: <20200714112927.GV10769@hirez.programming.kicks-ass.net> On Tue, 14 Jul 2020 at 14:31, Peter Zijlstra <peterz@infradead.org> wrote: > > On Tue, Jul 14, 2020 at 11:28:27AM +0100, Will Deacon wrote: > > > As Ard says, module_alloc() _is_ special, in the sense that the virtual > > memory it allocates wants to be close to the kernel text, whereas the > > concept of allocating executable memory is broader and doesn't have these > > restrictions. So, while I'm in favour of having a text_alloc() interface > > that can be used by callers which only require an executable mapping, I'd > > much prefer for the module_alloc() code to remain for, err, modules. > > So on x86 all those things (kprobes, bpf, ftrace) require that same > closeness. > > An interface like the late vmalloc_exec() will simply not work for us. > Fair enough. So for x86, implementing text_alloc() as an alias of module_alloc() makes sense. But that is not the case in general. > We recently talked about arm64-kprobes and how you're not doing any of > the optimizations and fully rely on the exception return. And I see > you're one of the few archs that has bpf_jit_alloc_exec() (also, > shouldn't you be using PAGE_KERNEL_EXEC there?). But the BPF core seems > to use module_alloc() as a default means of allocating text. > Indeed. Which means it uses up module space which may be scarce, especially on 32-bit ARM, and gets backed by kasan shadow pages, which only makes sense for modules (if CONFIG_KASAN=y) > > So what should this look like? Have a text_alloc() with an argument that > indicates where? But then I suppose we also need a means to manage PLT > entries. Otherwise I don't exactly see how you're going to call BPF > code, or how that BPF stuff is going to call back into its helpers. > If x86 chooses to back its implementation of text_alloc() by module_alloc(), that is absolutely fine. But arm64 has no use for text_alloc() at all today (bpf and kprobes don't use module_alloc(), and ftrace does not implement dynamic trampoline allocation), and in the general case, bpf, kprobes, ftrace and the module loader all have different requirements that deviate subtly between architectures. So perhaps the answer is to have text_alloc() not with a 'where' argument but with a 'why' argument. Or more simply, just have separate alloc/free APIs for each case, with generic versions that can be overridden by the architecture.
next prev parent reply other threads:[~2020-07-14 12:19 UTC|newest] Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-07-14 9:45 [PATCH v2 0/3] kprobes: Remove MODULE dependency Jarkko Sakkinen 2020-07-14 9:45 ` Jarkko Sakkinen 2020-07-14 9:45 ` [PATCH v2 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper Jarkko Sakkinen 2020-07-14 9:45 ` Jarkko Sakkinen 2020-07-14 9:50 ` Russell King - ARM Linux admin 2020-07-14 9:50 ` Russell King - ARM Linux admin 2020-07-14 10:28 ` Will Deacon 2020-07-14 10:28 ` Will Deacon 2020-07-14 11:29 ` Peter Zijlstra 2020-07-14 11:29 ` Peter Zijlstra 2020-07-14 12:19 ` Ard Biesheuvel [this message] 2020-07-14 12:19 ` Ard Biesheuvel 2020-07-14 13:01 ` Peter Zijlstra 2020-07-14 13:01 ` Peter Zijlstra 2020-07-14 13:33 ` Mark Rutland 2020-07-14 13:33 ` Mark Rutland 2020-07-14 13:47 ` Ard Biesheuvel 2020-07-14 13:47 ` Ard Biesheuvel 2020-07-14 14:03 ` Steven Rostedt 2020-07-14 14:03 ` Steven Rostedt 2020-07-15 5:03 ` Masami Hiramatsu 2020-07-15 5:03 ` Masami Hiramatsu 2020-07-14 16:31 ` Jarkko Sakkinen 2020-07-14 16:31 ` Jarkko Sakkinen 2020-07-14 16:46 ` Peter Zijlstra 2020-07-14 16:46 ` Peter Zijlstra 2020-07-15 8:15 ` David Laight 2020-07-15 8:15 ` David Laight 2020-07-14 16:42 ` Russell King - ARM Linux admin 2020-07-14 16:42 ` Russell King - ARM Linux admin 2020-07-14 12:25 ` Jarkko Sakkinen 2020-07-14 12:25 ` Jarkko Sakkinen 2020-07-14 13:56 ` Jessica Yu 2020-07-14 13:56 ` Jessica Yu 2020-07-14 15:44 ` Steven Rostedt 2020-07-14 15:44 ` Steven Rostedt 2020-07-14 16:37 ` Jarkko Sakkinen 2020-07-14 16:37 ` Jarkko Sakkinen 2020-07-14 14:35 ` kernel test robot 2020-07-14 14:35 ` kernel test robot 2020-07-16 16:49 ` Christophe Leroy 2020-07-16 16:49 ` Christophe Leroy 2020-07-23 1:51 ` Jarkko Sakkinen 2020-07-23 1:51 ` Jarkko Sakkinen 2020-07-23 12:42 ` Ard Biesheuvel 2020-07-23 12:42 ` Ard Biesheuvel 2020-07-24 7:36 ` Jarkko Sakkinen 2020-07-24 7:36 ` Jarkko Sakkinen 2020-07-24 8:05 ` Jessica Yu 2020-07-24 8:05 ` Jessica Yu 2020-07-24 15:46 ` Jarkko Sakkinen 2020-07-24 15:46 ` Jarkko Sakkinen 2020-07-14 9:45 ` [PATCH v2 2/3] module: Add lock_modules() and unlock_modules() Jarkko Sakkinen 2020-07-14 9:45 ` [PATCH v2 3/3] kprobes: Flag out CONFIG_MODULES dependent code Jarkko Sakkinen
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='CAMj1kXGG4vxWrp1de1FxdU=8F4Jof00=T1x-7e+BW7_HP-oZMQ@mail.gmail.com' \ --to=ardb@kernel.org \ --cc=Babu.Moger@amd.com \ --cc=James.Bottomley@hansenpartnership.com \ --cc=ak@linux.intel.com \ --cc=akpm@linux-foundation.org \ --cc=amit.kachhap@arm.com \ --cc=anders.roxell@linaro.org \ --cc=andriin@fb.com \ --cc=anil.s.keshavamurthy@intel.com \ --cc=anup.patel@wdc.com \ --cc=aou@eecs.berkeley.edu \ --cc=ast@kernel.org \ --cc=atish.patra@wdc.com \ --cc=bauerman@linux.ibm.com \ --cc=ben-linux@fluff.org \ --cc=benh@kernel.crashing.org \ --cc=borntraeger@de.ibm.com \ --cc=bp@alien8.de \ --cc=bpf@vger.kernel.org \ --cc=brgerst@gmail.com \ --cc=catalin.marinas@arm.com \ --cc=damien.lemoal@wdc.com \ --cc=daniel@iogearbox.net \ --cc=davem@davemloft.net \ --cc=deanbo422@gmail.com \ --cc=deller@gmx.de \ --cc=dhowells@redhat.com \ --cc=dja@axtens.net \ --cc=duwe@lst.de \ --cc=dvyukov@google.com \ --cc=elver@google.com \ --cc=gor@linux.ibm.com \ --cc=green.hu@gmail.com \ --cc=gxt@pku.edu.cn \ --cc=han_mao@c-sky.com \ --cc=heiko.carstens@de.ibm.com \ --cc=hpa@zytor.com \ --cc=jarkko.sakkinen@linux.intel.com \ --cc=jeyu@kernel.org \ --cc=jkosina@suse.cz \ --cc=joe.lawrence@redhat.com \ --cc=john.fastabend@gmail.com \ --cc=jolsa@redhat.com \ --cc=jpoimboe@redhat.com \ --cc=kafai@fb.com \ --cc=kpsingh@chromium.org \ --cc=ley.foon.tan@intel.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mips@vger.kernel.org \ --cc=linux-parisc@vger.kernel.org \ --cc=linux-riscv@lists.infradead.org \ --cc=linux-s390@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=luto@kernel.org \ --cc=mark.rutland@arm.com \ --cc=masahiroy@kernel.org \ --cc=mbenes@suse.cz \ --cc=mhiramat@kernel.org \ --cc=mingo@redhat.com \ --cc=mpe@ellerman.id.au \ --cc=naveen.n.rao@linux.ibm.com \ --cc=nayna@linux.ibm.com \ --cc=netdev@vger.kernel.org \ --cc=nickhu@andestech.com \ --cc=osandov@fb.com \ --cc=palmer@dabbelt.com \ --cc=paul.walmsley@sifive.com \ --cc=paulburton@kernel.org \ --cc=paulmck@kernel.org \ --cc=paulus@samba.org \ --cc=peterz@infradead.org \ --cc=pmladek@suse.com \ --cc=prudo@linux.ibm.com \ --cc=rostedt@goodmis.org \ --cc=rppt@linux.ibm.com \ --cc=samitolvanen@google.com \ --cc=sandipan@linux.ibm.com \ --cc=songliubraving@fb.com \ --cc=sparclinux@vger.kernel.org \ --cc=svens@stackframe.org \ --cc=tglx@linutronix.de \ --cc=thuth@redhat.com \ --cc=tsbogend@alpha.franken.de \ --cc=vincent.whitchurch@axis.com \ --cc=vincenzo.frascino@arm.com \ --cc=wangkefeng.wang@huawei.com \ --cc=will@kernel.org \ --cc=x86@kernel.org \ --cc=yangtiezhu@loongson.cn \ --cc=yhs@fb.com \ --cc=yzaikin@google.com \ --cc=zong.li@sifive.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.