Hi,
> >> size_t memrar_allocator_largest_free_area(struct memrar_allocator
> *allocator)
> >> {
> >> - if (allocator == NULL)
> >> - return 0;
> >> - return allocator->largest_free_area;
> >> + size_t tmp = 0;
> >> +
> >> + if (allocator != NULL) {
> >> + mutex_lock(&allocator->lock);
> >> + tmp = allocator->largest_free_area;
> >> + mutex_unlock(&allocator->lock);
> >
> > This doesn't seem to make any sense (in either version). The moment
> you
> > drop the lock the value in "tmp" becomes stale as the allocator could
> > change it. ?
> >
>
> The idea was proposed by Ossama Othman in his earlier reply.
:-)
[OO] > > Certainly the allocator->largest_free_area value could be updated
> after the lock is released and by the time it is returned to the user
> (for statistical purposes), but at least the internal allocator state
> would remain consistent in the presences of multiple threads.
My suggestion focused solely on hiding the allocator lock from the caller. The TOCTOU race I alluded to above exists in the current version of the code, and was not introduced with the change I proposed to your patch.
HTH,
-Ossama
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
