5e63333052
* A small error in r338152 let to the returned size always being exactly eight bytes too large. * The FUSE_LISTXATTR operation works like Linux's listxattr(2): if the caller does not provide enough space, then the server should return ERANGE rather than return a truncated list. That's true even though in FUSE's case the kernel doesn't provide space to the client at all; it simply requests a maximum size for the list. We previously weren't handling the case where the server returns ERANGE even though the kernel requested as much size as the server had told us it needs; that can happen due to a race. * We also need to ensure that a pathological server that always returns ERANGE no matter what size we request in FUSE_LISTXATTR won't cause an infinite loop in the kernel. As of this commit, it will instead cause an infinite loop that exits and enters the kernel on each iteration, allowing signals to be processed. Reviewed by: cem MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D21287 |
||
---|---|---|
.. | ||
autofs | ||
cd9660 | ||
cuse | ||
deadfs | ||
devfs | ||
ext2fs | ||
fdescfs | ||
fifofs | ||
fuse | ||
msdosfs | ||
nfs | ||
nfsclient | ||
nfsserver | ||
nullfs | ||
procfs | ||
pseudofs | ||
smbfs | ||
tmpfs | ||
udf | ||
unionfs |