You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's a lot of (rather deilcate) code in place to handle various cases around scratch-buffer management. I'd really like to simplify that if possible.
An idea that strikes me is that for syscalls like read() with unbounded buffer sizes, allocate scratch buffers on a best-effort basis, rather than all-or-none. The kernel can return as little data as it wants✱, so rr can take advantage of that to pass a smaller input buffer to the kernel if not enough scratch is available.
This would be unsound for syscalls with inoutparams, so it would still be possible to exhaust scratch, but those cases are so edge (deep sighandler interrupts of huge poll buffers, e.g.) I'm inclined not to care if it simplifies the code a lot.
✱ In reality, there are certain "gentlemen's agreements" linux makes with userspace, like reads of 4096 bytes or under on files succeed or fail atomically, IIRC. And the notion of "best-effort" is horrendously hard to define for a syscall like recvmsg(). And ioctl()s and interacting with special devices ...
The text was updated successfully, but these errors were encountered:
There's a lot of (rather deilcate) code in place to handle various cases around scratch-buffer management. I'd really like to simplify that if possible.
An idea that strikes me is that for syscalls like
read()
with unbounded buffer sizes, allocate scratch buffers on a best-effort basis, rather than all-or-none. The kernel can return as little data as it wants✱, so rr can take advantage of that to pass a smaller input buffer to the kernel if not enough scratch is available.This would be unsound for syscalls with inoutparams, so it would still be possible to exhaust scratch, but those cases are so edge (deep sighandler interrupts of huge
poll
buffers, e.g.) I'm inclined not to care if it simplifies the code a lot.✱ In reality, there are certain "gentlemen's agreements" linux makes with userspace, like reads of 4096 bytes or under on files succeed or fail atomically, IIRC. And the notion of "best-effort" is horrendously hard to define for a syscall like recvmsg(). And
ioctl()
s and interacting with special devices ...The text was updated successfully, but these errors were encountered: