Page MenuHomeFreeBSD

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

Authored by asomers on Apr 26 2020, 4:23 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Mar 28, 8:56 PM
Unknown Object (File)
Feb 23 2024, 11:12 AM
Unknown Object (File)
Feb 23 2024, 11:12 AM
Unknown Object (File)
Feb 23 2024, 11:12 AM
Unknown Object (File)
Feb 23 2024, 10:59 AM
Unknown Object (File)
Jan 16 2024, 6:33 PM
Unknown Object (File)
Jan 14 2024, 5:39 AM
Unknown Object (File)
Dec 20 2023, 7:36 AM
Subscribers

Details

Summary

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

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

I have no idea what mac_bsdextended is, but this seems fine.

tests/sys/mac/bsdextended/matches_test.sh
19 ↗(On Diff #71010)

I'd use $(). Not a big deal.

This revision is now accepted and ready to land.Apr 26 2020, 7:12 PM