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$(echo .)intel.com \
--cc=Babu.Moger@amd$(echo .)com \
--cc=James.Bottomley@hansenpartnership$(echo .)com \
--cc=ak@linux$(echo .)intel.com \
--cc=akpm@linux-foundation$(echo .)org \
--cc=amit.kachhap@arm$(echo .)com \
--cc=anders.roxell@linaro$(echo .)org \
--cc=andriin@fb$(echo .)com \
--cc=anil.s.keshavamurthy@intel$(echo .)com \
--cc=anup.patel@wdc$(echo .)com \
--cc=aou@eecs$(echo .)berkeley.edu \
--cc=ardb@kernel$(echo .)org \
--cc=aryabinin@virtuozzo$(echo .)com \
--cc=ast@kernel$(echo .)org \
--cc=atish.patra@wdc$(echo .)com \
--cc=bauerman@linux$(echo .)ibm.com \
--cc=ben-linux@fluff$(echo .)org \
--cc=borntraeger@de$(echo .)ibm.com \
--cc=bp@alien8$(echo .)de \
--cc=bpf@vger$(echo .)kernel.org \
--cc=brgerst@gmail$(echo .)com \
--cc=catalin.marinas@arm$(echo .)com \
--cc=damien.lemoal@wdc$(echo .)com \
--cc=daniel@iogearbox$(echo .)net \
--cc=davem@davemloft$(echo .)net \
--cc=deanbo422@gmail$(echo .)com \
--cc=deller@gmx$(echo .)de \
--cc=dja@axtens$(echo .)net \
--cc=duwe@lst$(echo .)de \
--cc=dvyukov@google$(echo .)com \
--cc=elver@google$(echo .)com \
--cc=gerald.schaefer@de$(echo .)ibm.com \
--cc=gor@linux$(echo .)ibm.com \
--cc=green.hu@gmail$(echo .)com \
--cc=gxt@pku$(echo .)edu.cn \
--cc=han_mao@c-sky$(echo .)com \
--cc=heiko.carstens@de$(echo .)ibm.com \
--cc=hpa@zytor$(echo .)com \
--cc=jeyu@kernel$(echo .)org \
--cc=jkosina@suse$(echo .)cz \
--cc=joe.lawrence@redhat$(echo .)com \
--cc=john.fastabend@gmail$(echo .)com \
--cc=jolsa@redhat$(echo .)com \
--cc=jpoimboe@redhat$(echo .)com \
--cc=kafai@fb$(echo .)com \
--cc=kpsingh@chromium$(echo .)org \
--cc=ley.foon.tan@intel$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-mips@vger$(echo .)kernel.org \
--cc=linux-parisc@vger$(echo .)kernel.org \
--cc=linux-riscv@lists$(echo .)infradead.org \
--cc=linux-s390@vger$(echo .)kernel.org \
--cc=linux@armlinux$(echo .)org.uk \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=luto@kernel$(echo .)org \
--cc=mark.rutland@arm$(echo .)com \
--cc=masahiroy@kernel$(echo .)org \
--cc=mbenes@suse$(echo .)cz \
--cc=mhiramat@kernel$(echo .)org \
--cc=mingo@redhat$(echo .)com \
--cc=naveen.n.rao@linux$(echo .)ibm.com \
--cc=nayna@linux$(echo .)ibm.com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=nickhu@andestech$(echo .)com \
--cc=oberpar@linux$(echo .)ibm.com \
--cc=palmer@dabbelt$(echo .)com \
--cc=paul.walmsley@sifive$(echo .)com \
--cc=paulburton@kernel$(echo .)org \
--cc=paulmck@kernel$(echo .)org \
--cc=paulus@samba$(echo .)org \
--cc=peterz@infradead$(echo .)org \
--cc=pmladek@suse$(echo .)com \
--cc=prudo@linux$(echo .)ibm.com \
--cc=rostedt@goodmis$(echo .)org \
--cc=rppt@linux$(echo .)ibm.com \
--cc=samitolvanen@google$(echo .)com \
--cc=sandipan@linux$(echo .)ibm.com \
--cc=sean.j.christopherson@intel$(echo .)com \
--cc=sergey.senozhatsky@gmail$(echo .)com \
--cc=songliubraving@fb$(echo .)com \
--cc=sparclinux@vger$(echo .)kernel.org \
--cc=svens@stackframe$(echo .)org \
--cc=tglx@linutronix$(echo .)de \
--cc=tsbogend@alpha$(echo .)franken.de \
--cc=vincent.whitchurch@axis$(echo .)com \
--cc=vincenzo.frascino@arm$(echo .)com \
--cc=wangkefeng.wang@huawei$(echo .)com \
--cc=will@kernel$(echo .)org \
--cc=x86@kernel$(echo .)org \
--cc=yangtiezhu@loongson$(echo .)cn \
--cc=yhs@fb$(echo .)com \
--cc=yzaikin@google$(echo .)com \
--cc=zong.li@sifive$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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