linux-kernel - Re: [RFC] mm/migrate: Consolidate page allocation helper functions

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]

Date:   Fri, 2 Feb 2018 15:02:49 +0530
From:   Anshuman Khandual <khandual@...ux.vnet.ibm.com>
To:     Hugh Dickins <hughd@...gle.com>,
        Anshuman Khandual <khandual@...ux.vnet.ibm.com>
Cc:     Michal Hocko <mhocko@...nel.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, akpm@...ux-foundation.org
Subject: Re: [RFC] mm/migrate: Consolidate page allocation helper functions

On 01/31/2018 09:56 AM, Hugh Dickins wrote:
> On Wed, 31 Jan 2018, Anshuman Khandual wrote:
>> On 01/30/2018 08:06 PM, Michal Hocko wrote:
>>> On Tue 30-01-18 10:36:42, Anshuman Khandual wrote:
>>>> Allocation helper functions for migrate_pages() remmain scattered with
>>>> similar names making them really confusing. Rename these functions based
>>>> on the context for the migration and move them all into common migration
>>>> header. Functionality remains unchanged.
> 
> I agree that their names could be made less confusing (though didn't
> succeed very well when I tried); and maybe a couple of them are general
> enough to be used from more than one callsite, and could well live in
> mm/migrate.c.
> 
> But moving all of page migration's (currently static) new_page allocator
> functions away from the code that relies on their special characteristics
> (probably relayed to them through a private argument), and into a single
> header file, just seems perverse to me.  And likely to be a nuisance when
> adding more in future: private structures having to be made public just
> to make them visible in that shared header file.
> 
> Would it make sense to keep the various functions that may be called by
> rmap_walk() together in one rmap_walk.h?  The different filesystems'
> writepage methods together in one writepage.h?  I don't think so.

Makes sense. Will probably just change the helper names to something
more meaningful (from previous suggestions in this thread) next around.