On Tue, Sep 16, 2025 at 10:47 AM Steven Rostedt <[email protected]> wrote: > > On Tue, 16 Sep 2025 10:36:57 -0700 > Kalesh Singh <[email protected]> wrote: > > > I completely agree with the principle that static tracepoints > > shouldn't be used as markers if a dynamic probe will suffice. The > > intent here is to avoid introducing overhead in the common case to > > avoid regressing mmap, munmap, and other syscall latencies; while > > still providing observability for the max vma_count exceeded failure > > condition. > > > > The original centralized check (before previous review rounds) was > > indeed in a dedicated function, exceeds_max_map_count(), where a > > kprobe/fprobe could have been easily attached without impacting the > > common path. This was changed due to previous review feedback to the > > capacity based vma_count_remaining() which necessitated the check to > > be done externally by the callers: > > > > https://lore.kernel.org/r/[email protected]/ > > > > Would you be ok with something like: > > > > trace_max_vma_count_exceeded(mm); > > > > TP_STRUCT__entry( > > __field(unsigned int, mm_id) > > __field(unsigned int vma_count) > > ) > > > > mm_id would be the hash of the mm_struct ptr similar to rss_stat and > > the vma_count is the current vma count (some syscalls have different > > requirements on the capacity remaining: mremap requires 6 available > > slots, other syscalls require 1). > > > > 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. Thanks, Kalesh > > -- Steve > > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. >
