On Tue, Sep 16, 2025 at 10:47 AM Steven Rostedt rostedt@goodmis.org wrote:
On Tue, 16 Sep 2025 10:36:57 -0700 Kalesh Singh kaleshsingh@google.com 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/20250903232437.1454293-1-kaleshsingh@google.com/
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 kernel-team+unsubscribe@android.com.