On Fri, Mar 06, 2026 at 10:27:26AM -0800, Linus Torvalds wrote: > On Fri, 6 Mar 2026 at 06:44, Christoph Hellwig <[email protected]> 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.
