From: Martin Wilck <mwilck@suse.com>
To: Julian Andres Klode <julian.klode@canonical.com>
Cc: dm-devel@redhat.com
Subject: Re: [PATCH] kpartx: Improve finding loopback device by file
Date: Mon, 05 Feb 2018 18:07:13 +0100 [thread overview]
Message-ID: <1517850433.14196.63.camel@suse.com> (raw)
In-Reply-To: <20180205154622.axv3cv5wxot3hmbx@jak-x230>
On Mon, 2018-02-05 at 16:46 +0100, Julian Andres Klode wrote:
> On Mon, Feb 05, 2018 at 04:12:00PM +0100, Martin Wilck wrote:
> >
> > Can we agree on the following:
> >
> > 1 if realpath (filename) results in error, abort
>
> OK
>
>
> > 2 if realpath(lo_name) results in ENODEV and filename matches
> > lo_name,
> > remove loop device
> > 3 if realpath(lo_name) results in another error code, skip it
> > 4 remove if realpath(filename) matches realpath(lo_name)
>
>
> This seems like a lot of ifs. It might be easier to just path if
> realpath(path) fails (as realpath(1) does), something like:
>
>
> char *loopname = loopinfo.lo_name;
> if (realpath(loopinfo.lo_name, rloopfilename) != NULL)
> loopname = rloopfilename;
>
> if (0 == strcmp(filename, loopinfo.lo_name) ||my
0 == strcmp(rfilename, loopname))) {
> found = realpath(path, NULL);
> break;
> }
>
>
> That should solve all problems and produce useful results with not
> a lot of logic.
I've reproduced your issue. I can see that the current behavior is
wrong.
This may be paranoid, but I really want to avoid false positives -
kpartx removing mappings it isn't supposed to remove. Therefore I'd
like to avoid compare by "filename" and "loopname". I think it's
possible.
IMO it would be better to have kpartx use the realpath while *creating*
the partition mapping already:
--- a/kpartx/kpartx.c
+++ b/kpartx/kpartx.c
@@ -341,7 +341,7 @@ main(int argc, char **argv){
if (!loopdev) {
loopdev = find_unused_loop_device();
- if (set_loop(loopdev, device, 0, &ro)) {
+ if (set_loop(loopdev, rpath, 0, &ro)) {
fprintf(stderr, "can't set up loop\n");
exit (1);
}
That would make sure that kpartx can delete loop devices created by
itself, which is what we want. IMO it's sufficient to solve your issue.
The -ENODEV case is more tricky, your patch doesn't solve it. If you do
kpartx -a /some/image
rm -f /some/image
kpartx -d /some/image
kpartx -d fails, and that's unrelated to the realpath code (it fails in
stat(device) already). Honestly, I don't think we need to support this
scenario. Setting up a loop device and then deleting the backing file
is shooting oneself in the foot.
Martin
--
Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2018-02-05 17:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-05 8:58 [PATCH] kpartx: Improve finding loopback device by file Julian Andres Klode
2018-02-05 10:32 ` Martin Wilck
2018-02-05 10:45 ` Julian Andres Klode
2018-02-05 13:53 ` Martin Wilck
2018-02-05 14:41 ` Julian Andres Klode
2018-02-05 15:12 ` Martin Wilck
2018-02-05 15:46 ` Julian Andres Klode
2018-02-05 17:07 ` Martin Wilck [this message]
2018-02-06 11:19 ` Julian Andres Klode
2018-02-06 12:53 ` Martin Wilck
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=1517850433.14196.63.camel@suse.com \
--to=mwilck@suse.com \
--cc=dm-devel@redhat.com \
--cc=julian.klode@canonical.com \
/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.