On 2018-12-03, Christian Brauner <christian@xxxxxxxxxx> wrote: > > > As I pointed out in another mail my I is to make this work by using > > > file descriptors for /proc/<pid>/task/<tid>. I don't want this in the > > > initial patchset though. I prefer to slowly add those features once > > > we have gotten the basic functionality in. > > > > Do you want to land all this in one kernel release? I wonder how > > applications are supposed to discover kernel support if functionality is > > split across several kernel releases. If you get EINVAL or EBADF, it > > may not be obvious what is going on. > > Sigh, I get that but I really don't want to have to land this in one big > chunk. I want this syscall to go in in a as soon as we can to fulfill > the most basic need: having a way that guarantees us that we signal the > process that we intended to signal. > > The thread case is easy to implement on top of it. But I suspect we will > quibble about the exact semantics for a long time. Even now we have been > on multiple - justified - detrous. That's all pefectly fine and > expected. But if we have the basic functionality in we have time to do > all of that. We might even land it in the same kernel release still. I > really don't want to come of as tea-party-kernel-conservative here but I > have time-and-time again seen that making something fancy and cover ever > interesting feature in one patchset takes a very very long time. > > If you care about userspace being able to detect that case I can return > EOPNOTSUPP when a tid descriptor is passed. Personally, I'm +1 on -EOPNOTSUPP so we can get an MVP merged, and add new features in later patches. > > What happens if you use the new interface with an O_PATH descriptor? > > You get EINVAL. When an O_PATH file descriptor is created the kernel > will set file->f_op = &empty_fops at which point the check I added > if (!proc_is_tgid_procfd(f.file)) > goto err; > will fail. Imho this is correct behavior since technically signaling a > struct pid is the equivalent of writing to a file and hence doesn't > purely operate on the file descriptor level. Not to mention that O_PATH file descriptors are a whole kettle of fish when it comes to permission checking semantics. -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/>
Attachment:
signature.asc
Description: PGP signature
