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 512FF366DB9 for ; Thu, 9 Jul 2026 03:28:30 +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=1783567711; cv=none; b=gbJNoHO84KNWtI3pTyh5DVdMiJeirT9CAFIDzxEsqIeuX7sRHmpLDoKBzTX03K8dyygCRshwUGSVgGLwqv4Y2D1YFNTRZAgk3+tifPkdoZwDXrEJ0Ii7o9sDGs1IY/aSkmDx2mIyTu3+zSuxhdDc6s/Mh3zPrkqxGz9pMevZ+tE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783567711; c=relaxed/simple; bh=bfP5AwRFR+ZT0c21AmRL15CD4IYBA6vLjgSCo8MinoI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lEA2eozpuxOLndXAOTj9hmO4NUH3VmKq3c5r35YivpBXXS5GhfjoVKc91CTLNFdkMTfMxABx4NGPMX8CCScb+25gj9pFDTNHIUsEqwzBWnsvl2bkbBU7gvv/x58zNKjtRKcVU4YQxTyYaQNa64YefT9odo6nzihqXlQuHAC7yMU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TAtzHmyw; 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="TAtzHmyw" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F020F1F00A3A; Thu, 9 Jul 2026 03:28:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783567710; bh=xRciu6aqk2hT8M2ZhXZzI9iw9mXVUQCubk+mN5dkY5w=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=TAtzHmywlWdJvkBsTAiysCobKwzQ7Z0o8aKvfF11aiuUP7SwpY6KVkSQe+Usu5L1z 3Xf2di/brO+8vp70H7fsDtjxn6Epqu2CkTh6wdlnBjoHDdT3a6+b9Bwj9EAWSjgq11 SbswXLcPx1RA5lGPXxMjjKLZok9fQ7fHNpdvC3d3AXEA9GqgIy6JX3SWtRsGZ6q592 tiMNhv1X2LZhmcUnend+KlASXmwVuF8g7U2yRD3FOTNmqseeaqwWzfM+pADo3RSO16 EB2MWvs0eU3uLGaa83WuCdqWPVwOFRorB+v3WZ6iIv5SAoiNyCEXEYchVvzMXNEbNN NRcRSziBjiHLA== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id BD7B0CE086A; Wed, 8 Jul 2026 20:28:29 -0700 (PDT) Date: Wed, 8 Jul 2026 20:28:29 -0700 From: "Paul E. McKenney" To: Mathieu Desnoyers Cc: Boqun Feng , linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v5 1/2] hazptr: Implement Hazard Pointers Message-ID: <61d3c796-50ef-4239-9a09-e7f950edf404@paulmck-laptop> Reply-To: paulmck@kernel.org References: <0d9f61c1-4a93-4f5a-a703-12ef4f325aa9@efficios.com> <8c12a0bf-68b8-4677-9745-c39b79d1f1c7@paulmck-laptop> <6623407f-8219-4a9a-8c6d-f17e0e73f828@efficios.com> <7741b89e-e36e-4288-ad85-83a413529526@efficios.com> <68bb6ee9-d28b-4a1c-b5fe-578591a5f85d@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: <68bb6ee9-d28b-4a1c-b5fe-578591a5f85d@efficios.com> On Wed, Jul 08, 2026 at 10:45:23PM -0400, Mathieu Desnoyers wrote: > On 2026-07-08 18:55, Paul E. McKenney wrote: > [...] > > OK, I did check, and all of the hazptr_torture_do_pending() function's > > hazard pointers have been passed to hazptr_detach_from_task(). > > > > But sometimes a given hazard pointer might be passed to > > hazptr_detach_from_task() twice, once just before that llist_add(), > > and again if hazptr_torture_reader_tail() decides to release that hazard > > pointer via smp_call_function_single(). > > > > Do I instead need to be careful to avoid detaching a given hazard pointer > > more than once? > That should be OK to call the "detach" more than once, because it checks > if the hazptr is already detached with: > > + if (unlikely(hazptr_slot_is_backup(ctx, slot))) > + return; > > (while under preempt off) > > My concern is about this worker thread: > > static int hazptr_torture_do_pending(void *arg) > { > int cpu = 0; > DEFINE_TORTURE_RANDOM(rand); > > VERBOSE_TOROUT_STRING("hazptr_torture_do_pending task started"); > do { > if (stutter_will_wait()) { > for_each_possible_cpu(cpu) > hazptr_torture_do_one_pending(cpu, &rand); > } else { > cpu = cpumask_next_wrap(cpu, cpu_possible_mask); > hazptr_torture_do_one_pending(cpu, &rand); > } > if (torture_must_stop()) > torture_hrtimeout_ms(kthread_do_pending_ms, USEC_PER_MSEC, &rand); > // Omit stutter_wait() because this function needs to do cleanup. > } while (!torture_must_stop()); > torture_kthread_stopping("hazptr_torture_do_pending"); > return 0; > } > > which as you will notice happily invoke "do_one_pending" on either > all possible cpus or on a next cpu (non-local), which does: > > llhp = per_cpu_ptr(&hazptr_pending, cpu); > llnp = llist_del_all(llhp); Except that every item on every CPU's llist has already been detached, courtesy of the call to hazptr_detach_from_task() from within hazptr_torture_defer() prior to the llist_add(). > if (!llnp) > return; > llist_for_each_entry_safe(hppp, hppp1, llnp, hpp_node) { > hazptr_torture_reader_tail(hppp, trsp); > atomic_long_inc(per_cpu_ptr(&hazptr_torture_releases_undefer, > raw_smp_processor_id())); > kfree(hppp); > } > > And here the reader_tail calls cur_ops->readunlock(hcp, htp); which > does a hazptr_release from the wrong CPU without previously detaching > the hazptr from its associated thread as it should. > > Does this line of thinking make sense ? Huh. There are actually two calls to hazptr_detach_from_task() within hazptr_torture_defer(), one outside of the guard(preempt) and the other within, as in I somehow misapplied your patch. But that would certainly not explain failures in the NOPREEMPT case. Still, time to ditch the call preceding the guard(preempt) and see what happens. Like this: static void hazptr_torture_defer(struct hazptr_pending *hppp, struct torture_random_state *trsp) { int cpu = torture_random(trsp) % nr_cpu_ids; struct llist_head *llhp; guard(preempt)(); hazptr_detach_from_task(&hppp->hpp_hc); cpu = cpumask_next_wrap(cpu, cpu_online_mask); llhp = per_cpu_ptr(&hazptr_pending, cpu); llist_add(&hppp->hpp_node, llhp); atomic_long_inc(per_cpu_ptr(&hazptr_torture_releases_defer, raw_smp_processor_id())); } Except that the same thing happens: [ 8.042111] Oops: general protection fault, probably for non-canonical address 0xdead000000000110: 0000 [#1] SMP PTI [ 8.043367] CPU: 8 UID: 0 PID: 135 Comm: hazptr_torture_ Not tainted 7.1.0-rc4-00080-g3d59e48086a0-dirty #1519 PREEMPT(full) [ 8.044685] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 8.045626] RIP: 0010:hazptr_synchronize_overflow_list+0x3e/0x90 [ 8.046356] Code: 08 48 89 c6 48 85 db 74 54 4d 8b 65 10 eb 1b e8 48 12 fa 00 f3 90 4c 89 ef e8 4e 14 fa 00 48 89 c6 49 8b 45 10 4c 39 e0 75 41 <48> 8b 43 10 4c 89 ef 48 39 e8 74 d9 48 83 f8 01 74 d3 e8 1b 12 fa [ 8.048592] RSP: 0000:ffffb289004f7e60 EFLAGS: 00010086 [ 8.049231] RAX: 0000000000000801 RBX: dead000000000100 RCX: 0000000000000003 [ 8.050136] RDX: 0000000000000001 RSI: 0000000000000286 RDI: ffff9006df3d80e0 [ 8.050993] RBP: ffffffff9b002940 R08: 0000000000122a09 R09: 0000000000000008 [ 8.051836] R10: 0000000000000001 R11: ffff9006c1d1b200 R12: 0000000000000801 [ 8.052889] R13: ffff9006df3d80e0 R14: ffffffff9b002940 R15: ffff9006df3d80c0 [ 8.053746] FS: 0000000000000000(0000) GS:ffff90074448f000(0000) knlGS:0000000000000000 [ 8.054641] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8.055286] CR2: 0000000000000000 CR3: 0000000017830000 CR4: 00000000000006f0 [ 8.056086] Call Trace: [ 8.056378] [ 8.056648] hazptr_synchronize+0xd1/0x130 [ 8.057118] hazptr_torture_writer+0x180/0x3f0 [ 8.057642] ? __pfx_hazptr_torture_writer+0x10/0x10 [ 8.058241] kthread+0xe5/0x120 [ 8.058629] ? __pfx_kthread+0x10/0x10 [ 8.059090] ret_from_fork+0x1bd/0x220 [ 8.059529] ? __pfx_kthread+0x10/0x10 [ 8.059954] ret_from_fork_asm+0x1a/0x30 [ 8.060417] [ 8.060685] Modules linked in: [ 8.061041] ---[ end trace 0000000000000000 ]--- So what am I missing here? Thanx, Paul