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
[email protected]
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
