All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will@kernel.org>
To: linux-kernel@vger.kernel.org
Cc: kernel-team@android.com, Will Deacon <will@kernel.org>,
	iommu@lists.linux.dev, Christoph Hellwig <hch@lst.de>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Petr Tesarik <petr.tesarik1@huawei-partners.com>,
	Dexuan Cui <decui@microsoft.com>,
	Nicolin Chen <nicolinc@nvidia.com>,
	Michael Kelley <mhklinux@outlook.com>
Subject: [PATCH v5 5/6] iommu/dma: Force swiotlb_max_mapping_size on an untrusted device
Date: Wed, 28 Feb 2024 13:39:29 +0000	[thread overview]
Message-ID: <20240228133930.15400-6-will@kernel.org> (raw)
In-Reply-To: <20240228133930.15400-1-will@kernel.org>

From: Nicolin Chen <nicolinc@nvidia.com>

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.
 => nvme 0000:00:01.0: swiotlb buffer is full (sz: 327680 bytes), total 32768 (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 <nicolinc@nvidia.com>
Link: https://lore.kernel.org/r/ee51a3a5c32cf885b18f6416171802669f4a718a.1707851466.git.nicolinc@nvidia.com
Acked-by: Robin Murphy <robin.murphy@arm.com>
[will: Drop redundant is_swiotlb_active(dev) check]
Signed-off-by: Will Deacon <will@kernel.org>
---
 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();
 }
 
+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 = {
 	.flags			= DMA_F_PCI_P2PDMA_SUPPORTED,
 	.alloc			= iommu_dma_alloc,
@@ -1728,6 +1736,7 @@ static const struct dma_map_ops iommu_dma_ops = {
 	.unmap_resource		= iommu_dma_unmap_resource,
 	.get_merge_boundary	= iommu_dma_get_merge_boundary,
 	.opt_mapping_size	= iommu_dma_opt_mapping_size,
+	.max_mapping_size       = iommu_dma_max_mapping_size,
 };
 
 /*
-- 
2.44.0.rc1.240.g4c46232300-goog


  parent reply	other threads:[~2024-02-28 13:39 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-28 13:39 [PATCH v5 0/6] Fix double allocation in swiotlb_alloc() Will Deacon
2024-02-28 13:39 ` [PATCH v5 1/6] swiotlb: Fix double-allocation of slots due to broken alignment handling Will Deacon
2024-02-29  5:44   ` Michael Kelley
2024-02-28 13:39 ` [PATCH v5 2/6] swiotlb: Enforce page alignment in swiotlb_alloc() Will Deacon
2024-02-28 13:39 ` [PATCH v5 3/6] swiotlb: Honour dma_alloc_coherent() " Will Deacon
2024-02-28 13:39 ` [PATCH v5 4/6] swiotlb: Fix alignment checks when both allocation and DMA masks are present Will Deacon
2024-02-28 13:39 ` Will Deacon [this message]
2024-02-29  5:57   ` [PATCH v5 5/6] iommu/dma: Force swiotlb_max_mapping_size on an untrusted device Michael Kelley
2024-02-28 13:39 ` [PATCH v5 6/6] swiotlb: Remove pointless stride adjustment for allocations >= PAGE_SIZE Will Deacon
2024-02-29  6:07   ` Michael Kelley
2024-02-29  7:36     ` Michael Kelley
2024-02-29 13:33       ` Christoph Hellwig
2024-02-29 15:44         ` Michael Kelley
2024-02-29 15:47           ` Christoph Hellwig
2024-03-01 15:39             ` Petr Tesařík
2024-03-01 16:38               ` Robin Murphy
2024-03-01 17:33                 ` Petr Tesařík
2024-03-01 17:08               ` Petr Tesařík
2024-03-01 17:54                 ` Robin Murphy
2024-03-01 18:42                   ` Petr Tesařík
2024-03-04  3:31                     ` Michael Kelley
2024-03-04 11:00                       ` Petr Tesařík
2024-03-04 13:37                         ` Robin Murphy
2024-03-04 15:55                           ` Petr Tesařík
2024-03-04 16:02                             ` Will Deacon
2024-03-04 16:10                               ` Michael Kelley
2024-03-04 16:53                                 ` Robin Murphy
2024-03-04 18:22                                   ` Michael Kelley
2024-03-05 11:20                                     ` Robin Murphy
2024-03-05 15:15                                       ` Petr Tesařík
2024-03-04 19:04                                 ` Petr Tesařík
2024-03-05 14:08                                   ` Christoph Hellwig
2024-03-04 16:04                             ` Michael Kelley
2024-03-04 17:11                               ` Robin Murphy
2024-03-04 18:08                                 ` Michael Kelley
2024-03-05 14:05                           ` Christoph Hellwig
2024-03-04 15:32     ` Will Deacon

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=20240228133930.15400-6-will@kernel.org \
    --to=will@kernel.org \
    --cc=decui@microsoft.com \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux.dev \
    --cc=kernel-team@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mhklinux@outlook.com \
    --cc=nicolinc@nvidia.com \
    --cc=petr.tesarik1@huawei-partners.com \
    --cc=robin.murphy@arm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.