On April 17, 2019 5:20:55 PM GMT+02:00, Oleg Nesterov <oleg@xxxxxxxxxx> wrote: >On 04/17, Christian Brauner wrote: >> >> On Wed, Apr 17, 2019 at 04:01:06PM +0200, Oleg Nesterov wrote: >> > On 04/16, Christian Brauner wrote: >> > > >> > > @@ -3581,12 +3588,12 @@ SYSCALL_DEFINE4(pidfd_send_signal, int, >pidfd, int, sig, >> > > if (flags) >> > > return -EINVAL; >> > > >> > > - f = fdget_raw(pidfd); >> > > + f = fdget(pidfd); >> > >> > could you explain this change? >> > >> > I am just curious, I don't understand why should we disallow O_PATH >and how >> > this connects to this patch. >> >> Sending a signal through a pidfd is considered to be on a par with a >> "write" to that pidfd. > >OK, but how this connects to "support pidfds" ? > >> Additionally, we use the fops associated with the fd to detect >whether >> it is actually a pidfd or not. This is not possible with O_PATH since >> f_ops will be set to dummy fops. > >indeed... I didn't know this, thanks! > >But this means that pidfd_send_signal() will return -EBADF with or >without >this change; pidfd_to_pid() will return -EBADF even if fdget_raw() >suceeds, >right? > >To clarify, I am not arguing. I am trying to understand why exactly do >we >need this s/fdget_raw/fdget/ change and, why it doesn't come as a >separate >patch. Can you add a note into the changelog? I should split this into a separate patch indeed. Let me do that for v2. Christian
