linux-kernel - Re: [PATCH v2 1/2] mm/vmalloc: export __vmalloc_node

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] [day] [month] [year] [list]

Message-ID: <YMGiFya4JP9VuV0Y@infradead.org>
Date:   Thu, 10 Jun 2021 06:24:39 +0100
From:   Christoph Hellwig <hch@...radead.org>
To:     Christian Borntraeger <borntraeger@...ibm.com>
Cc:     Claudio Imbrenda <imbrenda@...ux.ibm.com>,
        Christoph Hellwig <hch@...radead.org>,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        linux-s390@...r.kernel.org, frankja@...ux.ibm.com,
        cohuck@...hat.com, david@...hat.com, linux-mm@...ck.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Nicholas Piggin <npiggin@...il.com>,
        Uladzislau Rezki <urezki@...il.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        David Rientjes <rientjes@...gle.com>
Subject: Re: [PATCH v2 1/2] mm/vmalloc: export __vmalloc_node_range

On Wed, Jun 09, 2021 at 07:47:43PM +0200, Christian Borntraeger wrote:
> An alternative would be to provide a vmalloc_no_huge function in generic
> code  (similar to  vmalloc_32) (or if preferred in s390 base architecture code)
> Something like
> 
> void *vmalloc_no_huge(unsigned long size)
> {
>         return __vmalloc_node_flags(size, NUMA_NO_NODE,VM_NO_HUGE_VMAP |
>                                 GFP_KERNEL | __GFP_ZERO);
> }
> EXPORT_SYMBOL(vmalloc_no_huge);
> 
> or a similar vzalloc variant.

Exactly.  Given that this seems to be a weird pecularity of legacy s390
interfaces I'd only export it for 390 for now, although for
documentation purposes I'd probably still keep it in vmalloc.c.