答复: [外部邮件] [PATCH 03/20] iommu/vt-d: Fi x CACHE_TAG_NESTING_DEVTLB polluting shared v ariables in flush loop
"Li,Rongqing" <[email protected]> Tue, 4 Aug 2026 03:16:33 +0000
| Newsgroups | gmane.linux.kernel |
|---|---|
| Message-ID | <[email protected]> |
> From: Guanghui Feng <[email protected]> > > In cache_tag_flush_range(), the CACHE_TAG_NESTING_DEVTLB case modifies the > shared local variables 'addr' and 'mask' before falling through to > CACHE_TAG_DEVTLB. This causes all subsequent CACHE_TAG_DEVTLB entries in > the same loop iteration to incorrectly use the full-range flush parameters > (addr=0, mask=MAX_AGAW_PFN_WIDTH) instead of the precisely calculated PSI > range. This is not the intended behavior, as regular DEVTLB entries should always > perform targeted range-based invalidation. > > Fix this by having CACHE_TAG_NESTING_DEVTLB directly call > cache_tag_flush_devtlb_psi() with the full-range constants and break, instead of > modifying shared variables and falling through. This ensures > CACHE_TAG_DEVTLB always uses the original calculated addr and mask for > precise range flush. > > Signed-off-by: Guanghui Feng <[email protected]> > Signed-off-by: Guixin Liu <[email protected]> > Signed-off-by: Lu Baolu <[email protected]> > --- > drivers/iommu/intel/cache.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/drivers/iommu/intel/cache.c b/drivers/iommu/intel/cache.c index > fdc88817709f..26a758b0f501 100644 > --- a/drivers/iommu/intel/cache.c > +++ b/drivers/iommu/intel/cache.c > @@ -454,9 +454,8 @@ void cache_tag_flush_range(struct dmar_domain > *domain, unsigned long start, > * affected by a change in S2. So just flush the entire > * device cache. > */ > - addr = 0; > - mask = MAX_AGAW_PFN_WIDTH; > - fallthrough; > + cache_tag_flush_devtlb_psi(domain, tag, 0, > MAX_AGAW_PFN_WIDTH); > + break; > case CACHE_TAG_DEVTLB: > cache_tag_flush_devtlb_psi(domain, tag, addr, mask); > break; > -- > 2.43.0 This patch introduces a subtle side effect on the tracing logic later in this function. At the end of cache_tag_flush_range(), trace_cache_tag_flush_range(tag, start, end, addr, mask) is called to log the flush operation. With this patch: bypassed the assignment and used break, addr and mask retain their original range values. This causes the tracepoint to log an incorrect, smaller range while the actual hardware execution was a full-range flush. My patch has not this issue: https://lore.kernel.org/linux-iommu/[email protected]/ thanks [Li,Rongqing]