On Wed, Sep 19, 2018 at 9:50 PM, Nikolaus Rath <Nikolaus@xxxxxxxx> wrote: > On Sep 19 2018, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: >> On Wed, Sep 19, 2018 at 7:03 PM, Nikolaus Rath <Nikolaus@xxxxxxxx> wrote: >>> Hi, >>> >>> Are there any conditions under which a write to the fuse file descriptor >>> may block? >>> >>> It seems to me that this should never be the case - except possibly when >>> sending a FUSE_NOTIFY_INVAL_ENTRY or FUSE_NOTIFY_DELETE request that is >>> related for to an ongoing file system operation. Here would would much >>> appreciate if someone could clarify what operations exactly would cause >>> the write to block. >> >> NOTIFY_INVAL_ENTRY and NOTIFY_DELETE lock the parent directory >> i_mutex. Operations which run under i_mutex of parent are: lookup, >> symlink, mknod, mkdir, unlink, rmdir, rename, link, create, rename2. >> Operations which run under i_mutex of object: setattr, unlink, rmdir, >> rename, setxattr, removexattr, readdir, readdirplus, rename2. > > Thanks! Could you also confirm if that's the only situation where a > write might block? In other words, in all other cases I can safely skip > a select/poll/epoll for writability of fuse fd and be guaranteed that > the write will proceed immediately? Yes. In fact doing poll() on fuse device fd would always return POLLOUT, so it makes no sense to poll for this event. Thanks, Miklos
