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: <B51C0776-FF71-4A11-8813-57DD396AF68B@redhat.com>
Date: Thu, 12 Sep 2024 15:11:55 -0400
From: Benjamin Coddington <bcodding@...hat.com>
To: Chuck Lever III <chuck.lever@...cle.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 Kernel Mailing List <linux-kernel@...r.kernel.org>,
 gfs2@...ts.linux.dev, ocfs2-devel@...ts.linux.dev
Subject: Re: [PATCH v1 0/4] Fixup NLM and kNFSD file lock callbacks

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.  My worry is that a
"Fixes" on each implies a complete fix within that patch, so its really not
appropriate.

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.

Ben


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ