Re: [PATCH v4] trace: print alloca pointers as actual pointer values

[Kris Van Hees <kris.van.hees@oracle.com>]

On Thu, Sep 18, 2025 at 02:01:48PM +0100, Nick Alcock wrote:
> On 17 Sep 2025, Kris Van Hees spake thusly:
> 
> > On Wed, Sep 17, 2025 at 04:03:33PM +0100, Nick Alcock wrote:
> >> On 16 Sep 2025, Kris Van Hees verbalised:
> >> 
> >> > Because alloca pointers are stored internally as offsets into the
> >> > scratchmem area, they were printed as small integers.  They are
> >> > now printed as actual pointer values into kernel space.
> >> >
> >> > Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
> >> 
> >> So... the change is to generate real pointers for children of alloca
> >> nodes too, and scalarize more aggressively? I don't really see what the
> >> second part has to do with this change (and more specifically why it
> >> didn't cause problems before now).
> >
> > It doesn't cause problems - it is just not what should happen.  Since an alloca
> > pointer is a pointer into kernel space one would expect (and legacy behaviour
> > shows this) that printing it would give us an address value in kernel space.
> > Without this patchm we print the *offset* into the scratch memory area, which
> > is certainly not a valid pointer in kernel space.
> 
> Ooh true!
> 
> > Because of how code generation is done, it unfortunately requires slightly more
> > complex logic to know which values to convert into actual pointer values in
> > order to store them in the trace output buffer.  An extra complication is that,
> > if we are storing the pointer value into the trace event buffer, some versions
> > of the verifier will complain if it is a value that is marked as an address
> > into a BPF map.  That is why it needs to be scalarized.
> 
> Aha, this is saying "if this is not being dereferenced, but instead we
> want its literal value" (e.g. for pointer printing) "scalarize it to
> lose its mapdom". Presumably we know that the result of such a REF
> operation will never be dereferenced, since after scalarization we can't
> dereference it?

Yes.