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 [email protected] 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/[email protected]/ 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 <[email protected]> > > Signed-off-by: David Woodhouse <[email protected]> > > 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 <[email protected]> > Signed-off-by: David Woodhouse <[email protected]> > > 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.
smime.p7s
Description: S/MIME cryptographic signature
