On Wed, 2026-08-26 at 15:31 -0400, Steven Rostedt wrote: > On Mon, 24 Aug 2026 21:30:37 +0000 > [email protected] 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/[email protected]/
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
