[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <c2513395-74dc-aea3-9192-fd265aa44e35@suse.com>
Date: Fri, 17 Sep 2021 08:13:08 +0200
From: Jan Beulich <jbeulich@...e.com>
To: Juergen Gross <jgross@...e.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>
Cc: Stefano Stabellini <sstabellini@...nel.org>,
lkml <linux-kernel@...r.kernel.org>,
"xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>
Subject: [PATCH] Xen/gntdev: don't ignore kernel unmapping error
While working on XSA-361 and its follow-ups, I failed to spot another
place where the kernel mapping part of an operation was not treated the
same as the user space part. Detect and propagate errors and add a 2nd
pr_debug().
Signed-off-by: Jan Beulich <jbeulich@...e.com>
---
It is of course questionable whether zapping handles even upon failure
is the best course of action. Otoh unmapping shouldn't normally fail
unless there's a bug elsewhere (which is how I came to notice this
discrepancy).
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -396,6 +396,14 @@ static int __unmap_grant_pages(struct gn
map->unmap_ops[offset+i].handle,
map->unmap_ops[offset+i].status);
map->unmap_ops[offset+i].handle = INVALID_GRANT_HANDLE;
+ if (use_ptemod) {
+ if (map->kunmap_ops[offset+i].status)
+ err = -EINVAL;
+ pr_debug("kunmap handle=%u st=%d\n",
+ map->kunmap_ops[offset+i].handle,
+ map->kunmap_ops[offset+i].status);
+ map->kunmap_ops[offset+i].handle = INVALID_GRANT_HANDLE;
+ }
}
return err;
}
Powered by blists - more mailing lists