On Thu, Nov 22, 2018 at 10:36 AM Matthew Wilcox [off-list ref] wrote:

On Wed, Nov 21, 2018 at 10:26:26PM +0000, Robin Murphy wrote:

quoted

These are IOMMU page tables, rather than CPU ones, so we're already well
outside arch code - indeed the original motivation of io-pgtable was to be
entirely independent of the p*d types and arch-specific MM code (this Armv7
short-descriptor format is already "non-native" when used by drivers in an
arm64 kernel).

There was quite a lot of explanation missing from this patch description!

I totally agree ,-) I'm not familiar at all with either iommu or
mm/... Looks like the patchset triggered a helpful discussion, and I
understand the problem better now. I'll improve the description in the
next revision.

quoted

There are various efficiency reasons for using regular kernel memory instead
of coherent DMA allocations - for the most part it works well, we just have
the odd corner case like this one where the 32-bit format gets used on
64-bit systems such that the tables themselves still need to be allocated
below 4GB (although the final output address can point at higher memory by
virtue of the IOMMU in question not implementing permissions and repurposing
some of those PTE fields as extra address bits).

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.

I think you should look at using the page_frag allocator here.  You can
use whatever GFP_DMA flags you like.

I'll try that.

Thanks!