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@xxxxxxxxxx> 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@xxxxxxxxxx>
