From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) (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 BBEAD2737FD; Thu, 10 Jul 2025 15:30:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=216.40.44.17 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752161458; cv=none; b=p+l/HwbAzKqc/ZeAKABkpgyY8Onk75uvz0NFzYwQFvxFWZNLQihinDrERMwtc4+HprAp8S/l6H+uhqJIqbOZiQDJKqs8fAZ32Awy13T2bn1vDaz1KajW/aGPEmfYTSncIYEdmPze0nbrUZrqWR/sytbAOFXLEe78B6sV2sO1aA4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752161458; c=relaxed/simple; bh=eNnzmd/JEya04OP8Mh/whLJnjLXMDy1YqvTFq/nfITc=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=KdwJN9+8h/gRsf9bw2CoIBf4SRFEoe4dgiyrLF3aneET8PznKgYsrkJBx46zlvS6m1e19xLPCcZXCM0txAOVd4hfsPripgHxwPY8o7n0dy703VN3XqU9Vr4nFayBINKPoi7wn2AGTSb2DuedCv4XbtIfQPYCuDEc1z6jM2Sagzs= 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.17 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 omf15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id E214D129B3A; Thu, 10 Jul 2025 15:30:45 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: rostedt@goodmis.org) by omf15.hostedemail.com (Postfix) with ESMTPA id BF99617; Thu, 10 Jul 2025 15:30:40 +0000 (UTC) Date: Thu, 10 Jul 2025 11:30:39 -0400 From: Steven Rostedt To: Jens Remus Cc: Mathieu Desnoyers , Steven Rostedt , linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, x86@kernel.org, Masami Hiramatsu , Josh Poimboeuf , Peter Zijlstra , Ingo Molnar , Jiri Olsa , Namhyung Kim , Thomas Gleixner , Andrii Nakryiko , Indu Bhagat , "Jose E. Marchesi" , Beau Belgrave , Linus Torvalds , Andrew Morton , Jens Axboe , Florian Weimer , Sam James , Heiko Carstens , Vasily Gorbik Subject: Re: [PATCH v8 06/12] unwind_user/sframe: Wire up unwind_user to sframe Message-ID: <20250710113039.04a431d9@batman.local.home> In-Reply-To: References: <20250708021115.894007410@kernel.org> <20250708021159.386608979@kernel.org> <20250708161124.23d775f4@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: qfn11of8yy6w4krucobyhddby5pbo7ja X-Rspamd-Server: rspamout08 X-Rspamd-Queue-Id: BF99617 X-Session-Marker: 726F737465647440676F6F646D69732E6F7267 X-Session-ID: U2FsdGVkX1/2XbU+LTT2smNLeoAUds5lmeztJ568iEw= X-HE-Tag: 1752161440-812969 X-HE-Meta: U2FsdGVkX18qTiNldn/rZBbbsD1cKNTotV3OEputbyHklyK3GRwYIGzQzpnKY/cLIpLnAPD6Q9/WihCefUuNf/aGVQUEmwfkm6uqm3OoFWYd4MGAlz5ty9ZJuylAJMuGskKCUJvCQvyDY2gsllVjjaemdOCqbzEBRkXtQz1zWIQ16+Z/27QHfesEuG8dMa5NFIaV2ntvnuSDeIOrUlYMuuiTJnKvoNSqG06BZAdi31QazUMgTNCIBzku1ztcHQvQDX6tMJxtLCG0jMLZY3gx7zjTOv9mlxUb9WRuKIDK6bX3ClktZZHrN9OwNTd86MzI/EDn0l+rJOv0dnxsWstUMj+3FvrCt3lp On Wed, 9 Jul 2025 09:58:26 +0200 Jens Remus wrote: > I think Mathieu has a point, as unwind_user_next() calls the optional > architecture-specific arch_unwind_user_next() at the end. The x86 > implementation does state->type specific processing (for > UNWIND_USER_TYPE_COMPAT_FP). I'm not too comfortable with the compat patches at this stage. I'm thinking of separating out the compat patches, and just reject the deferred unwind if the task is in compat mode (forcing perf or other tracers to use whatever it uses today). I'll take Mathieu's patches and merge them with Josh's, but make them a separate series. I'm aiming to get the core series into this merge window, and the less complexity we have, the better. Then everything can be worked on simultaneously in the next merge window as all the other patches will not have any dependency on each other. They all have dependency on the core set. -- Steve