On Thu, Aug 01, 2024 at 10:01:20AM GMT, Oleg Nesterov wrote:
OK, I won't argue, but ....
On 08/01, Christian Brauner wrote:
On Wed, Jul 31, 2024 at 04:51:33PM GMT, Oleg Nesterov wrote:
On 07/31, Christian Brauner wrote:
It's currently possible to create pidfds for kthreads but it is unclear what that is supposed to mean. Until we have use-cases for it and we figured out what behavior we want block the creation of pidfds for kthreads.
Hmm... could you explain your concerns? Why do you think we should disallow pidfd_open(pid-of-kthread) ?
It basically just works now and it's not intentional - at least not on my part. You can't send signals to them,
Yes, you can't send signals to kthread. So what?
You can't send signals to the normal processes if check_kill_permission() fails. And even if you are root, you can't send an unhandled signal via pidfd = pidfd_open(1).
you may or may not get notified via poll when a kthread exits.
Why? the exiting kthread should not differ in this respect?
Why do you want to allow it? I see zero reason to get a reference to a kthread if there's no use-case for it. kthreads are mostly a kernel thing so why give userspace handles to it. And as I said before, there's userspace out there that's already confused why they can get references to them in the first place.
(So imho this causes more confusion then it is actually helpful. If we add supports for kthreads I'd also like pidfs to gain a way to identify them via statx() or fdinfo.)
/proc/$pid/status has a "Kthread" field...
Going forward, I don't want to force people to parse basic stuff out of procfs. Ideally, they'll be able to mostly rely on pidfd operations only.