[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;
 }




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.