linux-kernel - Re: [PATCH v2 0/3] iommu/io-pgtable-arm-v7s: Use DMA32 zone for page tables

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

Message-ID: <20181122082336.GA2049@infradead.org>
Date:   Thu, 22 Nov 2018 00:23:36 -0800
From:   Christoph Hellwig <hch@...radead.org>
To:     Robin Murphy <robin.murphy@....com>
Cc:     Matthew Wilcox <willy@...radead.org>,
        Christopher Lameter <cl@...ux.com>,
        Levin Alexander <Alexander.Levin@...rosoft.com>,
        Mike Rapoport <rppt@...ux.vnet.ibm.com>,
        Nicolas Boichat <drinkcat@...omium.org>,
        Huaisheng Ye <yehs1@...ovo.com>,
        Tomasz Figa <tfiga@...gle.com>,
        Will Deacon <will.deacon@....com>,
        linux-kernel@...r.kernel.org, Pekka Enberg <penberg@...nel.org>,
        linux-mm@...ck.org, iommu@...ts.linux-foundation.org,
        Michal Hocko <mhocko@...e.com>,
        linux-arm-kernel@...ts.infradead.org,
        David Rientjes <rientjes@...gle.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        yingjoe.chen@...iatek.com, Joonsoo Kim <iamjoonsoo.kim@....com>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Vlastimil Babka <vbabka@...e.cz>
Subject: Re: [PATCH v2 0/3] iommu/io-pgtable-arm-v7s: Use DMA32 zone for page
 tables

On Wed, Nov 21, 2018 at 10:26:26PM +0000, Robin Murphy wrote:
> TBH, if this DMA32 stuff is going to be contentious we could possibly just
> rip out the offending kmem_cache - it seemed like good practice for the
> use-case, but provided kzalloc(SZ_1K, gfp | GFP_DMA32) can be relied upon to
> give the same 1KB alignment and chance of succeeding as the equivalent
> kmem_cache_alloc(), then we could quite easily make do with that instead.

Neither is the slab support for kmalloc, not do kmalloc allocations
have useful alignment apparently (at least if you use slub debug).

But I do agree with the sentiment of not wanting to spread GFP_DMA32
futher into the slab allocator.

I think you want a simple genalloc allocator for this rather special
use case.