Re: [PATCH v2 17/20] multipath.rules: find_multipaths "smart" logic

[Hannes Reinecke <hare@suse.de>]

On Wed, 28 Mar 2018 16:51:12 +0200
Martin Wilck <mwilck@suse.com> wrote:

> On Tue, 2018-03-27 at 18:07 -0500, Benjamin Marzinski wrote:
> > On Tue, Mar 27, 2018 at 11:34:00PM +0200, Martin Wilck wrote:  
> > > 
> > > The following happens: multipath -u temporarily claims the device.
> > > When
> > > multipathd starts, it fails to set up the map, sets the "failed"
> > > marker, and retriggers udev. The second time, multipath -u
> > > unclaims the
> > > device because it recognizes it as failed.  
> > 
> > But if that device is already in use because multipath didn't claim
> > it
> > in the initramfs, and you suddenly mark it as
> > ENV{SYSTEMD_READY}="0", this can cause systemd to automatically
> > unmount any filesystem on it. This isn't just a problem with Red
> > Hat's setup.  If it's not a configured device type, there will only
> > be a short timeout, but that's
> > still enough to mess with devices that are already in use.  I'm
> > pretty
> > sure that the multipath temporary claiming is only safe the very
> > first
> > time a device appears. Otherwise, it's possible that something else
> > will
> > claim it first, and then multipath will claim it and mess with that
> > other user.
> >   
> 
> Arrgh. Thanks for pointing that out. It's even worse because even if
> we could figure out whether we're being called for the first or second
> time, it wouldn't be sufficient. multipath.rules may not even be
> present in the initrd, so the device may be present in the system, and
> used, without multipath.rules having ever been called.
> 
> The only way I see to avoid this is to try calling open(O_EXCL) on the
> path device in "multipath -u". So far we've avoided that because it's
> not completely race-free. But we're not talking about a race here, but
> a situation where some entity grabbed a device before pivot-root.
> So we could attempt open(O_EXCL) only in the "is maybe a valid path"
> case, and only return "maybe" if that open succeeds. Otherwise we'd
> return "no", as we already checked that the device isn't currently
> part of a multipath map.
> 
Ho-hum.

Watch out when you do this; systemd will generate another event
whenever you close this fd, and suddenly you find yourself in a middle
of an event storm ...

Cheers,

Hannes