Util-Linux package development
 help / color / mirror / Atom feed
From: Karel Zak <kzak@redhat.com>
To: NeilBrown <neilb@suse.com>
Cc: util-linux@vger.kernel.org
Subject: Re: [util-linux PATCH] umount: never 'stat' the path when "-c" is given.
Date: Wed, 7 Jun 2017 12:54:28 +0200	[thread overview]
Message-ID: <20170607105428.2st27zihhwpcnrwi@ws.net.home> (raw)
In-Reply-To: <20170607094451.vcesromvdygstjmw@ws.net.home>

On Wed, Jun 07, 2017 at 11:44:51AM +0200, Karel Zak wrote:
> On Mon, Jun 05, 2017 at 12:32:58PM +1000, NeilBrown wrote:
> > 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);
> 
> I've changed the code to be the mount table filter also usable for
> --no-canonicalize. It seems better to avoid mnt_resolve_path() than
> avoid all the filter.

Hmm... the filter seems like bad optimization for umount, because it
triggers path canonicalization. I did some another changes and umount
should be less aggressive with work with paths now.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

  reply	other threads:[~2017-06-07 10:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-05  2:32 [util-linux PATCH] umount: never 'stat' the path when "-c" is given NeilBrown
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
2017-06-07  9:44 ` Karel Zak
2017-06-07 10:54   ` Karel Zak [this message]
2017-06-09  4:23     ` NeilBrown

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=20170607105428.2st27zihhwpcnrwi@ws.net.home \
    --to=kzak@redhat.com \
    --cc=neilb@suse.com \
    --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