Re: [bug report] fanotify: support reporting non-decodeable file handles

[Jeff Layton <jlayton@kernel.org>]

On Thu, 2023-05-25 at 12:48 +0300, Amir Goldstein wrote:
> On Thu, May 25, 2023 at 12:26 PM Dan Carpenter <dan.carpenter@linaro.org> wrote:
> > 
> > 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).
> > 
> > ceph_encode_fh() can return -EINVAL
> 
> Ouch! thanks for pointing this out
> 
> Jeff,
> 
> In your own backyard ;-)
> Do you think this new information calls for rebasing my fix on top of master
> and marking it for stable? or is this still low risk in your opinion?
> 

(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.
-- 
Jeff Layton <jlayton@kernel.org>