On 05/02/2016 06:26 PM, Benjamin Marzinski wrote: > On Wed, Apr 27, 2016 at 01:10:29PM +0200, Hannes Reinecke wrote: >> 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. > > If we switch this to a shared lock, then what's the point in having it > at all? The whole point of lock_multipath is to keep multipath and > multipathd (or two concurrent calls to multipath) from trying to create > a device at the same time, and both failing. Without an exclusive lock, > this won't stop that. We can either decide that this is an unlikely > scenario, and drop it entirely, or we can have multipath create its own > lockfiles to prevent this issue without interfering with udev. But > unless I'm missing something, this won't actually do anything. > This is primarily for co-operation with udev. As we typically do _not_ use multipath for creating device-mapper tables the synchronisation problem between multipath and multipathd doesn't typically occur. At least not for us :-) And as described above, we need this patch to co-operate with udev. Kay was pretty adamant about _not_ changing udev here. That said, I'm happy with dropping the lock functionality completely; one possibility would be to use the CLI functionality to route calls from multipath to multipathd. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +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) -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
