[dm-devel] [PATCH] kpartx: Improve finding loopback device by file

[Martin Wilck]

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 at suse.com>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)