Searched hist:"14 f7dd632011bb89c035722edd6ea0d90ca6b078" (Results 1 – 1 of 1) sorted by relevance
| /openbmc/linux/fs/nfsd/ |
| H A D | vfs.c | diff 8d7c4203c681a3ec359eccff4e53bc8c0ccf403b Thu Oct 30 12:48:33 CDT 2008 J. Bruce Fields <bfields@citi.umich.edu> nfsd: fix failure to set eof in readdir in some situations
Before 14f7dd632011bb89c035722edd6ea0d90ca6b078 "[PATCH] Copy XFS
readdir hack into nfsd code", readdir_cd->err was reset to eof before
each call to vfs_readdir; afterwards, it is set only once. Similarly,
c002a6c7977320f95b5edede5ce4e0eeecf291ff "[PATCH] Optimise NFS readdir
hack slightly", can cause us to exit without nfserr_eof set. Fix this.
This ensures the "eof" bit is set when needed in readdir replies. (The
particular case I saw was an nfsv4 readdir of an empty directory, which
returned with no entries (the protocol requires "." and ".." to be
filtered out), but with eof unset.)
Cc: David Woodhouse <David.Woodhouse@intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
diff 14f7dd632011bb89c035722edd6ea0d90ca6b078 Thu Jul 31 14:29:12 CDT 2008 David Woodhouse <David.Woodhouse@intel.com> [PATCH] Copy XFS readdir hack into nfsd code.
Some file systems with their own internal locking have problems with the
way that nfsd calls the ->lookup() method from within a filldir function
called from their ->readdir() method. The recursion back into the file
system code can cause deadlock.
XFS has a fairly hackish solution to this which involves doing the
readdir() into a locally-allocated buffer, then going back through it
calling the filldir function afterwards. It's not ideal, but it works.
It's particularly suboptimal because XFS does this for local file
systems too, where it's completely unnecessary.
Copy this hack into the NFS code where it can be used only for NFS
export. In response to feedback, use it unconditionally rather than only
for the affected file systems.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|