Re: [PATCH 6/7] iommu/vt-d: Warn on out-of-range invalidation address

From: Lu Baolu
Date: Tue Jun 30 2020 - 21:50:10 EST


Hi Jacob,

On 7/1/20 1:34 AM, Jacob Pan wrote:
On Thu, 25 Jun 2020 18:10:43 +0800
Lu Baolu<baolu.lu@xxxxxxxxxxxxxxx> wrote:

Hi,

On 2020/6/23 23:43, Jacob Pan wrote:
For guest requested IOTLB invalidation, address and mask are
provided as part of the invalidation data. VT-d HW silently ignores
any address bits below the mask. SW shall also allow such case but
give warning if address does not align with the mask. This patch
relax the fault handling from error to warning and proceed with
invalidation request with the given mask.

Signed-off-by: Jacob Pan<jacob.jun.pan@xxxxxxxxxxxxxxx>
---
drivers/iommu/intel/iommu.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/intel/iommu.c
b/drivers/iommu/intel/iommu.c index 5ea5732d5ec4..50fc62413a35
100644 --- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -5439,13 +5439,12 @@ intel_iommu_sva_invalidate(struct
iommu_domain *domain, struct device *dev,
switch (BIT(cache_type)) {
case IOMMU_CACHE_INV_TYPE_IOTLB:
+ /* HW will ignore LSB bits based on
address mask */ if (inv_info->granularity == IOMMU_INV_GRANU_ADDR &&
size &&
(inv_info->addr_info.addr &
((BIT(VTD_PAGE_SHIFT + size)) - 1))) {
- pr_err_ratelimited("Address out of
range, 0x%llx, size order %llu\n",
-
inv_info->addr_info.addr, size);
- ret = -ERANGE;
- goto out_unlock;
+ WARN_ONCE(1, "Address out of
range, 0x%llx, size order %llu\n",
+
inv_info->addr_info.addr, size);
I don't think WARN_ONCE() is suitable here. It makes users think it's
a kernel bug. How about pr_warn_ratelimited()?

I think pr_warn_ratelimited might still be too chatty. There is no
functional issues, we just don't to silently ignore it. Perhaps just
say:
WARN_ONCE(1, "User provided address not page aligned, alignment forced")
?


WARN() is normally used for reporting a kernel bug. It dumps kernel
trace. And the users will report bug through bugzilla.kernel.org.

In this case, it's actually an unexpected user input, we shouldn't
treat it as a kernel bug and pr_err_ratelimited() is enough?

Best regards,
baolu