Re: [fuse-devel] clients don't wakeup from poll when filesystem dies.

[Bryan G. <br...@gr...>]

On Tue, 2011-01-18 at 13:58 +0100, Goswin von Brederlow wrote:
> Bryan Green <br...@gr...> writes:
> 
> > On Fri, 2011-01-14 at 18:15 +0100, Goswin von Brederlow wrote:
> >> "Bryan Green" <br...@gr...> writes:
> >> 
> >> > Hello,
> >> >
> >> > I've found that if a fuse filesystem is aborted or the fuse filesystem
> >> > process exits or dies, any processes that are blocked in a 'poll()'
> >> > system call will continue blocking forever or until killed explicitly,
> >> > while processes blocked in read/write system calls wake with an error.
> >> > Is this poll() behavior intentional, or can it be considered a bug?
> >> >
> >> > I've implemented a patch (against linux 2.6.37) that fixes the problem
> >> > and seems to work fine in the few tests I've done, and I'm wondering if
> >> > it is of use.
> >> >
> >> > Thanks,
> >> > -bryan
> >> 
> >> Are you polling for only read/write or also for errors?
> >
> > What do you mean by polling for errors?  The only event types that can
> > be polled for are POLLIN, POLLOUT, and POLLPRI.
> >
> > -bryan
> 
> I was thinking about epoll() not poll(). But even there:
> 
>        EPOLLERR
>               Error  condition  happened  on  the  associated file descriptor.
>               epoll_wait(2) will always wait for this event; it is not neces-
>               sary to set it in events.
> 
> The same should be true for poll and this is implicitly always polled.
> 
> >> 
> >> Also what happens when you umount the FS?
> 
> From your other mail I gather that on umount NOW poll keeps waiting and
> with your patch poll wakes up, right?

Right.  Regardless of how you kill the filesystem, whether by exiting
the fuse userspace process cleanly or abruptly, aborting with fusectl,
or 'umount -f', any processes blocking in poll() will continue blocking
indefinitely.  With my patch, they wake up, just like any processes
blocking on read() would.

-bryan