On Fri, 2022-01-07 at 17:51 +0000, Al Viro wrote: > On Fri, Jan 07, 2022 at 12:32:17PM -0500, Brian Foster wrote: > > > > Other problems here (aside of whitespace damage - was that a > > > cut'n'paste of some kind? Looks like 8859-1 NBSP for each > > > leading space...) are > > > > Hmm.. I don't see any whitespace damage, even if I pull the patch > > back > > from the mailing list into my tree..? > > That had occured in Ian's reply, almost certainly. Looks like > whatever > he's using for MUA (Evolution?) is misconfigured into doing > whitespace > damage - his next mail (in utf8, rather than 8859-1) had a scattering > of > U+00A0 in it... Frankly, I'd never seen a decent GUI MUA, so I've no > real experience with that thing and no suggestions on how to fix > that. Yes, your right, I've changed that. I'll play around some more to see if I can verify things are working, mutt should be able to tell me that ... Ian > > > > * misleading name of the new helper - it sounds like > > > "non-RCU side of complete_walk()" and that's not what it does > > > > The intent was the opposite, of course. :P I'm not sure how you > > infer > > the above from _rcu(), but I'll name the helper whatever. > > Suggestions? > > s/non-// in the above (I really had been half-asleep). What I'm > saying is that this name invites an assumption that in RCU case > complete_walk() is equivalent to it. Which is wrong - that's > what complete_walk() does as the first step if it needs to get > out of RCU mode.
