linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.com>
To: util-linux@vger.kernel.org,
	Linux NFS Mailing list <linux-nfs@vger.kernel.org>
Cc: Franck Bui <fbui@suse.com>
Subject: [util-linux PATCH] umount: never 'stat' the path when "-c" is given.
Date: Mon, 05 Jun 2017 12:32:58 +1000	[thread overview]
Message-ID: <8760gbduzp.fsf@notabene.neil.brown.name> (raw)

[-- Attachment #1: Type: text/plain, Size: 3118 bytes --]


It is currently not possible to reliably and automatically
unmount an NFS filesystem. If the server is not available, the
umount command will hang.

The hang can be avoided by using "-l" or "-f", but neither
of these are appropriate for automatic use such as by an
automounter (e.g automountd or systemd).

"-l" will unmount even if the filesystem is in use, which
an automounter generally doesn't want.  If the filesystem
is in use, then the umount should fail.

"-f" can cause the filesystem to abort pending transactions
which might break filesystem semantics.  This can be useful
in the hands of a sysadmin, but not when used by an
automatic tool.

umount has another option, "-c" aka "--no-canonicalize"
which avoids some "stat" calls.
Currently this doesn't avoid all calls to
canonicalize_path()
as
  mnt_context_prepare_umount() ->
    lookup_umount_fs() ->
      mnt_context_find_umount_fs() ->
        mnt_context_get_mtab_for_target() ->
	  mnt_resolve_path() ->
	    canonicalize_path_and_cache() ->
	      canonicalize_path()

leads to that function being called.

The "-c" option could be taken to mean "I know what I'm
doing, this really is the path to a mount point, I just want
you to unmount it".  Given that, it seems suitable to
extend this to avoid all 'stat' calls on the mountpoint.

It is already appropriate for any automount program to pass
"-c" to "umount", so they can be changed to do so at any
time.
With the patch below, "-c" will result in the mountpoint
never being "stat"ed, so umount won't hang on an
inaccessible server.

This isn't quite sufficient, for NFS at least, as the usage
of libmount in umount.nfs still calls 'stat' on the mount
point.
"-c" isn't passed to the umount helper, but it is reasonable
for such helpers to assume "-c" because "umount" will have
canonicalized the path when that is appropriate.

So, this patch treats "-c" much like "-l" and "-f" when
deciding whether it is safe to 'stat' the path.

Signed-off-by: NeilBrown <neilb@suse.com>
---
 libmount/src/context_umount.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libmount/src/context_umount.c b/libmount/src/context_umount.c
index e663a703cca0..693891def0e1 100644
--- a/libmount/src/context_umount.c
+++ b/libmount/src/context_umount.c
@@ -77,6 +77,7 @@ int mnt_context_find_umount_fs(struct libmnt_context *cxt,
 	 * it's usable only for canonicalized stuff (e.g. kernel mountinfo).
 	 */
 	if (!mnt_context_mtab_writable(cxt) && *tgt == '/' &&
+	    !mnt_context_is_nocanonicalize(cxt) &&
 	    !mnt_context_is_force(cxt) && !mnt_context_is_lazy(cxt))
 		rc = mnt_context_get_mtab_for_target(cxt, &mtab, tgt);
 	else
@@ -245,6 +246,7 @@ static int lookup_umount_fs(struct libmnt_context *cxt)
 	    && !mnt_context_mtab_writable(cxt)
 	    && !mnt_context_is_force(cxt)
 	    && !mnt_context_is_lazy(cxt)
+	    && !mnt_context_is_nocanonicalize(cxt)
 	    && !mnt_context_is_loopdel(cxt)
 	    && mnt_stat_mountpoint(tgt, &st) == 0 && S_ISDIR(st.st_mode)
 	    && !has_utab_entry(cxt, tgt)) {
-- 
2.12.2


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

             reply	other threads:[~2017-06-05  2:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-05  2:32 NeilBrown [this message]
2017-06-05  2:38 ` [nfs-utils PATCH] umount.nfs: assume path name is canonical NeilBrown
2017-06-13 12:40   ` Steve Dickson
2017-06-06  9:43 ` [util-linux PATCH] umount: never 'stat' the path when "-c" is given 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=8760gbduzp.fsf@notabene.neil.brown.name \
    --to=neilb@suse.com \
    --cc=fbui@suse.com \
    --cc=linux-nfs@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).