If I understand udev correctly, this sort of "conflict" is an inevitable consequence of its asynchronous nature, and helper programs like bcache-register need to be robust enough to deal with them.
(If I'm wrong about this, then I guess this is a udev bug?)
BTW, this is what the bcache-related dmesg entries look like when I hit the conflict with my patches applied:
You can see that the backing device is busy when it first tries to
register it, but it succeeds 1/10th of a second later. (I'm assuming
the last two "already registered" messages occur when udev replays
its events later in the boot process.)
From: http://thread.gmane.org/gmane.linux.kernel.bcache.devel/2594
If I understand udev correctly, this sort of "conflict" is an inevitable consequence of its asynchronous nature, and helper programs like bcache-register need to be robust enough to deal with them.
(If I'm wrong about this, then I guess this is a udev bug?)
BTW, this is what the bcache-related dmesg entries look like when I hit the conflict with my patches applied:
You can see that the backing device is busy when it first tries to register it, but it succeeds 1/10th of a second later. (I'm assuming the last two "already registered" messages occur when udev replays its events later in the boot process.)