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@suse.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;
 }

On 17.09.21 08:13, Jan Beulich wrote:
> 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@suse.com>

Pushed to xen/tip.git for-linus-5.15b


Juergen

On 17.09.21 08:13, Jan Beulich wrote:
> 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@suse.com>

Reviewed-by: Juergen Gross <jgross@suse.com>


Juergen