From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 E9747282F3E for ; Fri, 27 Mar 2026 15:41:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774626117; cv=none; b=WFKENXgA5l+gMSkVDy5Ljl9Z1jISd0FCNmTX91mSipI0+Ho+MiYHGfSCqgm0ZTqxaGWNa+jYN7g3megZ5Mi1wPDtuqVPi0rWQ1jkyHvHxwLRG1r44mcPFULAnzZKPTdo/31RglLQRwQakULZN9ZNV+xEAu9AE0U9YMcKXWhGMlc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774626117; c=relaxed/simple; bh=kfK7x2Fkrq4TYZPqSy32+t+FR/V5lSFExOfHJl0nd7Y=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=hlf/Dx7ETwEk7EHPzqpMWC+dG1lhy9U8//PXZ4U3xj6faj+vEZ1UzQEEhmlUrmEj6iSgryPeNp8E7d8C2I5KXJfa4ByKmacQH6Ko8hEECvdtHkI5g8PZ5Z0ZQJBzpnVBADisgkG3wJwjEHunJPO1GXXCklaq2sJMrQQ0phW2ptE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=ESuwu4pK; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="ESuwu4pK" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=rdvUgQ9yfjKFo7Dvk/5qwdl1so2j7mRNoE84oMfCE4U=; b=ESuwu4pKaSuytAe/KVLpIwMdbG u4BWBU14XN83s81sOXyQUPKU4x/d5E5GPCoRu5FiEO7w1A7EHQIhR6tLSlrIP0HZPd0KuI+8/V8bB ZotVy1Cst21trVtaPF6mgR56kiBt43Y4JjWJi2XfpHmDdv087MD+3KcGrJLDgEQxE95rBjUAzOXYL SmGEtdIQnpksVV9EQ19rrfFidKhZRd2xgZLFL1XlTs6hOow49XA8VR+97/xArhLQ0qu45LC+KzzG/ BuqDTCcJRmU3Y/sCQ74XeadxaOULqvgK1Yu3D5yNdMJ4G4E/PJwIirWhSnQJr0X0+M1k4m69ZddQ6 MFj7vJ3w==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1w69Ja-0000000229O-0IPe; Fri, 27 Mar 2026 15:41:38 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 736B4300E56; Fri, 27 Mar 2026 16:41:36 +0100 (CET) Date: Fri, 27 Mar 2026 16:41:36 +0100 From: Peter Zijlstra To: K Prateek Nayak Cc: John Stultz , LKML , Joel Fernandes , Qais Yousef , Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Valentin Schneider , Steven Rostedt , Ben Segall , Zimuzo Ezeozue , Mel Gorman , Will Deacon , Waiman Long , Boqun Feng , "Paul E. McKenney" , Metin Kaya , Xuewen Yan , Thomas Gleixner , Daniel Lezcano , Suleiman Souhlal , kuyo chang , hupu , kernel-team@android.com Subject: Re: [PATCH v26 00/10] Simple Donor Migration for Proxy Execution Message-ID: <20260327154136.GL3739106@noisy.programming.kicks-ass.net> References: <20260324191337.1841376-1-jstultz@google.com> <36e96f87-a682-436e-aefc-13e2e5810019@amd.com> <20260327114844.GQ2872@noisy.programming.kicks-ass.net> <33e60181-1809-44e1-bc4c-8ac7f79d49d6@amd.com> <20260327152052.GJ3738010@noisy.programming.kicks-ass.net> 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-Disposition: inline In-Reply-To: <20260327152052.GJ3738010@noisy.programming.kicks-ass.net> On Fri, Mar 27, 2026 at 04:20:52PM +0100, Peter Zijlstra wrote: > On Fri, Mar 27, 2026 at 07:03:19PM +0530, K Prateek Nayak wrote: > > > So John originally had that and then I saw Dan's comment in > > cleanup.h that reads: > > > > Lastly, given that the benefit of cleanup helpers is removal of > > "goto", and that the "goto" statement can jump between scopes, the > > expectation is that usage of "goto" and cleanup helpers is never > > mixed in the same function. I.e. for a given routine, convert all > > resources that need a "goto" cleanup to scope-based cleanup, or > > convert none of them. > > > > which can either be interpreted as "Don't do it unless you know what > > you are doing" or "There is at least one compiler that will get a > > goto + cleanup guard wrong" and to err on side of caution, I > > suggested we do break + enums. > > > > If there are no concerns, then the suggested diff is indeed much > > better. > > IIRC the concern was doing partial error handling conversions and > getting it hopelessly wrong. > > And while some GCC's generate wrong code when you goto into a guard, all > clangs ever will error on that, so any such code should not survive the > robots. > > And then there was an issue with computed gotos and asm_goto, but I the > former are exceedingly rare (and again, clang will error IIRC) and the > latter we upped the minimum clang version for. > > Anyway, there is nothing inherently wrong with using goto to exit a > scope and it works well. That is, consider this: void *foo(int bar) { int err; something_1(); err = register_something(..); if (!err) goto unregister; void *obj __free(kfree) = kzalloc_obj(...); .... return_ptr(obj); unregister: undo_something_1(); return ERR_PTR(err); } Looks okay, right? Except note how 'unregister' is inside the scope of @obj. (And this compiles 'fine' with various GCC) This is the kind of errors that you get from partial error handling conversion and is why Dan wrote what he did.