Re: [PATCH] kthread: remove kthread_exit()

[Christian Brauner <brauner@kernel.org>]

On Fri, Mar 06, 2026 at 10:27:26AM -0800, Linus Torvalds wrote:
> On Fri, 6 Mar 2026 at 06:44, Christoph Hellwig <hch@infradead.org> wrote:
> >
> > More a comment on the previous patch, but I think exporting do_exit
> > which can work on any task is a really bad idea.
> 
> What is the advantage of a module only being able to do
> kthread_exit(), and not able to do a regular do_exit()?
> 
> I think the only real advantage of having a "kthread_exit()" is that
> it's a nicer name.
> 
> Because if that's the main issue, then I agree that "do_exit()" is
> really not a great name, and it matches a very traditional "this is an
> internal function" naming convention, and not typically a "this is
> what random modules should use".
> 
> So kthread_exit() is a much better name, but it basically *has* to act
> exactly like do_exit(), and adding a limitation to only work on
> kthreads doesn't actually seem like an improvement.
> 
> Why make a function that is intentionally limited with no real
> technical upside? It's not like there's any real reason why a module
> couldn't call exit - we may not have exported it before, but we do
> have code that looks like it *could* be a module that calls do_exit()
> today.
> 
> For example, I'm looking at kernel/vhost_task.c, and the only users
> are things that *are* modules, and it's not hugely obvious that
> there's a big advantage to saying "that task handling has to be
> built-in for those modules".
> 
> So my reaction is that "no, do_exit() is not a great name, but there's
> no real technical upside to havign a separate kthread_exit()"
> function.
> 
> If it's just about naming, maybe we could just unify it all and call
> it "task_exit()" or something?

I have that as a follow-up series... But I didn't want to muddle the two
patches as this one was meant as a clean-up for the kthread_exit()
leftover. Now that you've applied the fixup for the BTF thing directly I
can send both at the same time. Give me a few minutes.

And no, we should definitely not keep kthread_exit() as a separate thing
around. That just seems weird and clearly that has led to bugs before.

The vhost example is good for another reason: the line between a task
acting as a proper kthread and something that is aking to a kthread is
very very blurry by now. Let's ignore usermodehelpers for a minute
(ugh). There's io workers or more generalized - like vhost - user
workers which are hybrid workers that aren't clearly completely
userspace conceptually but also aren't clearly kthreads so I'd not want
to have special-cases for any of them. task_exit() just should to the
right thing no matter what exactly exits. We also have way to many
cleanup hooks that need to be called depending on what precisely exists
to split this over different helpers.