[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181206162857.GA119243@gmail.com>
Date: Thu, 6 Dec 2018 17:28:57 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Nadav Amit <namit@...are.com>
Cc: Ingo Molnar <mingo@...hat.com>,
Steven Rostedt <rostedt@...dmis.org>,
LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
Borislav Petkov <bp@...en8.de>,
Andy Lutomirski <luto@...nel.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>,
Damian Tometzki <linux_dti@...oud.com>,
linux-integrity <linux-integrity@...r.kernel.org>,
LSM List <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH v7 08/14] x86/ftrace: Use text_poke_*() infrastructure
* Nadav Amit <namit@...are.com> wrote:
> > On Dec 4, 2018, at 5:34 PM, Nadav Amit <namit@...are.com> wrote:
> >
> > A following patch is going to make module allocated memory
> > non-executable. This requires to modify ftrace and make the memory
> > executable again after it is configured.
> >
> > In addition, this patch makes ftrace use the general text poking
> > infrastructure instead ftrace's homegrown text patching. This provides
> > the advantages of having slightly "safer" code patching and avoiding
> > races with module removal or other mechanisms that patch the kernel
> > code.
> >
> > Cc: Steven Rostedt <rostedt@...dmis.org>
> > Signed-off-by: Nadav Amit <namit@...are.com>
> > ---
> > arch/x86/kernel/ftrace.c | 74 +++++++++++++---------------------------
> > 1 file changed, 23 insertions(+), 51 deletions(-)
>
> Steven Rostedt pointed that using text_poke() instead of
> probe_kernel_write() would introduce considerable overheads. Running:
>
> # time { echo function > current_tracer; }
>
> takes 0.24s without this patch and 0.7s with. I don’t know whether to
> consider it “so bad”. Obviously we can introduce a batching mechanism and/or
> do some micro-optimization (the latter will not buy us much though).
This should definitely not regress, so can we try the batching approach?
Thanks,
Ingo
Powered by blists - more mailing lists