All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Jan Kara <jack@suse.cz>, Jeff Layton <jlayton@kernel.org>,
	Chuck Lever <chuck.lever@oracle.com>,
	Christian Brauner <brauner@kernel.org>,
	linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org
Subject: Re: [PATCH 5/5] exportfs: support encoding non-decodeable file handles by default
Date: Mon, 23 Oct 2023 18:33:08 +0200	[thread overview]
Message-ID: <20231023163308.7szzloiuzzc7lnia@quack3> (raw)
In-Reply-To: <CAOQ4uxhiRU2nNnYtuXUaURMCuYjssC9Rn=ORWW=MmVyMD1H6Rg@mail.gmail.com>

On Mon 23-10-23 16:55:40, Amir Goldstein wrote:
> On Wed, Oct 18, 2023 at 1:00 PM Amir Goldstein <amir73il@gmail.com> wrote:
> >
> > AT_HANDLE_FID was added as an API for name_to_handle_at() that request
> > the encoding of a file id, which is not intended to be decoded.
> >
> > This file id is used by fanotify to describe objects in events.
> >
> > So far, overlayfs is the only filesystem that supports encoding
> > non-decodeable file ids, by providing export_operations with an
> > ->encode_fh() method and without a ->decode_fh() method.
> >
> > Add support for encoding non-decodeable file ids to all the filesystems
> > that do not provide export_operations, by encoding a file id of type
> > FILEID_INO64_GEN from { i_ino, i_generation }.
> >
> > A filesystem may that does not support NFS export, can opt-out of
> > encoding non-decodeable file ids for fanotify by defining an empty
> > export_operations struct (i.e. with a NULL ->encode_fh() method).
> >
> > This allows the use of fanotify events with file ids on filesystems
> > like 9p which do not support NFS export to bring fanotify in feature
> > parity with inotify on those filesystems.
> >
> > Note that fanotify also requires that the filesystems report a non-null
> > fsid.  Currently, many simple filesystems that have support for inotify
> > (e.g. debugfs, tracefs, sysfs) report a null fsid, so can still not be
> > used with fanotify in file id reporting mode.
> >
> > Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> > ---
> 
> Hi Jan,
> 
> Did you get a chance to look at this patch?
> I saw your review comments on the rest of the series, so was waiting
> for feedback on this last one before posting v2.

Ah, sorry. I don't have any further comments regarding this patch besides
what Chuck already wrote.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  reply	other threads:[~2023-10-23 16:33 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-18  9:59 [PATCH 0/5] Support more filesystems with FAN_REPORT_FID Amir Goldstein
2023-10-18  9:59 ` [PATCH 1/5] fanotify: limit reporting of event with non-decodeable file handles Amir Goldstein
2023-10-19 14:22   ` Jan Kara
2023-10-18  9:59 ` [PATCH 2/5] exportfs: add helpers to check if filesystem can encode/decode " Amir Goldstein
2023-10-18 14:15   ` Jeff Layton
2023-10-19 14:23   ` Jan Kara
2023-10-18  9:59 ` [PATCH 3/5] exportfs: make ->encode_fh() a mandatory method for NFS export Amir Goldstein
2023-10-18 14:16   ` Jeff Layton
2023-10-18 14:53     ` Dave Kleikamp
2023-10-18 15:24       ` Amir Goldstein
2023-10-18 15:18   ` Chuck Lever
2023-10-18 15:26     ` Amir Goldstein
2023-10-18 15:36       ` Chuck Lever
2023-10-19 14:40   ` Jan Kara
2023-10-19 15:22     ` Amir Goldstein
2023-10-21 16:48   ` kernel test robot
2023-10-22  3:11   ` kernel test robot
2023-10-18  9:59 ` [PATCH 4/5] exportfs: define FILEID_INO64_GEN* file handle types Amir Goldstein
2023-10-18 14:18   ` Jeff Layton
2023-10-19 14:41   ` Jan Kara
2023-10-18 10:00 ` [PATCH 5/5] exportfs: support encoding non-decodeable file handles by default Amir Goldstein
2023-10-18 14:28   ` Jeff Layton
2023-10-18 15:11     ` Amir Goldstein
2023-10-18 15:27   ` Chuck Lever
2023-10-18 17:19     ` Amir Goldstein
2023-10-23 13:55   ` Amir Goldstein
2023-10-23 16:33     ` Jan Kara [this message]
2023-10-23 16:44       ` Amir Goldstein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231023163308.7szzloiuzzc7lnia@quack3 \
    --to=jack@suse.cz \
    --cc=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.