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: <20250709102904.18cfd2ff@batman.local.home>
Date: Wed, 9 Jul 2025 10:29:04 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: Jens Remus <jremus@...ux.ibm.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 10:10:30 -0400
Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:

> Indeed it's only kernel internal API, but this is API that will be
> expected by each architecture supporting unwind_user. Changing
> this later on will cause a lot of friction and cross-architecture churn
> compared to doing it right in the first place.

The changes you are suggesting is added info if an architecture needs
it. That is easy to do. All you need is to add an extra field in the
state structure and the architectures that need it can use it, and the
rest can ignore it.

Again, I'm not worried about it. If you want to send me a patch, feel
free, but I'm not doing this extra work, until I see a real problem.

-- Steve.