In D55047#1263024, @asomers wrote:

This looks like a real problem. But how did you find it? Was it just virtio-fs, or did you find it with a regular fuse file system too? If either case, do you know if FUSE_ASYNC_READ was set? And do you know what values are typically used for the entry and attribute cache?

Thank you! For context, this diff along with the elock issue we discussed on D55046 are the main blockers for getting virtiofs working (D46295 + D46296). This issue from this diff specifically causes constant truncations when using metadata caching from the virtiofs (and assume FUSE) server. This looks like corruption from a user's point of view. I actually think that it'd be better if we removed the warnings altogether because they trigger spuriously and so are not helpful as diagnostics.

In D55046#1258149, @asomers wrote:

Thanks for working on this! I was actually working on the exact same problem myself last week. And I came up with a very similar solution. But then I realized that it wouldn't work :( . The cached attrs also need to be modified in paths where the vnode lock cannot be upgraded. So my plan is to add a mutex just to protect them. I started work on it last week. But now I'm on vacation, so I can't resume work for a few more days. But thanks for your interest in fuse.

fix copy-paste job for SPDX License

adjust SPDX License Identifier

upload actual diff (previous update accidentally added different diff)

adjust ms queue usage, ticket response, and error handling/style bugfixes

bug fixes and style updates

• sys/dev/virtio/fs: use regular BSD-2-Clause license

• sys/fs/fuse: disallow FUSE_INTERRUPT for virtiofs

• virtiofs: rename 'tag' VFS option to 'from'
• fs/fuse/virtiofs: adjust FUSE flags and disallow fsync

• sys/dev/virtio/fs: drain virtqueues one at a time

• virtiofs: turn off FUSE_DESTROY for virtiofs

There are two outstanding bugs that need fixing before this can be merged:

• virtiofs: rename 'tag' VFS option to 'from'
• address feedback

Unnecessary since the generic mount utility can mount/unmount virtiofs.

address reviewer feedback

In D46296#1101873, @editor_callfortesting.org wrote:

Could someone provide some simple scripts for bringing up and testing a share?

In D46296#1060950, @val_packett.cool wrote:

A couple more notes from testing:

There's some other place where FUSE layer can pick up zero-padded-to-power-of-two things, now with 1024 instead of 4096:

WARNING: FUSE protocol violation for server mounted at /: Returned an embedded NUL from FUSE_READLINK.  This warning will not be repeated.
Len 1024
0000   62 61 73 68 00 00 00 00 00 00 00 00 00 00 00 00  |bash............|
0010   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
…

And trying to just find something in a src tree checkout, there are sporadic errors like

find: ./contrib/llvm-project/llvm/lib/DebugInfo/Symbolize: Bad file descriptor
find: ./sys/dev/qat/qat_hw: Invalid argument
find: ./sys/dev/qat/qat_api/common/stubs: Invalid argument
// etc…

that seem completely random, on one invocation there are none, on another there's a couple…

In D46297#1057513, @asomers wrote:

Can you add a man page, too?

Thanks for the feedback! I will update the diff accordingly.

In D45370#1038548, @asomers wrote:

Will do, I have been building it as part of the kernel so that's probably why it didn't need a definition in sys/modules. I have been running this manually.

I've been thinking on how to get this code to be more reviewable. Should I maybe try to get it published as a port instead of submitting it as a patch to src/? Most of this code is self-contained, and its size means it will be next to impossible to review in its current state. If we go down the port route, only changes we would be applying to src/ would be non-functional - most would be about turning some static functions global.

Alternatively, I can break this diff apart, get the virtio-dbg transport reviewed since it is more reasonably sized, and either spin off the userspace device emulation component as a port or introduce it later. Which do you think is more reasonable?

Splitting it apart sounds good. Especially if there's some way to exercise the virtio-dbg transport without the userspace device emulation. Then splitting it apart would be a very good idea.

In D45370#1035488, @asomers wrote:

I think you need to add a definition for the virtio_dbg module in sys/modules. Oh, and how do you use it? Eventually we want ATF tests, of course. But I assume for now you've been manually using it somehow?