Omar Sandoval
Posts
23Following
265Followers
284
@ljs @vbabka @brenns10 @jann nah, we don't grab locks. Since we're read-only (ignoring kmodify), the worst that can happen is we follow some stale data and get a Python exception. But kmodify could be used for that if you really wanted.
Really cool that you made the kernel code work in userspace! I wished the Btrfs code could do that when I was working on Btrfs.
The tricky parts for using that code for the in-kernel data are 1) you need to translate memory accesses to reads from /proc/kcore 2) you need to match the appropriate version of the userspace code to the kernel version.
Really cool that you made the kernel code work in userspace! I wished the Btrfs code could do that when I was working on Btrfs.
The tricky parts for using that code for the in-kernel data are 1) you need to translate memory accesses to reads from /proc/kcore 2) you need to match the appropriate version of the userspace code to the kernel version.
0
0
3
@ljs @vbabka @brenns10 nope, we walk the maple tree (or red black tree on old kernels) ourselves: https://github.com/osandov/drgn/blob/89260b18b9fa01ffc7d5bfaedeb34aeec0198557/drgn/helpers/linux/mm.py#L1353. We have drgn helpers for walking both data structures, which are basically translations of the C kernel code. The maple tree ones were pretty fun: https://github.com/osandov/drgn/blob/89260b18b9fa01ffc7d5bfaedeb34aeec0198557/drgn/helpers/linux/mapletree.py#L67.
It wouldn't be _too_ hard to translate those to libdrgn, but it'd be tedious.
One other idea for C integration that comes to mind is adding a function to libdrgn that evaluates a string of Python code for you, that way you don't need to resort to system(). We could even have it return the drgn_object to C so you could use libdrgn to get the rest of the way. Would that help, or am I missing the point?
P.S. drgn does have a way to call kernel functions: https://drgn.readthedocs.io/en/latest/helpers.html#kmodify. But that's provided as a way for the user to shoot their own foot, it's too risky to use internally.
It wouldn't be _too_ hard to translate those to libdrgn, but it'd be tedious.
One other idea for C integration that comes to mind is adding a function to libdrgn that evaluates a string of Python code for you, that way you don't need to resort to system(). We could even have it return the drgn_object to C so you could use libdrgn to get the rest of the way. Would that help, or am I missing the point?
P.S. drgn does have a way to call kernel functions: https://drgn.readthedocs.io/en/latest/helpers.html#kmodify. But that's provided as a way for the user to shoot their own foot, it's too risky to use internally.
0
0
2
@ljs @vbabka @brenns10 the big caveat is that all of the helpers (e.g., for looking up VMAs) are indeed Python-only. Stephen and I have both had crazy ideas for using CO-RE or transpiling a subset of C to make things easier for people more comfortable with C like yourself, but that's probably a ways away.
0
0
3
@ljs @vbabka @brenns10 no worries!
> Yeah libdrgn looked pretty dead to me in-repo so that's sad.
Almost all of drgn's core functionality is implemented in libdrgn first and only exposed via Python bindings, so it is very actively developed.
But @brenns10 is right, although we do have some internal users, it doesn't have a stable API or ABI and isn't installed by default.
That's mainly because no one has asked for that yet. I'd be very willing to do a bit of work to close the gap if it's important to you or anyone else.
> Yeah libdrgn looked pretty dead to me in-repo so that's sad.
Almost all of drgn's core functionality is implemented in libdrgn first and only exposed via Python bindings, so it is very actively developed.
But @brenns10 is right, although we do have some internal users, it doesn't have a stable API or ABI and isn't installed by default.
That's mainly because no one has asked for that yet. I'd be very willing to do a bit of work to close the gap if it's important to you or anyone else.
0
0
2
Omar Sandoval
repeated
repeated
Christian Brauner 🦊🐺
brauner@mastodon.social
Edited 3 months ago
I've done a series that adds support for AF_UNIX sockets in coredumps. Userspace provides an AF_UNIX socket path via core_pattern and the kernel connects to it, shuts down the read side and writes the coredump to the socket.
This means no more super privileged usermode helper upcalls and makes for a very nice API experience. I captured coredumps simply via socat:
https://lore.kernel.org/20250430-work-coredump-socket-v1-0-2faf027dbb47@kernel.org
The receiver can use SO_PEERPIDFD to get a stable handle on the crashed process.
6
12
1
Omar Sandoval
osandov
@monsieuricon I found this Akkoma PR which I thought looked merged: https://akkoma.dev/AkkomaGang/akkoma/pulls/405 but maybe I'm mistaken.
0
0
0
Omar Sandoval
osandov
@monsieuricon does social.kernel.org not support verified profile links or am I dumb?
1
0
0