On Fri, Mar 10, 2023 at 03:40:16AM +0000, Al Viro wrote: > On Thu, Mar 09, 2023 at 06:50:15AM -0500, Jeff Layton wrote: > > On Thu, 2023-03-09 at 10:25 +0100, Christian Brauner wrote: > > > From: Christian Brauner (Microsoft) <brauner@xxxxxxxxxx> > > > > > > > > > On Wed, 08 Mar 2023 15:13:16 +0800, Jiapeng Chong wrote: > > > > Variable 'cmd' set but not used. > > > > > > > > fs/locks.c:2428:3: warning: Value stored to 'cmd' is never read. > > > > > > > > > > > > > > Seems unused for quite a while. I've picked this up since there's a few other > > > trivial fixes I have pending. But I'm happy to drop this if you prefer this > > > goes via the lock tree, Jeff. > > > > > > [1/1] fs/locks: Remove redundant assignment to cmd > > > commit: dc592190a5543c559010e09e8130a1af3f9068d3 > > > > Thanks Christian, > > > > I had already picked it into the locks-next branch (though I didn't get > > a chance to reply and mention that), but I'll drop it and plan to let > > you carry it. > > IMO that's better off in locks tree; unless Christian is planning some > work in the area this cycle (I definitely do not), it's better to have > it in the branch in your git - we can always pull a branch from it if > needed and it's less likely to cause conflicts that way. I have picked up another fix for fs/locks.c for idmapped mounts so I plan on sending that with some other smaller fixes soon. (And that idmapped thing needs to be backported as well.) So if there's non-trivial changes then I fully agree that the locking tree is absolutely the right place. Especially since Jeff will also be able to describe the changes properly and as you said we can always just pull a branch to minimize conflicts. However, when we have simple stuff like this let's just collect it in our for *.misc trees and send it to Linus if we think enough stuff has piled up (2+?). There's no point in holding fixes like this back for a long time. The likelihood of getting merge conflicts for smallish things that we send weekly is rather low judging from my personal experience. Stephen will tell us that quickly anyway. And even if we do get them Linus has said repeatedly that he doesn't mind fixing them so we shouldn't be fuzzed about it. Worst(/best?) case, everyone gets to watch my head being torn off...
