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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230310034016.GH3390869@ZenIV>
Date:   Fri, 10 Mar 2023 03:40:16 +0000
From:   Al Viro <viro@...iv.linux.org.uk>
To:     Jeff Layton <jlayton@...nel.org>
Cc:     Christian Brauner <brauner@...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 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.