On 2026-09-25 07:09, Pádraig Brady wrote:
The point wasn't about the first read(), it was about the blocking in the subsequent read().
Agreed. That kdump output indicates a bug in NetBSD when reading from a pipe where EOF was already reported. My wild guess, without looking at the source code, is that the NetBSD code has some provision for named fifos (where a later read could indeed hang) that is leaking into the code for pipes (where a later read should return 0 and should never hang).
