From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) (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 E80701E3DF8; Sat, 30 Aug 2025 18:31:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=216.40.44.10 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756578693; cv=none; b=nylP80Ya1NdDnz6poTY6LMwffSL2Y3aYwAVApbgTZIWK9dFUcIN1UyOIhdhdvJdf1lK4UmuH6vkrvixHS1ezkJ0AEtM7XTuWFnN9ETbhG08AROtdlNgeGOnu62SAfSV59zad5LsRZQn7Nxnms3eCPPbCQ9C6rWV2Rj5ujtr/iJg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756578693; c=relaxed/simple; bh=h9s6lq5iWu0Uxgc5pGQipjyw7vKquKkQMSJ+qcO28b8=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=gwM8ijtNLVZna2SvA38VPx6hl65GbRdTfCD7hknSdb6Z/yfhtRjPWioO5bjmZT4RXZcd55n7XYVtKy8qdmQ1Js2xef+30ndc/XGWkCvrBsJlplTjWw3OBqnxRwUv+8asaDS/58VFm33mVZVutlUPOFJl8DekfBPjS/42fBk7pAg= 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.10 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 omf03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id DF1DA5792F; Sat, 30 Aug 2025 18:31:21 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: rostedt@goodmis.org) by omf03.hostedemail.com (Postfix) with ESMTPA id 2630A6000C; Sat, 30 Aug 2025 18:31:16 +0000 (UTC) Date: Sat, 30 Aug 2025 14:31:14 -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: <20250830143114.395ed246@batman.local.home> In-Reply-To: References: <20250828180300.591225320@kernel.org> <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> <20250829141142.3ffc8111@gandalf.local.home> <20250829171855.64f2cbfc@gandalf.local.home> <20250829190935.7e014820@gandalf.local.home> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-trace-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-Stat-Signature: dkx6cr1863tdyr5dwpt5ckwrppidbxnn X-Rspamd-Server: rspamout07 X-Rspamd-Queue-Id: 2630A6000C X-Session-Marker: 726F737465647440676F6F646D69732E6F7267 X-Session-ID: U2FsdGVkX19WYX6tr/gPCLPBNV9cVUMslGrPAuQfGGI= X-HE-Tag: 1756578676-55030 X-HE-Meta: U2FsdGVkX19XhVDsGgxPqnETmIKyPhWYVZOiIMrpYo75HbTYXBUckcEq91+PibmjNrdUChgztxVBITq5gIDJiZsVzxyHOW1c7Ao38pMYqbOe1gEd6w1TxA44k5zT/CBlImW+GYdOaF54NiWP8v4wLnyB0hInm1XncgCpNCSC9jiNoZ8bbM4qdbGme1iOEMuAb90vDxpAx/T5BI3RNrBLrcmwqccBSJ4Knm/S7fRoS6PEnrfTj7sZmgLgkT211zZpvd2z8MLvcd2gguBeQsYB3uj38ntcaO+Zkc3+GF35KgBDlBZjQigyb4V7nJF1nXCTz2SS+HUWNLN7JDKMv7MlR/pMB/hSHcX7kq17uiEvTyT4XIw+flvkXltxUreC0sQe On Fri, 29 Aug 2025 17:45:39 -0700 Linus Torvalds wrote: > But what it does *NOT* need is munmap() events. > > What it does *NOT* need is translating each hash value for each entry > by the kernel, when whoever treads the file can just remember and > re-create it in user space. If we are going to rely on mmap, then we might as well get rid of the vma_lookup() altogether. The mmap event will have the mapping of the file to the actual virtual address. If we add a tracepoint at mmap that records the path and the address as well as the permissions of the mapping, then the tracer could then trace only those addresses that are executable. To handle missed events, on start of tracing, trigger the mmap event for every currently running tasks for their executable sections, and that will allow the tracer to see where the files are mapped. After that, the stack traces can go back to just showing the virtual addresses of the user space stack without doing anything else. Let the trace map the tasks memory to all the mmaps that happened and translate it that way. The downside is that there may be a lot of information to record. But the tracer could choose which task maps to trace via filters and if it's tracing all tasks, it just needs to make sure its buffer is big enough. -- Steve