https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=167688
Alan Somers changed:
What|Removed |Added
Status|Open|Closed
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=167688
--- Comment #8 from Alan Somers ---
Firstly, let me thank you for such a good reproduction case. This is certainly
the best reproduction case I've ever seen for a user-reported fuse bug, and it
ranks highly for the best reproduction cases
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=167688
--- Comment #7 from Conrad Meyer ---
(In reply to Conrad Meyer from comment #6)
Sigh. Yes, we PCATCH, *but*:
314 static int
315 fticket_wait_answer(struct fuse_ticket *ftick)
316 {
...
334 fuse_block_sigs(&tset);
335 err =
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=167688
--- Comment #6 from Conrad Meyer ---
That said, it seems like all sleeps in the read path in sys/fs/fuse use PCATCH.
There is a PCATCH-less tsleep associated with flush, but I don't know why that
would be invoked for a read.
--
You are r
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=167688
--- Comment #5 from Conrad Meyer ---
(In reply to Alan Somers from comment #4)
> The signal does not interrupt the read(2).
Hm, isn't that part of the bug? Signals are supposed to interrupt blocked I/O;
not interrupting explains the sympt
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=167688
Alan Somers changed:
What|Removed |Added
CC||asom...@freebsd.org
--- Comment #4 f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=167688
Conrad Meyer changed:
What|Removed |Added
CC||c...@freebsd.org
--- Comment #3 fro
