Date: Fri, 27 Feb 2026 15:41:15 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 293489] readv(2) on cuse device never returns Message-ID: <bug-293489-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293489 Bug ID: 293489 Summary: readv(2) on cuse device never returns Product: Base System Version: 15.0-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: bugs@FreeBSD.org Reporter: unitrunker@unitrunker.net 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. -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-293489-227>