From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-25.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FSL_HELO_FAKE, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8D22CC07E95 for ; Wed, 14 Jul 2021 00:18:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6CED66136D for ; Wed, 14 Jul 2021 00:18:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237075AbhGNAVr (ORCPT ); Tue, 13 Jul 2021 20:21:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37422 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236981AbhGNAVp (ORCPT ); Tue, 13 Jul 2021 20:21:45 -0400 Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7F464C0613E9 for ; Tue, 13 Jul 2021 17:18:53 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id w15so104309pgk.13 for ; Tue, 13 Jul 2021 17:18:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=YILuWyfe6GXFMlRrJeKo1swCAPgOg98yYVF694DdW9c=; b=DLuisV1WS2RpGvQlO2Aa4nIdiMWqgkdMBJUbSkZLO4M9s4foQSYyLHt716KoYZTyzi Z60iKjkuUi3RVq93kM/ZxsDdl0iS2rc5M4PlZq9A/CfBi6ne4TteVfrF9SEda34v0n8+ 1uZFbVgt481yKtQNHy6aBIbHGlrg+p54q8gTVp7VMoYzDI+zYlSkEvZr9kovd+pDA2Hj Vosap6dfuLIruXFveMPh7NJDGPE6uCxvGJeNZnYjbCI8BK4WFjHlh5/dO2MBlam/76qu yirys4TvoG2eam4YI3DshdtmzrplbOI33J0cJKM+S6/lnElddsEotsIphab/ZvYCcxiP Edkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=YILuWyfe6GXFMlRrJeKo1swCAPgOg98yYVF694DdW9c=; b=hRXHF6yVKu8u83/rNZH7osBzI+PLdJcOH6GFFwSqZLD/DldvPs7tUGxV2mX8cvrrrH v7tPFTYH7wtlSJS4Drayj+5A0FhKJSqVO4cM6n03co/nojZqnGMpCm6aKh97/PgAlaLA odGNSy6cUwFIUKYy6cWyTbH7ET550LvkjnKBEpH1xY27Ln9ic3ZGxiR52XsDXTM30IGE pjAir7d++HMDWT02EnpJiS4Q7t2twioPdeQyt1iqF5Lw9erLeL9FCt+Pc4do1PR/+ouX CX3lsIyxOqxMr91hL49uyKEGYvOc2R/gmc2/93g1CVEBAx03ATCE2vEXApF8z8HiPm4f ve+Q== X-Gm-Message-State: AOAM5325eAcGsnZBf7CLjN+qTTLpAo2s0U14i7ecyKsNEm5IUlYSEg8O lkkfEfIw4RpoPrt1q4h0yFAkDA== X-Google-Smtp-Source: ABdhPJxP6oXW9qMSQZPX4GuDh0/MR5PX5zS82dm9IkkJzfnsBDoKAftmOzZ9RgOYiv300rqMotvIdA== X-Received: by 2002:a65:508a:: with SMTP id r10mr6678627pgp.96.1626221932808; Tue, 13 Jul 2021 17:18:52 -0700 (PDT) Received: from google.com ([2401:fa00:9:211:8048:54c2:c50c:3d93]) by smtp.gmail.com with ESMTPSA id t5sm266384pgb.58.2021.07.13.17.18.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Jul 2021 17:18:52 -0700 (PDT) Date: Wed, 14 Jul 2021 10:18:40 +1000 From: Matthew Bobrowski To: Amir Goldstein Cc: Jan Kara , Christian Brauner , linux-fsdevel , Linux API Subject: Re: [PATCH v2 5/5] fanotify: add pidfd support to the fanotify API Message-ID: References: <7f9d3b7815e72bfee92945cab51992f9db6533dd.1623282854.git.repnop@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Sat, Jul 10, 2021 at 05:49:57PM +0300, Amir Goldstein wrote: > On Thu, Jun 10, 2021 at 3:22 AM Matthew Bobrowski wrote: > > > > Introduce a new flag FAN_REPORT_PIDFD for fanotify_init(2) which > > allows userspace applications to control whether a pidfd info record > > containing a pidfd is to be returned with each event. > > > > If FAN_REPORT_PIDFD is enabled for a notification group, an additional > > struct fanotify_event_info_pidfd object will be supplied alongside the > > generic struct fanotify_event_metadata within a single event. This > > functionality is analogous to that of FAN_REPORT_FID in terms of how > > the event structure is supplied to the userspace application. Usage of > > FAN_REPORT_PIDFD with FAN_REPORT_FID/FAN_REPORT_DFID_NAME is > > permitted, and in this case a struct fanotify_event_info_pidfd object > > will follow any struct fanotify_event_info_fid object. > > > > Currently, the usage of FAN_REPORT_TID is not permitted along with > > FAN_REPORT_PIDFD as the pidfd API only supports the creation of pidfds > > for thread-group leaders. Additionally, the FAN_REPORT_PIDFD is > > limited to privileged processes only i.e. listeners that are running > > with the CAP_SYS_ADMIN capability. Attempting to supply either of > > these initialisation flags with FAN_REPORT_PIDFD will result with > > EINVAL being returned to the caller. > > > > In the event of a pidfd creation error, there are two types of error > > values that can be reported back to the listener. There is > > FAN_NOPIDFD, which will be reported in cases where the process > > responsible for generating the event has terminated prior to fanotify > > being able to create pidfd for event->pid via pidfd_create(). The > > there is FAN_EPIDFD, which will be reported if a more generic pidfd > > creation error occurred when calling pidfd_create(). > > > > Signed-off-by: Matthew Bobrowski > > > > [...] > > > diff --git a/include/uapi/linux/fanotify.h b/include/uapi/linux/fanotify.h > > index fbf9c5c7dd59..5cb3e2369b96 100644 > > --- a/include/uapi/linux/fanotify.h > > +++ b/include/uapi/linux/fanotify.h > > @@ -55,6 +55,7 @@ > > #define FAN_REPORT_FID 0x00000200 /* Report unique file id */ > > #define FAN_REPORT_DIR_FID 0x00000400 /* Report unique directory id */ > > #define FAN_REPORT_NAME 0x00000800 /* Report events with name */ > > +#define FAN_REPORT_PIDFD 0x00001000 /* Report pidfd for event->pid */ > > > > Matthew, > > One very minor comment. > I have a patch in progress to add FAN_REPORT_CHILD_FID (for reporting fid > of created inode) and it would be nice if we can reserve the flag space in the > same block with the rest of the FID flags. > > If its not a problem, maybe we could move FAN_REPORT_PIDFD up to 0x80 > right above FAN_REPORT_TID, which also happen to be related flags. That's fine by me, no objections. Updated my patch series with the updated flag value [0]. [0] https://github.com/matthewbobrowski/linux/commit/02ba3581fee21c34bd986e093d9eb0b9897fa741#diff-c83e05fe10af36146658416e55756f304a099606f4a2b18d2fcb683b277c3c62R54 /M