Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <7703ca436bb99e1b1e468863720a19e159ef2285.camel@kernel.org>
Subject: Re: [bug report] fanotify: support reporting non-decodeable file
 handles
From:   Jeff Layton <jlayton@kernel.org>
To:     Amir Goldstein <amir73il@gmail.com>,
        Dan Carpenter <dan.carpenter@linaro.org>,
        Xiubo Li <xiubli@redhat.com>
Cc:     Jan Kara <jack@suse.cz>, linux-fsdevel@vger.kernel.org,
        Chuck Lever <cel@kernel.org>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Date:   Thu, 25 May 2023 06:19:51 -0400
In-Reply-To: <CAOQ4uxgA-kQOOp69pyKhQpMZZuyWZ0t6ir+nqL4yL9wX5CBNgQ@mail.gmail.com>
References: <ca02955f-1877-4fde-b453-3c1d22794740@kili.mountain>
         <CAOQ4uxi6ST19WGkZiM=ewoK_9o-7DHvZcAc3v2c5GrqSFf0WDQ@mail.gmail.com>
         <20230524140648.u6pexxspze7pz63z@quack3>
         <080107ac-873c-41dc-b7c7-208970181c40@kili.mountain>
         <CAOQ4uxgA-kQOOp69pyKhQpMZZuyWZ0t6ir+nqL4yL9wX5CBNgQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.1 (3.48.1-1.fc38) 
MIME-Version: 1.0
Precedence: bulk

On Thu, 2023-05-25 at 12:48 +0300, Amir Goldstein wrote:
> On Thu, May 25, 2023 at 12:26=E2=80=AFPM Dan Carpenter <dan.carpenter@lin=
aro.org> wrote:
> >=20
> > On Wed, May 24, 2023 at 04:06:48PM +0200, Jan Kara wrote:
> > > Yes, I've checked and all ->encode_fh() implementations return
> > > FILEID_INVALID in case of problems (which are basically always only
> > > problems with not enough space in the handle buffer).
> >=20
> > ceph_encode_fh() can return -EINVAL
>=20
> Ouch! thanks for pointing this out
>=20
> Jeff,
>=20
> In your own backyard ;-)
> Do you think this new information calls for rebasing my fix on top of mas=
ter
> and marking it for stable? or is this still low risk in your opinion?
>=20

(cc'ing Xiubo in case he has thoughts here)

It looks like that mainly happens when trying to encode the fh for a
snapshot inode, if you can't find a dentry for it, or if it's not a
directory inode and it has no parent.

The logic of the ceph snapshot code has always escaped me,
unfortunately, and I don't have a good feel for how likely this is. It
seems like it's a non-zero chance though, and this patch is unlikely to
harm anything so marking it for stable might be a good idea.
--=20
Jeff Layton <jlayton@kernel.org>