[dm-devel] [RFC PATCH 0/2] multipath: change default devnode blacklist

[Benjamin Marzinski]

On Sat, Jun 06, 2020 at 07:23:28PM +0000, Martin Wilck wrote:
> On Fri, 2020-06-05 at 17:27 -0500, Benjamin Marzinski wrote:
> > On Fri, Jun 05, 2020 at 07:20:26PM +0000, Martin Wilck wrote:
> > > Hi Ben,
> > > 
> > > On Thu, 2020-06-04 at 19:30 -0500, Benjamin Marzinski wrote:
> > > > I recently got a request to add the Oracle ASM filer driver
> > > > devices
> > > > to
> > > > multipath's builtin devnode blacklist.  However, instead of
> > > > having to
> > > > do
> > > > always this for each device type individually, I decided to make
> > > > multipath blacklist all non scsi, nvme, and dasd devnodes by
> > > > default.
> > > > This is what the multipath udev rules already do. If people don't
> > > > like
> > > > this solution, the alternative is to add another line to the
> > > > default
> > > > devnode blacklist like "^(asm/|oracleafd/|ofsctl)".
> > > 
> > > Thanks, this looks ok. But I'd like to propose an alternative idea:
> > > Extend the RE syntax in our config file to allow negated regular 
> > > expressions. Like this:
> > > 
> > > blacklist {
> > >     devnode "!(^(sd[a-z]|dasd[a-z]|nvme[0-9]))"
> > > }
> > > 
> > > The "!(${RE})" construct would mean "everything that does not match
> > > ${RE}".
> > > This logic would only be applied to an entire regex.
> > > If a user needs a RE matching with "!(" and ending with ")", she
> > > can escape 
> > > the exclamation mark "\!(like this)".
> > > 
> > > AFAICS this could be implemented quite easily (by adding a "bool
> > > negate" field
> > > in struct blentry and some simple parser logic), and could be
> > > applied to other 
> > > REs in the config file as well. We could print this with "multipath
> > > -t", and 
> > > we wouldn't need to document an exception.
> > > 
> > > It's also pretty much backwards-compatible, I don't think many
> > > people use
> > > regexes starting with "!(" for multipath these days.
> > 
> > Sure, but since we can only really support negating the whole regular
> > expression, and c regular expressions don't treat '!' as a special
> > character, why do we need the prentheses around the regular
> > expression?
> > It seems like we can just treat regular expressions starting with '!'
> > as
> > negated, and ones starting with "\!" as starting with a literal '!'.
> > 
> > Do you think that there is much chance that users have blacklist
> > strings
> > that start with '!'? There are no devnodes, udev properties, or
> > protocols that start with that.  I don't know of a UUID format that
> > has
> > an exclamation point, and while it's possible that a product string
> > starts with one, it seems really unlikely.
> > 
> 
> Sure, just using "!" would be fine, too, and simpler. Does this mean
> you agree with my proposal in general?

yeah. I'll be posting a v2 shortly.

-Ben
 
> Martin
> 
> -- 
> Dr. Martin Wilck <mwilck at suse.com>, Tel. +49 (0)911 74053 2107
> SUSE  Software Solutions Germany GmbH
> HRB 36809, AG Nürnberg GF: Felix
> Imendörffer
>