Missing lock during partition read

["Tkaczyk, Mariusz" <mariusz.tkaczyk@intel.com>]

Hi all,

I found an issue related to missing locking mechanism during partition
detection process. I'm using md raid 5 with IMSM metadata. On top of
array I created GPT with some partitions.

The problem here is that partition may stay read-only even if the parent
device (in this case raid array) becomes read-write. The issue doesn't
affect every partition. I got result where some of partitions are
read-write and the rest doesn't.

It is related to raid assembly process for external arrays. First
array appears read-only and later it is switched to read-write mode.
The read-only for array is well respected and as a result, if partition
detection start at this stage, then partitions get read-only mode.

The mode switch is done from userspace by mdmon, it manages array's
sysfs attribute "md/array_state" and kernel changes to read-write from
this context. This is done by set_disk_ro() function
(see array_state_store() in md.c).

So, as I wrote before partition detection starts when array is read-only.
I investigated that the issue occurs if mdmon changes array state during 
this process in background. As a result, it changes state on already
detected partitions, it doesn't wait for rest to appear. Udev reports md
device change event (generated by "md/array_state" update) between adds:

KERNEL[85844.484805] add /devices/virtual/block/md126/md126p1 (block)
KERNEL[85844.484853] change /devices/virtual/block/md126 (block)
KERNEL[85844.484912] add /devices/virtual/block/md126/md126p2 (block)

It ends with /dev/md126p2 as read-only. It can be fixed manually by
partprobe, but system may drop to emergency shell or dracut, depending
on configuration.

My understanding is that those two actions aren't synchronized and time
race occurs. To prevent from it, common resources should be locked.
Looks like md problem, it cannot be reproduced on standalone drives.
What are your thoughts?

TIA,
Mariusz