public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
To: Masami Hiramatsu <mhiramat@kernel.org>,
	Jarkko Sakkinen <jarkko@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Jiri Olsa <jolsa@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86/kprobes: Simplify alloc_insn_page() with __vmalloc_node_range
Date: Wed, 14 Apr 2021 15:27:28 +0800	[thread overview]
Message-ID: <20210414152728.418a41fb@xhacker.debian> (raw)
In-Reply-To: <20210413220030.d1cbbc63659dcbc52876696d@kernel.org>

Jisheng Zhang wrote:

> 
> 
> Hi,  

Hi

> 
> On Tue, 13 Apr 2021 18:03:24 +0800
> Jisheng Zhang <Jisheng.Zhang@synaptics.com> wrote:
>   
> > Use the __vmalloc_node_range() to simplify x86's alloc_insn_page() 
> > implementation.  
> 
> Have you checked this is equivarent to the original code on all 
> architecture? IIRC, some arch has a special module_alloc(),  

> Indeed, this isn't equivarent to the original code. FWICT, the differences on x86 are:

> 1) module_alloc() allocates a special vmalloc range
> 2) module_alloc() randomizes the return address via. module_load_offset()
> 3) module_alloc() also supports kasan instrumentation by kasan_module_alloc()

> But I'm not sure whether the above differences are useful for kprobes ss
> insn slot page or not. Take 1) for example, special range in module_alloc
> is due to relative jump limitation, modules need to call kernel .text. does
> kprobes ss ins slot needs this limitation too?

Oops, I found this wonderful thread:
https://www.lkml.org/lkml/2020/7/28/1413

So kprobes ss ins slot page "must be in the range of relative branching only
for x86 and arm"

And Jarkko's "arch/x86: kprobes: Remove MODULES dependency" series look
much better. The last version is v5, I'm not sure whether Jarkko will
send new version to mainline the series.

thanks

  parent reply	other threads:[~2021-04-14  7:27 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-13 10:03 [PATCH] x86/kprobes: Simplify alloc_insn_page() with __vmalloc_node_range Jisheng Zhang
2021-04-13 13:00 ` Masami Hiramatsu
2021-04-14  7:14   ` Jisheng Zhang
2021-04-14  7:27   ` Jisheng Zhang [this message]
2021-04-14  8:22     ` Masami Hiramatsu
2021-04-14 13:13       ` Jarkko Sakkinen
2021-04-14 13:12     ` Jarkko Sakkinen
2021-04-16  7:06       ` Jisheng Zhang
2021-04-16 13:11         ` 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=20210414152728.418a41fb@xhacker.debian \
    --to=jisheng.zhang@synaptics.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=jarkko@kernel.org \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /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