Hello, I am looking for opinions on an idea: How about allowing ptracing of processes in the TASK_UNINTERRUPTIBLE state, at least for processes with CAP_SYS_PTRACE? I think that it would be useful to be able to grab coredumps of processes that are hanging in the TASK_UNINTERRUPTIBLE state, but for that, I think that it would be necessary to have some way to inspect the registers of processes that are hanging there, and the easiest way to allow that that I can see would be to patch ptrace. Here's my usecase: I wrote an OpenCL program to run some computations and estimated the real time it would run for to be around four hours. Now this program has run for ten hours. I'm relatively sure that it's not hanging, but I'd really like to inspect its state with gdb to see how much of the result buffer is filled with results – however, that's not possible because the OpenCL implementation has caused my process to go into the D state. I'll have to reboot the PC to abort the computation or to wait for an unknown amount of time until it finishes (in case it hasn't deadlocked somewhere). Yes, it's my mistake to send such an amount of work to the GPU without intermediary save steps, but still, I think that this would be a useful feature for debugging. The only potential issue I can see with this is that someone might use it for causing a denial of service by stopping something inside some kind of lock. Because of this, I'm suggesting to limit this ability to processes with CAP_SYS_PTRACE. As far as I know, security should not be an issue because kernel mode and user mode registers are seperate, but I'm not entirely sure about that – could anyone here tell me whether that's right? If you don't tell me that it's a very bad idea or hard to implement for some reason (I have written nearly no kernel code in the past, so I don't know how hard it will be), I'll try to write a patch. Jann
Attachment:
signature.asc
Description: Digital signature
