[Virtio-fs] bug in lo_do_readdir()?

[Laszlo Ersek]

Hi,

I believe lo_do_readdir() has a bug: for FUSE_READDIR (not
FUSE_READDIRPLUS), it does not call lo_do_lookup() -- which seems fine
in itself --, but then it doesn't load the inode into the inode map (?)
*at all*.

A subsequent FUSE_GETATTR that refers to one of the inode(s) learned via
FUSE_READDIR (not FUSE_READDIRPLUS) gets -EBADF, because the requested
inode is not in the map.

Because the inode is shared with the client through the normal (not
"plus") dirent format too (that is, via FUSE_READDIR and not
FUSE_READDIRPLUS), the server should remember the inode(s) from the
FUSE_READDIR request as well, in my opinion.

Sorry if I'm mistaken.

The reason I'm not using FUSE_READDIRPLUS is three-fold:

- one fewer wrapper to implement (I need FUSE_READ anyway, for reading
regular files, and FUSE_READDIR is identical, except for the opcode,
while FUSE_READDIRPLUS isn't),

- FUSE_READDIRPLUS requires feature negotiation, while FUSE_READDIR
doesn't, as far as I understand,

- performance for the firmware is not critical, so I'm fine calling a
separate FUSE_GETATTR on each inode learned through FUSE_READDIR -- I
don't need the attributes to come back together with the dirent.

Unfortunately, I'm not familiar enough with the virtiofsd internals at
this point to propose a patch. It feels like adding a lookup-like, but
lighter-weight, call, to the non-plus branch in lo_do_readdir(), should
do the trick.

Thanks!
Laszlo