Alright, so to sum it up: - current stack dumping (even looking at /proc/<pid>/stack) is not guaranteed to yield "correct" results in case the task is running at the time the stack is being examined
- the only fool-proof way is to send IPI-NMI to all CPUs, and synchronize the handlers between each other (to make sure that reschedule doesn't happen in between on some CPU and other task doesn't start running in the interim). The NMI handler dumps its current stack in case it's running in context of the process whose stack is to be dumped. Otherwise, one of the NMI handlers looks up the required task_struct, and dumps it if it's not running on any CPU - For live patching use-case, the stack has to be analyzed (and decision on what to do based on the analysis) in the NMI handler itself, otherwise it gets racy again Converting /proc/<pid>/stack to this mechanism seems like a correct thing to do in any case, as it's slow path anyway. The original intent seemed to have been to make this fast path for the live patching case, but that's probably not possible, so it seems like the price that will have to be paid for being able to finish live-patching of CPU-bound processess is the cost of IPI-NMI broadcast. Agreed? Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/