[DTrace-devel] [PATCH v4] trace: print alloca pointers as actual pointer values

[Nick Alcock]

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 at 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?

-- 
NULL && (void)