Bug 293489 - readv(2) on cuse device never returns
Summary: readv(2) on cuse device never returns
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 15.0-RELEASE
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2026-02-27 15:41 UTC by elephant
Modified: 2026-02-27 17:08 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description elephant 2026-02-27 15:41:15 UTC
Issuing a read(2) on a cuse device that has data to returns works as expected. When switching to readv(2) with eight iovec-s, the readv call never returns.

Logging from an instrumented cuse device shows the first read is passed the correct buffer address and size. The data appears to be transferred. All subsequent read requires processed inside the cuse device have a correct buffer address but the length is zero.

Code snippet follows:

#include <unistd.h>
#include <sys/uio.h>

int okay;
char chunk[8];
struct iovec list[8] =
{
    {chunk + 0, 1},
    {chunk + 1, 1},
    {chunk + 2, 1},
    {chunk + 3, 1},
    {chunk + 4, 1},
    {chunk + 5, 1},
    {chunk + 6, 1},
    {chunk + 7, 1}
};

int handle = open(/dev/cuse123", O_RDONLY);

do
{
    okay = readv(handle, list, 8);
    if (okay < 0) break;
    write(2, chunk, okay);
}
while (true);
close(handle);

Switching back to a simple read(2) call works as expected.

The underlying issue is likely inside the cuse kernel module but this is just a guess.
Comment 1 elephant 2026-02-27 15:44:52 UTC
typo: requires=request
Comment 2 elephant 2026-02-27 17:00:07 UTC
I updated the instrumented cuse drive to return -1 on read operations with a length of zero. readv(2) now returns "Device busy".

I'll take a look at the cuse kmod.
Comment 3 elephant 2026-02-27 17:08:54 UTC
I changed the readv call to pass only one iovec. Data was transferred but once all data was exhausted and the cuse device returns zero bytes copied, the readv call blocks indefinitely. This, I think is WAD since readv doesn't know when new data will eventually become available.