* [PATCH] swiotlb-xen: provide the "max_mapping_size" method
[not found] ` <20231106071008.GB17022@lst.de>
@ 2023-11-06 14:59 ` Mikulas Patocka
2023-11-06 15:16 ` Keith Busch
0 siblings, 1 reply; 6+ messages in thread
From: Mikulas Patocka @ 2023-11-06 14:59 UTC (permalink / raw)
To: Christoph Hellwig, Juergen Gross, Stefano Stabellini, xen-devel,
iommu
Cc: Keith Busch, Marek Marczykowski-G'orecki, Jens Axboe,
Sagi Grimberg, Jan Kara, Vlastimil Babka, Andrew Morton,
Matthew Wilcox, Michal Hocko, stable, regressions,
Alasdair Kergon, Mike Snitzer, dm-devel, linux-mm
[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]
There's a bug that when using the XEN hypervisor with dm-crypt on NVMe,
the kernel deadlocks [1].
The deadlocks are caused by inability to map a large bio vector -
dma_map_sgtable always returns an error, this gets propagated to the block
layer as BLK_STS_RESOURCE and the block layer retries the request
indefinitely.
XEN uses the swiotlb framework to map discontiguous pages into contiguous
runs that are submitted to the PCIe device. The swiotlb framework has a
limitation on the length of a mapping - this needs to be announced with
the max_mapping_size method to make sure that the hardware drivers do not
create larger mappings.
Without max_mapping_size, the NVMe block driver would create large
mappings that overrun the maximum mapping size.
[1] https://lore.kernel.org/stable/ZTNH0qtmint%2FzLJZ@mail-itl/
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Tested-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Suggested-by: Keith Busch <kbusch@kernel.org>
Suggested-by: Christoph Hellwig <hch@lst.de>
Cc: stable@vger.kernel.org
---
drivers/xen/swiotlb-xen.c | 1 +
1 file changed, 1 insertion(+)
Index: linux-stable/drivers/xen/swiotlb-xen.c
===================================================================
--- linux-stable.orig/drivers/xen/swiotlb-xen.c 2023-11-03 17:57:18.000000000 +0100
+++ linux-stable/drivers/xen/swiotlb-xen.c 2023-11-06 15:30:59.000000000 +0100
@@ -405,4 +405,5 @@ const struct dma_map_ops xen_swiotlb_dma
.get_sgtable = dma_common_get_sgtable,
.alloc_pages = dma_common_alloc_pages,
.free_pages = dma_common_free_pages,
+ .max_mapping_size = swiotlb_max_mapping_size,
};
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] swiotlb-xen: provide the "max_mapping_size" method
2023-11-06 14:59 ` [PATCH] swiotlb-xen: provide the "max_mapping_size" method Mikulas Patocka
@ 2023-11-06 15:16 ` Keith Busch
2023-11-06 15:30 ` Mike Snitzer
0 siblings, 1 reply; 6+ messages in thread
From: Keith Busch @ 2023-11-06 15:16 UTC (permalink / raw)
To: Mikulas Patocka
Cc: Christoph Hellwig, Juergen Gross, Stefano Stabellini, xen-devel,
iommu, Marek Marczykowski-G'orecki, Jens Axboe, Sagi Grimberg,
Jan Kara, Vlastimil Babka, Andrew Morton, Matthew Wilcox,
Michal Hocko, stable, regressions, Alasdair Kergon, Mike Snitzer,
dm-devel, linux-mm
On Mon, Nov 06, 2023 at 03:59:40PM +0100, Mikulas Patocka wrote:
> There's a bug that when using the XEN hypervisor with dm-crypt on NVMe,
> the kernel deadlocks [1].
>
> The deadlocks are caused by inability to map a large bio vector -
> dma_map_sgtable always returns an error, this gets propagated to the block
> layer as BLK_STS_RESOURCE and the block layer retries the request
> indefinitely.
>
> XEN uses the swiotlb framework to map discontiguous pages into contiguous
> runs that are submitted to the PCIe device. The swiotlb framework has a
> limitation on the length of a mapping - this needs to be announced with
> the max_mapping_size method to make sure that the hardware drivers do not
> create larger mappings.
>
> Without max_mapping_size, the NVMe block driver would create large
> mappings that overrun the maximum mapping size.
>
> [1] https://lore.kernel.org/stable/ZTNH0qtmint%2FzLJZ@mail-itl/
This should be a "Link:" tag.
> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
> Reported-by: Marek Marczykowski-G'orecki <marmarek@invisiblethingslab.com>
> Tested-by: Marek Marczykowski-G'orecki <marmarek@invisiblethingslab.com>
> Suggested-by: Keith Busch <kbusch@kernel.org>
I was about to send the same thing. I did a little more than suggest
this: it's is the very patch I wrote for testing, minus the redundant
nvme bits! But since you already have a commit message for it...
Acked-by: Keith Busch <kbusch@kernel.org>
> Suggested-by: Christoph Hellwig <hch@lst.de>
> Cc: stable@vger.kernel.org
>
> ---
> drivers/xen/swiotlb-xen.c | 1 +
> 1 file changed, 1 insertion(+)
>
> Index: linux-stable/drivers/xen/swiotlb-xen.c
> ===================================================================
> --- linux-stable.orig/drivers/xen/swiotlb-xen.c 2023-11-03 17:57:18.000000000 +0100
> +++ linux-stable/drivers/xen/swiotlb-xen.c 2023-11-06 15:30:59.000000000 +0100
> @@ -405,4 +405,5 @@ const struct dma_map_ops xen_swiotlb_dma
> .get_sgtable = dma_common_get_sgtable,
> .alloc_pages = dma_common_alloc_pages,
> .free_pages = dma_common_free_pages,
> + .max_mapping_size = swiotlb_max_mapping_size,
> };
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: swiotlb-xen: provide the "max_mapping_size" method
2023-11-06 15:16 ` Keith Busch
@ 2023-11-06 15:30 ` Mike Snitzer
2023-11-06 17:12 ` [PATCH v2] " Mikulas Patocka
0 siblings, 1 reply; 6+ messages in thread
From: Mike Snitzer @ 2023-11-06 15:30 UTC (permalink / raw)
To: Keith Busch
Cc: Mikulas Patocka, Christoph Hellwig, Juergen Gross,
Stefano Stabellini, xen-devel, iommu,
Marek Marczykowski-G'orecki, Jens Axboe, Sagi Grimberg,
Jan Kara, Vlastimil Babka, Andrew Morton, Matthew Wilcox,
Michal Hocko, stable, regressions, Alasdair Kergon, dm-devel,
linux-mm
On Mon, Nov 06 2023 at 10:16P -0500,
Keith Busch <kbusch@kernel.org> wrote:
> On Mon, Nov 06, 2023 at 03:59:40PM +0100, Mikulas Patocka wrote:
> > There's a bug that when using the XEN hypervisor with dm-crypt on NVMe,
> > the kernel deadlocks [1].
> >
> > The deadlocks are caused by inability to map a large bio vector -
> > dma_map_sgtable always returns an error, this gets propagated to the block
> > layer as BLK_STS_RESOURCE and the block layer retries the request
> > indefinitely.
> >
> > XEN uses the swiotlb framework to map discontiguous pages into contiguous
> > runs that are submitted to the PCIe device. The swiotlb framework has a
> > limitation on the length of a mapping - this needs to be announced with
> > the max_mapping_size method to make sure that the hardware drivers do not
> > create larger mappings.
> >
> > Without max_mapping_size, the NVMe block driver would create large
> > mappings that overrun the maximum mapping size.
> >
> > [1] https://lore.kernel.org/stable/ZTNH0qtmint%2FzLJZ@mail-itl/
>
> This should be a "Link:" tag.
>
> > Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
> > Reported-by: Marek Marczykowski-G'orecki <marmarek@invisiblethingslab.com>
> > Tested-by: Marek Marczykowski-G'orecki <marmarek@invisiblethingslab.com>
> > Suggested-by: Keith Busch <kbusch@kernel.org>
>
> I was about to send the same thing. I did a little more than suggest
> this: it's is the very patch I wrote for testing, minus the redundant
> nvme bits! But since you already have a commit message for it...
>
> Acked-by: Keith Busch <kbusch@kernel.org>
No, this patch should be attributed to you Keith.
Mikulas, I like that you ran with getting a fix prepared but please
update the patch so Keith is the author and use Link: as suggested for
the v2. Note: you'll still use your Signed-off-by since you had a role
in getting this patch together (but please move yours to the end of
the header).
Mike
>
> > Suggested-by: Christoph Hellwig <hch@lst.de>
> > Cc: stable@vger.kernel.org
> >
> > ---
> > drivers/xen/swiotlb-xen.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > Index: linux-stable/drivers/xen/swiotlb-xen.c
> > ===================================================================
> > --- linux-stable.orig/drivers/xen/swiotlb-xen.c 2023-11-03 17:57:18.000000000 +0100
> > +++ linux-stable/drivers/xen/swiotlb-xen.c 2023-11-06 15:30:59.000000000 +0100
> > @@ -405,4 +405,5 @@ const struct dma_map_ops xen_swiotlb_dma
> > .get_sgtable = dma_common_get_sgtable,
> > .alloc_pages = dma_common_alloc_pages,
> > .free_pages = dma_common_free_pages,
> > + .max_mapping_size = swiotlb_max_mapping_size,
> > };
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v2] swiotlb-xen: provide the "max_mapping_size" method
2023-11-06 15:30 ` Mike Snitzer
@ 2023-11-06 17:12 ` Mikulas Patocka
2023-11-07 4:18 ` Stefano Stabellini
2023-11-08 7:31 ` Christoph Hellwig
0 siblings, 2 replies; 6+ messages in thread
From: Mikulas Patocka @ 2023-11-06 17:12 UTC (permalink / raw)
To: Mike Snitzer
Cc: Keith Busch, Christoph Hellwig, Juergen Gross, Stefano Stabellini,
xen-devel, iommu, Marek Marczykowski-G'orecki, Jens Axboe,
Sagi Grimberg, Jan Kara, Vlastimil Babka, Andrew Morton,
Matthew Wilcox, Michal Hocko, stable, regressions,
Alasdair Kergon, dm-devel, linux-mm
[-- Attachment #1: Type: text/plain, Size: 1795 bytes --]
From: Keith Busch <kbusch@kernel.org>
There's a bug that when using the XEN hypervisor with bios with large
multi-page bio vectors on NVMe, the kernel deadlocks [1].
The deadlocks are caused by inability to map a large bio vector -
dma_map_sgtable always returns an error, this gets propagated to the block
layer as BLK_STS_RESOURCE and the block layer retries the request
indefinitely.
XEN uses the swiotlb framework to map discontiguous pages into contiguous
runs that are submitted to the PCIe device. The swiotlb framework has a
limitation on the length of a mapping - this needs to be announced with
the max_mapping_size method to make sure that the hardware drivers do not
create larger mappings.
Without max_mapping_size, the NVMe block driver would create large
mappings that overrun the maximum mapping size.
Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Link: https://lore.kernel.org/stable/ZTNH0qtmint%2FzLJZ@mail-itl/ [1]
Tested-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Suggested-by: Christoph Hellwig <hch@lst.de>
Cc: stable@vger.kernel.org
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
---
drivers/xen/swiotlb-xen.c | 1 +
1 file changed, 1 insertion(+)
Index: linux-stable/drivers/xen/swiotlb-xen.c
===================================================================
--- linux-stable.orig/drivers/xen/swiotlb-xen.c 2023-11-03 17:57:18.000000000 +0100
+++ linux-stable/drivers/xen/swiotlb-xen.c 2023-11-06 15:30:59.000000000 +0100
@@ -405,4 +405,5 @@ const struct dma_map_ops xen_swiotlb_dma
.get_sgtable = dma_common_get_sgtable,
.alloc_pages = dma_common_alloc_pages,
.free_pages = dma_common_free_pages,
+ .max_mapping_size = swiotlb_max_mapping_size,
};
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] swiotlb-xen: provide the "max_mapping_size" method
2023-11-06 17:12 ` [PATCH v2] " Mikulas Patocka
@ 2023-11-07 4:18 ` Stefano Stabellini
2023-11-08 7:31 ` Christoph Hellwig
1 sibling, 0 replies; 6+ messages in thread
From: Stefano Stabellini @ 2023-11-07 4:18 UTC (permalink / raw)
To: Mikulas Patocka
Cc: Mike Snitzer, Keith Busch, Christoph Hellwig, Juergen Gross,
Stefano Stabellini, xen-devel, iommu,
Marek Marczykowski-G'orecki, Jens Axboe, Sagi Grimberg,
Jan Kara, Vlastimil Babka, Andrew Morton, Matthew Wilcox,
Michal Hocko, stable, regressions, Alasdair Kergon, dm-devel,
linux-mm
[-- Attachment #1: Type: text/plain, Size: 1976 bytes --]
On Mon, 6 Nov 2023, Mikulas Patocka wrote:
> From: Keith Busch <kbusch@kernel.org>
>
> There's a bug that when using the XEN hypervisor with bios with large
> multi-page bio vectors on NVMe, the kernel deadlocks [1].
>
> The deadlocks are caused by inability to map a large bio vector -
> dma_map_sgtable always returns an error, this gets propagated to the block
> layer as BLK_STS_RESOURCE and the block layer retries the request
> indefinitely.
>
> XEN uses the swiotlb framework to map discontiguous pages into contiguous
> runs that are submitted to the PCIe device. The swiotlb framework has a
> limitation on the length of a mapping - this needs to be announced with
> the max_mapping_size method to make sure that the hardware drivers do not
> create larger mappings.
>
> Without max_mapping_size, the NVMe block driver would create large
> mappings that overrun the maximum mapping size.
>
> Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
> Link: https://lore.kernel.org/stable/ZTNH0qtmint%2FzLJZ@mail-itl/ [1]
> Tested-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
> Suggested-by: Christoph Hellwig <hch@lst.de>
> Cc: stable@vger.kernel.org
> Signed-off-by: Keith Busch <kbusch@kernel.org>
> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
> ---
> drivers/xen/swiotlb-xen.c | 1 +
> 1 file changed, 1 insertion(+)
>
> Index: linux-stable/drivers/xen/swiotlb-xen.c
> ===================================================================
> --- linux-stable.orig/drivers/xen/swiotlb-xen.c 2023-11-03 17:57:18.000000000 +0100
> +++ linux-stable/drivers/xen/swiotlb-xen.c 2023-11-06 15:30:59.000000000 +0100
> @@ -405,4 +405,5 @@ const struct dma_map_ops xen_swiotlb_dma
> .get_sgtable = dma_common_get_sgtable,
> .alloc_pages = dma_common_alloc_pages,
> .free_pages = dma_common_free_pages,
> + .max_mapping_size = swiotlb_max_mapping_size,
> };
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] swiotlb-xen: provide the "max_mapping_size" method
2023-11-06 17:12 ` [PATCH v2] " Mikulas Patocka
2023-11-07 4:18 ` Stefano Stabellini
@ 2023-11-08 7:31 ` Christoph Hellwig
1 sibling, 0 replies; 6+ messages in thread
From: Christoph Hellwig @ 2023-11-08 7:31 UTC (permalink / raw)
To: Mikulas Patocka
Cc: Mike Snitzer, Keith Busch, Christoph Hellwig, Juergen Gross,
Stefano Stabellini, xen-devel, iommu,
Marek Marczykowski-G'orecki, Jens Axboe, Sagi Grimberg,
Jan Kara, Vlastimil Babka, Andrew Morton, Matthew Wilcox,
Michal Hocko, stable, regressions, Alasdair Kergon, dm-devel,
linux-mm
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-11-08 7:32 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <ZULvkPhcpgAVyI8w@mail-itl>
[not found] ` <ac5b5ac0-9e8-c1b0-a26-62f832f845f0@redhat.com>
[not found] ` <ZUOL8kXVTF1OngeN@mail-itl>
[not found] ` <3cb4133c-b6db-9187-a678-11ed8c9456e@redhat.com>
[not found] ` <ZUUctamEFtAlSnSV@mail-itl>
[not found] ` <ZUUlqJoS6_1IznzT@kbusch-mbp.dhcp.thefacebook.com>
[not found] ` <ZUVYT1Xp4+hFT27W@mail-itl>
[not found] ` <ZUV3TApYYoh_oiRR@kbusch-mbp.dhcp.thefacebook.com>
[not found] ` <11a9886d-316c-edcd-d6da-24ad0b9a2b4@redhat.com>
[not found] ` <ZUZOKitOAqqKiJ4n@kbusch-mbp.dhcp.thefacebook.com>
[not found] ` <20231106071008.GB17022@lst.de>
2023-11-06 14:59 ` [PATCH] swiotlb-xen: provide the "max_mapping_size" method Mikulas Patocka
2023-11-06 15:16 ` Keith Busch
2023-11-06 15:30 ` Mike Snitzer
2023-11-06 17:12 ` [PATCH v2] " Mikulas Patocka
2023-11-07 4:18 ` Stefano Stabellini
2023-11-08 7:31 ` Christoph Hellwig
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox