Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sun, 30 Oct 2022 11:54:39 +0100
From:   Greg KH <gregkh@linuxfoundation.org>
To:     Trond Myklebust <trondmy@kernel.org>
Cc:     stable@vger.kernel.org, linux-nfs@vger.kernel.org,
        Anna Schumaker <Anna.Schumaker@netapp.com>,
        Benjamin Coddington <bcodding@redhat.com>,
        Scott Mayhew <smayhew@redhat.com>
Subject: Re: Stable patch for 5.15.x
Message-ID: <Y15X78hsDYWlSg6y@kroah.com>
References: <ed85737568bcecb5833130f10630c9fedbfa0336.camel@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ed85737568bcecb5833130f10630c9fedbfa0336.camel@kernel.org>
Precedence: bulk

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