linux-kernel - Re: [PATCH v8 06/12] unwind_user/sframe: Wire up unwind

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: <20250710113039.04a431d9@batman.local.home>
Date: Thu, 10 Jul 2025 11:30:39 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Jens Remus <jremus@...ux.ibm.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Steven Rostedt
 <rostedt@...nel.org>, linux-kernel@...r.kernel.org,
 linux-trace-kernel@...r.kernel.org, bpf@...r.kernel.org, x86@...nel.org,
 Masami Hiramatsu <mhiramat@...nel.org>, Josh Poimboeuf
 <jpoimboe@...nel.org>, Peter Zijlstra <peterz@...radead.org>, Ingo Molnar
 <mingo@...nel.org>, Jiri Olsa <jolsa@...nel.org>, Namhyung Kim
 <namhyung@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, Andrii
 Nakryiko <andrii@...nel.org>, Indu Bhagat <indu.bhagat@...cle.com>, "Jose
 E. Marchesi" <jemarch@....org>, Beau Belgrave <beaub@...ux.microsoft.com>,
 Linus Torvalds <torvalds@...ux-foundation.org>, Andrew Morton
 <akpm@...ux-foundation.org>, Jens Axboe <axboe@...nel.dk>, Florian Weimer
 <fweimer@...hat.com>, Sam James <sam@...too.org>, Heiko Carstens
 <hca@...ux.ibm.com>, Vasily Gorbik <gor@...ux.ibm.com>
Subject: Re: [PATCH v8 06/12] unwind_user/sframe: Wire up unwind_user to
 sframe

On Wed, 9 Jul 2025 09:58:26 +0200
Jens Remus <jremus@...ux.ibm.com> wrote:

> I think Mathieu has a point, as unwind_user_next() calls the optional
> architecture-specific arch_unwind_user_next() at the end.  The x86
> implementation does state->type specific processing (for
> UNWIND_USER_TYPE_COMPAT_FP).

I'm not too comfortable with the compat patches at this stage. I'm
thinking of separating out the compat patches, and just reject the
deferred unwind if the task is in compat mode (forcing perf or other
tracers to use whatever it uses today).

I'll take Mathieu's patches and merge them with Josh's, but make them a
separate series.

I'm aiming to get the core series into this merge window, and the less
complexity we have, the better. Then everything can be worked on
simultaneously in the next merge window as all the other patches will
not have any dependency on each other. They all have dependency on the
core set.

-- Steve