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;
Message-ID: <50bd4b4d-3730-4048-fcce-6c79dfe70acf@garloff.de>
Date:   Sun, 20 Feb 2022 23:26:30 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.0
Content-Language: en-US
To:     Olga Kornievskaia <kolga@netapp.com>
From:   Kurt Garloff <kurt@garloff.de>
Subject: 6f283634 / 1976b2b3 breaks NFS (QNAP/Linux kNFSD)
Cc:     linux-nfs@vger.kernel.org,
        Anna Schumaker <anna.schumaker@netapp.com>,
        Trond Myklebust <trond.myklebust@hammerspace.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi Olga,

your upstream commit 1976b2b3, applied to 5.15.24 as 6f283634 breaks NFS
for me.

This is while mounting many NFS filesystems from two NFS servers, one
Qnap (nfs v4.1) and one linux 5.15.16 knfsd (nfs v4.2).

The NFS mounts just would not succeed. This appears to happen to all
Qnap mounts and one of the mounts from the linux knfsd.

I did some bisecting in 5.15.24 ... reverting 6f283634 and subsequent
NFS/sunRPC patches from you and Xiyu, Anna did the trick to recover from
this failure.
To be precise: I reverted 4403233b 4b22aa42 5ca123c9 c5ae18fa be67be6a
6f283634 2df6a47a 0c5d3bfb 3cb5b317 58967a23 bbf647ec and 38ae9387 in
5.15.24. I started reenabling and 2df6aa647a is the last patch that
still results a working NFS for me.

Looking at the culprit patch, I could not immediately see what's wrong
-- so I'll leave it to you. I guess the server does not return
fs_locations in the way it's expected and thus the NFS mount hangs.

I seem not to be the only one, see
https://bbs.archlinux.org/viewtopic.php?pid=2022938
https://bugs.archlinux.org/task/73860

HTH,

-- 
Kurt Garloff <kurt@garloff.de>