Re: [PATCH RFC -rcu/dev] hazptrtorture: Release all deferred hazard pointers before stopping
From: Andrea Parri
Date: Mon Oct 19 2026 - 14:03:14 EST
On Mon, Oct 19, 2026 at 05:22:54PM +0100, Bradley Morgan wrote:
> On 19 October 2026 17:20:03 BST, Andrea Parri <parri.andrea@xxxxxxxxx>
> wrote:
[...]
> >Fixes: f23d7b47ced9 ("hazptrtorture: Add kthread to release deferred hazard pointers")
> >Assisted-by: LLM
>
> Why not put this into a series?
The two patches fix unrelated bugs, touch different files, and apply in
either order, so I posted them separately. But both are for -rcu/dev,
and the test notes in the hazptr patch rely on this one. I'll send the
next version as a two-patch series with this patch first, unless Paul
prefers separate submissions.
[...]
> >+ /*
> >+ * Run until hazptr_torture_cleanup() stops this kthread, not just
> >+ * until torture_must_stop(): the writer can be waiting in ->sync()
> >+ * for a deferred hazard pointer while it is being stopped.
> >+ */
>
> Could this be shorter?
Yes. The comment in hazptr_torture_cleanup() already says why, so this
one can just point there:
/* Keep going until hazptr_torture_cleanup() stops us, see there. */
[...]
> >+ /* The readers have stopped, so nothing new can be deferred. */
> >+ for_each_possible_cpu(cpu)
>
> Is the comment needed? I don't know if it's nessesary.
I'd keep it. A reader can defer after the last pass in the loop, and
kthread_stop() can then end the loop without another pass, so this
pass is needed; the comment says why one pass is enough.
> >+ /*
> >+ * Stop do_pending only after the writer and the readers: the writer
> >+ * may be waiting on hazard pointers that readers deferred.
> >+ */
>
> May we shorten this? Feel free to bikeshed that one.
Sure:
/* The writer may wait on hazard pointers that readers deferred. */
Thanks for the review,
Andrea