linux-kernel - Re: [PATCH 2/2] trace/kprobe: Remove limit on kretprobe maxactive

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <20210616112711.ce318fc66b389038203331d1@kernel.org>
Date:   Wed, 16 Jun 2021 11:27:11 +0900
From:   Masami Hiramatsu <mhiramat@...nel.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     "Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>,
        Anton Blanchard <anton@...abs.org>,
        linux-kernel@...r.kernel.org, Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH 2/2] trace/kprobe: Remove limit on kretprobe maxactive

On Tue, 15 Jun 2021 21:03:51 -0400
Steven Rostedt <rostedt@...dmis.org> wrote:

> On Wed, 16 Jun 2021 09:46:22 +0900
> Masami Hiramatsu <mhiramat@...nel.org> wrote:
> 
> > To avoid such trouble, I had set the 4096 limitation for the maxactive
> > parameter. Of course 4096 may not enough for some use-cases. I'm welcome
> > to expand it (e.g. 32k, isn't it enough?), but removing the limitation
> > may cause OOM trouble easily.
> 
> What if you just made the max as 10 * number of possible cpus, or 4096,
> which ever is greater? Why would a user need more?

It could be. But actually, that is not correct number because the
number of instances depends on the number of processes and the possiblity
of recursive. Thus the huge system which runs more than 64k processes,
may need more than that.

> I'd still like to get a wrapper around function graph tracing so that
> kretprobes could use it. I think that would get rid of the requirement
> of maxactive, because isn't that just used to have a way to know the
> original return value?

Hmm, yes, on some arch, it can be done. But on other arch we still need
current implementation for generic solution.
What I need is not fully wrapped by the function graph, but just share
the per-task (software) shadow stack.

Thank you,

-- 
Masami Hiramatsu <mhiramat@...nel.org>