On 17/02/2025 10:27 am, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko <[email protected]>
>
> 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).
:(
So it broke somewhere between v3 and v8 of the original patch series,
but I can't seem to find the intervening series on lore.
Given the comment, I suspect I got inadvertently-reviewed into this bug.
> 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.
This is one of the few interfaces we have low level testing for.
tools/tests/resource/test-resource.c
Please could you add a step looking for an invalid resource id and check
you get 0 back?
> Also, add an ASSERT_UNREACHABLE() in the default case of _acquire_resource(),
> normally we won't get to this point, as an unknown type will always be
> rejected
> earlier in resource_max_frames().
Fixes: 9244528955de ("xen/memory: Fix acquire_resource size semantics")
> Signed-off-by: Oleksandr Tyshchenko <[email protected]>
> Reviewed-by: Jan Beulich <[email protected]>
~Andrew
