[Bug 259071] Read past EoF in NFS client and fusefs

From: <bugzilla-noreply_at_freebsd.org>
Date: Sun, 31 Oct 2021 00:12:22 UTC

--- Comment #11 from commit-hook@FreeBSD.org ---
A commit in branch main references this bug:


commit 50dcff0816e5e4aa94f51ce27da5121e49902996
Author:     Rick Macklem <rmacklem@FreeBSD.org>
AuthorDate: 2021-10-31 00:08:28 +0000
Commit:     Rick Macklem <rmacklem@FreeBSD.org>
CommitDate: 2021-10-31 00:08:28 +0000

    nfscl: Add setting n_localmodtime to the Write RPC code

    Similar to commit 2be417843a, I believe there could be a race between
    the NFS client VOP_LOOKUP() and file Writing that could result in stale
    file attributes being loaded into the NFS vnode by VOP_LOOKUP().

    I have not been able to reproduce a failure due to this race, but
    I believe that there are two possibilities:

    The Lookup RPC happens while VOP_WRITE() is being executed and loads
    stale file attributes after VOP_WRITE() returns when it has already
    completed the Write/Commit RPC(s).
    --> For this case, setting the local modify timestamp at the end of
      VOP_WRITE() should ensure that stale file attributes are not loaded.

    The Lookup RPC occurs after VOP_WRITE() has returned, while
    asynchronous Write/Commit RPCs are in progress and then is
    blocked by the vnode held by VOP_OPEN/VOP_CLOSE/VOP_FSYNC which
    will flush writes via ncl_flush() or ncl_vinvalbuf(), clearing the
    NMODIFIED flag (which indicates Writes-in-progress). The VOP_LOOKUP()
    then acquires the NFS vnode lock and fills in stale file attributes.
     --> Setting the local modify timestamp in ncl_flsuh() and ncl_vinvalbuf()
       when they clear NMODIFIED should ensure that stale file attributes
       are not loaded.

    This patch does the above.

    PR:     259071
    Reviewed by:    asomers
    MFC after:      2 weeks
    Differential Revision:  https://reviews.freebsd.org/D32677

 sys/fs/nfsclient/nfs_clbio.c   | 18 +++++++++++++++---
 sys/fs/nfsclient/nfs_clvnops.c |  7 +++++++
 2 files changed, 22 insertions(+), 3 deletions(-)

You are receiving this mail because:
You are the assignee for the bug.