linux-kernel - Re: [rfc v2 3/6] dma-pool: dynamically expanding atomic pools

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: <20200414064441.GC23359@lst.de>
Date:   Tue, 14 Apr 2020 08:44:41 +0200
From:   Christoph Hellwig <hch@....de>
To:     David Rientjes <rientjes@...gle.com>
Cc:     Hillf Danton <hdanton@...a.com>, Christoph Hellwig <hch@....de>,
        Tom Lendacky <thomas.lendacky@....com>,
        "Singh, Brijesh" <brijesh.singh@....com>,
        "Grimm, Jon" <jon.grimm@....com>, Joerg Roedel <joro@...tes.org>,
        linux <linux-kernel@...r.kernel.org>,
        iommu <iommu@...ts.linux-foundation.org>
Subject: Re: [rfc v2 3/6] dma-pool: dynamically expanding atomic pools

On Fri, Apr 10, 2020 at 12:37:20PM -0700, David Rientjes wrote:
> I'll rely on Christoph to determine whether it makes sense to add some 
> periodic scavening of the atomic pools, whether that's needed for this to 
> be merged, or wheter we should enforce some maximum pool size.

I don't really see the point.  In fact the only part of the series
I feel uneasy about is the growing of the pools, because it already
adds a fair amount of complexity that we might not need for simple
things, but shrinking really doesn't make any sense.  So I'm tempted
to not ever support shrinking, and even make growing optional code under
a new config variable.  We'll also need a way to query the current size
through e.g. a debugfs file.