Re: [PATCH 1/4] tracing/osnoise: Per-cpu mutex and fd detachment

On Wed, 2026-08-26 at 15:31 -0400, Steven Rostedt wrote:

On Mon, 24 Aug 2026 21:30:37 +0000
sashiko-bot@kernel.org wrote:

quoted

[Severity: High]
Can holding osn_var->lock while calling kthread_stop() cause a deadlock?

kthread_stop() blocks waiting for the target kthread to exit. However, if
the kthread is currently handling a migration request in
osnoise_migration_pending() (shown slightly earlier in the diff), it will
attempt to acquire this same osn_var->lock before it can clear its state and
exit:

This code has a lot of nastiness in the locking with regard to the thread.
I haven't looked deeply at your patch, but the fact that Sashiko pointed
out a possible deadlock I think you may be hitting the mess I was hitting.

Have you looked at this thread: https://lore.kernel.org/all/20240820130001.124768-1-tglozar@redhat.com/ (local)

That thread is about user fd sync, which is what this patch is trying to
address.

This particular deadlock is with kernel threads, in a corner case of
getting migrated even though we try to pin them to one cpu.  We can get
rid of this migration code and just have stop_kthread() take care of it,
adding a get/put_task_struct() so that it's OK for the thread to die
early.  This way we can also handle any other abnormal thread exits.

I'll respond to the rest of the Sashiko comments soon.

It has some tests I ran along with tracing that detected issues. Of course,
everything needs to be run with lockdep enabled too.

I did run with lockdep (and some custom hacky state tracking) but
forcing migration is a hole in my test coverage.

Is there a particular test you're suggesting?

-Crystal