[PATCH] xen/memory: Make resource_max_frames() to return 0 on unknown type

[Oleksandr Tyshchenko <olekstysh@xxxxxxxxx>]

From: Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>

This is actually what the caller acquire_resource() expects on any kind
of error (the comment on top of resource_max_frames() also suggests that).
Otherwise, the caller will treat -errno as a valid value and propagate incorrect
nr_frames to the VM. As a possible consequence, a VM trying to query a resource
size of an unknown type will get the success result from the hypercall and 
obtain
nr_frames 4294967201.

Fixes: 9244528955de ("xen/memory: Fix acquire_resource size semantics")
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>
---
I am not aware of any real issues with that. I just spotted that when looking
into the code. Also, I don't think there is a similar issue with acquiring
resource of an unknown type.

Another possible more invasive solution could be to make resource_max_frames()
return int (+ clarify a comment on top of it) and teach the caller to also deal 
with -errno
returned on error (in addition to 0). This way we can propagate an exact error 
(-EOPNOTSUPP)
to the VM on an unknown type. The cons are that we limit max_frames, but it 
seems
to me that nr_frames is limited even harder anyway down the code to fit into 
high-order
bits of the cmd parameter to be able to properly encode a continuation.
---
---
 xen/common/memory.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/common/memory.c b/xen/common/memory.c
index a6f2f6d1b3..6ec471237b 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -1157,7 +1157,7 @@ static unsigned int resource_max_frames(const struct 
domain *d,
         return d->vmtrace_size >> PAGE_SHIFT;
 
     default:
-        return -EOPNOTSUPP;
+        return 0;
     }
 }
 
-- 
2.34.1