From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 53099346FA9 for ; Thu, 18 Dec 2025 16:12:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766074356; cv=none; b=tbUa0iJNq5sAoex8TD/26TwEW3LfvJ/g2ov94JdO0ixGRA/zY4VvbMzu3XADtemsJbEhmKUvoD3kjsJeyHzWlj5zonhVSaEpuYVpiSI1b6ohOB2tEIbWvuv3V63NDKvpga+FFCiMjiV0oLjbO9AmH8vC7x9tgGEw5L98bBgIdvg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766074356; c=relaxed/simple; bh=hILVjo4AUez19jo2pE3nhHEemYOjjDlMPLwgmLQmJjs=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=lzUa9S8pABik+f7qVtR6NMYgfJqcAnluBgsicK429mtHkrH9qB9vOa9ykiFwY/QIRmrpXRKaiSuhMR+vNJ9khFbYtcVqFDNyHby1ZF6M5A1UfC+4XBpgkATzKc6MczR+TH3xtBr9t+7A/X0ML/29TvcjgP3HgdTno5w0+JaKSm0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=O+qK1H+P; arc=none smtp.client-ip=209.85.221.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="O+qK1H+P" Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-431048c4068so507860f8f.1 for ; Thu, 18 Dec 2025 08:12:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766074353; x=1766679153; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=MWV/1Pvi/LREO51Q4j2bYTzBTPFXYl3JU+RoWaS0a6Q=; b=O+qK1H+PubwCyxIvRMd0jbBNETk5kQv4obd4IYfU/8F5wjf3f49JK6VHTKyHUe5MQW YzFjYxaHtvyeXHl1to9gyREC5fr52SwUg62o2Qf8FIMw5JJK1p2fCF61qCGJYyXj0Bzu n4xQsCWPeHFi7hgvTt32p6rF/Nt9FE9Rw6szs+FOSenC8lt1C6jVyTge5oAB2rmLEwSQ HaBTvFPf5OvvHdOPCQuND9s7XYYb6jkq/bHCCorHy8ANypEjBbiE1PV8OYyTJYov/mf0 1RZC7JkXBDSgGvhZkIb2H1aZkw4X+rdmjCscVPxfOk1DMHbi4HhHXamNORzwnSLzDvbE erQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766074353; x=1766679153; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=MWV/1Pvi/LREO51Q4j2bYTzBTPFXYl3JU+RoWaS0a6Q=; b=t1fSlhq+l00mDXJYAmMrjp7s9bxRJOVR0WLa2GPt1lbFYk16SxqsIeKp1b85QFA7va 9Tu0djEfKc+n1rLddckPANuAzjhjTrkKHGwDnSa186MMsVI8Eq5ieHuVG1K/dvlj6BfA 2xZ3C4aafsCDth5R5lS1QYXj+pgWdBbl6KdSiwqUmfRETOzAAM0MyqBM01ZYYsWnVG21 P8v14g6o6o1LC1BJQVsN1CyOSA3UkSs3z5IJvqYIGmycVf+V8Fo9/A+bZYVQ56eHEJWK kcJUL0KfAQuWPqu/0u5hd83SRqfY25TLd+ZVzi207Fu49rxVy5Wz2KN33uWwtrGskK0l fECA== X-Forwarded-Encrypted: i=1; AJvYcCXWn2u0kYbLeyAiAwf+zoXsokhNWc99z0YFMmKL9gccfcotFLXV2DRZCFKTAc9P5DCEP1W/u0NnVy/UT2Y=@vger.kernel.org X-Gm-Message-State: AOJu0YxyrRaCymsq/VdKb25nYSjwTEDmPsrZaB9L/gV6/3Pg7gKknIB8 PWoizIT1VUrmbfCXTGQ8ImJeNZK5us6Gkz1OfJrCZrrL+gH3enNgOAjn X-Gm-Gg: AY/fxX6lKdbwr2kUnO0uP2Uuvklhb64VMJPg8Qzb6kf2gbPgxGGQDuqEthUE+wLf4Hb 9Ocg05gsXHyi4aFCqKlxkDj2jn9bn54pSu1/RxO6WjODN/gxFG07h0hRXJS3w5o5Hk1FX4HWKCE 34tfw91xbShm0t7Kb0s7zsvhR7eSS7KkVbdEZ68DlTZqv7fetSLijqbioWFjTGCP1FTkmgwt8gm Og40aBnwTafVJoXMZ8L5BTTC7kdNzfs8k0d30bRnSWq85Y9BxVOSTbUErHAfb69ffhev19bw6ag sYDibL91qr2uUVaGgACtLoTEKvjR4jfrnKym49LZpfk0VtfZdvhnEnZaX7+PlbLM2fDmWjCnwOp Cd/ZF+hAmabbfh7QIdB8SwQoboNlmdbHFfOVqt5Q7YkiKYHF3oDQyzSYRyw81VUAP5B50swLvEn DxqCJbegwdGEEMLJTmDaWD57bLgwzuICO3Tbi7Fm6L0LM4fXxSIL9J X-Google-Smtp-Source: AGHT+IF9IwYAhi8+6w3+wxW3M7gEiPdh7t/1OgDyx7SiDKnto2Pyh4pbz29WYRXhF76RKtErZ/OMCg== X-Received: by 2002:a05:6000:18a8:b0:431:de5:93c7 with SMTP id ffacd0b85a97d-4324479535emr4292777f8f.2.1766074352470; Thu, 18 Dec 2025 08:12:32 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432449986f1sm5781954f8f.29.2025.12.18.08.12.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Dec 2025 08:12:32 -0800 (PST) Date: Thu, 18 Dec 2025 16:12:29 +0000 From: David Laight To: Gary Guo Cc: Mathieu Desnoyers , Boqun Feng , Joel Fernandes , "Paul E. McKenney" , linux-kernel@vger.kernel.org, Nicholas Piggin , Michael Ellerman , Greg Kroah-Hartman , Sebastian Andrzej Siewior , Will Deacon , Peter Zijlstra , Alan Stern , John Stultz , Neeraj Upadhyay , Linus Torvalds , Andrew Morton , Frederic Weisbecker , Josh Triplett , Uladzislau Rezki , Steven Rostedt , Lai Jiangshan , Zqiang , Ingo Molnar , Waiman Long , Mark Rutland , Thomas Gleixner , Vlastimil Babka , maged.michael@gmail.com, Mateusz Guzik , Jonas Oberhauser , rcu@vger.kernel.org, linux-mm@kvack.org, lkmm@lists.linux.dev, Nikita Popov , llvm@lists.linux.dev Subject: Re: [RFC PATCH v4 1/4] compiler.h: Introduce ptr_eq() to preserve address dependency Message-ID: <20251218161229.767dafbf@pumpkin> In-Reply-To: <20251218142736.464b7a4a.gary@garyguo.net> References: <20251218014531.3793471-1-mathieu.desnoyers@efficios.com> <20251218014531.3793471-2-mathieu.desnoyers@efficios.com> <20251218090313.33923750@pumpkin> <20251218142736.464b7a4a.gary@garyguo.net> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) 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-Transfer-Encoding: 7bit On Thu, 18 Dec 2025 14:27:36 +0000 Gary Guo wrote: > On Thu, 18 Dec 2025 09:03:13 +0000 > David Laight wrote: > > > On Wed, 17 Dec 2025 20:45:28 -0500 > > Mathieu Desnoyers wrote: > > > > > diff --git a/include/linux/compiler.h b/include/linux/compiler.h > > > index 5b45ea7dff3e..c5ca3b54c112 100644 > > > --- a/include/linux/compiler.h > > > +++ b/include/linux/compiler.h > > > @@ -163,6 +163,69 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val, > > > __asm__ ("" : "=r" (var) : "0" (var)) > > > #endif > > > > > > +/* > > > + * Compare two addresses while preserving the address dependencies for > > > + * later use of the address. It should be used when comparing an address > > > + * returned by rcu_dereference(). > > > + * > > > + * This is needed to prevent the compiler CSE and SSA GVN optimizations > > > + * from using @a (or @b) in places where the source refers to @b (or @a) > > > + * based on the fact that after the comparison, the two are known to be > > > + * equal, which does not preserve address dependencies and allows the > > > + * following misordering speculations: > > > + * > > > + * - If @b is a constant, the compiler can issue the loads which depend > > > + * on @a before loading @a. > > > + * - If @b is a register populated by a prior load, weakly-ordered > > > + * CPUs can speculate loads which depend on @a before loading @a. > > > + * > > > + * The same logic applies with @a and @b swapped. > > > + * > > > + * Return value: true if pointers are equal, false otherwise. > > > + * > > > + * The compiler barrier() is ineffective at fixing this issue. It does > > > + * not prevent the compiler CSE from losing the address dependency: > > > + * > > > + * int fct_2_volatile_barriers(void) > > > + * { > > > + * int *a, *b; > > > + * > > > + * do { > > > + * a = READ_ONCE(p); > > > + * asm volatile ("" : : : "memory"); > > > + * b = READ_ONCE(p); > > > + * } while (a != b); > > > + * asm volatile ("" : : : "memory"); <-- barrier() > > > + * return *b; > > > + * } > > > + * > > > + * With gcc 14.2 (arm64): > > > + * > > > + * fct_2_volatile_barriers: > > > + * adrp x0, .LANCHOR0 > > > + * add x0, x0, :lo12:.LANCHOR0 > > > + * .L2: > > > + * ldr x1, [x0] <-- x1 populated by first load. > > > + * ldr x2, [x0] > > > + * cmp x1, x2 > > > + * bne .L2 > > > + * ldr w0, [x1] <-- x1 is used for access which should depend on b. > > > + * ret > > > + * > > > + * On weakly-ordered architectures, this lets CPU speculation use the > > > + * result from the first load to speculate "ldr w0, [x1]" before > > > + * "ldr x2, [x0]". > > > + * Based on the RCU documentation, the control dependency does not > > > + * prevent the CPU from speculating loads. > > > > I'm not sure that example (of something that doesn't work) is really necessary. > > The simple example of, given: > > return a == b ? *a : 0; > > the generated code might speculatively dereference 'b' (not a) before returning > > zero when the pointers are different. > > I'm not sure I understand what you're saying. > > `b` cannot be speculatively dereferenced by the compiler in code-path > where pointers are different, as the compiler cannot ascertain that it is > valid. The 'validity' doesn't matter for speculative execution. > The speculative execution on the processor side *does not* matter here as > it needs to honour address dependency (unless you're Alpha, which is why we > add a `mb()` in each `READ_ONCE`). There isn't an 'address dependency', that is the problem. The issue is that 'a == b ? *a : 0' and 'a == b ? *b : 0' always evaluate to the same value and the compiler will (effectively) substitute one for the other. But sometimes you really do care which pointer is speculatively dereferenced when the they are different. Memory barriers can only enforce the order of the reads of 'a', 'b' and '*a', they won't change whether the generated code contains '*a' or '*b'. David > > Best, > Gary > > >