linux-kernel - Re: [PATCH v1 0/4] Fixup NLM and kNFSD file lock callbacks

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: <59A494E0-28C3-4D64-92AB-211CCB2EAD12@oracle.com>
Date: Thu, 12 Sep 2024 19:28:49 +0000
From: Chuck Lever III <chuck.lever@...cle.com>
To: Benjamin Coddington <bcodding@...hat.com>
CC: Christian Brauner <brauner@...nel.org>, Jeff Layton <jlayton@...nel.org>,
        Amir Goldstein <amir73il@...il.com>, Neil Brown <neilb@...e.de>,
        Trond
 Myklebust <trondmy@...nel.org>,
        Anna Schumaker <anna@...nel.org>, Jonathan
 Corbet <corbet@....net>,
        Andreas Gruenbacher <agruenba@...hat.com>,
        Mark
 Fasheh <mark@...heh.com>, Joel Becker <jlbec@...lplan.org>,
        Joseph Qi
	<joseph.qi@...ux.alibaba.com>,
        Al Viro <viro@...iv.linux.org.uk>, Jan Kara
	<jack@...e.cz>,
        Alexander Ahring Oder Aring <aahringo@...hat.com>,
        Linux FS
 Devel <linux-fsdevel@...r.kernel.org>,
        Linux NFS Mailing List
	<linux-nfs@...r.kernel.org>,
        "linux-doc@...r.kernel.org"
	<linux-doc@...r.kernel.org>,
        Linux Kernel Mailing List
	<linux-kernel@...r.kernel.org>,
        "gfs2@...ts.linux.dev"
	<gfs2@...ts.linux.dev>,
        "ocfs2-devel@...ts.linux.dev"
	<ocfs2-devel@...ts.linux.dev>
Subject: Re: [PATCH v1 0/4] Fixup NLM and kNFSD file lock callbacks



> On Sep 12, 2024, at 3:11 PM, Benjamin Coddington <bcodding@...hat.com> wrote:
> 
> On 12 Sep 2024, at 14:17, Chuck Lever III wrote:
> 
>>> On Sep 12, 2024, at 11:06 AM, Benjamin Coddington <bcodding@...hat.com> wrote:
>>> 
>>> On 12 Sep 2024, at 10:01, Chuck Lever III wrote:
>>> 
>>>> For the NFSD and exportfs hunks:
>>>> 
>>>> Acked-by: Chuck Lever <chuck.lever@...cle.com <mailto:chuck.lever@...cle.com>>
>>>> 
>>>> "lockd: introduce safe async lock op" is in v6.10. Does this
>>>> series need to be backported to v6.10.y ? Should the series
>>>> have "Fixes: 2dd10de8e6bc ("lockd: introduce safe async lock
>>>> op")" ?
>>> 
>>> Thanks Chuck! Probably yes, if we want notifications fixed up there.  It
>>> should be sufficient to add this to the signoff area for at least the first
>>> three (and fourth for cleanup):
>>> 
>>> Cc: <stable@...r.kernel.org> # 6.10.x
>> 
>> 2dd10de8e6bc landed in v6.7.
>> 
>> I suppose that since v6.10.y is likely to be closed by
>> the time this series is applied upstream, this tag might
>> be confusing.
>> 
>> Thus Fixes: 2dd10de8e6bc and a plain Cc: stable should
>> work best. Then whichever stable kernel is open when your
>> fixes are merged upstream will automatically get fixed.
> 
> So you want "Fixes: 2dd10de8e6bc" on all these patches?  Fixing the problem
> requires all of the first three patches together.

I didn't indicate which patches to add the tags to, sorry.
3/4 sounds like the right place.

If 4/4 is a clean-up only, no new tags apply to that.


> My worry is that a
> "Fixes" on each implies a complete fix within that patch, so its really not
> appropriate.

Fixes seems to mean different things to different people. It's
OK to drop that tag, but I prefer to see a pointer to the broken
commit. That helps downstream consumers of the commit log to
identify which patches they should be pulling in.


> The stable-kernel-rules.rst documentation says for a series, the Cc: stable
> tag should be suffient to request dependencies within the series, so that's
> why I suggested it for the version you requested.
> 
> What exactly would you like to see?  I am happy to send a 2nd version.

You don't need to send again. Christian can add tags in his repo.

My objection is to the "# 6.10.x" comment -- that doesn't make sense
because for sure, the stable tree will have moved on by the time that
v6.13-rc opens.


--
Chuck Lever