From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B86CF209F5A; Fri, 29 Aug 2025 18:11:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=216.40.44.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756491090; cv=none; b=fxbbe9rRJvBwQaaaXkcOkhgzTaMyr3Vo4CD0F3GT3ykpNtBjpBoCb/axRImFBRKAomxgXZkdxvXYabgvCnyPvC1IfO6ui1ShPHlwUanpisfKKCHsEBE5FQLE/valNi/rOBX28l39FMwYiLFqEUD7rURSiAw9ArIKb4UPtSZQQyc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756491090; c=relaxed/simple; bh=aTMz6QKRB8sX8tPG29W2hZGoOIxk1SKdVcBnuPoHXgI=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=MONg9NU8BtjDX4WR0jsNAdsg3RyvS2ZUamtFXMkqyU1kfUPuxPO/apoyewgTv1Zx56OGmzTI2Cl4OXvZLVLcrUMGm93an7DExGFIep3hFeNv7zLL5I5yn+jJgCG5GuatUjMGyFZA+leFhYOpwMQaGsFMM+Kxo4yDt8HcqUPKjBU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org; spf=pass smtp.mailfrom=goodmis.org; arc=none smtp.client-ip=216.40.44.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=goodmis.org Received: from omf01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 8842513A96D; Fri, 29 Aug 2025 18:11:24 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: rostedt@goodmis.org) by omf01.hostedemail.com (Postfix) with ESMTPA id 76F576000F; Fri, 29 Aug 2025 18:11:19 +0000 (UTC) Date: Fri, 29 Aug 2025 14:11:42 -0400 From: Steven Rostedt To: Linus Torvalds Cc: Arnaldo Carvalho de Melo , Steven Rostedt , linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, x86@kernel.org, Masami Hiramatsu , Mathieu Desnoyers , Josh Poimboeuf , Peter Zijlstra , Ingo Molnar , Jiri Olsa , Arnaldo Carvalho de Melo , Namhyung Kim , Thomas Gleixner , Andrii Nakryiko , Indu Bhagat , "Jose E. Marchesi" , Beau Belgrave , Jens Remus , Andrew Morton , Florian Weimer , Sam James , Kees Cook , "Carlos O'Donell" Subject: Re: [PATCH v6 5/6] tracing: Show inode and device major:minor in deferred user space stacktrace Message-ID: <20250829141142.3ffc8111@gandalf.local.home> In-Reply-To: References: <20250828180300.591225320@kernel.org> <20250828161718.77cb6e61@batman.local.home> <20250828164819.51e300ec@batman.local.home> <20250828171748.07681a63@batman.local.home> <20250829110639.1cfc5dcc@gandalf.local.home> <20250829121900.0e79673c@gandalf.local.home> <20250829124922.6826cfe6@gandalf.local.home> <6B146FF6-B84E-40A2-A4FA-ABD5576BF463@gmail.com> X-Mailer: Claws Mail 3.20.0git84 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 76F576000F X-Stat-Signature: 7g4cgxahc864hsc8pkq97bkmqmtg4bh9 X-Rspamd-Server: rspamout02 X-Session-Marker: 726F737465647440676F6F646D69732E6F7267 X-Session-ID: U2FsdGVkX19VoDMXkG87cPh4pXXWRE7cb0ZOSUa8IWQ= X-HE-Tag: 1756491079-407632 X-HE-Meta: U2FsdGVkX183qe31Z0942gMaignr2sHg+i2BLFlOyekXIPjeyCIt7jp8b81kngcQMUgvle8KM99ttt01QkLid3YpfHt3Qs8U2Vixniwd7aQHFt6BgE3JVVcAdgbAoEGPr008+Vl7hHHuE0Crwsn5Zf7H1mOHut/052ABwhZBXAbOSczNE7+aVRTKH8Ors48Y4NEq6fpd398417dlcXb9rDw5cYA/qFgUdZ+lAv9Uok1R1Hrosqk1UF73ndYYLZoJlmdjxsbTfXEy+s0HmRP6gGn0F4UolHdcqNsRde/qfzFRYy3/vLGkGPt556WrMs9gZknbesNA/t7oDx/YuPUKh039jkwT4tN7V+3L40IWcR90wAudf+7RCk5hPeHBSbw8Qxo1G4si1Vv5GEPVktpabQ== On Fri, 29 Aug 2025 10:33:38 -0700 Linus Torvalds wrote: > On Fri, 29 Aug 2025 at 10:18, Arnaldo Carvalho de Melo > wrote: > > > > As long as we don't lose those mmap events due to memory pressure/lost > > events and we have timestamps to order it all before lookups, yeah > > should work. > > The main reason to lose mmap events that I can see is that you start > tracing in the middle of running something (for example, tracing > systemd or some other "started at boot" thing). Note, for on-demand tracing, the applications are already running before the tracing starts. That is actually the common case. Yes, people do often "enabled tracing, run my code, stop tracing", but most of the use cases I deal with, it's (we are noticing something in the field, start tracing, issue gets hit, stop tracing), where the applications we are monitoring are already running when the tracing started. Just tracing the mmap when it happens will not be useful for us. Not to mention, in the future, this will also have to work with JIT. I was thinking of using 64 bit hashes in the stack trace, where the top bits are reserved for context (is this a file, or something dynamically created). > > Then you'd not have any record of an actual mmap at all because it > happened before you started tracing, even if there is no memory > pressure or other thing going on. > > That is not necessarily a show-stopper: you could have some fairly > simple count for "how many times have I seen this hash", and add a > "mmap reminder" event (which would just be the exact same thing as the > regular mmap event). I thought about clearing the file cache periodically, if for any other reason, but for dropped events where the mapping is lost. This is why I'm looking at clearing on "unmap". Yes, we don't care about unmap, but as soon as an unmap happens if that value gets used again then we know it's a new mapping. That is, dropped the hashes out of the file cache when they are no longer around. The idea is this (pseudo code): user_stack_trace() { foreach vma in each stack frame: key = hash(vma->vm_file); if (!lookup(key)) { trace_file_map(key, generate_path(vma), generate_buildid(vma)); add_into_hash(key); } } } On unmmaping: key = hash(vma->vm_file); remove_from_hash(key); Now if a new mmap happens where the vma->vm_file is reused, the lookup(key) will return false again and the file_map event will get triggered again. We don't need to look at the mmap() calls, as those new mappings may never end up in a user stack trace, and writing them out will just waste space in the ring buffer. -- Steve