lkml.org 
[lkml]   [2019]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH] perf, bpf: Retain kernel executable code in memory to aid Intel PT tracing
On Fri, Feb 08, 2019 at 10:53:41AM +0200, Adrian Hunter wrote:
> On 7/02/19 10:02 PM, Peter Zijlstra wrote:
> > On Thu, Feb 07, 2019 at 01:19:01PM +0200, Adrian Hunter wrote:
> >> Subject to memory pressure and other limits, retain executable code, such
> >> as JIT-compiled bpf, in memory instead of freeing it immediately it is no
> >> longer needed for execution.
> >>
> >> While perf is primarily aimed at statistical analysis, tools like Intel
> >> PT can aim to provide a trace of exactly what happened. As such, corner
> >> cases that can be overlooked statistically need to be addressed. For
> >> example, there is a gap where JIT-compiled bpf can be freed from memory
> >> before a tracer has a chance to read it out through the bpf syscall.
> >> While that can be ignored statistically, it contributes to a death by
> >> 1000 cuts for tracers attempting to assemble exactly what happened. This is
> >> a bit gratuitous given that retaining the executable code is relatively
> >> simple, and the amount of memory involved relatively small. The retained
> >> executable code is then available in memory images such as /proc/kcore.
> >>
> >> This facility could perhaps be extended also to init sections.
> >>
> >> Note that this patch is compile tested only and, at present, is missing
> >> the ability to retain symbols.
> >
> > You don't need the symbols; you already have them through
> > PERF_RECORD_KSYMBOL.
>
> And you intend to use that for module loading/unloading also?
>
> >
> > Also; afaict this patch guarantees exactly nothing. It registers a
> > shrinker which will (given enough memory pressure) happily free your
> > text before we get around to copying it out.
>
> No, there is a minimum size (default 0) which is not subject to the shrinker.
>
> >
> > Did you read this proposal?
>
> Please cc me on anything affecting Intel PT decoding.
>
> >
> > https://lkml.kernel.org/r/20190109101808.GG1900@hirez.programming.kicks-ass.net
> >
> > (also: s/KCORE_QC/KCORE_QS/ for quiescent state)
> >
> > That would create an RCU like interface to /proc/kcore and give you the
> > guarantees you need, while also allowing the memory to get freed once
> > you've obtained a copy.
>
> So, open /proc/kcore and it pins all executable code in memory?
>
> Do you intend to extend that to module / module init unloads?

I didn't intent to write it at all; but yes the intend was for this to
apply to all executable maps. Modules, BPF, ftrace, everything.

\
 
 \ /
  Last update: 2019-02-08 10:13    [W:0.925 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site