[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[PATCH] Xen/gntdev: don't ignore kernel unmapping error
- To: Juergen Gross <jgross@xxxxxxxx>, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Fri, 17 Sep 2021 08:13:08 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=E0C70BnHkf+Xjjy8puyk2DxDQEN3l79sxqdB6zmJekE=; b=M4SPYxDp6Zv9q4EjccpFIm1vr6twNv2RfCnmptwY3uzI1mBlJBl8OjMR7a+Eg113PjmtrCl9TcmyqK3RahDBbyzEp77CeXwe9d9UzhNnHYaMcT6iEhQuI4QgKQIquYIuAF0JtW9dpGPhS0Uly/q+Apg5ymzURSq8bSkjl/wC2Y4KSlLmzkIw4dIzOfeFJDEHwKyGGITbuJ5KrMyc7BdktzYcNTimWBtZKm7j9RgogjxiTB0VVjuj0TNnbHI4WKCMCh0GdWMN9CkmitqPqHkLnN5weI6y73ut4cIOP8IIpwoB9GfbFMfGUrnaNZGkeNfwP4BRyKAPqrHHXdBMgSKszA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fXhkYtSdvVa4wdvtljJxcynR9dYQupXOYSXT0Bm0PPrOssm3I2WzkX0vJXUrR6Es0cDBP4xIa1IQ+Ag1C5eoOLv68MbJKnd0SRLl21W9XjryTYKxUKJOCDhnEJdv5n73UaXjHLZx6XH0wWgAMv51tOqZm5si9SzmqTMjQEgtLHa3F3OL56Zo+XXsfAYVjGSvrOTHo0RGJSSNOP9G5Yi3GpqD9aaPnuVEiVirc8wCHlHqwwAyMx+tcGIUfhEV6DJaX/ssqIOhBggjiFZxa3w2f66XmWYqcvGLcwqPFaLO3FL/bVCKmkzmG9Ml8D5hPjP5lLFlKrB8gTl1Zj5CujU0Qw==
- Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com;
- Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, lkml <linux-kernel@xxxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Fri, 17 Sep 2021 06:13:36 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
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@xxxxxxxx>
---
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;
}
|