umount() taking minutes for FUSE filesystems

[Martin Simmons]

>>>>> On Tue, 05 Sep 2017 11:38:18 +0200, Nikolaus Rath said:
> 
> On Sep 05 2017, Stefan Esser <se at freebsd.org> wrote:
> > Am 04.09.17 um 23:14 schrieb Ben RUBSON:
> >> I managed to reproduce the issue.
> >> unmount takes exactly 60 seconds, as if a timeout was running.
> >> 
> >> # procstat -kk $!
> >> COMM     TDNAME KSTACK                       
> >> printcap - mi_switch+0xd2 sleepq_catch_signals+0xb7
> >> sleepq_timedwait_sig+0x10 _sleep+0x26f fdisp_wait_answ+0x171
> >> fuse_vfsop_unmount+0xf5 dounmount+0x9b6 sys_unmount+0x41b
> >> amd64_syscall+0x4ce Xfast_syscall+0xfb
> >> 
> >> # uname -sr
> >> FreeBSD 11.0-RELEASE-p9
> >
> > I have given the exact position of this 60 second msleep() in multiple
> > mails before. It is in fuse_ipc.c, the particular msleep with "fu_ans"
> > (line 333 in -CURRENT).
> >
> > I did not try to diagnose, why this particular umount() takes so long,
> > while others are fast, but it is obvious that the kernel module does
> > wait for a signal at the end of some IPC and the signal is either lost
> > or never sent. There is a check for a dead connection, just before the
> > msleep() and the connection is considered alive at that point (and
> > should be, to support the umount() result being reported).
> >
> > I did not have time to look into this during the previous week and
> > won't during this week, but it should not be too hard to see, what's
> > going on. A starting point could be to compare this test with those
> > that perform the unmount without delay.
> 
> Probably the crucial difference is that the test that takes long exits
> its main loop on its own and then informs the FUSE kernel module about
> that, while the other tests terminate the main loop because the kernel
> module tells them to do so.

What does "informs the FUSE kernel module about that" do to inform it?

__Martin