From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
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>, Yonghong Song <yhs@fb.com>,
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>,
"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>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
Iurii Zaikin <yzaikin@google.com>,
Andrii Nakryiko <andriin@fb.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>,
Peter Oberparleiter <oberpar@linux.ibm.com>,
Sean Christopherson <sean.j.christopherson@intel.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>,
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>,
Dmitry Vyukov <dvyukov@google.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>,
Peter Zijlstra <peterz@infradead.org>,
"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>,
Ard Biesheuvel <ardb@kernel.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>,
"open list:RISC-V ARCHITECTURE" <linux-riscv@lists.infradead.org>,
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>,
Gerald Schaefer <gerald.schaefer@de.ibm.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>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
"open list:LINUX FOR POWERPC \(32-BIT AND 64-BIT\)"
<linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper
Date: Tue, 14 Jul 2020 15:11:59 +0300 [thread overview]
Message-ID: <20200714121159.GD1463346@linux.intel.com> (raw)
In-Reply-To: <20200714103333.GB1551@shell.armlinux.org.uk>
On Tue, Jul 14, 2020 at 11:33:33AM +0100, Russell King - ARM Linux admin wrote:
> On Tue, Jul 14, 2020 at 01:17:22PM +0300, Ard Biesheuvel wrote:
> > On Tue, 14 Jul 2020 at 12:53, Jarkko Sakkinen
> > <jarkko.sakkinen@linux.intel.com> wrote:
> > >
> > > On Mon, Jul 13, 2020 at 10:49:48PM +0300, Ard Biesheuvel wrote:
> > > > This patch suggests that there are other reasons why conflating
> > > > allocation of module space and allocating text pages for other uses
> > > > is a bad idea, but switching all users to text_alloc() is a step in
> > > > the wrong direction. It would be better to stop using module_alloc()
> > > > in core code except in the module loader, and have a generic
> > > > text_alloc() that can be overridden by the arch if necessary. Note
> > > > that x86 and s390 are the only architectures that use module_alloc()
> > > > in ftrace code.
> > >
> > > This series essentially does this: introduces text_alloc() and
> > > text_memfree(), which have generic implementations in kernel/text.c.
> > > Those can be overriddent by arch specific implementations.
> > >
> > > What you think should be done differently than in my patch set?
> > >
> >
> > On arm64, module_alloc is only used by the module loader, and so
> > pulling it out and renaming it will cause unused code to be
> > incorporated into the kernel when building without module support,
> > which is the use case you claim to be addressing.
> >
> > Module_alloc has semantics that are intimately tied to the module
> > loader, but over the years, it ended up being (ab)used by other
> > subsystems, which don't require those semantics but just need n pages
> > of vmalloc space with executable permissions.
> >
> > So the correct approach is to make text_alloc() implement just that,
> > generically, and switch bpf etc to use it. Then, only on architectures
> > that need it, override it with an implementation that has the required
> > additional semantics.
> >
> > Refactoring 10+ architectures like this without any regard for how
> > text_alloc() deviates from module_alloc() just creates a lot of churn
> > that others will have to clean up after you.
>
> For 32-bit ARM, our bpf code uses "blx/bx" (or equivalent code
> sequences) rather than encoding a "bl" or "b", so BPF there doesn't
> care where the executable memory is mapped, and doesn't need any
> PLTs. Given that, should bpf always allocate from the vmalloc()
> region to preserve the module space for modules?
Most of the allocators use __vmalloc_node_range() but arch/nios2
uses just plain kmalloc():
/*
* Modules should NOT be allocated with kmalloc for (obvious) reasons.
* But we do it for now to avoid relocation issues. CALL26/PCREL26 cannot reach
* from 0x80000000 (vmalloc area) to 0xc00000000 (kernel) (kmalloc returns
* addresses in 0xc0000000)
*/
void *module_alloc(unsigned long size)
{
if (size == 0)
return NULL;
return kmalloc(size, GFP_KERNEL);
}
Also consider arch/x86 module_alloc():
void *module_alloc(unsigned long size)
{
void *p;
if (PAGE_ALIGN(size) > MODULES_LEN)
return NULL;
p = __vmalloc_node_range(size, MODULE_ALIGN,
MODULES_VADDR + get_module_load_offset(),
MODULES_END, GFP_KERNEL,
PAGE_KERNEL, 0, NUMA_NO_NODE,
__builtin_return_address(0));
if (p && (kasan_module_alloc(p, size) < 0)) {
vfree(p);
return NULL;
}
return p;
}
The generic version is
void * __weak module_alloc(unsigned long size)
{
return __vmalloc_node_range(size, 1, VMALLOC_START, VMALLOC_END,
GFP_KERNEL, PAGE_KERNEL_EXEC, VM_FLUSH_RESET_PERMS,
NUMA_NO_NODE, __builtin_return_address(0));
}
There is quite a lot of divergence from the generic version.
However, in other arch's it's mostly just divergence in vmalloc()
parameters and not as radical as in x86.
I could probably limit the total havoc to just nios2 and x86 if there
is a set of vmalloc parameters that work for all arch's. Then there
could be kernel/text.c and re-implementations for x86 and nios2.
I'm all for having separate text_alloc() and text_memfree() if these
issues can be somehow sorted out.
/Jarkko
next prev parent reply other threads:[~2020-07-14 12:50 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-13 18:19 [PATCH 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper Jarkko Sakkinen
2020-07-13 18:34 ` Russell King - ARM Linux admin
2020-07-14 9:49 ` Jarkko Sakkinen
2020-07-14 9:53 ` Russell King - ARM Linux admin
2020-07-14 11:43 ` Jarkko Sakkinen
2020-07-13 19:49 ` Ard Biesheuvel
2020-07-14 2:04 ` Steven Rostedt
2020-07-14 6:35 ` Ard Biesheuvel
2020-07-14 9:52 ` Jarkko Sakkinen
2020-07-14 10:17 ` Ard Biesheuvel
2020-07-14 10:33 ` Russell King - ARM Linux admin
2020-07-14 11:45 ` Peter Zijlstra
2020-07-14 12:11 ` Jarkko Sakkinen [this message]
2020-07-14 11:55 ` 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=20200714121159.GD1463346@linux.intel.com \
--to=jarkko.sakkinen@linux.intel.com \
--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=ardb@kernel.org \
--cc=aryabinin@virtuozzo.com \
--cc=ast@kernel.org \
--cc=atish.patra@wdc.com \
--cc=bauerman@linux.ibm.com \
--cc=ben-linux@fluff.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=dja@axtens.net \
--cc=duwe@lst.de \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=gerald.schaefer@de.ibm.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=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=naveen.n.rao@linux.ibm.com \
--cc=nayna@linux.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=nickhu@andestech.com \
--cc=oberpar@linux.ibm.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=sean.j.christopherson@intel.com \
--cc=sergey.senozhatsky@gmail.com \
--cc=songliubraving@fb.com \
--cc=sparclinux@vger.kernel.org \
--cc=svens@stackframe.org \
--cc=tglx@linutronix.de \
--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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).