On Tue, Jun 09, 2026 at 01:41:53PM +0900, Masami Hiramatsu wrote: > > This, you cannot take locks in unwinding. The only thing you can do is > > try to do the best you can without crashing. > > > > Typically unwind only happens on self -- this is natural, a task crashes > > and unwinds itself, or a task does something (takes a lock, hits a > > tracepoint, etc) and takes a snapshot of its own stack, and this is > > safe. > > > > Things like live-patch use task_call_func(), which ensures the callback > > function is done while holding sufficient locks for the task to not > > change state. > > Hmm, is there any way to ensure the function is called from task_call_func()?
Nope. And you shouldn't want to. > (Maybe checking p->pi_lock, but this is not sure the lock owner is this > context?) If not, I need to make this available only for current task > (anyway it just return kretprobe trampoline address, no critical issue) > or, introduce a spinlock. > > Or, eventually it may be better to replace kretprobe/rethook with > fprobe return handler. I'm not sure where you're wanting to go. AFAICT the current rethook stuff won't crash when called on an active task, it might just not give the right results -- but that is true for the entire unwind, so who cares? Those who call unwind on active tasks get to keep the pieces, not our problem etc.
