lkml.org 
[lkml]   [2010]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRE: [PATCH] Staging: memrar: Moved memrar_allocator struct into memrar_allocator.c
    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


    \
     
     \ /
      Last update: 2010-06-24 19:49    [W:0.026 / U:28.812 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site