Message-ID: <alpine.DEB.2.21.2502041233110.41663@angie.orcam.me.uk>
Date: Tue, 4 Feb 2025 13:42:48 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Ivan Kokshaysky <ink@...een.parts>
cc: Richard Henderson <richard.henderson@...aro.org>, 
    Matt Turner <mattst88@...il.com>, Oleg Nesterov <oleg@...hat.com>, 
    Al Viro <viro@...iv.linux.org.uk>, Arnd Bergmann <arnd@...db.de>, 
    "Paul E. McKenney" <paulmck@...nel.org>, 
    Magnus Lindholm <linmag7@...il.com>, 
    John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>, 
    linux-alpha@...r.kernel.org, linux-kernel@...r.kernel.org, 
    stable@...r.kernel.org
Subject: Re: [PATCH v2 1/4] alpha/uapi: do not expose kernel-only stack frame
 structures

On Mon, 3 Feb 2025, Ivan Kokshaysky wrote:

> >  What do you think about providing arch/alpha/include/asm/bpf_perf_event.h 
> > instead with either a dummy definition of `bpf_user_pt_regs_t', or perhaps 
> > one typedef'd to `struct sigcontext' (as it seems to provide all that's 
> > needed), and then reverting to v1 of arch/alpha/include/uapi/asm/ptrace.h 
> > (and then just copying the contents of arch/alpha/include/asm/ftrace.h 
> > over rather than leaving all the useless CPP stuff in) so that we don't 
> > have useless `struct pt_regs' exported at all?
> 
> Probably that's the right thing to do. However, it implies adding
> 
> #elif defined(__alpha__)
> #include "../../arch/alpha/include/uapi/asm/bpf_perf_event.h"
> 
> in tools/include/uapi/asm/bpf_perf_event.h. I'm afraid that will
> result in too many loosely related changes for this patch series.

 This seems to be the way, but...

> I'm starting to think that the best way for the time being is to keep
> uapi/asm/ptrace.h and apply the fix there (i.e. revert to v0 patch
> posted on linux-alpha). And mention the pt_regs vs uapi issue in the
> commit message, of course, to deal with it later. Your opinion?

 ... I agree.  I find this a pragmatic path of least resistance approach, 
which will keep backports to the minimum and prevent Greg from getting 
rightfully grumpy about it.  We need to get things straight here and BPF 
is the least of a problem.  Let's go for this minimal variant then.

 This will also buy us time to think what the structure format will be 
right for `bpf_user_pt_regs_t' and whether `struct sigcontext' is indeed 
the best fit.  Perhaps we'll want to define an entirely new structure and 
use it also for regset support, which I suppose would be good having, as 
it simplifies handling in debug software.  I'm not sure offhand though, 
which I suppose is a good sign to defer this stuff to a later change.

 NB GCC verification has completed successfully with no regressions (but 
no progressions either; there've been a couple of changes both ways with 
intermittent failures, mostly in Fortran and Go, but none related to this 
patch series), and glibc verification is still running; by the look of the 
progress current ETC is sadly Fri-Sat only.

 The previous glibc run completed in ~25h, but this time the testsuite 
includes recently added 576 extra formatted output `printf' tests, which I 
admit to have committed myself, which owing to their duration I proposed 
to be a part of the extended set, but the community insisted that they be 
a part of the regular set, to widen coverage.  This subset has already 
been running for ~30h and has made it through ~25%.  So there you go.

 For reference the 576 extra test cases complete in ~30m on POWER9 (in a 
serial run; a parallel run is obviously much faster on this 64-way SMP 
system, but infeasible with the UP Alpha over the network, so I need to 
compare apples to apples), which just shows how irrelevant the performance 
of these legacy systems nowadays is and it's just the matter of keeping 
them alive with current software that has been my objective all the time.

  Maciej

Powered by blists - more mailing lists