Bug 244229
| Summary: | fusefs tests fail when mac_bsdextended.ko is loaded | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Li-Wen Hsu <lwhsu> |
| Component: | tests | Assignee: | Alan Somers <asomers> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | CC: | asomers, markj |
| Priority: | --- | ||
| Version: | CURRENT | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Li-Wen Hsu
2020-02-19 14:01:54 UTC
Temporarily disable fusefs tests https://github.com/freebsd/freebsd-ci/commit/b19fa34c39686d149faf9d5ffb2a278e6322a58e asomers: could you help check this? I haven't checked this is a regression or not, but I cannot reproduce this on my r355861 current machine. lwhsu I don't see those failures locally, either. What I need is the verbose output. What's the easiest way to run something like `/usr/tests/sys/fs/fusefs/lookup -v` in the CI environment? This might be related to https://svnweb.freebsd.org/changeset/base/357574 (In reply to Alan Somers from comment #3) kyua console output is available at: https://ci.freebsd.org/job/FreeBSD-head-amd64-test/14387/testReport/sys.fs.fusefs/lookup/main/ For -v in googletest, I am not sure but we can execute them in the same VM CI use. Please see https://wiki.freebsd.org/Jenkins/Debug The problem with CI is that it runs with the mac_bsdextended.ko module loaded. The MAC checks cause some extra GETATTR operations that the fusefs tests aren't expecting. I could try to add optional expectations for them. However, that wouldn't work for the attribute cacheing tests, which need an exact knowledge of how many GETATTR operations to expect. Or, I could set sysctl security.mac.bsdextended.enabled=0 during these tests. But then they wouldn't be able to run concurrently with the actual sys/mac/bsdextended tests. I need to think this over some more. I'm ok for setting security.mac.bsdextended.enabled=0 when doing fusefs tests (and restore it after finishing) as a workaround. Currently we run tests sequentially and we will check orthogonality of the tests before running them in parallel, or introduce better isolation. I'm curious why the attribute caching tests will not work. What is it doing and is there any chance if we modify the test case itself to make the number of GETATTR operations predictable? (In reply to Li-Wen Hsu from comment #7) The attribute cacheing tests must require a specific number of GETATTR operations. Too many looks like an attribute wasn't cached when it should've been. We could modify them to work specifically when mac_bsdextended is loaded, but it might be an awful lot of special-case code. I'll try it after I finish Bug 244178. A commit references this bug: Author: asomers Date: Sat May 2 20:15:00 UTC 2020 New revision: 360567 URL: https://svnweb.freebsd.org/changeset/base/360567 Log: Resolve conflict between the fusefs(5) and mac_bsdextended(4) tests 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 Changes: head/tests/sys/fs/fusefs/utils.cc head/tests/sys/mac/bsdextended/matches_test.sh A commit references this bug: Author: lwhsu Date: Wed May 13 20:36:39 UTC 2020 New revision: 361018 URL: https://svnweb.freebsd.org/changeset/base/361018 Log: Temporarily skip sys.net.if_bridge_test.stp in CI as it always times out PR: 244229 Sponsored by: The FreeBSD Foundation Changes: head/tests/sys/net/if_bridge_test.sh A commit references this bug: Author: asomers Date: Sun May 17 02:35:51 UTC 2020 New revision: 361126 URL: https://svnweb.freebsd.org/changeset/base/361126 Log: MFC r360339, r360567 r360339: mac_bsdextended: ATFify the tests The new tests have more complete setup and cleanup, are more granular, and correctly annotate expected failures and skipped tests. A follow-up commit will resolve a conflict with the fusefs tests (bug 244229). Differential Revision: https://reviews.freebsd.org/D24257 r360567: Resolve conflict between the fusefs(5) and mac_bsdextended(4) tests 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 Differential Revision: https://reviews.freebsd.org/D24577 Changes: _U stable/12/ stable/12/tests/sys/fs/fusefs/utils.cc stable/12/tests/sys/mac/bsdextended/Makefile stable/12/tests/sys/mac/bsdextended/matches_test.sh |