Re: cvs update hangs 'amd' in tstile when 'firefox' is running

[christos%astron.com@localhost (Christos Zoulas)]

In article <Pine.NEB.4.64.1602111506580.1432%david.technoskunk.fur@localhost>,
John D. Baker <jdbaker%mylinuxisp.com@localhost> wrote:
>On Wed, 10 Feb 2016, John D. Baker wrote:
>
>> On Wed, 10 Feb 2016 18:43:38 +0000 (UTC), christos%astron.com@localhost (Christos
>> Zoulas) wrote:
>> 
>> > Unfortunately looks like you'll have to reboot and redo the test to
>> > answer this.
>> 
>> To make it unambiguous, I'll definitely arrange to do this again.
>
>OK, on the same system, still up and no pending shutdown.  The specific
>scenario was that during 'cvs update' on the file server, I switched
>desktop pages (fvwm2) to where my login to the file server was.  When
>I switched back to the page where 'firefox' had its window, it did not
>repaint its window after a substantial interval (and will never again do
>so while the system is up).
>
>There are fewer LWPs in "tstile" as I didn't attempt any other operations
>as soon as it was apparent that 'firefox' (and thus 'amd') had hung.
>I simply 'ssh'ed in as another user whose home directory is not managed
>by 'amd' and initiated 'crash'.

So amd tries to unmount, it is has taken the syncer_mutex and
mp->mnt_unmounting mutex. now it walks the vnode list trying
to vrecycle() all the vnodes, finds a busy one and blocks waiting
to become available.

The syncher (ioflush) task tries to take the syncer_mutex and blocks.

Firefox tries to open a file on the nfs filesystem that is being unmounted
and blocks waiting on mp->mnt_unmounting in vfs_busy().

So the problem is when nfs unmounts. You should be able to reproduce it

mount foo:/foo /foo
cd /foo
umount /foo

Or you might need to open a file for writing and keep it open....

And now umount is stuck and never returns EBUSY. Is that true?
I don't think that firefox or the syncher and involved in the lossage
but seem to be victims of it. I am not an FS locking expert though,
Hannken!!! Help :-)

christos