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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox