On Wed, 2 Jul 2025 15:21:11 -0400
Steven Rostedt [off-list ref] wrote:
The only case is if you see a deferred request with id 1 for task 8888,
then you start dropping all events and that task 8888 exits and a new
one appears with task id 8888 where it too has a deferred request with
id 1 then you start picking up events again and see a deferred stack
trace for the new task 8888 where it's id is 1, you lose.
And if we want to fix that, we could make the cookie 64 bit again, and
set the timestamp on the first time it is used for the trace.
union unwind_task_id {
struct {
u32 task_id;
u32 cnt;
}
u64 id;
};
static u64 get_cookie(struct unwind_task_info *info)
{
u32 cnt = READ_ONCE(info->id.cnt);
u32 new_cnt;
if (cnt & 1)
return info->id;
if (unlikely(!info->id.task_id)) {
u32 task_id = local_clock();
cnt = 0;
if (try_cmpxchg(&info->id.task_id, &cnt, task_id))
task_id = cnt;
}
new_cnt = cnt + 3;
if (try_cmpxchg(&info->id, &cnt, new_cnt))
new_cnt = cnt; // try_cmpxchg() expects something
return info->id;
}
So now each task will have its own id and even if we have a task wrap
around, the cookie will never be the same, as fork sets the info->id to
zero.
Yes, the local_clock() can wrap around, but now making all those the
same to cause an issue is extremely unlikely, and still, if it happens,
the worse thing that it causes is that the user space stack trace will
be associated to the wrong events.
-- Steve