On 2015-12-10 at 08:57 "'Davide Libenzi' via Akaros"
<[email protected]> wrote:
> LGTM, but I have a related question.
> Is there a way I can get a dump of user register status, from ^G, of
> any blocked process?
> That way we could build an API to kfunc into, that dumps the trace of
> any blocked process.
It's a little tricky. The main thing is that processes don't really
block in the kernel. You can capture (and print out) a user context
when we enter the kernel, since we haven't returned to the user yet.
But once a kthread blocks, we return to the user and the original
context that trapped into the kernel is gone.
Additionally, the user could have sent us an async call (to a remote
core, which no one does).
So the kernel doesn't really know about the details of the path that
led to the syscall.
The common path for a process that wants to wait for a syscall to
complete is:
- trap into the kernel, issuing syscall
- we can see the user_ctx still
- kthread blocks
- kernel returns to the user_ctx
- typically, we're in glibc, and we call out to the 2LS
- pthread 2LS registers for an event when the sysc completes
- a pointer to the thread is stored in sysc->u_data
- pthread 2LS looks for another thread to run. if none, then it yields
to the kernel, and enters a WAITING state
- the kernel doesn't know much about the process, and this is
the time that you want to know what user threads are blocked
- eventually the syscall completes, an event is sent to the 2LS, and it
reschedules/restarts the uthread.
The thread0 2LS (for apps that don't use pthreads) does something
similar, but it doesn't bother with sysc->u_data.
So the information about blocked threads is up in userspace, and in
general the kernel doesn't know about user threads. It doesn't even
know what a struct uthread looks like.
As a dirty hack, which I've had to do from time to time, if you know the
syscall struct pointer (from db sem), you can hexdump it, then get the
user pointer, then hexdump that. then use pahole (or just a printf, or
your eyes) to spit out the offsets for the PC and FP within the uthread,
then bt that. But that will only work with pthreads. For thread0,
you'd need to printf the addr of thread 0.
The right answer is to build some sort of interrogation mechanism for
the 2LS. I've done debugging with this too - just do a printf from an
event handler to print out whatever you want.
Barret
--
You received this message because you are subscribed to the Google Groups
"Akaros" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/d/optout.
