On 23/11/2018 10:49, Jan Beulich wrote:
>>>> On 23.11.18 at 11:28, <andrew.coop...@citrix.com> wrote:
>> On 23/11/2018 09:45, Jan Beulich wrote:
>>> When such pages get assigned to domains (and hence their ->tot_pages
>>> not incremented accordingly) we would otherwise also need to suppress
>>> decrementing the count when freeing those pages.
>>>
>>> Signed-off-by: Jan Beulich <jbeul...@suse.com>
>>> ---
>>> v2: Add ASSERT_UNREACHABLE().
>>>
>>> --- a/xen/common/page_alloc.c
>>> +++ b/xen/common/page_alloc.c
>>> @@ -2303,6 +2303,11 @@ struct page_info *alloc_domheap_pages(
>>>
>>> if ( memflags & MEMF_no_owner )
>>> memflags |= MEMF_no_refcount;
>>> + else if ( (memflags & MEMF_no_refcount) && d )
>>> + {
>>> + ASSERT_UNREACHABLE();
>> Sorry to do this, but on second thoughts, this path isn't actually
>> unreachable.
>>
>> Could I talk you into using ASSERT(!"Assigned domheap pages must be
>> refcounted") instead, to give a slightly more clear error to developers
>> who manage to hit it?
> I think there are other places where we use ASSERT_UNREACHABLE()
> when the path is reachable in the sense that one could construct a
> suitable path, but with how things are (supposed to be) it cannot be
> reached. I'm unconvinced the added string literal would be of overly
> much help - once you see the line number, it is pretty easy to figure
> out whats wrong.
>
> But if you insist, I'll switch to the alternative way of expressing it
> (although I'd then perhaps use
> ASSERT(!(memflags & MEMF_no_refcount)) instead). Just let me
> know.
That's fine as well.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
