3 ms·

Great story! I've had a lot of debugging nightmares, but thankfully never anything as bad as that. One thing that looks fishy is this branch: if (container_

Great story! I've had a lot of debugging nightmares, but thankfully never anything as bad as that. One thing that looks fishy is this branch: if (container_tasks_len == max_container_tasks) { printk("cplayground: ERROR: container_tasks list hit capacity! We " "may be missing processes from the procfile output.\n"); break; } Since you said printk can block, why isn't calling it in the rcu critical section a bug? Is it because you immediately break afterwards and don't try to reference the next task?

ksml 6y ago
That's a good point. I'm hoping that this never gets hit, and if that line ever appears in the logs, then things are already broken. However, it's probably better to improve the failure mode where possible :) [edit] and yes, since we break and don't follow the `next` pointer in the linked list, that also shouldn't cause any problems. [edit 2] a sibling comment by cesarb pointed out that printk actually does not block, since it's important for it to be usable in critical sections to debug when the kernel gets into trouble