@des what do you think of the alternate solution in D60489 ? I think it's more robust, because it doesn't require the socket names and receive buffers to be exactly matched in size.

This may work, but it seems a little bit fragile. Would it not be more robust to omit the MSG_WAITALL for the call when recv is expecting a variable-length string?

Works for me. Thanks for the quick fix!

In D55362#1364561, @ayushjayaswal.connect_gmail.com wrote:

Hi @asomers

What should I do next for this patch?

The 2026 Capsicumize FTS project is complete. In 16.0-CURRENT there is now an fts_openat function. Hopefully it can be used to finish this port.

Other than that inline comment, this LGTM. Thanks for fixing it. Do you need me to commit it for you? I can do that, after you address the one remaining comment.

• Don't heap-allocate a std::vector
• Use mount_fusefs with memfs

@arrowd what do you think of this? If we merge it, then we can eliminate my depedence on fuse-ext2 and your dependence on fuse-hello.

In D56165#1334631, @kib wrote:

In D56165#1334568, @asomers wrote:

In D56165#1285144, @kib wrote:

As was discussed elsewhere, fuse server which times out the responses could cause lock cascades in VFS. This would have global consequences for the whole system.

Until the vnodes are locked around communication with userspace, I do not think this change is appropriate.

I think kib means "unlocked around communication with userspace". But I do not see how such a change could possibly work.

Fuse needs to make some way to ensure liveness of the inode (not vnode) around calls to the userspace.

In D56165#1285144, @kib wrote:

As was discussed elsewhere, fuse server which times out the responses could cause lock cascades in VFS. This would have global consequences for the whole system.

Until the vnodes are locked around communication with userspace, I do not think this change is appropriate.

LGTM

Respond to @markj's latest comments