|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86/mm: Drop MEM_LOG() and correct some printed information
On 29/03/17 15:01, Jan Beulich wrote:
>>>> On 29.03.17 at 15:50, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 29/03/17 14:06, Jan Beulich wrote:
>>>>>> On 29.03.17 at 14:29, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>> @@ -1068,10 +1073,10 @@ get_page_from_l1e(
>>>> return 0;
>>>>
>>>> could_not_pin:
>>>> - MEM_LOG("Error getting mfn %lx (pfn %lx) from L1 entry %" PRIpte
>>>> - " for l1e_owner=%d, pg_owner=%d",
>>>> - mfn, get_gpfn_from_mfn(mfn),
>>>> - l1e_get_intpte(l1e), l1e_owner->domain_id,
>>>> pg_owner->domain_id);
>>>> + gdprintk(XENLOG_WARNING, "Error getting mfn %" PRI_mfn " (pfn %"
>>>> PRI_pfn
>>>> + ") from L1 entry %" PRIpte " for l1e_owner d%d, pg_owner
>>>> d%d",
>>>> + mfn, get_gpfn_from_mfn(mfn),
>>>> + l1e_get_intpte(l1e), l1e_owner->domain_id,
>>>> pg_owner->domain_id);
>>> Especially here the wrapping of the format string is rather
>>> unfortunate. Didn't we agree to allow format strings to exceed
>>> the 80 column restriction anyway?
>> It is split at a formatting boundary, which doesn't affect grep-ability.
>>
>> Putting this all on one line is 123 characters, which IMO is too long.
> Hmm, you're right, 123 seems a little excessive.
>
>>>> @@ -1388,7 +1398,7 @@ static int alloc_l1_table(struct page_info *page)
>>>> return 0;
>>>>
>>>> fail:
>>>> - MEM_LOG("Failure in alloc_l1_table: entry %d", i);
>>>> + gdprintk(XENLOG_WARNING, "Failure in alloc_l1_table: entry %d\n", i);
>>> %u (or even %03x; same in alloc_l[234]_table())
>> Actually, "slot %#x" would be clearer here. I though I fixed the 0x
>> prefix in alloc_l[]_table(), and I am not sure the leading zeroes are
>> helpful.
> I'm not too fussed about the leading zeros, but I do actively
> dislike 0x prefixes except when a message mixes hex and dec
> numbers.
Mixed hex and dec is obviously a problem, but it is also very much a
problem for a number which isn't clear from context how it is
formatted. *fn are all uniformly formatted as hex everywhere, whereas
slot/entry could easily be either.
>
>>>> @@ -4459,10 +4512,11 @@ int steal_page(
>>>>
>>>> fail:
>>>> spin_unlock(&d->page_alloc_lock);
>>>> - MEM_LOG("Bad page %lx: ed=%d sd=%d caf=%08lx taf=%" PRtype_info,
>>>> - page_to_mfn(page), d->domain_id,
>>>> - owner ? owner->domain_id : DOMID_INVALID,
>>>> - page->count_info, page->u.inuse.type_info);
>>>> + gdprintk(XENLOG_WARNING, "Bad mfn %" PRI_mfn
>>>> + ": ed=%d sd=%d caf=%08lx taf=%" PRtype_info "\n",
>>>> + page_to_mfn(page), d->domain_id,
>>>> + owner ? owner->domain_id : DOMID_INVALID,
>>>> + page->count_info, page->u.inuse.type_info);
>>> Same here.
>>>
>>> Is this intended for 4.9?
>> At this point, yes.
> In which case you should Cc Julien.
Will do on v2.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |