From: robin.murphy@arm.com (Robin Murphy)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm: dma-mapping: fix off-by-one check in arm_setup_iommu_dma_ops
Date: Tue, 28 Apr 2015 16:10:27 +0100 [thread overview]
Message-ID: <553FA2E3.30402@arm.com> (raw)
In-Reply-To: <553F9EA8.7030403@arm.com>
On 28/04/15 15:52, Robin Murphy wrote:
> Hi Marek,
>
> On 28/04/15 10:08, Marek Szyprowski wrote:
>> Patch 22b3c181c6c324a46f71aae806d8ddbe61d25761 ("arm: dma-mapping: limit
>> IOMMU mapping size") added a check for IO address space size. However
>> this patch broke IOMMU initialization for typical platforms initialized
>> from device tree, which get the default IO address space size of 4GiB.
>> This value doesn't fit into size_t and fails a check introduced by that
>> commit resulting in failed dma-mapping/iommu initialization. This patch
>> fixes this issue by adding proper support for full 4GiB address space
>> size.
>>
>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>
> Much nicer than my hack of just passing in size-1, thanks! I'd offer a
> tested-by for the default 32-bit case, however...
>
>> ---
>> arch/arm/include/asm/dma-iommu.h | 2 +-
>> arch/arm/mm/dma-mapping.c | 9 +++------
>> 2 files changed, 4 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/dma-iommu.h b/arch/arm/include/asm/dma-iommu.h
>> index 8e3fcb924db6..2ef282f96651 100644
>> --- a/arch/arm/include/asm/dma-iommu.h
>> +++ b/arch/arm/include/asm/dma-iommu.h
>> @@ -25,7 +25,7 @@ struct dma_iommu_mapping {
>> };
>>
>> struct dma_iommu_mapping *
>> -arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, size_t size);
>> +arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, u64 size);
>>
>> void arm_iommu_release_mapping(struct dma_iommu_mapping *mapping);
>>
>> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
>> index 09c5fe3d30c2..b43b762eebc1 100644
>> --- a/arch/arm/mm/dma-mapping.c
>> +++ b/arch/arm/mm/dma-mapping.c
>> @@ -1878,7 +1878,7 @@ struct dma_map_ops iommu_coherent_ops = {
>> * arm_iommu_attach_device function.
>> */
>> struct dma_iommu_mapping *
>> -arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, size_t size)
>> +arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, u64 size)
>> {
>> unsigned int bits = size >> PAGE_SHIFT;
>
> ...doesn't this u64->int conversion now have the potential to truncate
> (if the device has a large enough DMA mask specified) and end up
> generating a weirdly small mapping rather than failing outright?
> Admittedly you'd have to have a 44-bit or larger DMA mask, and I'm not
> sure what the practical likelihood of seeing that even on LPAE systems
> is, but still I'm a little uneasy about it.
...by which I mean we should move the current size check into
arm_iommu_create_mapping itself, rather than relying on the caller,
because looking at dependent bits of code in isolation can be confusing ;)
Robin.
>> unsigned int bitmap_size = BITS_TO_LONGS(bits) * sizeof(long);
>> @@ -2057,11 +2057,8 @@ static bool arm_setup_iommu_dma_ops(struct device *dev, u64 dma_base, u64 size,
>> if (!iommu)
>> return false;
>>
>> - /*
>> - * currently arm_iommu_create_mapping() takes a max of size_t
>> - * for size param. So check this limit for now.
>> - */
>> - if (size > SIZE_MAX)
>> + /* Only 32-bit DMA address space is supported for now */
>> + if (size > DMA_BIT_MASK(32) + 1)
>> return false;
>>
>> mapping = arm_iommu_create_mapping(dev->bus, dma_base, size);
>>
>
> _______________________________________________
> iommu mailing list
> iommu at lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
>
next prev parent reply other threads:[~2015-04-28 15:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-28 9:08 [PATCH] arm: dma-mapping: fix off-by-one check in arm_setup_iommu_dma_ops Marek Szyprowski
2015-04-28 14:52 ` Robin Murphy
2015-04-28 15:10 ` Robin Murphy [this message]
2015-04-29 6:46 ` Marek Szyprowski
-- strict thread matches above, loose matches on Subject: below --
2015-04-29 10:02 Marek Szyprowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=553FA2E3.30402@arm.com \
--to=robin.murphy@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox