[Gluster-devel] FUSE directory filehandle

Amar Tumballi Suryanarayan atumball at redhat.com
Fri Jan 11 08:37:36 UTC 2019

On Thu, Jan 10, 2019 at 8:17 AM Emmanuel Dreyfus <manu at netbsd.org> wrote:

> Hello
> This is not strictly a GlusterFS question since I came to it porting
> LTFS to NetBSD, however I would like to make sure I will not break
> GlusterFS by fixing NetBSD FUSE implementation for LTFS.
> Current NetBSD FUSE implementation sends the filehandle in any FUSE
> requests for an open node, regardless of its type (directory or file).
> I discovered that libfuse low level code manages filehandle differently
> for opendir/readdir/syncdir/releasedir than for other operations. As a
> result, when a getattr is done on a directory, setting the filehandle
> obtained from opendir can cause a crash in libfuse.
> The fix for NetBSD FUSE implementation is to avoid setting the
> filehandle for the following FUSE operations on directories: getattr,
> setattr, poll, getlk, setlk, setlkw, read, write (only the first two
> ones are likely to be actually used, though)
> Does anyone forsee a possible problem for GlusterFS with such a
> behavior? In other words, will it be fine to always have a
> FUSE_UNKNOWN_FH (aka null) filehandle for getattr/setattr on
> directories?
Below is the code snippet from fuse_getattr().

    priv = this->private;
    if (priv->proto_minor >= 9 && fgi->getattr_flags & FUSE_GETATTR_FH)
        state->fd = fd_ref((fd_t *)(uintptr_t)fgi->fh);

Which means, it may crash if we get fd as NULL, when FUSE_GETATTR_FH is set.

> --
> Emmanuel Dreyfus
> http://hcpnet.free.fr/pubz
> manu at netbsd.org
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-devel

Amar Tumballi (amarts)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20190111/67949aac/attachment-0001.html>

More information about the Gluster-devel mailing list