From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-f195.google.com ([209.85.214.195]:34969 "EHLO mail-pl1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729062AbeLKGMv (ORCPT ); Tue, 11 Dec 2018 01:12:51 -0500 Received: by mail-pl1-f195.google.com with SMTP id p8so6444887plo.2 for ; Mon, 10 Dec 2018 22:12:50 -0800 (PST) Date: Tue, 11 Dec 2018 17:12:42 +1100 From: Matthew Bobrowski To: Jan Kara Cc: Amir Goldstein , linux-fsdevel , linux-api@vger.kernel.org Subject: Re: [PATCH v4 08/15] fanotify: enable FAN_REPORT_FID init flag Message-ID: <20181211061240.GA16052@lithium.mbobrowski.org> References: <20181202113826.32133-1-amir73il@gmail.com> <20181202113826.32133-9-amir73il@gmail.com> <20181210162038.GQ29289@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181210162038.GQ29289@quack2.suse.cz> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Dec 10, 2018 at 05:20:38PM +0100, Jan Kara wrote: > On Sat 08-12-18 11:26:38, Amir Goldstein wrote: > > On Sun, Dec 2, 2018 at 1:38 PM Amir Goldstein wrote: > > > > > > When setting up an fanotify listener, user may request to get fid > > > information in event instead of an open file descriptor. > > > > > > The fid obtained with event on a watched object contains the file > > > handle returned by name_to_handle_at(2) and fsid returned by statfs(2). > > > > > > When setting a mark, we need to make sure that the filesystem > > > supports encoding file handles with name_to_handle_at(2) and that > > > statfs(2) encodes a non-zero fsid. > > > > > > > Jan, > > > > On a discussion with Matthew about tests he is writing for FAN_REPORT_TID, > > the issue of permission events came up. > > Since I am not aware of any specific benefit that FAN_REPORT_TID could > > bring to users of permission events, I think the best course of action is to > > limit the use of FAN_REPORT_TID to group with priority FAN_CLASS_NOTIF. > > That would simplify tests and man page and if we ever see a use case for > > anything else, we can add that in the future. > > > > If you agree, we should add something like this to this patch: > > Yeah, that's a good point. Agreed. OK, good to know. I will continue to write the FAN_REPORT_FID tests based on Amir's fanotify_dirent branch, which contains the amendment suggested below. Amir, presumably we should also have a separate test that covers the expected error result when FAN_REPORT_FID is supplied with invalid class bits? > > --- a/fs/notify/fanotify/fanotify_user.c > > +++ b/fs/notify/fanotify/fanotify_user.c > > @@ -768,6 +768,10 @@ SYSCALL_DEFINE2(fanotify_init, unsigned int, > > flags, unsigned int, event_f_flags) > > return -EINVAL; > > } > > > > + if ((flags & FAN_REPORT_FID) && > > + (flags & FANOTIFY_CLASS_BITS) != FAN_CLASS_NOTIF) > > + return -EINVAL; > > + > > user = get_current_user(); > > if (atomic_read(&user->fanotify_listeners) > > > FANOTIFY_DEFAULT_MAX_LISTENERS) { > > free_uid(user); -- Matthew Bobrowski