From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) (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 D017DC2EF; Fri, 29 Aug 2025 16:49:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=216.40.44.13 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756486151; cv=none; b=l4VaMoAzsdqjZQ3MNfTsBHr1QtTMT0vXzNpY4/Wuj7NqpIhZQG9CR+NvgogR7+P08w5NtXjLp8Hh6YqxAdtqghQ8JkDFyXAHygeHHtYkNFW0or3VbJBI2vFxIlNZuTCuDEBKF0eP7KKd34CmSf4IevfqV5t+zN3djCUdaG1pJ6s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756486151; c=relaxed/simple; bh=dCt30wKbDCQm0FDUqIsPulV9rLmOk3zea0Iq/3zuSvc=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=m3gVqJVDoDswbULCY7NylmFX5C3mgN40cuaXgldHV7AN4EJWPgosBk8Lt5q+Jzn+RVpkHaqvaf4mMjCTvuSX4OGpOzqkyW9vb8f9wVaNwW9+7Ed3OgZ0ORhaMCKktfF5HpUrLKGnasGTHfkxhmXm2gHYTcg03970AigOWzDGnxw= 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.13 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 omf14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 55B7E5B7B5; Fri, 29 Aug 2025 16:49:05 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: rostedt@goodmis.org) by omf14.hostedemail.com (Postfix) with ESMTPA id 0A34A2D; Fri, 29 Aug 2025 16:48:59 +0000 (UTC) Date: Fri, 29 Aug 2025 12:49:22 -0400 From: Steven Rostedt To: Linus Torvalds Cc: Steven Rostedt , Arnaldo Carvalho de Melo , 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: <20250829124922.6826cfe6@gandalf.local.home> In-Reply-To: References: <20250828180300.591225320@kernel.org> <20250828180357.223298134@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> X-Mailer: Claws Mail 3.20.0git84 (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-Rspamd-Queue-Id: 0A34A2D X-Stat-Signature: 6r13j6g1rjbjafbgxk1xyumyxequ7g1i X-Rspamd-Server: rspamout06 X-Session-Marker: 726F737465647440676F6F646D69732E6F7267 X-Session-ID: U2FsdGVkX1+biBp7yBNj+yTwKZOEmDrCWXtoHjQUIWM= X-HE-Tag: 1756486139-237950 X-HE-Meta: U2FsdGVkX1/yXWtVRqXL0E+MDqAeLakcKFAdXF9+Rjg3+CbYP4whJQGI+kzqpWaRJ6ugBxbYai870PuGvFouVBPpPbCVv1VrSkiYgE3uz/IiB1SzzzG0jDxbbEhAvvC2MxfIQ62pKkIVQnsB3a+auZ+h2sG+hVHZI9yxqxc2GBNVKBUKlv5t3N+/HRETswvj6S7vkp0cGPLs7XkwGFQ7v3TdDqrMbhGcR+31BM/qgDBgyrNGCQPpw92S1IjZm2U5ozh/PDc/h3J1N7OGdXusnSt85KCFsAh5TYPOdueERel+uDTCNWZRFf0JsN9SmB7IwcQQBpXa+v5INlGhsIW/dGtGDyj0qkNP4V9MFUQk1H4DMaPCut/Jm715BoxMgDWh On Fri, 29 Aug 2025 09:28:41 -0700 Linus Torvalds wrote: > Don't try to "reuse" hashes. Just treat them as opaque numbers. What do I use to make the hash? One thing this is trying to do is not have to look up the path name for every line of a stack trace. I could just have every instance do the full look up, make a hash from the path name and build id, and pass the hash to the caller. My worry is the time it takes to generate that. Perhaps I could have a hash that maps the pid with the vma->vm_start, and if that's unique, get the path and build-id and create the hash for that and send it back to the user. Save the hash for that mapping in the rhashtable with the pid/vm_start as the key. Then the code that adds the vma, will see if the pid/vma->start exists, if it does, return the hash associated with that, if it does not, add it and trigger the event that a new address has been created. -- Steve