From: Konstantin Khlebnikov <khlebnikov@parallels.com>
To: util-linux <util-linux@vger.kernel.org>, <khlebnikov@openvz.org>
Subject: Re: [BUG] umount does not work for disconected nfs mounts
Date: Tue, 28 Jun 2011 13:14:46 +0400 [thread overview]
Message-ID: <4E099B86.1030802@parallels.com> (raw)
In-Reply-To: <20110628085724.GE22770@foxbat.suse.cz>
Petr Uzel wrote:
> On Tue, Jun 28, 2011 at 12:18:03PM +0400, Konstantin Khlebnikov wrote:
>> commit 33cee6675edecbd27c0628f8b7c74c7d88fc02b2
>> http://git.kernel.org/?p=utils/util-linux/util-linux-ng.git;a=commitdiff;h=33cee6675edecbd27c0628f8b7c74c7d88fc02b2;hp=fde25e6be6e00a0998eb58b4b9d0d0b9ad65dbfd
>> "umount: allow unmounting loopdev specified by associated file"
>> broke umounting (by mountpoint) for broken nfs mounts,
>> because now umount always call stat() for target argument and umount hang inside nfs-rpc:
>>
>> [<ffffffff8163df3f>] rpc_wait_bit_killable+0x1f/0x40
>> [<ffffffff8163eb85>] __rpc_execute+0xe5/0x2f0
>> [<ffffffff8163eebe>] rpc_execute+0x3e/0x50
>> [<ffffffff816372f0>] rpc_run_task+0x70/0x90
>> [<ffffffff816373fe>] rpc_call_sync+0x3e/0x70
>> [<ffffffff812228f3>] nfs3_rpc_wrapper.constprop.11+0x43/0x70
>> [<ffffffff81223bd2>] nfs3_proc_getattr+0x42/0x80
>> [<ffffffff81212955>] __nfs_revalidate_inode+0x95/0x1f0
>> [<ffffffff81212bf1>] nfs_revalidate_inode+0x31/0x60
>> [<ffffffff81212cca>] nfs_getattr+0x5a/0x110
>> [<ffffffff8112caea>] vfs_getattr+0x1a/0x30
>> [<ffffffff8112cce3>] vfs_fstatat+0x53/0x70
>> [<ffffffff8112cd36>] vfs_stat+0x16/0x20
>> [<ffffffff8112d0c5>] sys_newstat+0x15/0x30
>> [<ffffffff816c45bb>] tracesys+0xd9/0xde
>> [<ffffffffffffffff>] 0xffffffffffffffff
>
> Shouldn't this be handled in the kernel? Or is stat() really
> supposed to fail in such way with broken nfs?
It depends on used mount options, IIRR in "soft" mode it by default fail with EIO after 3-6 minutes timeout,
in "hard" mode syscalls never returns EIO.
BTW linux support bindmounting for individual files,
so argument can refer to regular file not only for loop device image.
>
>>
>> so mount /mnt/nfs get stuck, umounting by device is still possible.
>
> We might first scan through mtab to check if umount arg is known
> mountpoint and only if we fail, we would look for associated loopfile.
Yes, it seems is the best solution
>
> Karel?
>
>
> Petr
>
> --
> Petr Uzel
> IRC: ptr_uzl @ freenode
next prev parent reply other threads:[~2011-06-28 9:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-28 8:18 [BUG] umount does not work for disconected nfs mounts Konstantin Khlebnikov
2011-06-28 8:57 ` Petr Uzel
2011-06-28 9:14 ` Konstantin Khlebnikov [this message]
2011-06-29 6:44 ` Mike Frysinger
2011-06-29 6:40 ` Karel Zak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E099B86.1030802@parallels.com \
--to=khlebnikov@parallels.com \
--cc=khlebnikov@openvz.org \
--cc=util-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.