From nobody Wed Dec 24 12:14:11 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9B150200C1; Fri, 8 Mar 2024 15:28:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709911722; cv=none; b=WQXxmjSzPR7Xg3bsxmkjhha9+cmSApvsBCXRS4qT5t9oa6o6h7oXJp4K0jTHDGWWp7xhhBfHZIIrIJz76fuw6r+SCzLtPiD/TY3NKpuh6mp2gWlUTUoFxAhQhhgi4g928VrK6MiEznYByEK+mzZ3FKQLxf03iQ73tQ509xg28a8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709911722; c=relaxed/simple; bh=B47ZjXmKOyAMLhid8Xlwz+oOPX1zHRpOemRv4vSO/iQ=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=MR4wpsndwKQYBbWclbzzS8HrQheLNfZ1lLLTMWCVELoWp34nrimk+CbbijXr4Dh2QH2KvSssp+nlJBbdIWv7C/D1OzzVkGvQhQ9uv/zJ8Y0xCNIQZOjg98i4ZnfTk6uOyO0kxjbNDareaIDUFZC0JfCSlHLcAauqtGnQjqz0xlE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kO428Zvw; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kO428Zvw" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0B746C433C7; Fri, 8 Mar 2024 15:28:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709911722; bh=B47ZjXmKOyAMLhid8Xlwz+oOPX1zHRpOemRv4vSO/iQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kO428Zvwc60S9I5oBgHH1u4aTum7m8PoAjVesiFRRKW8xb1o9xfjmiBrRAu7lOb2t jjU4fYxCpZLzeyiG0Yj7Vk13J23CkZAflFOnaTw7y9JUdDdWIHsiC8AHbPu1EoFJYU Mnlr9u51fLSxQRU/m3SQ0FdMvJrY4UV9IWLtA2ZTKt3wAMATqno6iTRPj4rt8mUIMp lgsoVq0pxmJy+nJIoeceEZ0IdTiD8qvXxuAM1jD3HvahdP3bjdFvIY46baLWHtk3CT uxVwqreCHLgASOEWf/i20RCIaTLDnJ1ahGznIvHiG40h4UeJOwmdV6dPN8wSpUzlbf JNVAwJOgcpjog== From: Will Deacon To: linux-kernel@vger.kernel.org Cc: kernel-team@android.com, Will Deacon , iommu@lists.linux.dev, Christoph Hellwig , Marek Szyprowski , Robin Murphy , Petr Tesarik , Dexuan Cui , Nicolin Chen , Michael Kelley Subject: [PATCH v6 1/6] swiotlb: Fix double-allocation of slots due to broken alignment handling Date: Fri, 8 Mar 2024 15:28:24 +0000 Message-Id: <20240308152829.25754-2-will@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20240308152829.25754-1-will@kernel.org> References: <20240308152829.25754-1-will@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Commit bbb73a103fbb ("swiotlb: fix a braino in the alignment check fix"), which was a fix for commit 0eee5ae10256 ("swiotlb: fix slot alignment checks"), causes a functional regression with vsock in a virtual machine using bouncing via a restricted DMA SWIOTLB pool. When virtio allocates the virtqueues for the vsock device using dma_alloc_coherent(), the SWIOTLB search can return page-unaligned allocations if 'area->index' was left unaligned by a previous allocation from the buffer: # Final address in brackets is the SWIOTLB address returned to the caller | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_ma= sk 0x800 stride 0x2: got slot 1645-1649/7168 (0x98326800) | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_ma= sk 0x800 stride 0x2: got slot 1649-1653/7168 (0x98328800) | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_ma= sk 0x800 stride 0x2: got slot 1653-1657/7168 (0x9832a800) This ends badly (typically buffer corruption and/or a hang) because swiotlb_alloc() is expecting a page-aligned allocation and so blindly returns a pointer to the 'struct page' corresponding to the allocation, therefore double-allocating the first half (2KiB slot) of the 4KiB page. Fix the problem by treating the allocation alignment separately to any additional alignment requirements from the device, using the maximum of the two as the stride to search the buffer slots and taking care to ensure a minimum of page-alignment for buffers larger than a page. This also resolves swiotlb allocation failures occuring due to the inclusion of ~PAGE_MASK in 'iotlb_align_mask' for large allocations and resulting in alignment requirements exceeding swiotlb_max_mapping_size(). Fixes: bbb73a103fbb ("swiotlb: fix a braino in the alignment check fix") Fixes: 0eee5ae10256 ("swiotlb: fix slot alignment checks") Cc: Christoph Hellwig Cc: Marek Szyprowski Cc: Robin Murphy Cc: Dexuan Cui Reviewed-by: Michael Kelley Reviewed-by: Petr Tesarik Tested-by: Nicolin Chen Signed-off-by: Will Deacon --- kernel/dma/swiotlb.c | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c index b079a9a8e087..2ec2cc81f1a2 100644 --- a/kernel/dma/swiotlb.c +++ b/kernel/dma/swiotlb.c @@ -982,7 +982,7 @@ static int swiotlb_search_pool_area(struct device *dev,= struct io_tlb_pool *pool phys_to_dma_unencrypted(dev, pool->start) & boundary_mask; unsigned long max_slots =3D get_max_slots(boundary_mask); unsigned int iotlb_align_mask =3D - dma_get_min_align_mask(dev) | alloc_align_mask; + dma_get_min_align_mask(dev) & ~(IO_TLB_SIZE - 1); unsigned int nslots =3D nr_slots(alloc_size), stride; unsigned int offset =3D swiotlb_align_offset(dev, orig_addr); unsigned int index, slots_checked, count =3D 0, i; @@ -993,19 +993,18 @@ static int swiotlb_search_pool_area(struct device *de= v, struct io_tlb_pool *pool BUG_ON(!nslots); BUG_ON(area_index >=3D pool->nareas); =20 + /* + * For mappings with an alignment requirement don't bother looping to + * unaligned slots once we found an aligned one. + */ + stride =3D get_max_slots(max(alloc_align_mask, iotlb_align_mask)); + /* * For allocations of PAGE_SIZE or larger only look for page aligned * allocations. */ if (alloc_size >=3D PAGE_SIZE) - iotlb_align_mask |=3D ~PAGE_MASK; - iotlb_align_mask &=3D ~(IO_TLB_SIZE - 1); - - /* - * For mappings with an alignment requirement don't bother looping to - * unaligned slots once we found an aligned one. - */ - stride =3D (iotlb_align_mask >> IO_TLB_SHIFT) + 1; + stride =3D umax(stride, PAGE_SHIFT - IO_TLB_SHIFT + 1); =20 spin_lock_irqsave(&area->lock, flags); if (unlikely(nslots > pool->area_nslabs - area->used)) @@ -1015,11 +1014,14 @@ static int swiotlb_search_pool_area(struct device *= dev, struct io_tlb_pool *pool index =3D area->index; =20 for (slots_checked =3D 0; slots_checked < pool->area_nslabs; ) { - slot_index =3D slot_base + index; + phys_addr_t tlb_addr; =20 - if (orig_addr && - (slot_addr(tbl_dma_addr, slot_index) & - iotlb_align_mask) !=3D (orig_addr & iotlb_align_mask)) { + slot_index =3D slot_base + index; + tlb_addr =3D slot_addr(tbl_dma_addr, slot_index); + + if ((tlb_addr & alloc_align_mask) || + (orig_addr && (tlb_addr & iotlb_align_mask) !=3D + (orig_addr & iotlb_align_mask))) { index =3D wrap_area_index(pool, index + 1); slots_checked++; continue; --=20 2.44.0.278.ge034bb2e1d-goog From nobody Wed Dec 24 12:14:11 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2C086250F3; Fri, 8 Mar 2024 15:28:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709911725; cv=none; b=fIrEKoqdoPlSQuggCwdPKo4wa78LYzZ4XRrcIMLx9KZpRJDFw/xRsMczNM0VlXCCkAsfXUJMOw+bMEJpRQP9EcTyBRm9LprtCN5MgAm9mu1FGQ4pAH0kFvHDleAIQAYfjKa3Kc7dmMQR/FxitYrIRImeCnE6SEIiX87TJcgVH8E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709911725; c=relaxed/simple; bh=Ow9SAlH4+n7rZYPGZozjvHYRa/8sNh9HhIRpID4khJg=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=gysD9VMnDuMDt5ylEIX0mp5rPxXGAQ8WULKv6gdgzKnD2500ugaxFCIHk9lo2KYqC5S/l8y+gQKxwYvUJ3XY50dVQ8YyomA8K7ABwaK2fBlVrJBtMTyRj6Jea/ygtKCo69fkezlJ1uIDxShyK8L2YfDTDREOtqZwEVaN20GJvg8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=iw1bQR64; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="iw1bQR64" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9FF7FC43394; Fri, 8 Mar 2024 15:28:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709911724; bh=Ow9SAlH4+n7rZYPGZozjvHYRa/8sNh9HhIRpID4khJg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=iw1bQR64cRNIugB/M++lMYhdds6aAyuYjHFy/xL/Q/MPZU0xLKAqIIc5LyKOud1Ca Fj+I8H4cqEse5HtWYHmCtj0xqJx3m5duWWck29kK/BX8NzOtfem5CKeyMSJ47JLPzX f/N4k6UnKPLon3uxounK1uVGwOm9WJBmQKuEHH9oS5pVzIFRhye+yj0HYzQp41rTzE t/h5LCGix5T+eWrKJM/G+ytqq7cqAs7vV05cz60RvMjAuhAZEMnnBFdaSaRMI7cewn kw2KyUypJWVXd3U+t+pSad6ZJ2FOuo+0jbAlIA1J29K5fzNpcXgIT0oU0raecjL0MM iJUW3y67dkWqw== From: Will Deacon To: linux-kernel@vger.kernel.org Cc: kernel-team@android.com, Will Deacon , iommu@lists.linux.dev, Christoph Hellwig , Marek Szyprowski , Robin Murphy , Petr Tesarik , Dexuan Cui , Nicolin Chen , Michael Kelley Subject: [PATCH v6 2/6] swiotlb: Enforce page alignment in swiotlb_alloc() Date: Fri, 8 Mar 2024 15:28:25 +0000 Message-Id: <20240308152829.25754-3-will@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20240308152829.25754-1-will@kernel.org> References: <20240308152829.25754-1-will@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When allocating pages from a restricted DMA pool in swiotlb_alloc(), the buffer address is blindly converted to a 'struct page *' that is returned to the caller. In the unlikely event of an allocation bug, page-unaligned addresses are not detected and slots can silently be double-allocated. Add a simple check of the buffer alignment in swiotlb_alloc() to make debugging a little easier if something has gone wonky. Cc: Christoph Hellwig Cc: Marek Szyprowski Cc: Robin Murphy Cc: Dexuan Cui Reviewed-by: Petr Tesarik Tested-by: Nicolin Chen Reviewed-by: Michael Kelley Signed-off-by: Will Deacon --- kernel/dma/swiotlb.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c index 2ec2cc81f1a2..ab7fbb40bc55 100644 --- a/kernel/dma/swiotlb.c +++ b/kernel/dma/swiotlb.c @@ -1643,6 +1643,12 @@ struct page *swiotlb_alloc(struct device *dev, size_= t size) return NULL; =20 tlb_addr =3D slot_addr(pool->start, index); + if (unlikely(!PAGE_ALIGNED(tlb_addr))) { + dev_WARN_ONCE(dev, 1, "Cannot allocate pages from non page-aligned swiot= lb addr 0x%pa.\n", + &tlb_addr); + swiotlb_release_slots(dev, tlb_addr); + return NULL; + } =20 return pfn_to_page(PFN_DOWN(tlb_addr)); } --=20 2.44.0.278.ge034bb2e1d-goog From nobody Wed Dec 24 12:14:11 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C589D2C869; Fri, 8 Mar 2024 15:28:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709911727; cv=none; b=HuofwPDQGA1zmoLicIRLGtcV4JIJ0ceiR224zIza8k2xoEndq3uKuR5yk6gOuUWX6cw8EMCQHPxdoaaUxyIvj/76UjPc5b3w5deCBxeTprXhOcTz8x4duo+HveXCqT9nhLloPo6Dc2pmazTSI/Gdtm0voz0dcwk/7nYgmduV/i0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709911727; c=relaxed/simple; bh=vsrvrkZU89TFmvM4wV64YJV1Q5GWDF7dRggI1U7nSbU=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=hy3/EstDETaJPmvJwD2mMxQ7nKR2M1gCjwfGFUSzABWlQtwz4SNVCg8Tp+qfe1htg/zXSulf0QNb7eUcSwmV31ogiuLlsEC0Ne2xCY32MRrfFPjDOZyApe0kZQaRqSNqqG+DPZ47czTcb0ZuhGeRd6RAvXf6Ozz6tg09u1+5BMQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nnCgYEZ4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nnCgYEZ4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 43033C433A6; Fri, 8 Mar 2024 15:28:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709911727; bh=vsrvrkZU89TFmvM4wV64YJV1Q5GWDF7dRggI1U7nSbU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nnCgYEZ4nXN7XpgODKCOquD+5BkcgKUeur8d4aB79bU2sc4SuWWcy6VAwYhwe7+zP ixoNMbZ/sQVOuxsh/9cd/IpRmewfqMxY+G9hw6MjE60Gw6CwfLHAzauU2YwbzCIyXi gQcWsxloGV1qbeS0shCTCsAwCthd5x1YSWScXFg+GEMUOF0+rfFfQXv/e60ZE1PJYX Vml2gU8tAe3fz9qkHLN2xMnE/kN5T+Lrico/ySXdv2o/Rw6r2RygqBytam0+Sc057S zVd44SHp8Bt4p39Att83L8GQOsEZtXrwOmZeSvykGG4aCAsyL3wMJ2AP1wqFoX0wlw yFV8dmbVS08iw== From: Will Deacon To: linux-kernel@vger.kernel.org Cc: kernel-team@android.com, Will Deacon , iommu@lists.linux.dev, Christoph Hellwig , Marek Szyprowski , Robin Murphy , Petr Tesarik , Dexuan Cui , Nicolin Chen , Michael Kelley Subject: [PATCH v6 3/6] swiotlb: Honour dma_alloc_coherent() alignment in swiotlb_alloc() Date: Fri, 8 Mar 2024 15:28:26 +0000 Message-Id: <20240308152829.25754-4-will@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20240308152829.25754-1-will@kernel.org> References: <20240308152829.25754-1-will@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" core-api/dma-api-howto.rst states the following properties of dma_alloc_coherent(): | The CPU virtual address and the DMA address are both guaranteed to | be aligned to the smallest PAGE_SIZE order which is greater than or | equal to the requested size. However, swiotlb_alloc() passes zero for the 'alloc_align_mask' parameter of swiotlb_find_slots() and so this property is not upheld. Instead, allocations larger than a page are aligned to PAGE_SIZE, Calculate the mask corresponding to the page order suitable for holding the allocation and pass that to swiotlb_find_slots(). Cc: Christoph Hellwig Cc: Marek Szyprowski Cc: Robin Murphy Cc: Dexuan Cui Fixes: e81e99bacc9f ("swiotlb: Support aligned swiotlb buffers") Reviewed-by: Petr Tesarik Tested-by: Nicolin Chen Reviewed-by: Michael Kelley Signed-off-by: Will Deacon --- kernel/dma/swiotlb.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c index ab7fbb40bc55..c20324fba814 100644 --- a/kernel/dma/swiotlb.c +++ b/kernel/dma/swiotlb.c @@ -1633,12 +1633,14 @@ struct page *swiotlb_alloc(struct device *dev, size= _t size) struct io_tlb_mem *mem =3D dev->dma_io_tlb_mem; struct io_tlb_pool *pool; phys_addr_t tlb_addr; + unsigned int align; int index; =20 if (!mem) return NULL; =20 - index =3D swiotlb_find_slots(dev, 0, size, 0, &pool); + align =3D (1 << (get_order(size) + PAGE_SHIFT)) - 1; + index =3D swiotlb_find_slots(dev, 0, size, align, &pool); if (index =3D=3D -1) return NULL; =20 --=20 2.44.0.278.ge034bb2e1d-goog From nobody Wed Dec 24 12:14:11 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6AD1F1EEFD; Fri, 8 Mar 2024 15:28:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709911730; cv=none; b=FnqfgdJzvhV1wqIy+os+vJWSsRNqXSoD1HupzZtuo5/5oWqoGz78Vb5Ox2nko7gMfG2v/iI30lAGcGmMnTJXH67edzlymDWya/2gVpYmiJKQPQVioQdcR3e3922aWF3XsZzUxzQ8ITeekWKxniZQ+ahlLZSLtYlCO9O3rgUkdu8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709911730; c=relaxed/simple; bh=n76N/QmTxWzDYO3g7VF7EKTPs6uGGLuTDor+G+M6gCk=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=k9plknX4LUBMv30vGIditcy70Ljq/4+U29OJAX9X+95KKqNUpPYg303dmvZGsvNN7a7DZ4ijrEBDmtXssey+portSir27zqHK6p7aMKwflq/jWaVamkOmcYoPspR5e9PGV14WtN8hwPs1pPJXcmFBWS0g/PO5PwC3ZQOqk5vkAE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=iTUGVGZz; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="iTUGVGZz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D3782C433F1; Fri, 8 Mar 2024 15:28:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709911730; bh=n76N/QmTxWzDYO3g7VF7EKTPs6uGGLuTDor+G+M6gCk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=iTUGVGZz5UkT+wKearzCBeceKmqF7KhauGIuliGwu3VwgUiqOjnIygC569njryNLU 3O3iSRsZrDckfRk45+HSxH6MhWSLe2lOxbhh46wWJiXqNiHppDomb6uXKyBiC7WfDR MiCdBsEV7z6XSOvyKwof/V6kW1pS4swtLTQW7xSOotAsbV/NiScHmuB4XY5MLXPHOl Kc6mpbe2FQejG55weRLA5aEHN/DRC9nqkdlhIIPSr9h0KpfnIkV9Y2dITdw3aTGLSd GAIrHnBfr+Rc6dASfIa0RWsfEHCgZ/KEg+Cskl818j00KlRj5gioBBjX0ZfYRFmfbu 4+pmM9+zWELZQ== From: Will Deacon To: linux-kernel@vger.kernel.org Cc: kernel-team@android.com, Will Deacon , iommu@lists.linux.dev, Christoph Hellwig , Marek Szyprowski , Robin Murphy , Petr Tesarik , Dexuan Cui , Nicolin Chen , Michael Kelley Subject: [PATCH v6 4/6] swiotlb: Fix alignment checks when both allocation and DMA masks are present Date: Fri, 8 Mar 2024 15:28:27 +0000 Message-Id: <20240308152829.25754-5-will@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20240308152829.25754-1-will@kernel.org> References: <20240308152829.25754-1-will@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Nicolin reports that swiotlb buffer allocations fail for an NVME device behind an IOMMU using 64KiB pages. This is because we end up with a minimum allocation alignment of 64KiB (for the IOMMU to map the buffer safely) but a minimum DMA alignment mask corresponding to a 4KiB NVME page (i.e. preserving the 4KiB page offset from the original allocation). If the original address is not 4KiB-aligned, the allocation will fail because swiotlb_search_pool_area() erroneously compares these unmasked bits with the 64KiB-aligned candidate allocation. Tweak swiotlb_search_pool_area() so that the DMA alignment mask is reduced based on the required alignment of the allocation. Fixes: 82612d66d51d ("iommu: Allow the dma-iommu api to use bounce buffers") Reported-by: Nicolin Chen Link: https://lore.kernel.org/r/cover.1707851466.git.nicolinc@nvidia.com Tested-by: Nicolin Chen Reviewed-by: Michael Kelley Signed-off-by: Will Deacon --- kernel/dma/swiotlb.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c index c20324fba814..c381a7ed718f 100644 --- a/kernel/dma/swiotlb.c +++ b/kernel/dma/swiotlb.c @@ -981,8 +981,7 @@ static int swiotlb_search_pool_area(struct device *dev,= struct io_tlb_pool *pool dma_addr_t tbl_dma_addr =3D phys_to_dma_unencrypted(dev, pool->start) & boundary_mask; unsigned long max_slots =3D get_max_slots(boundary_mask); - unsigned int iotlb_align_mask =3D - dma_get_min_align_mask(dev) & ~(IO_TLB_SIZE - 1); + unsigned int iotlb_align_mask =3D dma_get_min_align_mask(dev); unsigned int nslots =3D nr_slots(alloc_size), stride; unsigned int offset =3D swiotlb_align_offset(dev, orig_addr); unsigned int index, slots_checked, count =3D 0, i; @@ -993,6 +992,14 @@ static int swiotlb_search_pool_area(struct device *dev= , struct io_tlb_pool *pool BUG_ON(!nslots); BUG_ON(area_index >=3D pool->nareas); =20 + /* + * Ensure that the allocation is at least slot-aligned and update + * 'iotlb_align_mask' to ignore bits that will be preserved when + * offsetting into the allocation. + */ + alloc_align_mask |=3D (IO_TLB_SIZE - 1); + iotlb_align_mask &=3D ~alloc_align_mask; + /* * For mappings with an alignment requirement don't bother looping to * unaligned slots once we found an aligned one. --=20 2.44.0.278.ge034bb2e1d-goog From nobody Wed Dec 24 12:14:11 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ACFAC4EB54; Fri, 8 Mar 2024 15:28:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709911732; cv=none; b=T+upW3btdIHA+5uEnHzhNdpCumInp9oy12skhRacjitt84TzXaIfO77cfDKvy6+ieJf6aVl0HqaGRhPNHLPA+yJprXSBazgJpeTOpKZiS4bCFj4c52Ps5MCXzyJWOmVIbBtitNbLCb94RvcN/ADKXP4czP9+4rzyrLjDMGwtlY4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709911732; c=relaxed/simple; bh=dnzQBdb26QBemWGVHklaNCufoG7O//83hkXs/2Gr8UY=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=fzmfTMEzcz3mVBWGtjNiab7ExhFKLHA8ZOQ3iIlhb404SVaosGnXJVMiqlAkdBKe7O1KcZI06rGf8uWylRnpDYTV8F4zc88V0tJcZuTPbEr8ebmMuhcU0WbBWaoz99ns0rHFGS/IgHX8dnEcL1SyLwtdQHgwJwkLzvZTvtmUqpA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=pyUTXeCS; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="pyUTXeCS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 70C52C433C7; Fri, 8 Mar 2024 15:28:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709911732; bh=dnzQBdb26QBemWGVHklaNCufoG7O//83hkXs/2Gr8UY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pyUTXeCSeZKqvYdPkI9BWu1WGiLbeKCjg0iLnFyYDc1GR3GlWRPUQOPH/WlgLTsxA TUI2QZKV0U0Xh++W8nt3U+rGk84NeGRdqfKClI7mWKdrr+/F7NYhHFxKQgBVH1Sg3D 2aZrYueIDOQa95rKn1fK2COsFaJLoqeOT7R0SmpD5kORnYVpjqKGASgWisTn3IwmFZ GBWN7jda/PtOsAVidwPy9JAsv1LOljetblNIdflZluav5KgSPl0iRugQEVoKRPqNVJ 3WproAmzt66vLUlrYozXeTuZvCOX3/eNz1Hq6AXlgRduozGMi0EVexO7rXGQgLFvhu CKWWtkdiCB8WA== From: Will Deacon To: linux-kernel@vger.kernel.org Cc: kernel-team@android.com, Will Deacon , iommu@lists.linux.dev, Christoph Hellwig , Marek Szyprowski , Robin Murphy , Petr Tesarik , Dexuan Cui , Nicolin Chen , Michael Kelley Subject: [PATCH v6 5/6] iommu/dma: Force swiotlb_max_mapping_size on an untrusted device Date: Fri, 8 Mar 2024 15:28:28 +0000 Message-Id: <20240308152829.25754-6-will@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20240308152829.25754-1-will@kernel.org> References: <20240308152829.25754-1-will@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Nicolin Chen The swiotlb does not support a mapping size > swiotlb_max_mapping_size(). On the other hand, with a 64KB PAGE_SIZE configuration, it's observed that an NVME device can map a size between 300KB~512KB, which certainly failed the swiotlb mappings, though the default pool of swiotlb has many slots: systemd[1]: Started Journal Service. =3D> nvme 0000:00:01.0: swiotlb buffer is full (sz: 327680 bytes), total 3= 2768 (slots), used 32 (slots) note: journal-offline[392] exited with irqs disabled note: journal-offline[392] exited with preempt_count 1 Call trace: [ 3.099918] swiotlb_tbl_map_single+0x214/0x240 [ 3.099921] iommu_dma_map_page+0x218/0x328 [ 3.099928] dma_map_page_attrs+0x2e8/0x3a0 [ 3.101985] nvme_prep_rq.part.0+0x408/0x878 [nvme] [ 3.102308] nvme_queue_rqs+0xc0/0x300 [nvme] [ 3.102313] blk_mq_flush_plug_list.part.0+0x57c/0x600 [ 3.102321] blk_add_rq_to_plug+0x180/0x2a0 [ 3.102323] blk_mq_submit_bio+0x4c8/0x6b8 [ 3.103463] __submit_bio+0x44/0x220 [ 3.103468] submit_bio_noacct_nocheck+0x2b8/0x360 [ 3.103470] submit_bio_noacct+0x180/0x6c8 [ 3.103471] submit_bio+0x34/0x130 [ 3.103473] ext4_bio_write_folio+0x5a4/0x8c8 [ 3.104766] mpage_submit_folio+0xa0/0x100 [ 3.104769] mpage_map_and_submit_buffers+0x1a4/0x400 [ 3.104771] ext4_do_writepages+0x6a0/0xd78 [ 3.105615] ext4_writepages+0x80/0x118 [ 3.105616] do_writepages+0x90/0x1e8 [ 3.105619] filemap_fdatawrite_wbc+0x94/0xe0 [ 3.105622] __filemap_fdatawrite_range+0x68/0xb8 [ 3.106656] file_write_and_wait_range+0x84/0x120 [ 3.106658] ext4_sync_file+0x7c/0x4c0 [ 3.106660] vfs_fsync_range+0x3c/0xa8 [ 3.106663] do_fsync+0x44/0xc0 Since untrusted devices might go down the swiotlb pathway with dma-iommu, these devices should not map a size larger than swiotlb_max_mapping_size. To fix this bug, add iommu_dma_max_mapping_size() for untrusted devices to take into account swiotlb_max_mapping_size() v.s. iova_rcache_range() from the iommu_dma_opt_mapping_size(). Fixes: 82612d66d51d ("iommu: Allow the dma-iommu api to use bounce buffers") Signed-off-by: Nicolin Chen Link: https://lore.kernel.org/r/ee51a3a5c32cf885b18f6416171802669f4a718a.17= 07851466.git.nicolinc@nvidia.com Acked-by: Robin Murphy Reviewed-by: Michael Kelley [will: Drop redundant is_swiotlb_active(dev) check] Signed-off-by: Will Deacon Tested-by: Nicolin Chen --- drivers/iommu/dma-iommu.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c index 50ccc4f1ef81..639efa0c4072 100644 --- a/drivers/iommu/dma-iommu.c +++ b/drivers/iommu/dma-iommu.c @@ -1706,6 +1706,14 @@ static size_t iommu_dma_opt_mapping_size(void) return iova_rcache_range(); } =20 +static size_t iommu_dma_max_mapping_size(struct device *dev) +{ + if (dev_is_untrusted(dev)) + return swiotlb_max_mapping_size(dev); + + return SIZE_MAX; +} + static const struct dma_map_ops iommu_dma_ops =3D { .flags =3D DMA_F_PCI_P2PDMA_SUPPORTED, .alloc =3D iommu_dma_alloc, @@ -1728,6 +1736,7 @@ static const struct dma_map_ops iommu_dma_ops =3D { .unmap_resource =3D iommu_dma_unmap_resource, .get_merge_boundary =3D iommu_dma_get_merge_boundary, .opt_mapping_size =3D iommu_dma_opt_mapping_size, + .max_mapping_size =3D iommu_dma_max_mapping_size, }; =20 /* --=20 2.44.0.278.ge034bb2e1d-goog From nobody Wed Dec 24 12:14:11 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A328E5674C; Fri, 8 Mar 2024 15:28:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709911735; cv=none; b=iO2hrzPkdoi3qrLDmb1dAY0cLifzR2qDUXNVj/NWb7c6GoVng7MkXT+Zmte4VFbzb/PJahB2Hq7EYNHR8egh4rU77KZ0Xct6BfYT7CFr4bLGYllEFPk3n6dFRyyxaqY8atPTvNEik7h+3pCk8n6GGVnpf4C78hYCnbyuM1pWfAk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709911735; c=relaxed/simple; bh=bMtbuNa4OfY3K2WJdXy/zJcV5S/fCzZ4bwmKbkY1b0s=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=NyAhIp+RHj60HXP9ePW06+K6mV1GSwvi+FhT3jQxcu43u2/4cgWRaS9GMJfQjPYCce0sfc7umX58XNUl+oRlbZR5tMf5U/ctumdE+W+M5OOYDwbbQi1ZCOp+6ACSxE8YVZMysVkny7ysB3NiIlxvXRbP/sCPDv6Qdzong1Jw3XE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CWbYXEOa; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CWbYXEOa" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0C4AAC43399; Fri, 8 Mar 2024 15:28:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709911735; bh=bMtbuNa4OfY3K2WJdXy/zJcV5S/fCzZ4bwmKbkY1b0s=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CWbYXEOa6wE27t0jsLOmA9bTsLR6V2AlvBrk9RktDdS3R6g9SZe+VXXgiqY5iCmQM BLsOZxtpGCfCeilWAcXaUoe01rL/2+jfsdkGBtf1Mp8hYwzzgT/apZ99IIIK5kBrVq RhHjx7Tb8sR7LP3hknRbpH86ZV/wDKXlRloDx6rQUHWfHd6KgoAIpmzBNdLrPOiE9s RP6DvfPeGP+eQfGB1u93rLXhVuGS+TUzmblBNlnulL7USEx9Z6yh9tPswczTDxQ3m4 wGbeGkVm1EKuGnWCWy/P1ueOqelDsezPCP+2b43C3kIcartNXssO36WKyf+3i2OP6B AdWdNeBf6S+TQ== From: Will Deacon To: linux-kernel@vger.kernel.org Cc: kernel-team@android.com, Will Deacon , iommu@lists.linux.dev, Christoph Hellwig , Marek Szyprowski , Robin Murphy , Petr Tesarik , Dexuan Cui , Nicolin Chen , Michael Kelley Subject: [PATCH v6 6/6] swiotlb: Reinstate page-alignment for mappings >= PAGE_SIZE Date: Fri, 8 Mar 2024 15:28:29 +0000 Message-Id: <20240308152829.25754-7-will@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20240308152829.25754-1-will@kernel.org> References: <20240308152829.25754-1-will@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" For swiotlb allocations >=3D PAGE_SIZE, the slab search historically adjusted the stride to avoid checking unaligned slots. This had the side-effect of aligning large mapping requests to PAGE_SIZE, but that was broken by 0eee5ae10256 ("swiotlb: fix slot alignment checks"). Since this alignment could be relied upon drivers, reinstate PAGE_SIZE alignment for swiotlb mappings >=3D PAGE_SIZE. Reported-by: Michael Kelley Signed-off-by: Will Deacon Reviewed-by: Petr Tesarik Reviewed-by: Robin Murphy Tested-by: Nicolin Chen --- kernel/dma/swiotlb.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c index c381a7ed718f..c5851034523f 100644 --- a/kernel/dma/swiotlb.c +++ b/kernel/dma/swiotlb.c @@ -992,6 +992,17 @@ static int swiotlb_search_pool_area(struct device *dev= , struct io_tlb_pool *pool BUG_ON(!nslots); BUG_ON(area_index >=3D pool->nareas); =20 + /* + * Historically, swiotlb allocations >=3D PAGE_SIZE were guaranteed to be + * page-aligned in the absence of any other alignment requirements. + * 'alloc_align_mask' was later introduced to specify the alignment + * explicitly, however this is passed as zero for streaming mappings + * and so we preserve the old behaviour there in case any drivers are + * relying on it. + */ + if (!alloc_align_mask && !iotlb_align_mask && alloc_size >=3D PAGE_SIZE) + alloc_align_mask =3D PAGE_SIZE - 1; + /* * Ensure that the allocation is at least slot-aligned and update * 'iotlb_align_mask' to ignore bits that will be preserved when @@ -1006,13 +1017,6 @@ static int swiotlb_search_pool_area(struct device *d= ev, struct io_tlb_pool *pool */ stride =3D get_max_slots(max(alloc_align_mask, iotlb_align_mask)); =20 - /* - * For allocations of PAGE_SIZE or larger only look for page aligned - * allocations. - */ - if (alloc_size >=3D PAGE_SIZE) - stride =3D umax(stride, PAGE_SHIFT - IO_TLB_SHIFT + 1); - spin_lock_irqsave(&area->lock, flags); if (unlikely(nslots > pool->area_nslabs - area->used)) goto not_found; --=20 2.44.0.278.ge034bb2e1d-goog