From: "Jarkko Sakkinen" <jarkko@kernel.org>
To: "Mark Rutland" <mark.rutland@arm.com>,
"Masami Hiramatsu" <mhiramat@kernel.org>
Cc: <linux-riscv@lists.infradead.org>,
"Paul Walmsley" <paul.walmsley@sifive.com>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Albert Ou" <aou@eecs.berkeley.edu>,
<linux-kernel@vger.kernel.org>,
"Naveen N . Rao" <naveen.n.rao@linux.ibm.com>,
"Anil S Keshavamurthy" <anil.s.keshavamurthy@intel.com>,
"David S . Miller" <davem@davemloft.net>,
<linux-trace-kernel@vger.kernel.org>,
"Calvin Owens" <jcalvinowens@gmail.com>
Subject: Re: [PATCH v2] arch/riscv: Enable kprobes when CONFIG_MODULES=n
Date: Tue, 26 Mar 2024 19:11:46 +0200 [thread overview]
Message-ID: <D03UKZ3OIEXX.2PCKOX8NOLMKT@kernel.org> (raw)
In-Reply-To: <ZgL5779MIS61GpV6@FVFF77S0Q05N.cambridge.arm.com>
On Tue Mar 26, 2024 at 6:38 PM EET, Mark Rutland wrote:
> On Wed, Mar 27, 2024 at 12:24:03AM +0900, Masami Hiramatsu wrote:
> > On Tue, 26 Mar 2024 14:46:10 +0000
> > Mark Rutland <mark.rutland@arm.com> wrote:
> > >
> > > On Mon, Mar 25, 2024 at 11:56:32AM +0900, Masami Hiramatsu wrote:
> > > > I think, we'd better to introduce `alloc_execmem()`,
> > > > CONFIG_HAVE_ALLOC_EXECMEM and CONFIG_ALLOC_EXECMEM at first
> > > >
> > > > config HAVE_ALLOC_EXECMEM
> > > > bool
> > > >
> > > > config ALLOC_EXECMEM
> > > > bool "Executable trampline memory allocation"
> > > > depends on MODULES || HAVE_ALLOC_EXECMEM
> > > >
> > > > And define fallback macro to module_alloc() like this.
> > > >
> > > > #ifndef CONFIG_HAVE_ALLOC_EXECMEM
> > > > #define alloc_execmem(size, gfp) module_alloc(size)
> > > > #endif
> > >
> > > Please can we *not* do this? I think this is abstracting at the wrong level (as
> > > I mentioned on the prior execmem proposals).
> > >
> > > Different exectuable allocations can have different requirements. For example,
> > > on arm64 modules need to be within 2G of the kernel image, but the kprobes XOL
> > > areas can be anywhere in the kernel VA space.
> > >
> > > Forcing those behind the same interface makes things *harder* for architectures
> > > and/or makes the common code more complicated (if that ends up having to track
> > > all those different requirements). From my PoV it'd be much better to have
> > > separate kprobes_alloc_*() functions for kprobes which an architecture can then
> > > choose to implement using a common library if it wants to.
> > >
> > > I took a look at doing that using the core ifdeffery fixups from Jarkko's v6,
> > > and it looks pretty clean to me (and works in testing on arm64):
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=kprobes/without-modules
> > >
> > > Could we please start with that approach, with kprobe-specific alloc/free code
> > > provided by the architecture?
> >
> > OK, as far as I can read the code, this method also works and neat!
> > (and minimum intrusion). I actually found that exposing CONFIG_ALLOC_EXECMEM
> > to user does not help, it should be an internal change. So hiding this change
> > from user is better choice. Then there is no reason to introduce the new
> > alloc_execmem, but just expand kprobe_alloc_insn_page() is reasonable.
> >
> > Mark, can you send this series here, so that others can review/test it?
>
> I've written up a cover letter and sent that out:
>
> https://lore.kernel.org/lkml/20240326163624.3253157-1-mark.rutland@arm.com/
>
> Mark.
Ya, saw it thanks!
BR, Jarkko
_______________________________________________
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: "Jarkko Sakkinen" <jarkko@kernel.org>
To: "Mark Rutland" <mark.rutland@arm.com>,
"Masami Hiramatsu" <mhiramat@kernel.org>
Cc: <linux-riscv@lists.infradead.org>,
"Paul Walmsley" <paul.walmsley@sifive.com>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Albert Ou" <aou@eecs.berkeley.edu>,
<linux-kernel@vger.kernel.org>,
"Naveen N . Rao" <naveen.n.rao@linux.ibm.com>,
"Anil S Keshavamurthy" <anil.s.keshavamurthy@intel.com>,
"David S . Miller" <davem@davemloft.net>,
<linux-trace-kernel@vger.kernel.org>,
"Calvin Owens" <jcalvinowens@gmail.com>
Subject: Re: [PATCH v2] arch/riscv: Enable kprobes when CONFIG_MODULES=n
Date: Tue, 26 Mar 2024 19:11:46 +0200 [thread overview]
Message-ID: <D03UKZ3OIEXX.2PCKOX8NOLMKT@kernel.org> (raw)
In-Reply-To: <ZgL5779MIS61GpV6@FVFF77S0Q05N.cambridge.arm.com>
On Tue Mar 26, 2024 at 6:38 PM EET, Mark Rutland wrote:
> On Wed, Mar 27, 2024 at 12:24:03AM +0900, Masami Hiramatsu wrote:
> > On Tue, 26 Mar 2024 14:46:10 +0000
> > Mark Rutland <mark.rutland@arm.com> wrote:
> > >
> > > On Mon, Mar 25, 2024 at 11:56:32AM +0900, Masami Hiramatsu wrote:
> > > > I think, we'd better to introduce `alloc_execmem()`,
> > > > CONFIG_HAVE_ALLOC_EXECMEM and CONFIG_ALLOC_EXECMEM at first
> > > >
> > > > config HAVE_ALLOC_EXECMEM
> > > > bool
> > > >
> > > > config ALLOC_EXECMEM
> > > > bool "Executable trampline memory allocation"
> > > > depends on MODULES || HAVE_ALLOC_EXECMEM
> > > >
> > > > And define fallback macro to module_alloc() like this.
> > > >
> > > > #ifndef CONFIG_HAVE_ALLOC_EXECMEM
> > > > #define alloc_execmem(size, gfp) module_alloc(size)
> > > > #endif
> > >
> > > Please can we *not* do this? I think this is abstracting at the wrong level (as
> > > I mentioned on the prior execmem proposals).
> > >
> > > Different exectuable allocations can have different requirements. For example,
> > > on arm64 modules need to be within 2G of the kernel image, but the kprobes XOL
> > > areas can be anywhere in the kernel VA space.
> > >
> > > Forcing those behind the same interface makes things *harder* for architectures
> > > and/or makes the common code more complicated (if that ends up having to track
> > > all those different requirements). From my PoV it'd be much better to have
> > > separate kprobes_alloc_*() functions for kprobes which an architecture can then
> > > choose to implement using a common library if it wants to.
> > >
> > > I took a look at doing that using the core ifdeffery fixups from Jarkko's v6,
> > > and it looks pretty clean to me (and works in testing on arm64):
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=kprobes/without-modules
> > >
> > > Could we please start with that approach, with kprobe-specific alloc/free code
> > > provided by the architecture?
> >
> > OK, as far as I can read the code, this method also works and neat!
> > (and minimum intrusion). I actually found that exposing CONFIG_ALLOC_EXECMEM
> > to user does not help, it should be an internal change. So hiding this change
> > from user is better choice. Then there is no reason to introduce the new
> > alloc_execmem, but just expand kprobe_alloc_insn_page() is reasonable.
> >
> > Mark, can you send this series here, so that others can review/test it?
>
> I've written up a cover letter and sent that out:
>
> https://lore.kernel.org/lkml/20240326163624.3253157-1-mark.rutland@arm.com/
>
> Mark.
Ya, saw it thanks!
BR, Jarkko
next prev parent reply other threads:[~2024-03-26 17:12 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-23 23:29 [PATCH v2] arch/riscv: Enable kprobes when CONFIG_MODULES=n Jarkko Sakkinen
2024-03-23 23:29 ` Jarkko Sakkinen
2024-03-23 23:31 ` Jarkko Sakkinen
2024-03-23 23:31 ` Jarkko Sakkinen
2024-03-24 0:37 ` Randy Dunlap
2024-03-24 0:37 ` Randy Dunlap
2024-03-24 2:09 ` Jarkko Sakkinen
2024-03-24 2:09 ` Jarkko Sakkinen
2024-03-25 2:56 ` Masami Hiramatsu
2024-03-25 2:56 ` Masami Hiramatsu
2024-03-25 3:58 ` Calvin Owens
2024-03-25 3:58 ` Calvin Owens
2024-03-25 18:37 ` Jarkko Sakkinen
2024-03-25 18:37 ` Jarkko Sakkinen
2024-03-25 19:11 ` Jarkko Sakkinen
2024-03-25 19:11 ` Jarkko Sakkinen
2024-03-25 19:16 ` Jarkko Sakkinen
2024-03-25 19:16 ` Jarkko Sakkinen
2024-03-26 14:46 ` Mark Rutland
2024-03-26 14:46 ` Mark Rutland
2024-03-26 15:24 ` Masami Hiramatsu
2024-03-26 15:24 ` Masami Hiramatsu
2024-03-26 16:15 ` Calvin Owens
2024-03-26 16:15 ` Calvin Owens
2024-03-26 16:45 ` Mark Rutland
2024-03-26 16:45 ` Mark Rutland
2024-03-26 17:09 ` Jarkko Sakkinen
2024-03-26 17:09 ` Jarkko Sakkinen
2024-03-26 16:38 ` Mark Rutland
2024-03-26 16:38 ` Mark Rutland
2024-03-26 17:11 ` Jarkko Sakkinen [this message]
2024-03-26 17:11 ` Jarkko Sakkinen
2024-03-26 17:08 ` Jarkko Sakkinen
2024-03-26 17:08 ` Jarkko Sakkinen
2024-03-26 17:00 ` Jarkko Sakkinen
2024-03-26 17:00 ` 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=D03UKZ3OIEXX.2PCKOX8NOLMKT@kernel.org \
--to=jarkko@kernel.org \
--cc=anil.s.keshavamurthy@intel.com \
--cc=aou@eecs.berkeley.edu \
--cc=davem@davemloft.net \
--cc=jcalvinowens@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mhiramat@kernel.org \
--cc=naveen.n.rao@linux.ibm.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@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 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.