Skip to contentSkip to conversation

Staging: memrar: Moved memrar_allocator struct into memrar_allocator.c

PATCH In review Henri Häkkinen 4 participants 5 messages Jun 23, 2010 – Jun 24, 2010 Staging

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 Staging: memrar: Moved memrar_allocator struct into memrar_allocator.c

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().

---
 drivers/staging/memrar/memrar_allocator.c |   56 ++++++++++++++++++++++++
 drivers/staging/memrar/memrar_allocator.h |   66 ++++++++++++++++------------
 drivers/staging/memrar/memrar_handler.c   |   11 +++--
 3 files changed, 100 insertions(+), 33 deletions(-)
drivers/staging/memrar/memrar_allocator.c +56 -0
index a4f8c58..955d1eb 100644
@@ -41,6 +41,36 @@
 #include <linux/kernel.h>
 
 
+/**
+ * struct memrar_allocator - encapsulation of the memory allocator state
+ * @lock:		Lock used to synchronize access to the memory
+ *			allocator state.
+ * @base:		Base (start) address of the allocator memory
+ *			space.
+ * @capacity:		Size of the allocator memory space in bytes.
+ * @block_size:		The size in bytes of individual blocks within
+ *			the allocator memory space.
+ * @largest_free_area:	Largest free area of memory in the allocator
+ *			in bytes.
+ * @allocated_list:	List of allocated memory block address
+ *			ranges.
+ * @free_list:		List of free address ranges.
+ *
+ * This structure contains all memory allocator state, including the
+ * base address, capacity, free list, lock, etc.
+ */
+struct memrar_allocator {
+/* private: internal use only */
+	struct mutex lock;
+	unsigned long base;
+	size_t capacity;
+	size_t block_size;
+	size_t largest_free_area;
+	struct memrar_address_ranges allocated_list;
+	struct memrar_address_ranges free_list;
+};
+
+
 struct memrar_allocator *memrar_create_allocator(unsigned long base,
 						 size_t capacity,
 						 size_t block_size)
@@ -423,7 +453,33 @@ exit_memrar_free:
 	return 0;
 }
 
+size_t memrar_allocator_largest_free_area(struct memrar_allocator *allocator)
+{
+	if (allocator == NULL)
+		return 0;
+	return allocator->largest_free_area;
+}
+
+size_t memrar_allocator_capacity(struct memrar_allocator *allocator)
+{
+	if (allocator == NULL)
+		return 0;
+	return allocator->capacity;
+}
+
+void memrar_allocator_lock(struct memrar_allocator *allocator)
+{
+	if (allocator == NULL)
+		return;
+	mutex_lock(&allocator->lock);
+}
 
+void memrar_allocator_unlock(struct memrar_allocator *allocator)
+{
+	if (allocator == NULL)
+		return;
+	mutex_unlock(&allocator->lock);
+}
 
 /*
   Local Variables:
drivers/staging/memrar/memrar_allocator.h +38 -28

78 lines not on this page · raw message

drivers/staging/memrar/memrar_handler.c +6 -5
index efa7fd6..6a4628c 100644
@@ -350,7 +350,8 @@ static int memrar_init_rar_resources(int rarnum, char const *devname)
 			devname, rarnum, (unsigned long) low, (unsigned long) high);
 
 	pr_info("%s: BRAR[%d] size = %zu KiB\n",
-			devname, rarnum, rar->allocator->capacity / 1024);
+			devname, rarnum,
+			memrar_allocator_capacity(rar->allocator) / 1024);
 
 	rar->allocated = 1;
 	return 0;
@@ -545,11 +546,11 @@ static long memrar_get_stat(struct RAR_stat *r)
 	 * Allocator capacity doesn't change over time.  No
 	 * need to synchronize.
 	 */
-	r->capacity = allocator->capacity;
+	r->capacity = memrar_allocator_capacity(allocator);
 
-	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);
 	return 0;
 }
 
Signature · 1 line
1.7.1
#1 lore raw

Hi,

Quoted 4 lines

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().

...

drivers/staging/memrar/memrar_handler.c static long memrar_get_stat(struct RAR_stat *r) · line 553

Quoted 7 lines
drivers/staging/memrar/memrar_handler.c +2 -3
-	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);

drivers/staging/memrar/memrar_handler.c +1 -0
+	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

���{.n�+�������+%�����ݶ��w��{.n�+����{��G�����{ay�ʇڙ�,j��f���h��������z_�(�階�ݢj"���m������G������?����&���~��iO��z��v�^�m���� ������?�I�

#2 lore raw

PATCH 1/1 Staging: memrar: Moved memrar_allocator struct into memrar_allocator.c

Quoted 7 lines · Alan Cox
Quoted 7 lines

size_t memrar_allocator_largest_free_area(struct memrar_allocator *allocator) {

(quoted diff) +2 -3
-	if (allocator == NULL)
-		return 0;
-	return allocator->largest_free_area;
+	size_t tmp = 0;
+
Quoted 9 lines

drivers/staging/memrar/memrar_allocator.c exit_memrar_free: · line 481

Quoted 4 lines
drivers/staging/memrar/memrar_allocator.c +4 -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.

Begin forwarded message:

Quoted 40 lines

From: "Othman, Ossama" <[email protected]>
To: Henri Häkkinen <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>
Subject: RE: [PATCH] Staging: memrar: Moved memrar_allocator struct into memrar_allocator.c

Hi,

Quoted 4 lines

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().

...

drivers/staging/memrar/memrar_handler.c static long memrar_get_stat(struct RAR_stat *r) · line 553

Quoted 7 lines
drivers/staging/memrar/memrar_handler.c +2 -3
-	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);

drivers/staging/memrar/memrar_handler.c +1 -0
+	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

#3 lore raw

Hi,

Quoted 14 lines
Quoted 1 line
Quoted 1 line

size_t memrar_allocator_largest_free_area(struct memrar_allocator

*allocator)

Quoted 4 lines
Quoted 4 lines

{

(quoted diff) +0 -3
-	if (allocator == NULL)
-		return 0;
-	return allocator->largest_free_area;
Quoted 8 lines

drivers/staging/memrar/memrar_allocator.c exit_memrar_free: · line 481

Quoted 6 lines
drivers/staging/memrar/memrar_allocator.c +6 -0
+	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

Quoted 6 lines

you

Quoted 3 lines

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

Quoted 3 lines

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

#4 lore raw
In reply to Henri Häkkinen
Quoted 4 lines · Henri Häkkinen

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