All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Marzinski <bmarzins@redhat.com>
To: Christophe Varoqui <christophe.varoqui@free.fr>
Cc: device-mapper development <dm-devel@redhat.com>
Subject: Re: Multipath blacklist exceptions issues
Date: Tue, 13 Nov 2007 15:21:59 -0600	[thread overview]
Message-ID: <20071113212158.GK28113@ether.msp.redhat.com> (raw)
In-Reply-To: <1194657466.6724.49.camel@localhost.localdomain>

On Sat, Nov 10, 2007 at 02:17:45AM +0100, Christophe Varoqui wrote:
> Indeed the current situation is fishy. Ben pointed a true braino in the
> code I introduced when restructuring the blacklist lib :
> 
> in _filter_path(), I test each _filter_*() for r!=0 , where I intented
> to check for r>0.
> 
> r==0 implements  : "exit on first blacklist or exception match".
>  r>0 implements  : "exit on first blacklist match".
> 
> With this later behaviour I can set things like that for max safety and
> efficiency :
> 
> blacklist {
>         devnode .*
>         device {
>                 vendor .*
>                 product .*
>         }
>         wwid .*
> }
> blacklist_exceptions {
>         devnode sd.*
>         device {
>                 vendor IET.*
>                 product .*
>         }
>         wwid "1646561646265.*"
> }
> 
> or pragmatically :
> 
> blacklist {
>         devnode .*
>         wwid .*
> }
> blacklist_exceptions {
>         devnode sd.*
>         wwid "1646561646265.*"
> }
> 
> 
> 
> Working that out, I also realized there may be another small
> misbehaviour :
> 
> First, a little background on path discovery operations :
> 
> 1) /sys/block parsing shows devnode names
> 2) devnode names examination shows device identification strings
> 3) these strings help us choose a getuid helper, which finally shows
> wwids
> 
> Meaning we want the devnode blacklisting to prevail over device and
> wwid, in case we know we don't have device strings available (loop, dm-,
> raw, ...)
> 
> Similarily, we want the device blacklist to prevail over wwid, in case
> we know we don't have getuid callout available. I have no example for
> this case though, so it shouldn't be as important as the previous one.
> 
> Problem is we challenge _filter_device() after _filter_wwid().
> This can be easily shufled around.
> 
> 
> So, I submit this (attached) patch to your review.

Looks fine to me.

-Ben
 
> regards,
> cvaroqui
> 
> 	
> Le samedi 10 novembre 2007 à 00:20 +0100, Stefan Bader a écrit :
> > 
> >         
> >         Any thoughts on this? Good Idea? Worth doing?
> > 
> > To be honest, I do not see the real simplification in that many
> > changes. Spreading black- and/or white-lists over so many places seems
> > rather confusion to me. I agree that using devnode names is not ideal
> > for the reasons you mentioned. That was done mainly to have an
> > internal blacklist of known devices that are known not to work.
> > Potentially this could be a device type (= driver name?). But would
> > this not also be possible as a new element of the blacklist? E.g.:
> > 
> > blacklist {
> >     driver fd
> >     driver device-mapper
> >     ...
> > }
> > 
> > The problem with the current implementation, in my thinking, is that
> > we have a dependency between two sections (blacklist and
> > blacklist_exceptions) and the keywords within. Without reading any
> > further 
> > documentation it seems awkward that it is not possible to blacklist
> > device nodes and punch holes by certain wwid numbers. When I think
> > about it, I guess (any other opinions welcome) that a exception is
> > what is really intended to be used. So that should always have more
> > priority than a blacklist. So if the filter finds a matching entry in
> > the blacklist_exceptions section, the device should be used. 
> > 
> > So my proposal would be:
> > 
> > 1. process the blacklist_exceptions (any match enables the device)
> > 2. process the blacklist
> > 3. any device dropping through is also used.
> > 
> > Additionally I like the idea of a match-by-driver extension. 
> > 
> > Stefan

> diff --git a/libmultipath/blacklist.c b/libmultipath/blacklist.c
> index 9a058f7..6297516 100644
> --- a/libmultipath/blacklist.c
> +++ b/libmultipath/blacklist.c
> @@ -297,16 +297,14 @@ _filter_path (struct config * conf, struct path * pp)
>  	int r;
>  
>  	r = _filter_devnode(conf->blist_devnode, conf->elist_devnode,pp->dev);
> -	if (r)
> -		return r;
> -	r = _filter_wwid(conf->blist_wwid, conf->elist_wwid, pp->wwid);
> -	if (r)
> +	if (r > 0)
>  		return r;
>  	r = _filter_device(conf->blist_device, conf->elist_device,
>  		 	   pp->vendor_id, pp->product_id);
> -	if (r)
> +	if (r > 0)
>  		return r;
> -	return 0;
> +	r = _filter_wwid(conf->blist_wwid, conf->elist_wwid, pp->wwid);
> +	return r;
>  }
>  
>  int

  reply	other threads:[~2007-11-13 21:21 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-09  0:23 Multipath blacklist exceptions issues Benjamin Marzinski
2007-11-09 14:20 ` Stefan Bader
2007-11-09 20:20   ` Benjamin Marzinski
2007-11-09 23:20     ` Stefan Bader
2007-11-10  1:17       ` Christophe Varoqui
2007-11-13 21:21         ` Benjamin Marzinski [this message]
2007-11-10  1:48       ` Benjamin Marzinski
2007-11-11  0:25         ` Stefan Bader
2007-11-13 20:18           ` Benjamin Marzinski
2007-11-13 22:29             ` Kiyoshi Ueda
2007-11-13 23:17             ` Stefan Bader
2007-11-14 20:44               ` Kiyoshi Ueda
     [not found]                 ` <5201e28f0711141411ue475f31qc4db61076479bd7e@mail.gmail.com>
     [not found]                   ` <20071114.182842.97297202.k-ueda@ct.jp.nec.com>
2007-11-15 15:07                     ` Stefan Bader
2007-11-15 15:57                       ` Kiyoshi Ueda
2007-11-15 16:29                       ` Kiyoshi Ueda
2007-11-15 19:24                 ` Benjamin Marzinski
2007-11-15 20:42                   ` Stefan Bader
2007-11-15 22:03                   ` Kiyoshi Ueda

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=20071113212158.GK28113@ether.msp.redhat.com \
    --to=bmarzins@redhat.com \
    --cc=christophe.varoqui@free.fr \
    --cc=dm-devel@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.