linux-kernel - Re: NFS Caching broken in 4.19.37

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <946354d2-7a4d-348e-2c6d-285122503d4a@rothenpieler.org>
Date:   Fri, 26 Feb 2021 16:48:06 +0100
From:   Timo Rothenpieler <timo@...henpieler.org>
To:     Anton Ivanov <anton.ivanov@...bridgegreys.com>,
        Bruce Fields <bfields@...ldses.org>
Cc:     Salvatore Bonaccorso <carnil@...ian.org>,
        Chuck Lever <chuck.lever@...cle.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
        trond.myklebust@...merspace.com, anna.schumaker@...app.com
Subject: Re: NFS Caching broken in 4.19.37

On 26.02.2021 16:40, Anton Ivanov wrote:
> These are two different clients, then what you see is possible on NFS 
> with client side caching. If you have multiple clients reading/writing 
> to the same files you usually need to tune the caching options and/or 
> use locking. I suspect that if you leave it for a while (until the cache 
> expires) it will sort itself out.

Yes, letting the client sit for just a few minutes (without interacting 
with file or directory in question) gets it back in sync with the server.

> In my test-case it is just one client, it missed a file deletion and 
> nothing short of an unmount and remount fixes that. I have waited for 30 
> mins+. It does not seem to refresh or expire. I also see the opposite 
> behavior - the bug shows up on 4.x up to at least 5.4. I do not see it 
> on 5.10.

Yeah, that's indeed different, though still looks somewhat similar.
Makes me wonder if what fixed that issue is what's causing mine.

The primarily broken use case here is users starting their SLURM jobs, 
and then observing them via "tail -f slurm.out", which has worked 
perfectly fine in the past, prior to the update from 5.4 to 5.10.


Download attachment "smime.p7s" of type "application/pkcs7-signature" (4494 bytes)