linux-kernel - Re: [RFC 06/23] mm/memblock: Add memblock early memory allocation apis

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <525C07C0.2020303@ti.com>
Date:	Mon, 14 Oct 2013 11:03:28 -0400
From:	Santosh Shilimkar <santosh.shilimkar@...com>
To:	Tejun Heo <tj@...nel.org>
CC:	"yinghai@...nel.org" <yinghai@...nel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Strashko, Grygorii" <grygorii.strashko@...com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC 06/23] mm/memblock: Add memblock early memory allocation
 apis

On Monday 14 October 2013 10:58 AM, Tejun Heo wrote:
> Hello,
> 
> On Mon, Oct 14, 2013 at 10:39:54AM -0400, Santosh Shilimkar wrote:
>>>> +void __memblock_free_early(phys_addr_t base, phys_addr_t size);
>>>> +void __memblock_free_late(phys_addr_t base, phys_addr_t size);
>>>
>>> Would it be possible to drop "early"?  It's redundant and makes the
>>> function names unnecessarily long.  When memblock is enabled, these
>>> are basically doing about the same thing as memblock_alloc() and
>>> friends, right?  Wouldn't it make more sense to define these as
>>> memblock_alloc_XXX()?
>>>
>> A small a difference w.r.t existing memblock_alloc() vs these new
>> exports returns virtual mapped memory pointers. Actually I started
>> with memblock_alloc_xxx() but then memblock already exports memblock_alloc_xx()
>> returning physical memory pointer. So just wanted to make these interfaces
>> distinct and added "early". But I agree with you that the 'early' can
>> be dropped. Will fix it.
> 
> Hmmm, so while this removes address limit on the base / limit side, it
> keeps virt address on the result.  In that case, we probably want to
> somehow distinguish the two sets of interfaces - one set dealing with
> phys and the other dealing with virts.  Maybe we want to build the
> base interface on phys address and add convenience wrappers for virts?
> Would that make more sense?
> 
Thats what more or less we are doing if you look at it. The only
additional code we have is to manage the virtual memory and checks
as such, just the same way initially done in nobootmem.c wrappers.

Not sure if adding 'virt' word in these APIs to make it explicit
would help to avoid any confusion.

Regards,
Santosh



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/