[<prev] [next>] [day] [month] [year] [list]
Message-ID: <2595040c7aeb3f7332c9bd3d7421e16d9465c0a8.camel@kjtsanaktsidis.id.au>
Date: Fri, 30 Dec 2022 23:06:25 +1100
From: KJ Tsanaktsidis <kj@...sanaktsidis.id.au>
To: linux-kernel@...r.kernel.org
Cc: christian@...uner.io
Subject: Why no pidfd's for threads?
Hi all,
I've been working on some performance profiling tooling for Ruby with
eBPF/pref_event_open. I was hoping to be able to use pidfd's from my
profiler process to keep track of when threads from a Ruby program
being profiled had exited. Unfortunately, I was surprised to find out
that pidfd_open can't be used to get fd's for non-thread-group-leaders
(it just returns EINVAL).
The first version of the pidfd_open patch seemed to support this, but
the version finally merged in did not, and I couldn't see any
discussion about _why_ doing this for threads was blocked. It seemed
there were a few warts around pidfd_send_signal directed at threads,
but having the pidfd of a thread seems to be independently useful
without pidfd_send_signal (e.g. - I want to use it to be notified about
thread exits in my profiling tool in a race-free way).
Absent this functionality, I'll have to either live with the race
conditions or use ptrace. The profiler binary has CAP_HWMON and
CAP_BPF, but it having CAP_PTRACE too is substantially scarier!
I was mostly just curious to understand the rationale for why
pidfd_open can't work with threads?
Thanks,
KJ
Powered by blists - more mailing lists