Linux Device Mapper development
 help / color / mirror / Atom feed
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

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