flushing "anonymous" buffers over NFS is rejected by server (more weird bugs with mmap-ing via NFS)

[Matthew Dillon]

:So, the problem is, the dirtied buffers _sometimes_ lose their owner and thus 
:become root-owned. When the NFS client tries to flush them out, the NFS 
:server (by default suspecting remote roots of being evil) rejects the 
:flushing, which brings the client to its weak knees.
:
:1. Do the yet unflushed buffers really have to be anonymous?
:
:2. Can't the client's knees be strengthened in this regard?
:
:Thanks!
:
:	-mi

    Basically correct, though its not the buffers that get lost, its that
    the VM pages get disconnected from the buffers when the buffers are
    recycled, then get reconnected (sans creds info) later on.

    The basic answer is that we don't want to strengthen the client
    with regards to buffer/VM page creds, because buffers and VM pages
    are cached items in the system and can potentially have many 
    different 'owners'.  The entire cred infrastructure for buffers
    was a terrible hack put into place many years ago, solely to support NFS.
    It created a huge mess in the system code and didn't even solve
    the problem (as you found out).  I've already removed most of that junk
    from DragonFly and I would argue that there isn't much point keeping it
    in FreeBSD either.

    The only real solution is to make the NFS client aware of the 
    restricted user id exported by the server by requiring that the
    same uid be specified in the mount command the client uses to
    mount the NFS partition.  The NFS client would then use that user id
    for all write I/O operations.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>