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
next prev parent 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