linux-kernel - Re: [PATCH v4 17/39] unwind_user/sframe: Add support for reading .sframe headers

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: <20250205005710.35wdzvobyhm6zyda@jpoimboe>
Date: Tue, 4 Feb 2025 16:57:10 -0800
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Indu Bhagat <indu.bhagat@...cle.com>
Cc: Andrii Nakryiko <andrii.nakryiko@...il.com>, x86@...nel.org,
	Peter Zijlstra <peterz@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...nel.org>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	linux-kernel@...r.kernel.org, Mark Rutland <mark.rutland@....com>,
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
	Jiri Olsa <jolsa@...nel.org>, Namhyung Kim <namhyung@...nel.org>,
	Ian Rogers <irogers@...gle.com>,
	Adrian Hunter <adrian.hunter@...el.com>,
	linux-perf-users@...r.kernel.org, Mark Brown <broonie@...nel.org>,
	linux-toolchains@...r.kernel.org, Jordan Rome <jordalgo@...a.com>,
	Sam James <sam@...too.org>, linux-trace-kernel@...r.kernel.org,
	Jens Remus <jremus@...ux.ibm.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Florian Weimer <fweimer@...hat.com>,
	Andy Lutomirski <luto@...nel.org>,
	Masami Hiramatsu <mhiramat@...nel.org>,
	Weinan Liu <wnliu@...gle.com>
Subject: Re: [PATCH v4 17/39] unwind_user/sframe: Add support for reading
 .sframe headers

On Thu, Jan 30, 2025 at 01:39:52PM -0800, Indu Bhagat wrote:
> On 1/28/25 6:02 PM, Josh Poimboeuf wrote:
> > However, if we're going that route, we might want to even consider a
> > completely revamped data layout.  For example:
> > 
> > One insight is that the vast majority of (cfa, fp, ra) tuples aren't
> > unique.  They could be deduped by storing the unique tuples in a
> > standalone 'fre_data' array which is referenced by another
> > address-specific array.
> > 
> >    struct fre_data {
> > 	s8|s16|s32 cfa, fp, ra;
> > 	u8 info;
> >    };
> >    struct fre_data fre_data[num_fre_data];
> > 
> 
> We had the same observation at the time of SFrame V1.  And this method of
> compaction (deduped tuples) was brain-stormed a bit.  Back then, the costs
> were thought to be:
>   - more work at build time.
>   - an additional data access once the FRE is found (as there is
> indirection).
> 
> So it was really compaction at the costs above.  We did steer towards
> simplicity and the SFrame FRE is what it stands today.
> 
> The difference in the pros and cons now from then:
>   - pros: helps mitigate unaligned accesses
>   - cons: interferes slightly with the design goal of efficient addition and
> removal of stack trace information per function for JIT. Think "removal" as
> the set of actions necessary for addressing fragmentation in SFrame section
> data in JIT usecase.

If fre_data[] is allowed to have duplicates then the deduping could be
optional.

> > Note FDEs aren't even needed here as the unwinder doesn't need to know
> > when a function begins/ends.  The only info needed by the unwinder is
> > just the fre_data struct.  So a simple binary search of fres[] is all
> > that's really needed.
> 
> Splitting out information (start_address) to an FDE (as done in V1/V2) has
> the benefit that a job like relocating information is proportional to
> O(NumFunctions).
> 
> In the case above, IIUC, where the proposal puts start_address in the FRE,
> these costs will be (much) higher.

I'm not sure I follow, is this referring to the link-time work of
sorting things?

> In addition, not being able to identify stack trace information per function
> will affect the JIT usecase.  We need to able to mark stack trace
> information stale for functions in JIT environment.

Maybe, though it's hard to really say how any of these changes would
affect JIT without knowing what those interfaces are going to look like.

-- 
Josh