On Fri, 2014-03-07 at 10:22 -0800, Christoph Hellwig wrote:
On Fri, Mar 07, 2014 at 10:12:09AM -0800, Andy Grover wrote:
I can't see how the synchronization can work without refcounting the lun
structure. The lock just protectes the assignment, but you free it
right after. What happens to
- se_tpg-tpg_lun_list = array_zalloc(TRANSPORT_MAX_LUNS_PER_TPG,
- sizeof(struct se_lun), GFP_KERNEL);
+ se_tpg-tpg_lun_list = kzalloc(TRANSPORT_MAX_LUNS_PER_TPG *
sizeof(void*),
+GFP_KERNEL);
Again seems like the pointer array
On 03/07/2014 02:41 AM, Christoph Hellwig wrote:
- se_tpg-tpg_lun_list = array_zalloc(TRANSPORT_MAX_LUNS_PER_TPG,
- sizeof(struct se_lun), GFP_KERNEL);
+ se_tpg-tpg_lun_list = kzalloc(TRANSPORT_MAX_LUNS_PER_TPG *
sizeof(void*),
+
On Fri, Mar 07, 2014 at 10:12:09AM -0800, Andy Grover wrote:
I can't see how the synchronization can work without refcounting the lun
structure. The lock just protectes the assignment, but you free it
right after. What happens to how jsut dereferenced it under the lock
but then uses it
On 03/07/2014 10:22 AM, Christoph Hellwig wrote:
On Fri, Mar 07, 2014 at 10:12:09AM -0800, Andy Grover wrote:
I can't see how the synchronization can work without refcounting the lun
structure. The lock just protectes the assignment, but you free it
right after. What happens to how jsut
Instead of allocating the tpg_lun_list and each member of the list when
the tpg is created, just create the tpg_lun_list array, and use an
element being non-NULL to indicate an active LUN. This will save memory
if less than all the se_luns are actually configured.
Now that things are actually
6 matches
Mail list logo
