[Bug 257043] NFS nfsrpc_readdirplus() panic

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257043

Rick Macklem <rmacklem@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjg@FreeBSD.org,
                   |                            |rmacklem@FreeBSD.org
           Assignee|fs@FreeBSD.org              |rmacklem@FreeBSD.org

--- Comment #1 from Rick Macklem <rmacklem@FreeBSD.org> ---
I believe that the KASSERT() at line# 2471 in sys/kern/vfs_cache.c
is not feasible for the NFS client.
In general, the NFS client cannot know that a directory has been
modified locally on the server (or by another NFS client) such
that the same file name now refers to a different file.
(NFS does not have a cache coherency protocol.)

For NFS, what needs to happen for this case is that the new
entry needs to replace the old (now bogus/stale) entry.

I will look to see if a change in directory attributes can
be used to invalidate all entries in the cache for that directory
for the case of re-reading the directory, but this will, at best,
reduce the likelyhood of having a new file for the same name and
not stop it from happening.

Not using the "rdirplus" mount option should avoid the problem in
the meantime.

mjg@, can you change cache_enter_time() so that it replaces the
entry instead of panics?

I reproduced this by doing the following:
- NFS mount and "ll".
- go to server and do two "mv"s, where nfs_clstate.c and xxx.c were files
  in the directory
# mv nfs_clstate.c xxxx
# mv xxx.c nfs_clstate.c
- then "ll" again on the NFS client

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