On 01/10/18 10:08, Jan Beulich wrote:
>>>> On 28.09.18 at 19:22, <andrew.coop...@citrix.com> wrote:
>> --- a/xen/common/vsprintf.c
>> +++ b/xen/common/vsprintf.c
>> @@ -264,6 +264,47 @@ static char *string(char *str, char *end, const char *s,
>> return str;
>> }
>>
>> +/* Print a domain id, using names for system domains. (e.g. d0 or d[IDLE])
>> */
>> +static char *print_domain(char *str, char *end, const struct domain *d)
>> +{
>> + const char *name = NULL;
>> +
>> + /* Some debugging may have an optionally-NULL pointer. */
>> + if ( unlikely(!d) )
>> + return string(str, end, "NULL", -1, -1, 0);
>> +
>> + if ( str < end )
>> + *str = 'd';
>> +
>> + switch ( d->domain_id )
>> + {
>> + case DOMID_IO: name = "[IO]"; break;
>> + case DOMID_XEN: name = "[XEN]"; break;
>> + case DOMID_COW: name = "[COW]"; break;
>> + case DOMID_IDLE: name = "[IDLE]"; break;
> default: ASSERT_UNREACHABLE();
>
> ?
No - specifically not in this case.
This path is used when printing crash information, and falling back to a
number is better behaviour than falling into an infinite loop,
overflowing the primary stack, then taking a #DF (which escalates to
triple fault on AMD), without printing anything useful.
In general, we cannot have BUG/WARN/ASSERTs in the middle vsprintf() path.
>
>> + }
> Perhaps the insertion of 'd' might better live here, to make a
> better connection between the lack of a ++ there and the + 1
> below?
Will move.
>
>> + if ( name )
>> + return string(str + 1, end, name, -1, -1, 0);
>> + else
>> + return number(str + 1, end, d->domain_id, 10, -1, -1, 0);
>> +}
> Anyway, even without the adjustments
> Reviewed-by: Jan Beulich <jbeul...@suse.com>
Thanks,
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
