On Tue, Sep 16, 2025 at 11:01 AM Steven Rostedt <[email protected]> wrote: > > On Tue, 16 Sep 2025 10:57:43 -0700 > Kalesh Singh <[email protected]> wrote: > > > > BTW, why the hash of the mm pointer and not the pointer itself? We save > > > pointers in lots of places, and if it is the pointer, you could use an > > > eprobe to attache to the trace event to dereference its fields. > > > > In Android we try to avoid exposing raw kernel pointers to userspace > > for security reasons: raising /proc/sys/kernel/kptr_restrict to 2 > > immediately after symbols are resolved for necessary telemetry tooling > > during early boot. I believe this is also why rss_stat uses the hash > > and not the raw pointer. > > When it comes to tracing, you already lost. If it goes into the ring buffer > it's a raw pointer. BPF doesn't use the output of the trace event, so you > are exposing nothing from that. It uses the proto directly.
My understanding is that the BPF tracepoint type uses the trace event fields from TP_STRUCT__entry(); whereas the raw tracepoint type has access to the proto arguments. Please CMIW: Isn't what we'd be adding to the trace buffer is the hashed mm_id value? > > Heck, if you enable function tracing, you are exposing every function > address it traces via the raw data output. Right, security doesn't allow compiling CONFIG_FUNCTION_TRACER in Android production kernels. Thanks, Kalesh > > -- Steve
