From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id AEF11CDD1CE for ; Fri, 27 Sep 2024 17:17:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0182C6B00B3; Fri, 27 Sep 2024 13:17:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EE30F6B0118; Fri, 27 Sep 2024 13:17:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D83CB6B00C5; Fri, 27 Sep 2024 13:17:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id B60D16B0118 for ; Fri, 27 Sep 2024 13:17:28 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 1399A1A1265 for ; Fri, 27 Sep 2024 17:17:28 +0000 (UTC) X-FDA: 82611174576.15.C046227 Received: from smtpout.efficios.com (smtpout.efficios.com [167.114.26.122]) by imf24.hostedemail.com (Postfix) with ESMTP id 06FCB18000D for ; Fri, 27 Sep 2024 17:17:25 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=efficios.com header.s=smtpout1 header.b="fjx/aFpp"; spf=pass (imf24.hostedemail.com: domain of mathieu.desnoyers@efficios.com designates 167.114.26.122 as permitted sender) smtp.mailfrom=mathieu.desnoyers@efficios.com; dmarc=pass (policy=none) header.from=efficios.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727457409; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=u1OyGR4DhmCN6k7R0oa7yYA6KNO3K9cS5ifqm/NWIhE=; b=LfEV4n1mDGWIiyB8InfDaupKzFb+WHcnnHTeWgzP0ZCbsu879mIbpoQv5Sh2jOk5hi/WiG +TK1cL1hJAz/RNzroAw8/ppdvDoYt+PSiQBlrwcIoV6PiodP/3+G84z6mwVBSBZ5plodRa KzFMHmnjWVhMkSkogrJ/f5Tlj/lxpSk= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=efficios.com header.s=smtpout1 header.b="fjx/aFpp"; spf=pass (imf24.hostedemail.com: domain of mathieu.desnoyers@efficios.com designates 167.114.26.122 as permitted sender) smtp.mailfrom=mathieu.desnoyers@efficios.com; dmarc=pass (policy=none) header.from=efficios.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727457409; a=rsa-sha256; cv=none; b=1GC4e9TeO9bG8Uv5O7JnN9Rfd2JwkCKf0cxJGWuLLtDeGUHFn9XB79lwtV+qxM+FIItH46 aK5JPmLV3BaLHO9yGk3LZfvWCl5jIOqr7Fp9oJOsVBO7OTU1RUSY0qplwIClPYbs5T62T7 JANpTKj1gTZ5R7/Kd7txGWhOLOw6/F4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=efficios.com; s=smtpout1; t=1727457444; bh=9Pl6bXAtXjhyfWlziszA39Bp4r22pKu2aujIPaMnnVc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=fjx/aFppwNW8w8vhvtDpCiF5R+jIMtcUVs/0TycezS6PfO7g4K17zRV7o0UkWamr5 vgPyDSJnVIn2UCvDU7GH9MdXEUArA53xCUsR3ANZsu9Ipfta/PZy+hupewNXXldJkr Q/TeKkoxv9WjYUMwAfQsHAbf0HnJLAL3bhvSYy4J1ONG99q0n5qXN2kRU4LbH5D8tG a3jE4NxHTySOJ1JuT13o5SYdYdzOcmoGTJ6O/gZeDlq7LoZ7trHhOfE2qUFq+13inS zFbDBuv9sKLqosN++v9s0Rp7DxzDKCtmuKlGVjHzhcCzlSMNXwsyQ0f/hgkfZDzCo5 ObmckiIHVU8+Q== Received: from [IPV6:2606:6d00:100:4000:cacb:9855:de1f:ded2] (unknown [IPv6:2606:6d00:100:4000:cacb:9855:de1f:ded2]) by smtpout.efficios.com (Postfix) with ESMTPSA id 4XFcbS44H9z1Q6v; Fri, 27 Sep 2024 13:17:24 -0400 (EDT) Message-ID: <7e1c8a5e-c110-414c-8fb2-022eacc2bd4a@efficios.com> Date: Fri, 27 Sep 2024 13:15:19 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 1/4] hazptr: Add initial implementation of hazard pointers To: Linus Torvalds , Boqun Feng Cc: Jonas Oberhauser , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-mm@kvack.org, lkmm@lists.linux.dev, "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Josh Triplett , "Uladzislau Rezki (Sony)" , rostedt , Lai Jiangshan , Zqiang , Peter Zijlstra , Ingo Molnar , Will Deacon , Waiman Long , Mark Rutland , Thomas Gleixner , Kent Overstreet , Vlastimil Babka , maged.michael@gmail.com, Neeraj Upadhyay , Greg Kroah-Hartman References: <4167e6f5-4ff9-4aaa-915e-c1e692ac785a@efficios.com> <48992c9f-6c61-4716-977c-66e946adb399@efficios.com> <2b2aea37-06fe-40cb-8458-9408406ebda6@efficios.com> <55633835-242c-4d7f-875b-24b16f17939c@huaweicloud.com> <54487a36-f74c-46c3-aed7-fc86eaaa9ca2@huaweicloud.com> <0b262fe5-2fc5-478d-bf66-f208723238d5@efficios.com> From: Mathieu Desnoyers Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Stat-Signature: 5tu64a7uciro5peeq9bhaztaoru3eikp X-Rspamd-Queue-Id: 06FCB18000D X-Rspamd-Server: rspam11 X-HE-Tag: 1727457445-883716 X-HE-Meta: U2FsdGVkX1+JzbvvypiDnnDT5OfKJamA5MqXMxn6lPELLprLMDI6ZG2oRpQVg721CtgZtNCFm2/awYXEqe3jjpLGo5+0xFrwgF+qdJ3ud7or3Q9upe1muKPLIgXmuVZ1lrMvpJw7gytjdpvGzxWRpSIL07TUuZdVZ4H9nWeGkUap3CnKDFxwJ9pcSGLplRKyiyCujN35Vy30v8ujblhZ5f0/EkBJzPL8f2LDgcUXq90WfIcgCXWqQ1eQVGmjIcwDfcVGFcj1pveMbKvieoym8EaK+6Hi0HN4Sty4uQ9Tvfx8DD+Uv1RTyP6gLcvhsknabIBZw1WSCDQA6zWATNVINXzGNEQX1XLeT/BNTUujJENN1WpPgtXHxEXXB/FBMW7XLZ6fYxTVBRgFtxfJrI4d5X9HsHLp+LDIXncZTOQAaSquqYWwXK3X3bgEZ6lOiEunMp8/pXlXXl3zD2HyGyy7WWvL7xSU5H8CAizvvopQyJPeg3iHttdE5rHTwRHfMkIT9zqWm5GUN0TPfTHd9ifbjKqVytlrdSFAmlpCsPhENLhl8a9qYH9QifcUqHFdiDB6lmXTmo9ev9yO/3fPZJKTOmAXoiH8o4iSQLGI9HgaIC4BW/JVJWdVQN9GJoZ4ztvJPKx/3lwgbIAyE+zVdptoEiaaCga7zcOxpGA6Tn8KcaaEskDiZUh+NqQDxt7C0DON+EZkH2iHFqDwrRbeKR7aTrsT9G1B7+6oh+bLcnH+D6B36Y7dGP0IxViXjP9VBMj837395YvEFwcVJiEZbNIBH7Xr/eIs0tFkw0XaziMS4jEmikGoEfSbGPzdqMchG1EhiwSVlr3R+NLMouE8uXz5nmVjdlWSSiioIIvWwlQpK93yHywzEUWqQP5MHB9EIMUvQ7/uFP5fuJ1ssPf7UQ8xijOb1tpYokzqAw7rbgTaJTqAVsq2AIjB87oiLbutL+pMxmz1+9eREWYImuw/TwQ Iys4I/zh KbiIN3IiSqAmNxFOto9cBeWJEE6H5GF4Bj8VXmszrNf5gW9BaV2w4qCI85y0nLyXBeFy3AAI1LjUJi9bHhjEn8RFx0YhzddcKsUNPjHqB9nAti3p3lKcEwThtRWMjucsZFqvdYw+q0S5V5yqLDsBV/S7Ww2Ikog+ofrfPkXdp5DFKwY8Ypn+ZO4LRjyCEqiUmiMtKMypsU9Jle5XRpkBYG2Pmg+nCfTQSMQ1zyk0q7eyGak9Wg+UAtL2EI1YbY9BQrK7ddNwbqooC0sLV//aFBH4XpwZiFKty6I4fQ5ewV+uOPVTOQXtgUBsebSk4hrv7xFIIk5DYe3i3f5C1X8z5tNVihOipILUOn2Aea3QQ625wYDCPTupsYwAUAhdMh0kMGmNue8x69RUdVY7gsU1zcnyedXZZuzWv8zsD2pUjdNP6rkGoezOKpfceR1HfKpkbj6fPrK50ZI/bOUdW796NSvQxgI1TIFcLQLPB X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 2024-09-27 18:44, Linus Torvalds wrote: > On Thu, 26 Sept 2024 at 18:38, Boqun Feng wrote: >> >> Note that ADDRESS_EQ() only hide first parameter, so this should be ADDRESS_EQ(b, a). > > Yeah, please stop making things unnecessarily complicated. > > Just use a barrier(). Please. Stop these stupid games until you can > show why it matters. The barrier() is ineffective at fixing the 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"); <----- where you would like your 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. There are a few ways to fix this: - Compile everything with -fno-cse-follow-jumps. - Make the compiler unaware of the relationship between the address equality and address-dependent use of b. This can be done either using ADDRESS_EQ() or asm goto. I prefer ADDRESS_EQ() because it is arch-agnostic. I don't care that it adds one more register movement instruction. > And by "why it matters" I mean "major difference in code generation", > not some "it uses one more register and has to spill" kind of small > detail. Why it matters is because gcc generates code that does not preserve address dependency of the second READ_ONCE(). > At this point, I'm not even convinced the whole hazard pointer > approach makes sense. And you're not helping by making it more > complicated than it needs to be. I'm preparing a small series that aims to show how a minimal hazard pointer implementation can help improve common scenarios: - Guarantee object existence on pointer dereference to increment a reference count: - replace locking used for that purpose in drivers (e.g. usb), - replace RCU + inc_not_zero pattern, - rtmutex: I suspect we can improve situations where locks need to be taken in reverse dependency chain order by guaranteeing existence of first and second locks in traversal order, allowing them to be locked in the correct order (which is reverse from traversal order) rather than try-lock+retry on nested lock. This can be done with hazard pointers without requiring object reclaim to be delayed by an RCU grace period. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com