linux-kernel - Re: [PATCH] fs/locks: Remove redundant assignment to cmd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20230310085254.counxoqhuv5bmkr5@wittgenstein>
Date:   Fri, 10 Mar 2023 09:52:54 +0100
From:   Christian Brauner <brauner@...nel.org>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     Jeff Layton <jlayton@...nel.org>,
        Jiapeng Chong <jiapeng.chong@...ux.alibaba.com>,
        chuck.lever@...cle.com, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, Abaci Robot <abaci@...ux.alibaba.com>
Subject: Re: [PATCH] fs/locks: Remove redundant assignment to cmd

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@...nel.org>
> > > 
> > > 
> > > 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...