lkml.org 
[lkml]   [2019]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: For review: pidfd_open(2) manual page
    On Mon, Sep 23, 2019 at 12:53:09PM +0200, Florian Weimer wrote:
    > * Michael Kerrisk:
    >
    > > SYNOPSIS
    > > int pidfd_open(pid_t pid, unsigned int flags);
    >
    > Should this mention <sys/types.h> for pid_t?
    >
    > > ERRORS
    > > EINVAL flags is not 0.
    > >
    > > EINVAL pid is not valid.
    > >
    > > ESRCH The process specified by pid does not exist.
    >
    > Presumably, EMFILE and ENFILE are also possible errors, and so is
    > ENOMEM.

    So, error codes that could surface are:
    EMFILE: too many open files
    ENODEV: the anon inode filesystem is not available in this kernel (unlikely)
    ENOMEM: not enough memory (to allocate the backing struct file)
    ENFILE: you're over the max_files limit which can be set through proc

    I think that should be it.

    >
    > > A PID file descriptor can be monitored using poll(2), select(2),
    > > and epoll(7). When the process that it refers to terminates, the
    > > file descriptor indicates as readable. Note, however, that in the
    > > current implementation, nothing can be read from the file descrip‐
    > > tor.
    >
    > “is indicated as readable” or “becomes readable”? Will reading block?
    >
    > > The pidfd_open() system call is the preferred way of obtaining a
    > > PID file descriptor. The alternative is to obtain a file descrip‐
    > > tor by opening a /proc/[pid] directory. However, the latter tech‐
    > > nique is possible only if the proc(5) file system is mounted; fur‐
    > > thermore, the file descriptor obtained in this way is not pol‐
    > > lable.
    >
    > One question is whether the glibc wrapper should fall back back to the
    > /proc subdirectory if it is not available. Probably not.

    No, that would not be transparent to userspace. Especially because both
    fds differ in what can be done with them.

    >
    > > static
    > > int pidfd_open(pid_t pid, unsigned int flags)
    > > {
    > > return syscall(__NR_pidfd_open, pid, flags);
    > > }
    >
    > Please call this function something else (not pidfd_open), so that the
    > example continues to work if glibc provides the system call wrapper.

    Agreed!

    \
     
     \ /
      Last update: 2019-09-23 16:49    [W:4.172 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site