linux-kernel - Re: About patch NFS: Fix O_DIRECT accounting of number of bytes read/written

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 for Android: free password hash cracker in your pocket

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

Message-ID: <ee3fc922be7850532a6625a09569b74e24d75b15.camel@hammerspace.com>
Date:   Wed, 16 Oct 2019 03:09:29 +0000
From:   Trond Myklebust <trondmy@...merspace.com>
To:     "suyj.fnst@...fujitsu.com" <suyj.fnst@...fujitsu.com>
CC:     "linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: About patch NFS: Fix O_DIRECT accounting of number of bytes
 read/written

On Wed, 2019-10-16 at 01:00 +0000, Su, Yanjun wrote:
> Hi trond,
> Because My mail system cant receive nfs mail list’s mails, I reply
> your patch here.
> I have some question for the patch.
> 
> > No. Basic O_DIRECT does not guarantee atomicity of requests, which
> > is
> > why we do not have generic locking at the VFS level when reading
> > and
> > writing. The only guarantee being offered is that O_DIRECT and
> > buffered
> > writes do not collide.
> Do you mean other fs also cant guarantee atomicity of O_DIRECT
> request or just nfs?
> 
> > IOW: I think the basic premise for this test is just broken (as I
> > commented in the patch series I sent) because it is assuming a
> > behaviour that is simply not guaranteed.
> So the generic/465 of xfstests can’t apply to nfs for now, am I
> right?

As far as I can see, it is does not belong in the 'generic' category at
all.

> 
> > BTW: note that buffered writes have the same property. They are
> > ordered
> > when being written into the page cache, meaning that reads on the
> > same
> > client will see no holes, however if you try to read from another
> > client, then you will see the same behaviour, with temporary holes
> > magically appearing in the file.
> As you say, nfs buffered write also has the hole problem with
> multiple r/w on different clients.
> I want to know if the problem exists in other local fs such as
> xfs,ext4?
> 

There is no VFS locking that enforces any serialisation for O_DIRECT.
So unless the filesystem implements its own serialisation (which xfs
does) then there is no guarantee.

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@...merspace.com