Hi Greg / Sasha,
Can we please pull commit c3ed222745d9 ("NFSv4: Fix free of
uninitialized nfs4_label on referral lookup.") into the 5.15.x tree? As
far as I can tell, it should apply cleanly on top of v5.15.75.
Unfortunately, that commit also contains a bug, which requires us to
pull in commit 4f40a5b55446 ("NFSv4: Add an fattr allocation to
_nfs4_discover_trunking()"), which does not apply cleanly. I've
attached a backported version to this email.
I'm seeing the Oops that this commit fixes when I do a NFSv4.2 mount
from a NFS client running a 5.15.75 kernel against a server that has
referrals configured. The reason is that commit d755ad8dc752 ("NFS:
Create a new nfs_alloc_fattr_with_label() function") got pulled into
v5.15.46 apparently as part of a dependency.
Thanks
Trond
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
[email protected]
On Fri, Oct 28, 2022 at 10:58:05PM -0400, Trond Myklebust wrote:
> Hi Greg / Sasha,
>
> Can we please pull commit c3ed222745d9 ("NFSv4: Fix free of
> uninitialized nfs4_label on referral lookup.") into the 5.15.x tree? As
> far as I can tell, it should apply cleanly on top of v5.15.75.
>
> Unfortunately, that commit also contains a bug, which requires us to
> pull in commit 4f40a5b55446 ("NFSv4: Add an fattr allocation to
> _nfs4_discover_trunking()"), which does not apply cleanly. I've
> attached a backported version to this email.
>
> I'm seeing the Oops that this commit fixes when I do a NFSv4.2 mount
> from a NFS client running a 5.15.75 kernel against a server that has
> referrals configured. The reason is that commit d755ad8dc752 ("NFS:
> Create a new nfs_alloc_fattr_with_label() function") got pulled into
> v5.15.46 apparently as part of a dependency.
Both now queued up, thanks.
greg k-h