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

From: <bugzilla-noreply_at_freebsd.org>
Date: Tue, 26 Oct 2021 23:46:59 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259071

--- Comment #7 from Rick Macklem <rmacklem@FreeBSD.org> ---
Created attachment 229053
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=229053&action=edit
timestamp file mods so Lookup can discard stale attributes against Writing

Similar to attachment #228973, 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.

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