On Sun, Mar 09, 2008 at 09:23:09PM -0700, Mai N wrote:
> I think we need to check, in __get_uuid_cell() , DMF_FREEING flag, to
> cover the race condition that we are trying to get the device while
> others is freeing (or have freed) it, same check is needed in
> __get_name_cell()...
I don't ever recall any bug reports that could be ascribed to this.
But I agree that it's not immediately obvious the code is correct.
So we need to find code paths that would cause a race, or write a
test program to demonstrate it.
> static struct hash_cell *__get_uuid_cell(const char *str)
> {
> + struct mapped_device *md = NULL;
>
> list_for_each_entry (hc, _uuid_buckets + h, uuid_list)
> + md = hc->md;
> + if ((!strcmp(hc->uuid, str)) &&
> + (md) && (!(test_bit(DMF_FREEING, &md->flags)))) {
>
> - if (!strcmp(hc->uuid, str)) {
> dm_get(hc->md);
> }
The fix would be need to be within dm.c to ensure dm_get() can't succeed
while the final dm_put() is underway. The question is, are there any
*actual* code paths which could lead to that happening, where existing
locking/serialisation is inadequate?
Alasdair
--
agk@xxxxxxxxxx
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
