Re: pidfd_open.2: PIDFD_NONBLOCK is not defined by the listed headers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, May 20, 2024 at 07:02:39AM GMT, Emanuele Torre wrote:
> Hello.

Hi Emanuele,

> pidfd_open(2) only lists sys/syscall.h and unistd.h in its SYNOPSYS:
> 
>   SYNOPSIS
>          #include <sys/syscall.h>      /* Definition of SYS_* constants */
>          #include <unistd.h>
> 
>          int syscall(SYS_pidfd_open, pid_t pid, unsigned int flags);
> 
>          Note:  glibc provides no wrapper for pidfd_open(), necessitating
>          the use of syscall(2).
> 
> Then it mentions PIDFD_NONBLOCK as one of its flags:
> 
>   PIDFD_NONBLOCK (since Linux 5.10)
>          Return  a nonblocking file descriptor.  If the process referred
>          to by the file descriptor has not yet terminated, then  an  at‐
>          tempt to wait on the file descriptor using waitid(2) will imme‐
>          diately return the error EAGAIN rather than blocking.
> 
> But PIDFD_NONBLOCK is not defined in any of the listed headers.

Hmmm.  Thanks!  We need to add its header.

> I have noticed that PIDFD_NONBLOCK is the same value as O_NONBLOCK,
> so perhaps this flag could be listed as
> 
>   O_NONBLOCK or PIDFD_NONBLOCK (since Linux 5.10)
> 
> like O_NDELAY and O_NONBLOCK in open.2.
> 
> This way the user would know that O_NONBLOCK may be used instead of
> PIDFD_NONBLOCK if PIDFD_NONBLOCK is not available.

No.  That's an implementation detail, which shouldn't be abused.

> I have also noticed that GNU libc (in its linux-api-headers submodule)
> provides a linux/pidfd.h header that just defines PIDFD_NONBLOCK as
> O_NONBLOCK, perhaps another solution would be to list in linux/pidfd.h
> in the synopsis and say it is required to use PIDFD_NONBLOCK.

Yep, that's the kernel uapi header.  I didn't know glibc redistributes
those.

Anyway, we should indeed include <linux/pidfd.h> for this macro.

> Then, I also noticed that GNU libc now also provides the sys/pidfd.h
> header with the definition of PIDFD_NONBLOCK, and prototypes for
> pidfd_open, pidfd_send_signal, pidfd_getfd, and also a prototype for
> pidfd_getpid that is an helper function that parses the "Pid:" field
> from /proc/self/fdinfo/FD and currently does not have a man page.

Hmmm, I've CCed glibc for a question:  When you provide a macro like
this one, without providing a syscall wrapper, should we include the
glibc header or the kernel one?  Do you provide all kernel uapi macros,
or just select ones?

> 
> So probably the best solution is to just make the pidfd_open(2),
> pidfd_send_signal(2), and pidfd_getfd(2) man pages tell users to include
> sys/pidfd.h and call the GNU libc functions instead of including
> sys/syscall.h and unistd.h and calling syscall(2) directly; now that
> sys/pidfd.h exists.

Ahh, interesting.  I'm using glibc 2.38 and still don't have that one.
It seems added in 2.39.  We can directly document that in
pidfd_getfd(2).

> And maybe to also add a pidfd_getpid(3) man page for the new pidfd
> helper function.

No, usually we document the glibc wrapper in man2, unless there's a big
difference between the kernel syscall and the glibc wrapper.

Thanks for the detailed report!

Have a lovely day!
Alex

> 
> 
> o/
>  emanuele6

-- 
<https://www.alejandro-colomar.es/>

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux