Re: [PATCH] libmultipath: don't lock block device but use lock files

[Hannes Reinecke <hare@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]

On 05/23/2015 11:00 PM, Christian Seiler wrote:
> In recent versions udev uses flock() on the device node itself,
> breaking libmultipath's current locking logic. Since libmultipath
> doesn't actually modify anything on the device itself (and hence does
> not actually need an exclusive lock on the device node, unlike e.g.
> tools that create partitions etc.), and the reason for the lock is to
> guard against multipath interfering with multipathd, use lock files
> (named after the devices) in /run/lock/multipath instead.
> 
> See the discussion under:
> https://www.redhat.com/archives/dm-devel/2014-December/msg00083.html
> Especially:
> https://www.redhat.com/archives/dm-devel/2014-December/msg00117.html
> 
> Signed-off-by: Christian Seiler <christian@iwakd.de>
> 
> ---
Well ... couldn't you just use a shared lock here?

I thought to have send this patch already; hmm.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)

[-- Attachment #2: multipath-shared-lock.patch --]
[-- Type: text/x-patch, Size: 1538 bytes --]

From 841977fc9c3432702c296d6239e4a54291a6007a Mon Sep 17 00:00:00 2001
From: Hannes Reinecke <hare@suse.de>
Date: Tue, 24 Jun 2014 08:49:15 +0200
Subject: [PATCH] libmultipath: use a shared lock to co-operate with udev

udev since v214 is placing a shared lock on the device node
whenever it's processing the event. This introduces a race
condition with multipathd, as multipathd is processing the
event for the block device at the same time as udev is
processing the events for the partitions.
And a lock on the partitions will also be visible on the
block device itself, hence multipathd won't be able to
lock the device.
When multipath manages to take a lock on the device,
udev will fail, and consequently ignore this entire event.
Which in turn might cause the system to malfunction as it
might have been a crucial event like 'remove' or 'link down'.

So we should better use LOCK_SH here; with that the flock
call in multipathd _and_ udev will succeed and the events
can be processed.

References: bnc#883878

Signed-off-by: Hannes Reinecke <hare@suse.de>

diff --git a/libmultipath/configure.c b/libmultipath/configure.c
index 0ddd3d5..dc2ebf0 100644
--- a/libmultipath/configure.c
+++ b/libmultipath/configure.c
@@ -529,7 +529,7 @@ lock_multipath (struct multipath * mpp, int lock)
 		if (!pgp->paths)
 			continue;
 		vector_foreach_slot(pgp->paths, pp, j) {
-			if (lock && flock(pp->fd, LOCK_EX | LOCK_NB) &&
+			if (lock && flock(pp->fd, LOCK_SH | LOCK_NB) &&
 			    errno == EWOULDBLOCK)
 				goto fail;
 			else if (!lock)

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]