linux-kernel - Re: [PATCH 1/1] swiotlb: extend buffer pre-padding to alloc_align

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

Message-ID: <b4488238-0c05-4d06-a60d-10e00460ea98@arm.com>
Date: Mon, 18 Mar 2024 13:05:03 +0000
From: Robin Murphy <robin.murphy@....com>
To: Michael Kelley <mhklinux@...look.com>,
 Petr Tesarik <petrtesarik@...weicloud.com>, Christoph Hellwig <hch@....de>,
 Marek Szyprowski <m.szyprowski@...sung.com>, Will Deacon <will@...nel.org>,
 Nicolin Chen <nicolinc@...dia.com>,
 "open list:DMA MAPPING HELPERS" <iommu@...ts.linux.dev>,
 open list <linux-kernel@...r.kernel.org>
Cc: Roberto Sassu <roberto.sassu@...weicloud.com>,
 Petr Tesarik <petr.tesarik1@...wei-partners.com>
Subject: Re: [PATCH 1/1] swiotlb: extend buffer pre-padding to
 alloc_align_mask if necessary

On 15/03/2024 2:53 am, Michael Kelley wrote:
[...]
>> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
>> index 86fe172b5958..8ce11abc691f 100644
>> --- a/kernel/dma/swiotlb.c
>> +++ b/kernel/dma/swiotlb.c
>> @@ -69,11 +69,13 @@
>>    * @alloc_size:	Size of the allocated buffer.
>>    * @list:	The free list describing the number of free entries available
>>    *		from each index.
>> + * @padding:    Number of preceding padding slots.
>>    */
>>   struct io_tlb_slot {
>>   	phys_addr_t orig_addr;
>>   	size_t alloc_size;
>>   	unsigned int list;
>> +	unsigned int padding;
> 
> Even without the padding field, I presume that in
> 64-bit builds this struct is already 24 bytes in size so as
> to maintain 64-bit alignment for the orig_addr and
> alloc_size fields. If that's the case, then adding the
> padding field doesn't change the amount of memory
> required for the slot array.  Is that correct? Both the
> "list" and "padding" fields contain only small integers,
> but presumably reducing their size from "int" to "short"
> wouldn't help except in 32-bit builds.

Technically I think we could shrink the whole thing down to 16 bytes*, 
since just 24 bits of size should still be more than enough, with the 
remaining 8 bits similarly plenty for a padding slot count. Depends if 
we think the overall memory saving is worth the marginal extra 
complexity of packing values into bitfields.

Thanks,
Robin.


* The relevance of SWIOTLB to 32-bit builds is primarily going to be for 
PAE cases where phys_addr_t is still 64-bit.