linux-kernel - Re: [PATCH v4 1/1] perf/kprobe: maxactive for fd-based kprobe

lists.openwall.net		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 linux-hardening linux-cve-announce 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]

Message-ID: <YtgMKDgNLnMIkHLI@worktop.programming.kicks-ass.net>
Date:   Wed, 20 Jul 2022 16:07:36 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Dmitry Dolgov <9erthalion6@...il.com>
Cc:     linux-kernel@...r.kernel.org, bpf@...r.kernel.org,
        songliubraving@...com, rostedt@...dmis.org, mingo@...hat.com,
        mhiramat@...nel.org, alexei.starovoitov@...il.com
Subject: Re: [PATCH v4 1/1] perf/kprobe: maxactive for fd-based kprobe

On Fri, Jul 15, 2022 at 11:52:36AM +0200, Dmitry Dolgov wrote:
> > On Thu, Jul 14, 2022 at 09:57:48PM +0200, Peter Zijlstra wrote:
> > On Thu, Jul 14, 2022 at 09:34:03PM +0200, Dmitrii Dolgov wrote:
> > > From: Song Liu <songliubraving@...com>
> > >
> > > Enable specifying maxactive for fd based kretprobe. This will be useful
> > > for tracing tools like bcc and bpftrace (see for example discussion [1]).
> > > Use highest 4 bit (bit 59-63) to allow specifying maxactive by log2.
> >
> > What's maxactive? This doesn't really tell me much.
> 
> Maxactive allows specifying how many instances of the specified function
> can be probed simultaneously, it would indeed make sense to mention this
> in the commit message.

But why would we need per-fd configurability? Isn't a global sysctrl
good enough?

> > Why are the top 4 bits the best to use?
> 
> This format exists mostly on proposal rights. Per previous discussions,
> 4 bits seem to be enough to cover reasonable range of maxactive values.
> Top bits seems like a natural place to me following perf_probe_config
> enum, but I would love to hear if there are any alternative suggestions?

I think the precedent you're referring to is UPROBE_REF_CTR, which is a
full 32bit. That lives in the upper half of the word because bit0 is
already taken and using the upper half makes the thing naturally
aligned.

If we only need 4 bits it's must simpler to simply stick it at the
bottom or so.

> 
> > > Note that changes in rethook implementation may render maxactive
> > > obsolete.
> >
> > Then why bother creating an ABI for it?
> 
> If I got Masami right, those potential changes mentioned above are only
> on the planning stage. At the same time the issue is annoying enough to
> try to solve it already now.

Masami; how hard would it be to do this? Creating an ABI for something
that's already planned to be removed seems unfortunate, it would be best
to see if we can find someone to accelerate this work.