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@xxxxxxxx>, 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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
