Re: DMF_FREEING flag checking

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux