From: David Woodhouse <dwmw2@infradead.org>
To: paulmck@kernel.org
Cc: rcu@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-team@meta.com, rostedt@goodmis.org
Subject: Re: [PATCH v2 04/21] srcutree: Add an atomic Tree SRCU
Date: Mon, 12 Oct 2026 13:49:15 +0100 [thread overview]
Message-ID: <3aba8068a1424c91c81ec35b2ea6dfaa28161fb1.camel@infradead.org> (raw)
In-Reply-To: <d1539cc5-0ff3-400e-a487-eedd942cf6f5@paulmck-laptop>
[-- Attachment #1: Type: text/plain, Size: 2910 bytes --]
On Thu, 2026-10-08 at 08:51 -0700, Paul E. McKenney wrote:
> On Thu, Oct 08, 2026 at 09:39:29AM +0200, David Woodhouse wrote:
> > If it isn't already too late (i.e. if it hasn't already made it to a
> > tree where changing commit-ids is painful), please could you change my
> > attribution to use the dwmw@amazon.co.uk email address for both Co-
> > developed-by: and Signed-off-by: tags? I'm fairly sure you made up that
> > Signed-off-by: with the infradead address, which is naughty of you :)
>
> Indeed, I would have grabbed the first email I could find from you and
> applied the From: field from that email, as opposed to finding the exact
> email containing your prototype of the patch and then locating and copying
> out the Signed-off-by. And if I were to happen to find the email that
> I am now replying to, I would once again get infradead rather than amazon.
>
> Apologies, but life was flowing fast, and it probably will be from time
> to time in the future. So thank you for checking and please continue
> to do so.
Yeah, no problem. I do try to be good and give a SoB even when I'm
throwing out a snippet of code that's *directional* and doesn't even
compile. Mostly because I hate it when I'm on the receiving end of
such, *use* the snippet I'm given, and then have to chase for a real
SoB from a drive-by co-author.
In this case I think it was
https://lore.kernel.org/all/fb87f673bf290cad133d113dbb0750a7752b9d30.camel@infradead.org/
which did have them both on the patch itself.
> > I tell people you should only ever cut-and-paste SoB lines, because
> > that way the magic is intact. So here are the two you need for patches
> > 4 and 5 of this series:
> >
> > Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> > Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
>
> Thank you again, and I have this note to myself for my next rebase:
>
> a5130cf7b27f ("srcutree: Add an atomic Tree SRCU")
> 85d5f89bdc42 ("srcutiny: Add an atomic Tiny SRCU")
> Co-developed-by: David Woodhouse <dwmw@amazon.co.uk>
> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
>
> Does that cover it?
Looks good, thanks!
> And while we are discussing, how goes the use case?
It's working well. Torture tests and Sashiko reviews have tweaked it a
bit, and found one issue that was already there in the upstream kernel.
https://git.infradead.org/?p=users/dwmw2/linux.git;a=shortlog;h=refs/heads/gpc-srcu-v2
I've also backported it to a production tree (albeit using non-atomic
SRCU there for now) and it works there too.
I still have to put my own eyes on some of those latest tweaks (and
probably rewrite/decimate the commit messages). Will do so once the
dust settles on the atomic-srcu work and I can rebase on top of a
stable commit. But there's no rush; this whole thing has been on the
back burner for a long time.
Thanks.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 6179 bytes --]
next prev parent reply other threads:[~2026-10-12 12:49 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-07 20:59 [PATCH v2 0/21] Add atomic SRCU &c for v7.4 Paul E. McKenney
2026-10-07 20:59 ` [PATCH v2 01/21] srcutiny: Make a Tiny SRCU grace period imply an RCU grace period Paul E. McKenney
2026-10-07 20:59 ` [PATCH v2 02/21] srcutree: Suppress srcu_advance_state() mutex_lock in atomic Paul E. McKenney
2026-10-07 20:59 ` [PATCH v2 03/21] srcutree: Suppress to-big transition for atomic SRCU Paul E. McKenney
2026-10-07 20:59 ` [PATCH v2 04/21] srcutree: Add an atomic Tree SRCU Paul E. McKenney
2026-10-08 7:39 ` David Woodhouse
2026-10-08 15:51 ` Paul E. McKenney
2026-10-12 12:49 ` David Woodhouse [this message]
2026-10-07 20:59 ` [PATCH v2 05/21] srcutiny: Add an atomic Tiny SRCU Paul E. McKenney
2026-10-07 20:59 ` [PATCH v2 06/21] rcutorture: Add support for testing synchronize_srcu_atomic() Paul E. McKenney
2026-10-07 20:59 ` [PATCH v2 07/21] srcutree: Disable preemption across synchronize_srcu_atomic() Paul E. McKenney
2026-10-07 20:59 ` [PATCH v2 08/21] srcu: Use IRQ_WORK_INIT_HARD for srcu's irq_work Paul E. McKenney
2026-10-07 20:59 ` [PATCH v2 09/21] srcutree: Warn if Tiny SRCU readers are preempted Paul E. McKenney
2026-10-07 20:59 ` [PATCH v2 10/21] srcutree: Explicitly note DEFINE_SRCU() needs for srcu_barrier() Paul E. McKenney
2026-10-07 20:59 ` [PATCH v2 11/21] rcutorture: Add atomic-SRCU support to torture.sh Paul E. McKenney
2026-10-07 20:59 ` [PATCH v2 12/21] srcutree: Add reader-free fastpath to synchronize_srcu_atomic() Paul E. McKenney
2026-10-07 20:59 ` [PATCH v2 13/21] srcutree: Skip callback scheduling for atomic SRCU grace periods Paul E. McKenney
2026-10-07 20:59 ` [PATCH v2 14/21] srcutree: Remove srcu_barrier() sleep for atomic SRCU Paul E. McKenney
2026-10-07 20:59 ` [PATCH v2 15/21] srcu: Restrict atomic-SRCU non_block annotation to task context Paul E. McKenney
2026-10-07 20:59 ` [PATCH v2 16/21] srcutree: Make init_srcu_struct_atomic() prevent transition to big Paul E. McKenney
2026-10-07 20:59 ` [PATCH v2 17/21] srcutree: Don't transition atomic SRCU to big in srcu_gp_end() Paul E. McKenney
2026-10-07 20:59 ` [PATCH v2 18/21] srcutree: Skip torture to-big transition for atomic SRCU Paul E. McKenney
2026-10-07 20:59 ` [PATCH v2 19/21] srcutree: Add lockdep and early-boot checks to synchronize_srcu_atomic() Paul E. McKenney
2026-10-07 20:59 ` [PATCH v2 20/21] srcutiny: " Paul E. McKenney
2026-10-07 20:59 ` [PATCH v2 21/21] srcutree: Preserve IRQ state in synchronize_srcu_atomic() callchain Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3aba8068a1424c91c81ec35b2ea6dfaa28161fb1.camel@infradead.org \
--to=dwmw2@infradead.org \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®