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 E9A171CFBC; Wed, 2 Jul 2025 19:05:48 +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=1751483151; cv=none; b=urSwMPQ+cxzBvwN+QdfVzF/ZANaHkgrf50oEWuwUYcYr/MToGZreajPSb35igcItikYBfMNWjjSF/YN91KYcODvzaKBh4EWsBr/KbmihkXJbzQE93atRulWRrayArQIFRB1QMPZGGqPD4V/79jYU5i4NvWeL4gH6BYWdGVIKIO4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751483151; c=relaxed/simple; bh=c8ok4QMFo7+HEcYyTCRfFIXnQO9UbXOGRRngVgllYuc=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=sQhvWI/Q6BnsslbeRwP2N/5czmxbPSO04MTIXzsEXS/Mahi7SqnSLPSe+lt03H2VsrguPjIJ1ZIhqYYabeHo3JCHfsnql/n/eMquo4HTGNDpJ6cBBvsK2INlHoRH6WZSwh0YzrdsXp6xoJ19hnZ+RQHkjQBWRJ1T82ABickrK+Q= 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 unirelay04.hostedemail.com (Postfix) with ESMTP id 219231A03FE; Wed, 2 Jul 2025 19:05:41 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: rostedt@goodmis.org) by omf03.hostedemail.com (Postfix) with ESMTPA id 657376000F; Wed, 2 Jul 2025 19:05:36 +0000 (UTC) Date: Wed, 2 Jul 2025 15:05:35 -0400 From: Steven Rostedt To: Mathieu Desnoyers Cc: Linus Torvalds , Peter Zijlstra , linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, x86@kernel.org, Masami Hiramatsu , Josh Poimboeuf , Ingo Molnar , Jiri Olsa , Namhyung Kim , Thomas Gleixner , Andrii Nakryiko , Indu Bhagat , "Jose E. Marchesi" , Beau Belgrave , Jens Remus , Andrew Morton , Jens Axboe , Florian Weimer Subject: Re: [PATCH v12 06/14] unwind_user/deferred: Add deferred unwinding interface Message-ID: <20250702150535.7d2596df@batman.local.home> In-Reply-To: <482f6b76-6086-47da-a3cf-d57106bdcb39@efficios.com> References: <20250701005321.942306427@goodmis.org> <20250701005451.571473750@goodmis.org> <20250702163609.GR1613200@noisy.programming.kicks-ass.net> <20250702124216.4668826a@batman.local.home> <20250702132605.6c79c1ec@batman.local.home> <20250702134850.254cec76@batman.local.home> <482f6b76-6086-47da-a3cf-d57106bdcb39@efficios.com> 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: 5mpzyodm5431gmmcpfg86rfgqxrczaqw X-Rspamd-Server: rspamout08 X-Rspamd-Queue-Id: 657376000F X-Session-Marker: 726F737465647440676F6F646D69732E6F7267 X-Session-ID: U2FsdGVkX1/+DRI7nGHYvaDXc4bHmI+irhRtiHvIlS0= X-HE-Tag: 1751483136-110189 X-HE-Meta: U2FsdGVkX18P5Kt6XSMAA0+QuG1ZCGAPnK0nT8CEIBBYVyBEw3fBTeemYEUDHYv2lwZ7I20iXQFQAJsuVVtfAaawqiuJVNsNQGQdvzLeRplwZSn7w01TIv7E6m7rgKrvbVAMpUnYbaIrhXlDLDnmCqXvVB3cGpRgcDLCcWEbFr07cm6G8yikh2hvfY4dLpqx2OIbTmCLkdHeO3o4RUq5ZOjAl/ZA8/1zXvU7pC8fXvVtkufYw7dz1IKIm1QXfGWleOsu7wyqLkdUZBoU0Kztbg0H9oE/7RncmXWkYLIw5tsBvs4myZR3D3TO8pikjPOIL+EpdnhGwFrQfNbjyoPvAkOjb+uUTwQcDxiRWJvPzuHtdNnyzdhqauxqW2pyeSPz On Wed, 2 Jul 2025 14:47:10 -0400 Mathieu Desnoyers wrote: > > AFAIR, one of the goals here is to save the cookie into the trace > to allow trace post-processing to link the event triggering the > unwinding with the deferred unwinding data. > > In order to make the trace analysis results reliable, we'd like > to avoid the following causes of uncertainty, which would > mistakenly cause the post-processing analysis to associate > a stack trace with the wrong event: > > - Thread ID re-use (exit + clone/fork), > - Thread migration, > - Events discarded (e.g. buffer full) causing missing > thread lifetime events or missing unwind-related events. > > Unless I'm missing something, the per-thread counter would have > issues with thread ID re-use during the trace lifetime. But you are missing one more thing that the trace can use, and that's the time sequence. As soon as the same thread has a new id you can assume all the older user space traces are not applicable for any new events for that thread, or any other thread with the same thread ID. Thus the only issue that can truly be a problem is if you have missed events where thread id wraps around. I guess that could be possible if a long running task finally exits and it's thread id is reused immediately. Is that a common occurrence? -- Steve.