From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 392BA34F474 for ; Thu, 9 Jul 2026 23:57:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783641455; cv=none; b=VapJ/HvWDd4taqKAjcYJDCVedivxy94+Ghn4mPp+qhHCeZl7ad25hh3muQu5nmu3j2zofCYUBgaNEFdKK9ln7PDRW1YDpg6MYN+NGOd/Ts5/uqVxt/H/Ojnq5KhQ0jSXOj8zjOIfMAJ81opa1jsze5oiim1CEYBsF/lYt40jKb8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783641455; c=relaxed/simple; bh=ELWsDBQZyI3WgW2VNxo77U7JzxwiLgpAmW1NVIhD1SE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Iku5BivwzRksSvIbNbFlFmMtXyGITEJM2Uj+2fYJ/gYah+SFgXj6Ff4fncMyt9TQuFsfwoF7sU9b1zLc3Rx1qpp7RohDxVrc0NqDBH2iFWPUxw+I9pxtd5U+KMQrA1Jvd/tZSy+N4sXGjKlOhoX5GLiyvJZjasrPQvwTxFVEc0g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NXB6lh37; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NXB6lh37" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EBD861F00AC4 for ; Thu, 9 Jul 2026 23:57:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783641454; bh=dDriUN3bAW9RG3K1E9Wd3Og99SALKx4oeKBmJfFh2dM=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=NXB6lh37hriqzGE1MuOikAqrJTfgsbW+KL1+XxFa27EI8kV0CjNDEzxNzTqwsp7R/ wqKXg8gsvkOaE6bi21zGByvsU1iQpSjP1jiphgqQJVCMZf8rfriEjHDWr8AXysa7Nv 7PSqbMH+UqdABlC5G0RHI2IPbpuJJq4pj3bCA12w9cXzDvXqoGXcOO8EYl6j+VrPlu a8YSl7EOvOHnLiTgruTofjZxfoZ0yy4FcT42+Sp7zRXGOpruN64AKsHM6+ocWpdOYA +rkwz5xzI5GqspatEK+STDODZAnqNuVt8F1vkSe56Rn9wwYxN+jJWm/R21nRKG8uwt A9XYYW5HUOSSw== Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfauth.phl.internal (Postfix) with ESMTP id 2CA8FF40069; Thu, 9 Jul 2026 19:57:33 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Thu, 09 Jul 2026 19:57:33 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTE1x5IJdoJiyQBiqgz3CUldK4VBprFJeOO3aeQsLfnGA9U5He4PQ6L2ktgEz/pujI V7ixQKf6DUAGQwBr5Bf4hSEqgS80nGKF7XSUG85W/z7ulLnYWBeINmWSZEekhwtPjsmXZD E+MiHQIo8z86cooOMsA5LKsPYJhH4co3HKudbSwsWZYuJ15YGKd93kqkTweoiThD6Z3uaU hQ1tJb2LOrGZVff/grLK2LRKI7nJh/b234ETIqy/0CS2SVS/PpPe6FxvxBleS6Oe2HNF9v TT28Ti9L6E0Mv5S99xwcw1zTa6Y6+7/aBOO1MTiTWwp2t7Xp95snvKsjpsTNQQMU4KjCnJ oNTmxNfdbm34XXun74E9lj/f1yfgETB//M1Jou0j/69shVJXL1E0V4ojtXKacTSEiaql0C fIEPZp53ceHmCUpN5fq71QWQ6jAnO/tV96rnXWBdVvPOfjLvFfADh58x5gQtsX3W7Ghp0I djY79yZmInFqrhe1y2imWS7ds1hPmnx2wRZIu8TAQ/xOLRvDpcp9tZ9o//SWQ/eDulxU8n aY40XGkXZ4/44M4KE7ckahp62LdOqcLu0kXa01KAACFB9pMiMm4Ef4aNO7ZLAA8BRUesyg qXeM1CcCq7yA6QARllpH+/vRURJOfjpJGpmFxZfkOPFx/Ek9je1GB30GKg/w X-ME-Proxy: Feedback-ID: i8dbe485b:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 9 Jul 2026 19:57:32 -0400 (EDT) Date: Thu, 9 Jul 2026 16:57:31 -0700 From: Boqun Feng To: Mathieu Desnoyers Cc: paulmck@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] hazptr: Introduce CONFIG_HAZPTR_DEBUG misuse detection Message-ID: References: <20260709183009.6814-1-mathieu.desnoyers@efficios.com> <20260709183009.6814-2-mathieu.desnoyers@efficios.com> <2402b90a-7f26-4ef8-b5ff-b3c92d1be9d0@paulmck-laptop> <55079bd3-b049-4e0f-9225-ad41e3562500@efficios.com> <222ca62f-a39f-4b6e-b5b4-7e40bb5ceb36@paulmck-laptop> <2c7f97fa-8429-4fbb-bb33-53e015629f01@paulmck-laptop> <2d801522-6a77-47ad-8daf-d23cc85cbb7a@efficios.com> 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: <2d801522-6a77-47ad-8daf-d23cc85cbb7a@efficios.com> On Thu, Jul 09, 2026 at 07:22:18PM -0400, Mathieu Desnoyers wrote: > On 2026-07-09 19:05, Paul E. McKenney wrote: > > On Thu, Jul 09, 2026 at 05:47:00PM -0400, Mathieu Desnoyers wrote: > [...] > > > > + */ > > > > static inline > > > > void hazptr_detach_from_task(struct hazptr_ctx *ctx) > > > > { > > > > @@ -160,17 +178,29 @@ void hazptr_note_context_switch(void) > > > > } > > > > } > > > > -/* > > > > - * hazptr_acquire: Load pointer at address and protect with hazard pointer. > > > > +/** > > > > + * hazptr_acquire - Load pointer at address and protect with hazard pointer. > > > > + * > > > > + * @ctx: The hazard-pointer context to be passed to hazptr_release(). > > > > + * @addr_p: Pointer to the pointer that is to be hazard-pointer protected. > > > > * > > > > * Load @addr_p, and protect the loaded pointer with hazard pointer. > > > > - * When using hazptr_acquire from interrupt handlers, the acquired slots > > > > - * need to be released before returning from the interrupt handler. > > > > > > I see that you removed wording of a major constraint here which allowed > > > use of hazptr locally in a interrupt handler: the need to pair the > > > acquire/release within the handler. > > > > I did indeed remove that wording. You could do something like this: > > > > Task Context IRQ Handler Interrupts Task > > ------------ --------------------------- > > preempt_disable(); > > ihp = __this_cpu_read(irq_hc); ihp = __this_cpu_read(irq_hc); > > p = hazptr_acquire(ihp, &gp); > > lp = xchg(p, NULL); > > if (lp) { > > do_something(lp); > > hazptr_release(ihp, lp); > > } > > preempt_enable(); > > > > If I understand the rules correctly (ha!), this is perfectly legal > > and does not require a hazptr_detach_from_task(). > > > I am concerned about it, because I knowingly just used preempt disable > to protect hazptr_acquire from the scheduler, but not from interrupt > handlers, because it's faster than irqoff. > > I am concerned that this use of hazptr_acquire could confuse the > thread-level hazptr_acquire, let's dig: > > void *hazptr_acquire(struct hazptr_ctx *ctx, void * const *addr_p) > { > struct hazptr_percpu_slots *percpu_slots; > struct hazptr_slot_item *slot_item; > struct hazptr_slot *slot; > void *addr; > > guard(preempt)(); > percpu_slots = this_cpu_ptr(&hazptr_percpu_slots); > slot_item = &percpu_slots->items[0]; > slot = &slot_item->slot; > [...] > > from here -------------------- > if (unlikely(slot->addr)) > return __hazptr_acquire(ctx, addr_p); > WRITE_ONCE(slot->addr, HAZPTR_WILDCARD); /* Store B */ > > /* Memory ordering: Store B before Load A. */ > smp_mb(); > > /* > * Load @addr_p after storing wildcard to the hazard pointer slot. > */ > addr = READ_ONCE(*addr_p); /* Load A */ > > /* > * We don't care about ordering of Store C. It will simply > * replace the wildcard by a more specific address. If addr is > * NULL, we simply store NULL into the slot. > */ > WRITE_ONCE(slot->addr, addr); /* Store C */ > to here ---------------------------- > > I designed hazptr_acquire so a _nested_ interrupt which _brings back_ > the slot addr to its original state will work. Now let's see if > that's still OK if the interrupt handler leaves the slot->addr > populated with an address. > > And no. If the interrupt happens right before "Store B", its > reserved slot address is overwritten by the thread. That's incorrect. > > So as it is today, the irq handler needs to vacate the slot before it > returns, either through a hazptr release or a detach. > > That being said, this is the code as it is today. If someone finds a > clever way to support this use-case and keep it fast and not too complex, > I'm all ears! :) > I don't find this use-case is very useful, but I guess a different set of percpu slot for interrupts can resolve this issue? Regards, Boqun > One possible way to make it work would be to install the HAZPTR_WILDCARD > with a local-cmpxchg expecting a NULL slot->addr. This would close this > race window. But it comes at a non-null overhead price. Another alternative > on x86 would be to use a lock prefixed cmpxchg, which has an implied smp_mb > on success, which may be in the same ballpark as the sequence of WRITE_ONCE+ > explicit smp_mb(). > > Thanks, > > Mathieu > > -- > Mathieu Desnoyers > EfficiOS Inc. > https://www.efficios.com