Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp929314pxk; Thu, 3 Sep 2020 17:02:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzoMBD/oxXOGdTDXN4RlMH4o3Bde7zcr/u+W5dl6vcW4uZydvz+ZEW0YGdlEJKBacSkZIGB X-Received: by 2002:a17:906:1404:: with SMTP id p4mr4709462ejc.256.1599177748771; Thu, 03 Sep 2020 17:02:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599177748; cv=none; d=google.com; s=arc-20160816; b=iwipCDOZzbo6AGm3+oRMEmDzKVyYf4ynb1JfW6VrBihChBE/EOiP8bDoYgk/Ok7oM+ MUdhHTtqKr3TdEIvne+sR5MiNEth1yuzsBWFzep8PuIJmYUzEcsaZMoURp2Lwsn+H1Fk dEJnrrZicguTsApURdh7ZV/MFnwarN3WBxWNtq5spd6eqHny8wmz5cbm+8PaQ5Ji3Q9H Gta2jm8D/310VR2c8Kz6JIAm6av3mRTC2h2B1ENSm6NxaGHTX0w9RwwBpRYJqHndp0tW +lVQFY/8tB0p9484Z3TabIvyLJ5BlHGxEvcYKE9zBKFCJ/BWzNDGKu6Zc+Bi0Q8CEhXI 4Uxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=g6KkxgvtXitwB3MZgW5m5d+kMsV0xwDTX+WW8LWHHiw=; b=dntq8yHxZ3LsIQxOrw1wTKMDj47NNLtRHHEFBzeQPLDQCeHFQ9QwosxTuQhZ4IyKp3 U4qCzOnGQFpblfJRSKp+6cpakEpChNL74+KOT5CKFfddmODfc3EKT8SgRXG5Eoaj9P/d CKA//18FgqLR33IUyOfpXHOihEvb+ZK3B9QdfPoWf14BclBl67ooZIUlhLfh+8bTvrM9 PnvPs8RXIFFF75JvenO4P5jrcDJ008d2vUdPj/zLxUX3HSJaVfQfkMYMXg1qoVDTKcW9 1TRcIaUJRvPIt/fZUjIFDyDLUPf3d9TUrPuKKOm9dW+zNzohbaap5LMSeT06DZapyd81 Q5GA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cb15si2925993ejb.366.2020.09.03.17.02.05; Thu, 03 Sep 2020 17:02:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729455AbgICX7H (ORCPT + 99 others); Thu, 3 Sep 2020 19:59:07 -0400 Received: from relay9-d.mail.gandi.net ([217.70.183.199]:37095 "EHLO relay9-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725782AbgICX7G (ORCPT ); Thu, 3 Sep 2020 19:59:06 -0400 X-Originating-IP: 50.39.163.217 Received: from localhost (50-39-163-217.bvtn.or.frontiernet.net [50.39.163.217]) (Authenticated sender: josh@joshtriplett.org) by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id 9458CFF802; Thu, 3 Sep 2020 23:58:58 +0000 (UTC) Date: Thu, 3 Sep 2020 16:58:55 -0700 From: Josh Triplett To: Christian Brauner Cc: linux-kernel@vger.kernel.org, Christian Brauner , "Peter Zijlstra (Intel)" , Ingo Molnar , Thomas Gleixner , Oleg Nesterov , "Eric W. Biederman" , Kees Cook , Sargun Dhillon , Aleksa Sarai , linux-kselftest@vger.kernel.org, Jens Axboe , linux-api@vger.kernel.org Subject: Re: [PATCH v2 0/4] Support non-blocking pidfds Message-ID: <20200903235855.GD210207@localhost> References: <20200902102130.147672-1-christian.brauner@ubuntu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200902102130.147672-1-christian.brauner@ubuntu.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 02, 2020 at 12:21:26PM +0200, Christian Brauner wrote: > Hi, > > Passing a non-blocking pidfd to waitid() currently has no effect, i.e. > is not supported. There are users which would like to use waitid() on > pidfds that are O_NONBLOCK and mix it with pidfds that are blocking and > both pass them to waitid(). > The expected behavior is to have waitid() return -EAGAIN for > non-blocking pidfds and to block for blocking pidfds without needing to > perform any additional checks for flags set on the pidfd before passing > it to waitid(). > Non-blocking pidfds will return EAGAIN from waitid() when no child > process is ready yet. Returning -EAGAIN for non-blocking pidfds makes it > easier for event loops that handle EAGAIN specially. > > It also makes the API more consistent and uniform. In essence, waitid() > is treated like a read on a non-blocking pidfd or a recvmsg() on a > non-blocking socket. > With the addition of support for non-blocking pidfds we support the same > functionality that sockets do. For sockets() recvmsg() supports > MSG_DONTWAIT for pidfds waitid() supports WNOHANG. Both flags are > per-call options. In contrast non-blocking pidfds and non-blocking > sockets are a setting on an open file description affecting all threads > in the calling process as well as other processes that hold file > descriptors referring to the same open file description. Both behaviors, > per call and per open file description, have genuine use-cases. > > A concrete use-case that was brought on-list (see [1]) was Josh's async > pidfd library. Ever since the introduction of pidfds and more advanced > async io various programming languages such as Rust have grown support > for async event libraries. These libraries are created to help build > epoll-based event loops around file descriptors. A common pattern is to > automatically make all file descriptors they manage to O_NONBLOCK. > > For such libraries the EAGAIN error code is treated specially. When a > function is called that returns EAGAIN the function isn't called again > until the event loop indicates the the file descriptor is ready. > Supporting EAGAIN when waiting on pidfds makes such libraries just work > with little effort. Thanks for the patch series, Christian! This will make it much easier to use pidfd in non-blocking event loops. Reviewed-by: Josh Triplett - Josh Triplett