lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 9 Jan 2019 11:18:08 +0100
From:   Peter Zijlstra <>
To:     Song Liu <>
Cc:     lkml <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>,
        Kernel Team <>,
        Andi Kleen <>
Subject: Re: [PATCH v5 perf, bpf-next 3/7] perf, bpf: introduce

On Tue, Jan 08, 2019 at 11:54:04PM +0000, Song Liu wrote:

> I think Intel PT case is at instruction granularity (instead of ksymbol
> granularity)? 


> If this is true, modules, BPF, and PT could still share
> the ksymbol record for basic profiling. And advanced use cases like 
> annotation will depend on user space to record BPF_EVENT (and equivalent
> for other cases) timely. But at least, the ksymbol is already there. 
> Does this make sense?  

I'm not sure I follow; the idea was that on ksym events we copy out the
instructions using kcore. The ksym event already has addr+len.

All we need is some means of ensuring the symbol is still there by the
time we see the event and do the copy.

I think we can do this with a new ioctl() on /proc/kcore itself:

 - when we have kcore open, we queue all text-free operations on list-1.

 - when we close kcore, we drain all (text-free) list-* and perform the
   pending frees immediately.

 - on ioctl(KCORE_QC) we perform the pending free of list-3 and advance
   list-2 to list-3 and list-1 to list-2.

Perf would then open kcore at the start of the record, make a complete
copy and keep the FD open. At the end of every buffer process, we issue
KCORE_QC IFF we observed a ksym unreg in that buffer.

We use 3 lists instead of 2 to guard against races, if there was a
reg+unreg en-route but not yet visible in the buffer, then we don't want
that free to be processed. The next buffer (read) will have the event(s)
and all should be well.

Powered by blists - more mailing lists