linux-kernel - Re: [PATCH 2/2] mm/sparse: add common helper to mark all memblocks present

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 7 Nov 2018 13:36:34 -0700
From:   Logan Gunthorpe <logang@...tatee.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        linux-arch@...r.kernel.org, linux-riscv@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org, linux-sh@...r.kernel.org,
        Stephen Bates <sbates@...thlin.com>,
        Palmer Dabbelt <palmer@...ive.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Christoph Hellwig <hch@....de>, Arnd Bergmann <arnd@...db.de>,
        Michal Hocko <mhocko@...e.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        Oscar Salvador <osalvador@...e.de>
Subject: Re: [PATCH 2/2] mm/sparse: add common helper to mark all memblocks
 present



On 2018-11-07 1:26 p.m., Thomas Gleixner wrote:
> Logan,
> 
> On Wed, 7 Nov 2018, Logan Gunthorpe wrote:
>> On 2018-11-07 1:12 p.m., Andrew Morton wrote:
>>>> +void __init memblocks_present(void)
>>>> +{
>>>> +	struct memblock_region *reg;
>>>> +
>>>> +	for_each_memblock(memory, reg) {
>>>> +		memory_present(memblock_get_region_node(reg),
>>>> +			       memblock_region_memory_base_pfn(reg),
>>>> +			       memblock_region_memory_end_pfn(reg));
>>>> +	}
>>>> +}
>>>> +
>>>
>>> I don't like the name much.  To me, memblocks_present means "are
>>> memblocks present" whereas this actually means "memblocks are present".
>>> But whatever.  A little covering comment which describes what this
>>> does and why it does it would be nice.
>>
>> The same argument can be made about the existing memory_present()
>> function and I think it's worth keeping the naming consistent. I'll add
>> a comment and resend shortly.
> 
> Actually if both names suck, then there also is the option to rename both
> instead of adding a comment to explain the suckage.

Ok, well, I wasn't expecting to take on a big rename like that as it
would create a patch touching a bunch of arches and mm files... But if
we can come to some agreement on a better name and someone is willing to
take that patch without significant delay then I'd be happy to create
the patch and add it to the start of my series.

Some ideas for new names:

mark_memory_present() / mark_memblocks_present()
set_memory_present() / set_memblocks_present()
memory_register() / memblocks_register()
register_memory() / register_memblocks()

Logan