Hi Alan,
> > 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. ?
Agreed, but I don't think there's anything we can do about it with the current interface. We will always have a time-of-check-time-of-use TOCTOU race with this function as it stands. I pointed out the issue in my response to Henri as well, but I focused more on hiding the lock from the caller. The TOCTOU race exists in both versions, i.e. the old code and proposed new code. The value returned from this function in this particular case will ultimately be passed to the user when the user issues a RAR_HANDLER_STAT ioctl to the /dev/memrar device. For the most part, this function is only used for debugging. It is not needed for general operation of the memrar_allocator or the memrar_handler (/dev/memrar).
-Ossama
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
