Re: cuse(3) cuse_wait_and_process thread safety

Hello Christos!

I am working on a POC to demonstrate the problem. While doing so I found a separate issue with readv. Bug is here:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293489

Multiple threads make sense but one would want to partition the data so that packets inside the same stream are processed in-order.

My theory of a bug is based on two assumptions.

I am assuming the kernel module does not enforce one-stream per worker thread (which may be wrong but I've not seen such logic in the module).

For the POC, I created a simple cuse process and a test program that sends a burst of one byte writes to the cuse process. Inside the cuse process, each worker thread sleeps a random amount of time in between events. This requires multiple events to be queued (which I assume is possible). Another process reads the data. Any mis-ordering of bytes is proof of a bug.

Example: ABCDEFGH => ABCEDFGH

I'll drop a POC once I have it working. Of course, if I can't make it fail, that's a good thing.

Regards,
Rick

On Wednesday, March 4th, 2026 at 12:16 PM, Christos Margiolis <christos@freebsd.org> wrote:

> I'm the maintainer of virtual_oss. To be fair, I don't know what was
> HPS's (RIP) rationale for giving each device 4 threads, so I'm not sure
> how to answer this question. Have you run into the problem you described
> since you sent the email?
> 
> Christos