linux-kernel - Re: [PATCH v2] iommu/arm-smmu-v3: limit use of 2-level stream 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]

Date:	Thu, 14 Jul 2016 14:31:07 +0100
From:	Will Deacon <will.deacon@....com>
To:	Nate Watterson <nwatters@...eaurora.org>
Cc:	Robin Murphy <robin.murphy@....com>,
	Joerg Roedel <joro@...tes.org>,
	linux-arm-kernel@...ts.infradead.org,
	iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] iommu/arm-smmu-v3: limit use of 2-level stream tables

On Tue, Jul 12, 2016 at 02:19:20PM -0400, Nate Watterson wrote:
> In the current arm-smmu-v3 driver, all smmus that support 2-level
> stream tables are being forced to use them. This is suboptimal for
> smmus that support fewer stream id bits than would fill in a single
> second level table. This patch limits the use of 2-level tables to
> smmus that both support the feature and whose first level table can
> possibly contain more than a single entry.

Just to be clear, what exactly are you seeing as being suboptimal here?
Is it the memory wastage from overallocating the L2 table, or something
more?

if it's just the memory allocation, I'd sooner restrict the span field
in the L1 desc.

Will