On 22 Sep 2020, at 10:43, Anna Schumaker wrote:
On Tue, Sep 22, 2020 at 10:31 AM Anna Schumaker
<anna.schumaker@xxxxxxxxxx> wrote:
On Tue, Sep 22, 2020 at 10:22 AM Benjamin Coddington
<bcodding@xxxxxxxxxx> wrote:
On 22 Sep 2020, at 10:03, Anna Schumaker wrote:
Hi Ben,
Once I apply this patch I have trouble with generic/478 doing lock
reclaim:
[ 937.460505] run fstests generic/478 at 2020-09-22 09:59:14
[ 937.607990] NFS: __nfs4_reclaim_open_state: Lock reclaim failed!
And the test just hangs until I kill it.
Just thought you should know!
Yes, thanks! I'm not seeing that.. I've tested these based on
v5.8.4, I'll
rebase and check again. I see a wirecap of generic/478 is only 515K
on my
system, would you be willing to share a capture of your test
failing?
I have it based on v5.9-rc6 (plus the patches I have queued up for
v5.10), so there definitely could be a difference there! I'm using a
stock kernel on my server, though :)
I can definitely get you a packet trace once I re-apply the patch and
rerun the test.
Here's the packet trace, I reran the test with just this patch applied
on top of v5.9-rc6 so it's not interacting with something else in my
tree. Looks like it's ending up in an NFS4ERR_OLD_STATEID loop.
Thanks very much!
Did you see this failure with all three patches applied, or just with
the
first patch?
I see the client get two OPEN responses, but then is sending
TEST_STATEID
with the first seqid. Seems like seqid 2 is getting lost. I wonder if
we're making a bad assumption that NFS_OPEN_STATE can only be toggled
under
the so_lock.
Ben
