src-test/tests/sys/fs, branch main

fusefs tests: quell Coverity "Argument cannot be negative" warnings

2020-10-02T17:06:05Z

Must abort tests early if open(2) fails. Reported by: Coverity Coverity CID: 1432810 and many others Reviewed by: kevans MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D26635

Do a sweep and remove most WARNS=6 settings

2020-10-01T01:10:51Z

Repeating the default WARNS here makes it slightly more difficult to experiment with default WARNS changes, e.g. if we did something absolutely bananas and introduced a WARNS=7 and wanted to try lifting the default to that. Drop most of them; there is one in the blake2 kernel module, but I suspect it should be dropped -- the default WARNS in the rest of the build doesn't currently apply to kernel modules, and I haven't put too much thought into whether it makes sense to make it so.

fusefs: fix mmap'd writes in direct_io mode

2020-09-24T16:27:53Z

If a FUSE server returns FOPEN_DIRECT_IO in response to FUSE_OPEN, that instructs the kernel to bypass the page cache for that file. This feature is also known by libfuse's name: "direct_io". However, when accessing a file via mmap, there is no possible way to bypass the cache completely. This change fixes a deadlock that would happen when an mmap'd write tried to invalidate a portion of the cache, wrongly assuming that a write couldn't possibly come from cache if direct_io were set. Arguably, we could instead disable mmap for files with FOPEN_DIRECT_IO set. But allowing it is less likely to cause user complaints, and is more in keeping with the spirit of open(2), where O_DIRECT instructs the kernel to "reduce", not "eliminate" cache effects. PR: 247276 Reported by: trapexit@spawn.link Reviewed by: cem MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D26485

fusefs: fix the FUSE_FORGET unit test after r364064

2020-08-11T01:09:06Z

Thanks to r364064, the name cache now returns a hit where previously it would miss. Adjust the expectations accordingly. PR: 248583 Reported by: lwhsu MFC with: r364064

Fix issues with FUSE_ACCESS when default_permissions is disabled

2020-05-22T18:11:17Z

This patch fixes two issues relating to FUSE_ACCESS when the default_permissions mount option is disabled: * VOP_ACCESS() calls with VADMIN set should never be sent to a fuse server in the form of FUSE_ACCESS operations. The FUSE protocol has no equivalent of VADMIN, so we must evaluate such things kernel-side, regardless of the default_permissions setting. * The FUSE protocol only requires FUSE_ACCESS to be sent for two purposes: for the access(2) syscall and to check directory permissions for searchability during lookup. FreeBSD sends it much more frequently, due to differences between our VFS and Linux's, for which FUSE was designed. But this patch does eliminate several cases not required by the FUSE protocol: * for any FUSE_*XATTR operation * when creating a new file * when deleting a file * when setting timestamps, such as by utimensat(2). * Additionally, when default_permissions is disabled, this patch removes one FUSE_GETATTR operation when deleting a file. PR: 245689 Reported by: MooseFS FreeBSD Team Reviewed by: cem MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D24777

fusefs: fix intermittency in some ENOENT tests

2020-05-18T18:36:32Z

When a FUSE operation other than LOOKUP returns ENOENT, the kernel will reclaim that vnode, resuling in a FUSE_FORGET being sent a short while later. Many of the ENOENT tests weren't expecting those FUSE_FORGET operations. They usually passed by luck since FUSE_FORGET is often delayed. This commit adds appropriate expectations. MFC after: 2 weeks

fusefs: fix two small bugs in the tests' expectations

2020-05-08T23:00:02Z

These two errors have been present since the tests' introduction. Coincidentally every test (I think there's only one) that cares about that field also works when the field's value is 0. MFC after: 2 weeks

Resolve conflict between the fusefs(5) and mac_bsdextended(4) tests

2020-05-02T20:14:59Z

mac_bsdextended(4), when enabled, causes ordinary operations to send many more VOP_GETATTRs to file system. The fusefs tests expectations aren't written with those in mind. Optionally expecting them would greatly obfuscate the fusefs tests. Worse, certain fusefs functionality (like attribute caching) would be impossible to test if the tests couldn't expect an exact number of GETATTR operations. This commit resolves that conflict by making two changes: 1. The fusefs tests will now check for mac_bsdextended, and skip if it's enabled. 2. The mac_bsdextended tests will now check whether the module is enabled, not merely loaded. If it's loaded but disabled, the tests will automatically enable it for the duration of the tests. With these changes, a CI system can achieve best coverage by loading both fusefs and mac_bsdextended at boot, and setting security.mac.bsdextended.enabled=0 PR: 244229 Reported by: lwhsu Reviewed by: cem MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D24577

fusefs: avoid cache corruption with buggy fuse servers

2020-03-11T04:29:45Z

The FUSE protocol allows the client (kernel) to cache a file's size, if the server (userspace daemon) allows it. A well-behaved daemon obviously should not change a file's size while a client has it cached. But a buggy daemon might. If the kernel ever detects that that has happened, then it should invalidate the entire cache for that file. Previously, we would not only cache stale data, but in the case of a file extension while we had the size cached, we accidentally extended the cache with zeros. PR: 244178 Reported by: Ben RUBSON Reviewed by: cem MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D24012

fusefs: fix fsync for files with multiple open handles

2020-03-09T01:57:21Z

We were reusing a structure for multiple operations, but failing to reinitialize one member. The result is that a server that cares about FUSE file handle IDs would see one correct FUSE_FSYNC operation, and one with the FHID unset. PR: 244431 Reported by: Agata MFC after: 2 weeks