From: Martin Wilck <mwilck@suse.com>
To: dm-devel@redhat.com, Julian Andres Klode <julian.klode@canonical.com>
Subject: Re: [PATCH] kpartx: Improve finding loopback device by file
Date: Mon, 05 Feb 2018 14:53:07 +0100 [thread overview]
Message-ID: <1517838787.14196.10.camel@suse.com> (raw)
In-Reply-To: <20180205104500.n5rrw6nqzamwijvl@jak-x230>
On Mon, 2018-02-05 at 11:45 +0100, Julian Andres Klode wrote:
> On Mon, Feb 05, 2018 at 11:32:13AM +0100, Martin Wilck wrote:
> > On Mon, 2018-02-05 at 09:58 +0100, Julian Andres Klode wrote:
> > > C
> > > close (fd);
> > >
> > > - if (0 == strcmp(filename, loopinfo.lo_name)) {
> > > + if (0 == strcmp(filename, loopinfo.lo_name) ||
> > > + 0 == strcmp(rfilename, loopinfo.lo_name) ||
> > > + (realpath(loopinfo.lo_name, rloopfilename)
> > > &&
> > > + 0 == strcmp(rfilename, rloopfilename))) {
> > > found = realpath(path, NULL);
> > > break;
> > > }
> >
> > That "if x matches y or x matches y' or x' matches y" feels like
> > guesswork. Can't we simply call realpath() on both loopinfo.lo_name
> > and
> > filename, and compare the two?
>
> Probably yes. That said there might be some corner cases:
>
> (1) What happens if the backing file of a loopback is deleted -
> realpath
> can fail with ENOENT.
> (2) A path could be longer than PATH_MAX and it would fail with
> ENAMETOOLONG
> - this is a "problem" with the initial realpath as well, but less
> so, because
> the user can control that.
Both are scenarios in which kpartx would have good reason to fail (with
a meaningful error message). That's better than guessing, IMO.
kpartx' functionality to work with loop file names (as opposed to just
block devices) is a convenience feature anyway. I'd rather be certain
to avoid deleting stuff we aren't supposed to.
Regards
Martin
>
> I guess the 0 == strcmp(rfilename, loopinfo.lo_name) is not likely to
> happen, but
> in the end, I did not want to think that much about it and go with
> something that
> definitely works as best as possible.
>
--
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 13:53 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 [this message]
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
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=1517838787.14196.10.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