On Mon, Apr 26, 2021 at 09:08:32AM -0700, Shakeel Butt wrote: > On Mon, Apr 26, 2021 at 8:29 AM Christian Brauner > <christian.brauner@xxxxxxxxxx> wrote: > > > [...] > > > Have you considered accepting a cgroup fd to pidfd_send_signal and > > > realize this operation through this syscall? (Just asking as it may > > > prevent some of these consequences whereas bring other unclarities.) > > > > That's semantically quite wrong on several fronts, I think. > > pidfd_send_signal() operates on pidfds (and for a quirky historical > > reason /proc/<pid> though that should die at some point). Making this > > operate on cgroup fds is essentially implicit multiplexing which is > > pretty nasty imho. In addition, this is a cgroup concept not a pidfd > > concept. > > What's your take on a new syscall cgroupfd_send_signal()? One > complexity would be potentially different semantics for v1 and v2. I would think that this will be labeled overkill and has - imho - almost zero chance of being accepted. You'd essentially need to argue that it's sensible for a (virtual) filesystem to have a separate syscall or syscalls (a signal sending one at that). In addition you'd break the filesystem api model that cgroups are designed around which seems unpleasant. (And fwiw, an ioctl() would have the same issues though it has precedence if you look at nsfs. But nsfs doesn't have any real filesystem interaction model apart from being open()able and is basically a broken out part from procfs.)
