On Tue, May 03, 2016 at 04:31:19PM +0100, Germano Percossi wrote:
> Hi,
>
> Sorry for jumping in the middle of patch review
>
> On 05/03/2016 03:27 PM, Benjamin Marzinski wrote:
> >On Tue, May 03, 2016 at 07:57:01AM +0200, Hannes Reinecke wrote:
> >>On 05/02/2016 06:26 PM, Benjamin Marzinski
Hi,
Sorry for jumping in the middle of patch review
On 05/03/2016 03:27 PM, Benjamin Marzinski wrote:
On Tue, May 03, 2016 at 07:57:01AM +0200, Hannes Reinecke wrote:
On 05/02/2016 06:26 PM, Benjamin Marzinski wrote:
On Wed, Apr 27, 2016 at 01:10:29PM +0200, Hannes Reinecke wrote:
This is
On Tue, May 03, 2016 at 09:27:32AM -0500, Benjamin Marzinski wrote:
> On Tue, May 03, 2016 at 07:57:01AM +0200, Hannes Reinecke wrote:
> > 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
On Tue, May 03, 2016 at 09:27:32AM -0500, Benjamin Marzinski wrote:
> I don't see why this same issue can't happen for anyone creating any
> type of dm device build out of multiple physical devices, and AFAIK, lvm
> doesn't bother to protect users against this, even though it can now
>
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
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 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
