Bug 244229

Summary: fusefs tests fail when mac_bsdextended.ko is loaded
Product: Base System Reporter: Li-Wen Hsu <lwhsu>
Component: testsAssignee: Alan Somers <asomers>
Status: Closed FIXED    
Severity: Affects Only Me CC: asomers, markj
Priority: ---    
Version: CURRENT   
Hardware: Any   
OS: Any   

Comment 1 Li-Wen Hsu freebsd_committer 2020-02-19 14:30:09 UTC
Temporarily disable fusefs tests

https://github.com/freebsd/freebsd-ci/commit/b19fa34c39686d149faf9d5ffb2a278e6322a58e
Comment 2 Li-Wen Hsu freebsd_committer 2020-02-19 14:31:20 UTC
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.
Comment 3 Alan Somers freebsd_committer 2020-02-19 15:34:00 UTC
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?
Comment 4 Li-Wen Hsu freebsd_committer 2020-02-19 23:52:23 UTC
This might be related to https://svnweb.freebsd.org/changeset/base/357574
Comment 5 Li-Wen Hsu freebsd_committer 2020-02-19 23:54:39 UTC
(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
Comment 6 Alan Somers freebsd_committer 2020-02-20 03:16:58 UTC
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.
Comment 7 Li-Wen Hsu freebsd_committer 2020-02-20 16:37:37 UTC
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?
Comment 8 Alan Somers freebsd_committer 2020-02-20 16:45:26 UTC
(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.
Comment 9 commit-hook freebsd_committer 2020-05-02 20:15:50 UTC
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
Comment 10 commit-hook freebsd_committer 2020-05-13 20:37:30 UTC
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
Comment 11 commit-hook freebsd_committer 2020-05-17 02:36:05 UTC
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