Prev: 2.6.34-rc5-git7 (plus all patches) -- another suspicious rcu_dereference_check() usage.
Next: ext3/4: enhance fsync performance when using CFQ
From: Greg KH on 22 Jun 2010 18:10
On Mon, Jun 14, 2010 at 02:54:33PM +0300, Henri Häkkinen wrote:
> Forward declared memrar_allocator in memrar_allocator.h and moved it
> to memrar_allocator.c file. Implemented memrar_allocator_capacity() and
> memrar_allocator_largest_free_area().

Um, did you try building the code after this patch? It fails in bad
ways:

CC [M] drivers/staging/memrar/memrar_handler.o
drivers/staging/memrar/memrar_handler.c: In function 'memrar_init_rar_resources':
drivers/staging/memrar/memrar_handler.c:352:2: error: dereferencing pointer to incomplete type
drivers/staging/memrar/memrar_handler.c: In function 'memrar_get_stat':
drivers/staging/memrar/memrar_handler.c:548:25: error: dereferencing pointer to incomplete type
drivers/staging/memrar/memrar_handler.c:550:23: error: dereferencing pointer to incomplete type
drivers/staging/memrar/memrar_handler.c:551:35: error: dereferencing pointer to incomplete type
drivers/staging/memrar/memrar_handler.c:552:25: error: dereferencing pointer to incomplete type

Please always build the patches you send out. I can't take
this one obviously :(

Care to fix it up?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Othman, Ossama on 23 Jun 2010 14:00
Hi,

> Forward declared memrar_allocator in memrar_allocator.h and moved it
> to memrar_allocator.c file. Implemented memrar_allocator_capacity(),
> memrar_allocator_largest_free_area(), memrar_allocoator_lock() and
> memrar_allocator_unlock().
...
> - mutex_lock(&allocator->lock);
> - r->largest_block_size = allocator->largest_free_area;
> - mutex_unlock(&allocator->lock);
> + memrar_allocator_lock(allocator);
> + r->largest_block_size =
> memrar_allocator_largest_free_area(allocator);
> + memrar_allocator_unlock(allocator);

I don't think it's necessary to expose the allocator lock. Why not just grab the lock in memrar_allocator_largest_free_area() while the underlying struct field is being accessed and then unlock it before that function returns? That would allow the allocator lock to remain an internal implementation detail. We only need to ensure access to the struct field itself is synchronized, e.g.:

size_t memrar_allocator_largest_free_area(struct memrar_allocator *allocator)
{
size_t tmp = 0;

if (allocator != NULL) {
mutex_lock(&allocator->lock);
tmp = allocator->largest_free_area;
mutex_unlock(&allocator->lock);
}

return tmp;
}

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.

HTH,
-Ossama

From: Greg KH on 23 Jun 2010 18:30
On Mon, Jun 14, 2010 at 03:40:27PM +0300, Henri H�kkinen wrote:
> Forward declared memrar_allocator in memrar_allocator.h and moved it
> to memrar_allocator.c file. Implemented memrar_allocator_capacity(),
> memrar_allocator_largest_free_area(), memrar_allocoator_lock() and
> memrar_allocator_unlock().

Shouldn't this be more than just one single patch?

Please only do one thing per patch.

Care to respin these and take into consideration the other comments for
this patch?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Othman, Ossama on 24 Jun 2010 13:50
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: 2.6.34-rc5-git7 (plus all patches) -- another suspicious rcu_dereference_check() usage.
Next: ext3/4: enhance fsync performance when using CFQ