On Tue, 2023-07-11 at 20:01 +1000, NeilBrown wrote: > On Tue, 11 Jul 2023, Chuck Lever III wrote: > > > On Jul 10, 2023, at 6:18 PM, NeilBrown <neilb@xxxxxxx> wrote: > > > > > > What do you think of removing the ability to stop an nfsd thread by > > > sending it a signal. Note that this doesn't apply to lockd or to nfsv4 > > > callback threads. And nfs-utils never relies on this. > > > I'm keen. It would make this patch a lot simpler. > > > > I agree the code base would be cleaner for it. > > > > But I'm the new kid. I'm not really sure if this is > > part of a kernel - user space API that we mustn't > > alter, or whether it's something that was added but > > never used, or .... > > > > I can sniff around to get a better understanding. > > Once upon a time it was the only way to kill the threads. > There was a syscall which let you start some threads. You couldn't > change the number of threads, but you could kill them. > And shutdown always kills processes, so letting nfsd threads be killed > meant that would be removed at system shutdown. > > When I added the ability to dynamically change the number of threads it > made sense that we could set the number to zero, and then to use that > functionality to shut down the nfs server. So the /etc/init.d/nfsd > script changed from "killall -9 nfsd" or whatever it was to > "rpc.nfsd 0". > > But it didn't seem sensible to remove the "kill" functionality until > after a transition process, and I never thought the schedule a formal > deprecation. So it just stayed... > > The more I think about it, the more I am in favour of removing it. I > don't think any other kernel threads can be killed. nfsd doesn't need > to be special. > > Maybe I'll post a patch which just does that. > I'd be in favor of removing signal handling from the nfsd threads. It's always been a bit hacky, particularly since we moved everything to the kthread API around a decade ago. -- Jeff Layton <jlayton@xxxxxxxxxx>
