Post B7LnJg0hcFtQSkWVPM by wolf480pl@mstdn.io
(DIR) More posts by wolf480pl@mstdn.io
(DIR) Post #B7KtMaU11mBwkw2sxE by wolf480pl@mstdn.io
0 likes, 0 repeats
strace(1) is cool btwI usually take it for granted, but like, imagine how hard life would be if your OS didn't have a well-documented syscall layer, or if you couldn't snoop at it to see how a process interacts with the rest of the system.
(DIR) Post #B7KtQ3GeSqFctkRkTQ by wolf480pl@mstdn.io
0 likes, 0 repeats
(you don't need to imagine, just try debugging anything that uses netlink on Linux)
(DIR) Post #B7KtYHI2DIOGhj13R2 by wolf480pl@mstdn.io
0 likes, 0 repeats
I wonder how io_uring plays with that... does it hook into ptrace to report uring syscalls like normal syscalls?Or does it have its own bespoke monitoring interface, like netlink?
(DIR) Post #B7Kv4CIkObswSB8LTs by schrotthaufen@mastodon.social
0 likes, 0 repeats
@wolf480pl @buherator I love the moment when I can show juniors the “magic” of strace. (Usually it’s just `strace -fe openat $ProcessThatWontTellYouWhichFileItCantOpen`)
(DIR) Post #B7KvnfVeeCD64XqxTU by amonakov@mastodon.gamedev.place
0 likes, 0 repeats
@wolf480pl it doesn't, but submission (io_uring_enter) is visible to strace, at which point it decodes the contents of the ring buffera sufficiently advanced userspace may enqueue more commands after the submission though, or even alter an enqueued command (racing against the kernel reading the buffer)
(DIR) Post #B7L2egKQvrXNgYGZv6 by wolf480pl@mstdn.io
0 likes, 0 repeats
@amonakovyeah isn't that the whole point of io_uring though? To send syscalls asynchronously, like you're talking talking to a separate physical device?
(DIR) Post #B7Lh8JSsV4J5d1tsrQ by amonakov@mastodon.gamedev.place
0 likes, 0 repeats
@wolf480pl I suspect it's debatable whether that's literally its whole point, but yeah, it's hard to observe async enqueue from another layer, so creating a faithful userspace tracer for io_uring looks challenging.
(DIR) Post #B7LnJfRxhQ6Uj0GlG4 by sertonix@social.treehouse.systems
0 likes, 0 repeats
@wolf480pl @amonakov I would compare it like throwing stuff into an already running mashine instead of turning the machine on and off all the time.
(DIR) Post #B7LnJffQtKsZOmZWFs by sertonix@social.treehouse.systems
0 likes, 0 repeats
@wolf480pl @amonakov If one would create a debugger for io_uring (might even do that myself at some point) I think the only race-free approach would be to modify the buffers passed to syscalls like io_uring_enter and then print the events before copying them to the real buffer.
(DIR) Post #B7LnJfqQETfZwriINs by amonakov@mastodon.gamedev.place
0 likes, 0 repeats
@sertonix @wolf480pl I'm afraid there are complications: for instance, io_uring_setup returns a pollable fd, so if you interpose another fd you'd have to pass poll events somehow...
(DIR) Post #B7LnJg0hcFtQSkWVPM by wolf480pl@mstdn.io
0 likes, 0 repeats
@amonakov@sertonix I was thinking: why not add a new ptrace,event that the kernel calls whenever it dequeues an entry from the ring buffer.But that'd mean receivin ptrace events wihout stopping the tracee - I think that violates an invariant or two.
(DIR) Post #B7LnhNbLiB3qJny0ye by amonakov@mastodon.gamedev.place
0 likes, 0 repeats
@wolf480pl @sertonix yeah, instead, why not let the tracer register a parallel ring buffer that is asynchronously filled with events. fight fire with fire!in fact, why not let the tracer do all the work via a ring buffer
(DIR) Post #B7LoNmUVYwh7ftzAoK by wolf480pl@mstdn.io
0 likes, 0 repeats
@amonakovwe already have that, it's called /sys/kernel/tracing :P @sertonix
(DIR) Post #B7Lp7uOMWH8lV36eIa by wolf480pl@mstdn.io
0 likes, 0 repeats
@amonakovalthough that's fully async, it won't let you stop the tracee, block syscalls, or modify their args. How about: map the buffer read-only in the tracee, so that writes to it trap. Then single-step any instruction that writes to it.@sertonix
(DIR) Post #B7LqrkhgyLJ4j9ZUg4 by amonakov@mastodon.gamedev.place
0 likes, 0 repeats
@wolf480pl @sertonix I think the visibility you get from this is too one-sided (towards the less-useful side): you can see when/what the userspace enqueued, but not when the kernel dequeued that. But generally that's a great approach to keep in mind (nowadays with userfaulfd probably?)