https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255523
Mark Millard <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #1 from Mark Millard <[email protected]> --- Would this deal with: https://cgit.freebsd.org/src/commit/?id=19fe23fa2bd52d6a42fb408d21b9d49c4bee81ef Titled: "Make vn_generic_copy_file_range() interruptible via a signal." QUOTE This patch adds checks for signals that need to be processed after each successful data copy cycle. END QUOTE Might making the "data copy cycle" huge in some contexts reintroduce such problems by making the sig_intr() calls too infrequent? In other words: might vn_rdwr(. . .) and/or vn_write_outvp(. . .) sometimes take too long relative to checking sig_intr() frequently enough? There is also the cantseek related mem_iszero(dat,xfer) if xfer were huge. Note: I've not done a deep analyzis. I'm just asking based on what I see in the vn_generic_copy_file_range(. . .) code. -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "[email protected]"
