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

[Crystal Wood <crwood@redhat.com>]

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:
> 
> > [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/

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