Race condition in write_sb_page? (was: Re: Incorrect in-kernel bitmap on raid10)

Mario 'BitKoenig' Holbe
2009-04-20T00:13:22Z

Neil Brown <neilb@suse.de> wrote:
> On Monday April 20, Mario.Holbe@TU-Ilmenau.DE wrote:
>> existing bitmapped device. When the full-sync of the new component is
>> finished, the bitmap on the new component does usually show still lots
>> of dirty bits (sometimes only a few %, sometimes up to 95%) while the
> I think that problem is fixed by
> commit 355a43e641b948a7b755cb4c2466ec548d5b495f
> which is in 2.6.29.

.2 probably :)

While looking at commit 355a43e641b948a7b755cb4c2466ec548d5b495f I'm not
sure, if this could raise a race condition: the comment in
next_active_rdev() states:
* As devices are only added or removed when raid_disk is < 0 and
* nr_pending is 0 and In_sync is clear, the entries we return will
* still be in the same position on the list when we re-enter
* list_for_each_continue_rcu.
but commit 355a43e641b948a7b755cb4c2466ec548d5b495f does exactly remove
the In_sync test. If the comment is true, the removal of the test
probably opens a window for a race condition.

regards
Mario
--
Programmieren in C++ haelt die grauen Zellen am Leben. Es schaerft
alle fuenf Sinne: den Schwachsinn, den Bloedsinn, den Wahnsinn, den
Unsinn und den Stumpfsinn.
[Holger Veit in doc]