From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Sasha Levin <sashal@kernel.org>, Joerg Roedel <jroedel@suse.de>,
will@kernel.org, Yunfei Wang <yf.wang@mediatek.com>,
iommu@lists.linux-foundation.org,
Miles Chen <miles.chen@mediatek.com>,
linux-mediatek@lists.infradead.org, matthias.bgg@gmail.com,
Robin Murphy <robin.murphy@arm.com>,
linux-arm-kernel@lists.infradead.org
Subject: [PATCH AUTOSEL 5.4 27/37] iommu/iova: Improve 32-bit free space estimate
Date: Fri, 1 Apr 2022 10:44:36 -0400 [thread overview]
Message-ID: <20220401144446.1954694-27-sashal@kernel.org> (raw)
In-Reply-To: <20220401144446.1954694-1-sashal@kernel.org>
From: Robin Murphy <robin.murphy@arm.com>
[ Upstream commit 5b61343b50590fb04a3f6be2cdc4868091757262 ]
For various reasons based on the allocator behaviour and typical
use-cases at the time, when the max32_alloc_size optimisation was
introduced it seemed reasonable to couple the reset of the tracked
size to the update of cached32_node upon freeing a relevant IOVA.
However, since subsequent optimisations focused on helping genuine
32-bit devices make best use of even more limited address spaces, it
is now a lot more likely for cached32_node to be anywhere in a "full"
32-bit address space, and as such more likely for space to become
available from IOVAs below that node being freed.
At this point, the short-cut in __cached_rbnode_delete_update() really
doesn't hold up any more, and we need to fix the logic to reliably
provide the expected behaviour. We still want cached32_node to only move
upwards, but we should reset the allocation size if *any* 32-bit space
has become available.
Reported-by: Yunfei Wang <yf.wang@mediatek.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Miles Chen <miles.chen@mediatek.com>
Link: https://lore.kernel.org/r/033815732d83ca73b13c11485ac39336f15c3b40.1646318408.git.robin.murphy@arm.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/iommu/iova.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index 906582a21124..628a586be695 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -138,10 +138,11 @@ __cached_rbnode_delete_update(struct iova_domain *iovad, struct iova *free)
cached_iova = rb_entry(iovad->cached32_node, struct iova, node);
if (free == cached_iova ||
(free->pfn_hi < iovad->dma_32bit_pfn &&
- free->pfn_lo >= cached_iova->pfn_lo)) {
+ free->pfn_lo >= cached_iova->pfn_lo))
iovad->cached32_node = rb_next(&free->node);
+
+ if (free->pfn_lo < iovad->dma_32bit_pfn)
iovad->max32_alloc_size = iovad->dma_32bit_pfn;
- }
cached_iova = rb_entry(iovad->cached_node, struct iova, node);
if (free->pfn_lo >= cached_iova->pfn_lo)
--
2.34.1
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Robin Murphy <robin.murphy@arm.com>,
Yunfei Wang <yf.wang@mediatek.com>,
Miles Chen <miles.chen@mediatek.com>,
Joerg Roedel <jroedel@suse.de>, Sasha Levin <sashal@kernel.org>,
joro@8bytes.org, will@kernel.org, matthias.bgg@gmail.com,
iommu@lists.linux-foundation.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org
Subject: [PATCH AUTOSEL 5.4 27/37] iommu/iova: Improve 32-bit free space estimate
Date: Fri, 1 Apr 2022 10:44:36 -0400 [thread overview]
Message-ID: <20220401144446.1954694-27-sashal@kernel.org> (raw)
In-Reply-To: <20220401144446.1954694-1-sashal@kernel.org>
From: Robin Murphy <robin.murphy@arm.com>
[ Upstream commit 5b61343b50590fb04a3f6be2cdc4868091757262 ]
For various reasons based on the allocator behaviour and typical
use-cases at the time, when the max32_alloc_size optimisation was
introduced it seemed reasonable to couple the reset of the tracked
size to the update of cached32_node upon freeing a relevant IOVA.
However, since subsequent optimisations focused on helping genuine
32-bit devices make best use of even more limited address spaces, it
is now a lot more likely for cached32_node to be anywhere in a "full"
32-bit address space, and as such more likely for space to become
available from IOVAs below that node being freed.
At this point, the short-cut in __cached_rbnode_delete_update() really
doesn't hold up any more, and we need to fix the logic to reliably
provide the expected behaviour. We still want cached32_node to only move
upwards, but we should reset the allocation size if *any* 32-bit space
has become available.
Reported-by: Yunfei Wang <yf.wang@mediatek.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Miles Chen <miles.chen@mediatek.com>
Link: https://lore.kernel.org/r/033815732d83ca73b13c11485ac39336f15c3b40.1646318408.git.robin.murphy@arm.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/iommu/iova.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index 906582a21124..628a586be695 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -138,10 +138,11 @@ __cached_rbnode_delete_update(struct iova_domain *iovad, struct iova *free)
cached_iova = rb_entry(iovad->cached32_node, struct iova, node);
if (free == cached_iova ||
(free->pfn_hi < iovad->dma_32bit_pfn &&
- free->pfn_lo >= cached_iova->pfn_lo)) {
+ free->pfn_lo >= cached_iova->pfn_lo))
iovad->cached32_node = rb_next(&free->node);
+
+ if (free->pfn_lo < iovad->dma_32bit_pfn)
iovad->max32_alloc_size = iovad->dma_32bit_pfn;
- }
cached_iova = rb_entry(iovad->cached_node, struct iova, node);
if (free->pfn_lo >= cached_iova->pfn_lo)
--
2.34.1
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
WARNING: multiple messages have this Message-ID (diff)
From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Robin Murphy <robin.murphy@arm.com>,
Yunfei Wang <yf.wang@mediatek.com>,
Miles Chen <miles.chen@mediatek.com>,
Joerg Roedel <jroedel@suse.de>, Sasha Levin <sashal@kernel.org>,
joro@8bytes.org, will@kernel.org, matthias.bgg@gmail.com,
iommu@lists.linux-foundation.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org
Subject: [PATCH AUTOSEL 5.4 27/37] iommu/iova: Improve 32-bit free space estimate
Date: Fri, 1 Apr 2022 10:44:36 -0400 [thread overview]
Message-ID: <20220401144446.1954694-27-sashal@kernel.org> (raw)
In-Reply-To: <20220401144446.1954694-1-sashal@kernel.org>
From: Robin Murphy <robin.murphy@arm.com>
[ Upstream commit 5b61343b50590fb04a3f6be2cdc4868091757262 ]
For various reasons based on the allocator behaviour and typical
use-cases at the time, when the max32_alloc_size optimisation was
introduced it seemed reasonable to couple the reset of the tracked
size to the update of cached32_node upon freeing a relevant IOVA.
However, since subsequent optimisations focused on helping genuine
32-bit devices make best use of even more limited address spaces, it
is now a lot more likely for cached32_node to be anywhere in a "full"
32-bit address space, and as such more likely for space to become
available from IOVAs below that node being freed.
At this point, the short-cut in __cached_rbnode_delete_update() really
doesn't hold up any more, and we need to fix the logic to reliably
provide the expected behaviour. We still want cached32_node to only move
upwards, but we should reset the allocation size if *any* 32-bit space
has become available.
Reported-by: Yunfei Wang <yf.wang@mediatek.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Miles Chen <miles.chen@mediatek.com>
Link: https://lore.kernel.org/r/033815732d83ca73b13c11485ac39336f15c3b40.1646318408.git.robin.murphy@arm.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/iommu/iova.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index 906582a21124..628a586be695 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -138,10 +138,11 @@ __cached_rbnode_delete_update(struct iova_domain *iovad, struct iova *free)
cached_iova = rb_entry(iovad->cached32_node, struct iova, node);
if (free == cached_iova ||
(free->pfn_hi < iovad->dma_32bit_pfn &&
- free->pfn_lo >= cached_iova->pfn_lo)) {
+ free->pfn_lo >= cached_iova->pfn_lo))
iovad->cached32_node = rb_next(&free->node);
+
+ if (free->pfn_lo < iovad->dma_32bit_pfn)
iovad->max32_alloc_size = iovad->dma_32bit_pfn;
- }
cached_iova = rb_entry(iovad->cached_node, struct iova, node);
if (free->pfn_lo >= cached_iova->pfn_lo)
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Robin Murphy <robin.murphy@arm.com>,
Yunfei Wang <yf.wang@mediatek.com>,
Miles Chen <miles.chen@mediatek.com>,
Joerg Roedel <jroedel@suse.de>, Sasha Levin <sashal@kernel.org>,
joro@8bytes.org, will@kernel.org, matthias.bgg@gmail.com,
iommu@lists.linux-foundation.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org
Subject: [PATCH AUTOSEL 5.4 27/37] iommu/iova: Improve 32-bit free space estimate
Date: Fri, 1 Apr 2022 10:44:36 -0400 [thread overview]
Message-ID: <20220401144446.1954694-27-sashal@kernel.org> (raw)
In-Reply-To: <20220401144446.1954694-1-sashal@kernel.org>
From: Robin Murphy <robin.murphy@arm.com>
[ Upstream commit 5b61343b50590fb04a3f6be2cdc4868091757262 ]
For various reasons based on the allocator behaviour and typical
use-cases at the time, when the max32_alloc_size optimisation was
introduced it seemed reasonable to couple the reset of the tracked
size to the update of cached32_node upon freeing a relevant IOVA.
However, since subsequent optimisations focused on helping genuine
32-bit devices make best use of even more limited address spaces, it
is now a lot more likely for cached32_node to be anywhere in a "full"
32-bit address space, and as such more likely for space to become
available from IOVAs below that node being freed.
At this point, the short-cut in __cached_rbnode_delete_update() really
doesn't hold up any more, and we need to fix the logic to reliably
provide the expected behaviour. We still want cached32_node to only move
upwards, but we should reset the allocation size if *any* 32-bit space
has become available.
Reported-by: Yunfei Wang <yf.wang@mediatek.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Miles Chen <miles.chen@mediatek.com>
Link: https://lore.kernel.org/r/033815732d83ca73b13c11485ac39336f15c3b40.1646318408.git.robin.murphy@arm.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/iommu/iova.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index 906582a21124..628a586be695 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -138,10 +138,11 @@ __cached_rbnode_delete_update(struct iova_domain *iovad, struct iova *free)
cached_iova = rb_entry(iovad->cached32_node, struct iova, node);
if (free == cached_iova ||
(free->pfn_hi < iovad->dma_32bit_pfn &&
- free->pfn_lo >= cached_iova->pfn_lo)) {
+ free->pfn_lo >= cached_iova->pfn_lo))
iovad->cached32_node = rb_next(&free->node);
+
+ if (free->pfn_lo < iovad->dma_32bit_pfn)
iovad->max32_alloc_size = iovad->dma_32bit_pfn;
- }
cached_iova = rb_entry(iovad->cached_node, struct iova, node);
if (free->pfn_lo >= cached_iova->pfn_lo)
--
2.34.1
next prev parent reply other threads:[~2022-04-01 14:45 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-01 14:44 [PATCH AUTOSEL 5.4 01/37] drm: Add orientation quirk for GPD Win Max Sasha Levin
2022-04-01 14:44 ` Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 02/37] ath5k: fix OOB in ath5k_eeprom_read_pcal_info_5111 Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 03/37] drm/amd/amdgpu/amdgpu_cs: fix refcount leak of a dma_fence obj Sasha Levin
2022-04-01 14:44 ` Sasha Levin
2022-04-01 14:44 ` Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 04/37] ptp: replace snprintf with sysfs_emit Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 05/37] powerpc: dts: t104xrdb: fix phy type for FMAN 4/5 Sasha Levin
2022-04-01 14:44 ` Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 06/37] bpf: Make dst_port field in struct bpf_sock 16-bit wide Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 07/37] scsi: mvsas: Replace snprintf() with sysfs_emit() Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 08/37] scsi: bfa: " Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 09/37] power: supply: axp20x_battery: properly report current when discharging Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 10/37] ipv6: make mc_forwarding atomic Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 11/37] powerpc: Set crashkernel offset to mid of RMA region Sasha Levin
2022-04-01 14:44 ` Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 12/37] drm/amdgpu: Fix recursive locking warning Sasha Levin
2022-04-01 14:44 ` Sasha Levin
2022-04-01 14:44 ` Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 13/37] PCI: aardvark: Fix support for MSI interrupts Sasha Levin
2022-04-01 14:44 ` Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 14/37] iommu/arm-smmu-v3: fix event handling soft lockup Sasha Levin
2022-04-01 14:44 ` Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 15/37] usb: ehci: add pci device support for Aspeed platforms Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 16/37] PCI: pciehp: Add Qualcomm quirk for Command Completed erratum Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 17/37] power: supply: axp288-charger: Set Vhold to 4.4V Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 18/37] ipv4: Invalidate neighbour for broadcast address upon address addition Sasha Levin
2022-04-01 14:44 ` [dm-devel] [PATCH AUTOSEL 5.4 19/37] dm ioctl: prevent potential spectre v1 gadget Sasha Levin
2022-04-01 14:44 ` Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 20/37] drm/amdkfd: make CRAT table missing message informational only Sasha Levin
2022-04-01 14:44 ` Sasha Levin
2022-04-01 14:44 ` Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 21/37] scsi: pm8001: Fix pm8001_mpi_task_abort_resp() Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 22/37] scsi: aha152x: Fix aha152x_setup() __setup handler return value Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 23/37] net/smc: correct settings of RMB window update limit Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 24/37] mips: ralink: fix a refcount leak in ill_acc_of_setup() Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 25/37] macvtap: advertise link netns via netlink Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 26/37] tuntap: add sanity checks about msg_controllen in sendmsg Sasha Levin
2022-04-01 14:44 ` Sasha Levin
2022-04-01 14:44 ` Sasha Levin [this message]
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 27/37] iommu/iova: Improve 32-bit free space estimate Sasha Levin
2022-04-01 14:44 ` Sasha Levin
2022-04-01 14:44 ` Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 28/37] bnxt_en: Eliminate unintended link toggle during FW reset Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 29/37] MIPS: fix fortify panic when copying asm exception handlers Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 30/37] powerpc/code-patching: Pre-map patch area Sasha Levin
2022-04-01 14:44 ` Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 31/37] scsi: libfc: Fix use after free in fc_exch_abts_resp() Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 32/37] usb: dwc3: omap: fix "unbalanced disables for smps10_out1" on omap5evm Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 33/37] xtensa: fix DTC warning unit_address_format Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 34/37] Bluetooth: Fix use after free in hci_send_acl Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 35/37] netlabel: fix out-of-bounds memory accesses Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 36/37] init/main.c: return 1 from handled __setup() functions Sasha Levin
2022-04-01 14:44 ` [PATCH AUTOSEL 5.4 37/37] minix: fix bug when opening a file with O_DIRECT Sasha Levin
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=20220401144446.1954694-27-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=iommu@lists.linux-foundation.org \
--cc=jroedel@suse.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=miles.chen@mediatek.com \
--cc=robin.murphy@arm.com \
--cc=stable@vger.kernel.org \
--cc=will@kernel.org \
--cc=yf.wang@mediatek.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.