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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20220724103651.qhtqgzhfx2ftrpcx@erthalion.local>
Date:   Sun, 24 Jul 2022 12:36:51 +0200
From:   Dmitry Dolgov <9erthalion6@...il.com>
To:     Peter Zijlstra <peterz@...radead.org>
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 Wed, Jul 20, 2022 at 04:07:36PM +0200, Peter Zijlstra wrote:
> > > > 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?

Do you mean there is an existing sysctl option for maxactive, or propose
to introduce one? A global option indeed could be fine for my use case I
guess, although there will be a bit of awkward asymmetry -- one can
specify maxactive via text-based API, but not via perf API.

> > > 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.

Yes, you're right, I was referring to UPROBE_REF_CTR. Makes sense to me,
will change the location.