From:   Benjamin Coddington <bcodding@redhat.com>
To:     Chuck Lever III <chuck.lever@oracle.com>
Cc:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        Trond Myklebust <trond.myklebust@hammerspace.com>
Subject: Re: git regression failures with v6.2-rc NFS client
Date:   Wed, 01 Feb 2023 10:53:37 -0500
Message-ID: <F1833EA0-263F-46DF-8001-747A871E5757@redhat.com>
In-Reply-To: <5FF4061F-108C-4555-A32D-DDBFA80EE4E7@redhat.com>
References: <9A4A5673-691D-47EC-BC44-C43BE7E50A48@oracle.com>
 <D0404F55-2692-4DB6-8DD6-CAC004331AC1@redhat.com>
 <5FF4061F-108C-4555-A32D-DDBFA80EE4E7@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On 1 Feb 2023, at 9:10, Benjamin Coddington wrote:
>
> Working on a fix..

=2E. actually, I have no idea how to fix this - if tmpfs is going to modi=
fy
the position of its dentries, I can't think of a way for the client to lo=
op
through getdents() and remove every file reliably.

The patch you bisected into just makes this happen on directories with 18=

entries instead of 127 which can be verified by changing COUNT in the
reproducer.

As Trond pointed out in:
https://lore.kernel.org/all/eb2a551096bb3537a9de7091d203e0cbff8dc6be.came=
l@hammerspace.com/

    POSIX states very explicitly that if you're making changes to the
    directory after the call to opendir() or rewinddir(), then the
    behaviour w.r.t. whether that file appears in the readdir() call is
    unspecified. See
    https://pubs.opengroup.org/onlinepubs/9699919799/functions/readdir.ht=
ml

The issue here is not quite the same though, we unlink the first batch of=

entries, then do a second getdents(), which returns zero entries even tho=
ugh
some still exist.  I don't think POSIX talks about this case directly.

I guess the question now is if we need to drop the "ls -l" improvement
because after it we are going to see this behavior on directories with >1=
7
entiries instead of >127 entries.

It should be possible to make tmpfs (and friends) generate reliable cooki=
es
by doing something like hashing out the cursor->d_child into the cookie
space.. (waving hands)

Ben