Re: [Xen-devel] [PATCH] xen/x86: Fix errors arising from c/s dab76ff

[Jan Beulich]

>>> On 15.02.16 at 16:15,  wrote:
> What about something like this instead?  (Ported to be on top of this
> patch, since it's already been committed.)
> 
>  -George
> 
> [PATCH] xen/p2m: Make dump table printing less clever
> 
> Rather than detecting whether to print out the numerical value of the
> memory type based on whether
> the second byte of the stringified value is a null character, just
> always print out both.

Generally a good idea, but ...

> @@ -1262,14 +1262,13 @@ static void ept_dump_p2m_table(unsigned char key)
>  if ( ept_entry->sa_p2mt == p2m_populate_on_demand )
>  printk("gfn: %13lx order: %2d PoD\n", gfn, order);
>  else
> -printk("gfn: %13lx order: %2d mfn: %13lx %c%c%c%c%c%c\n",
> +printk("gfn: %13lx order: %2d mfn: %13lx 
> %c%c%c%s(%d)%c\n",
> gfn, order, ept_entry->mfn + 0UL,
> ept_entry->r ? 'r' : ' ',
> ept_entry->w ? 'w' : ' ',
> ept_entry->x ? 'x' : ' ',
> -   memory_type_to_str(ept_entry->emt)[0],
> -   memory_type_to_str(ept_entry->emt)[1]
> -   ?: ept_entry->emt + '0',
> +   memory_type_to_str(ept_entry->emt),
> +   ept_entry->emt,
> c ?: ept_entry->ipat ? '!' : ' ');

... this will further increase the amount of data to be pushed out,
and the debug key being handled here is already putting quite a
bit of load on the serial console. It was the goal to save every byte
we can which drove me to the solution currently in place.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen/x86: Fix errors arising from c/s dab76ff

[George Dunlap]

On 12/02/16 14:59, Andrew Cooper wrote:
> Coverity correctly identifies that the changes in mtrr_attrib_to_str()
> introduce dead code.  strings[] is a 2d array, rather than an array of
> strings, which means that strings[x] will never be a NULL pointer.
> 
> Adjust the check to compenstate, by looking for a NUL in strings[x][0]
> instead.
> 
> Curiously, Coverity did not notice the same error with memory_type_to_str().
> There was also a further error; the strings were not NULL terminated, which
> made the return type of memory_type_to_str() erronious.
> 
> Bump the 2D array to 3 characters, so the strings retain their NUL characters,
> and introduce an ASSERT() as requested on one thread of the original patch.
> 
> Signed-off-by: Andrew Cooper 

What about something like this instead?  (Ported to be on top of this
patch, since it's already been committed.)

 -George

[PATCH] xen/p2m: Make dump table printing less clever

Rather than detecting whether to print out the numerical value of the
memory type based on whether
the second byte of the stringified value is a null character, just
always print out both.

Signed-off-by: George Dunlap 
---
CC: Andrew Cooper 
CC: Jan Beulich 
CC: Tim Deegan 
---
 xen/arch/x86/mm/p2m-ept.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 3cb6868..be528e7 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -1204,7 +1204,7 @@ void ept_p2m_uninit(struct p2m_domain *p2m)

 static const char *memory_type_to_str(unsigned int x)
 {
-static const char memory_types[8][3] = {
+static const char *memory_types[8] = {
 [MTRR_TYPE_UNCACHABLE] = "UC",
 [MTRR_TYPE_WRCOMB] = "WC",
 [MTRR_TYPE_WRTHROUGH]  = "WT",
@@ -1262,14 +1262,13 @@ static void ept_dump_p2m_table(unsigned char key)
 if ( ept_entry->sa_p2mt == p2m_populate_on_demand )
 printk("gfn: %13lx order: %2d PoD\n", gfn, order);
 else
-printk("gfn: %13lx order: %2d mfn: %13lx %c%c%c
%c%c%c\n",
+printk("gfn: %13lx order: %2d mfn: %13lx %c%c%c
%s(%d)%c\n",
gfn, order, ept_entry->mfn + 0UL,
ept_entry->r ? 'r' : ' ',
ept_entry->w ? 'w' : ' ',
ept_entry->x ? 'x' : ' ',
-   memory_type_to_str(ept_entry->emt)[0],
-   memory_type_to_str(ept_entry->emt)[1]
-   ?: ept_entry->emt + '0',
+   memory_type_to_str(ept_entry->emt),
+   ept_entry->emt,
c ?: ept_entry->ipat ? '!' : ' ');

 if ( !(record_counter++ % 100) )
-- 
2.1.4


>From b9d1d77c001507c4c414b83666a3f59e327364c3 Mon Sep 17 00:00:00 2001
From: George Dunlap 
Date: Mon, 15 Feb 2016 14:58:29 +
Subject: [PATCH] xen/p2m: Make dump table printing less clever

Rather than detecting whether to print out the numerical value of the memory type based on whether
the second byte of the stringified value is a null character, just always print out both.

Signed-off-by: George Dunlap 
---
CC: Andrew Cooper 
CC: Jan Beulich 
CC: Tim Deegan 
---
 xen/arch/x86/mm/p2m-ept.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 3cb6868..be528e7 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -1204,7 +1204,7 @@ void ept_p2m_uninit(struct p2m_domain *p2m)
 
 static const char *memory_type_to_str(unsigned int x)
 {
-static const char memory_types[8][3] = {
+static const char *memory_types[8] = {
 [MTRR_TYPE_UNCACHABLE] = "UC",
 [MTRR_TYPE_WRCOMB] = "WC",
 [MTRR_TYPE_WRTHROUGH]  = "WT",
@@ -1262,14 +1262,13 @@ static void ept_dump_p2m_table(unsigned char key)
 if ( ept_entry->sa_p2mt == p2m_populate_on_demand )
 printk("gfn: %13lx order: %2d PoD\n", gfn, order);
 else
-printk("gfn: %13lx order: %2d mfn: %13lx %c%c%c %c%c%c\n",
+printk("gfn: %13lx order: %2d mfn: %13lx %c%c%c %s(%d)%c\n",
gfn, order, ept_entry->mfn + 0UL,
ept_entry->r ? 'r' : ' ',
ept_entry->w ? 'w' : ' ',
ept_entry->x ? 'x' : ' ',
-   memory_type_to_str(ept_entry->emt)[0],
-   memory_type_to_str(ept_entry->emt)[1]
-   ?: ept_entry->emt + '0',
+   

Re: [Xen-devel] [PATCH] xen/x86: Fix errors arising from c/s dab76ff

[Jan Beulich]

>>> On 12.02.16 at 15:59,  wrote:
> Coverity correctly identifies that the changes in mtrr_attrib_to_str()
> introduce dead code.  strings[] is a 2d array, rather than an array of
> strings, which means that strings[x] will never be a NULL pointer.
> 
> Adjust the check to compenstate, by looking for a NUL in strings[x][0]
> instead.
> 
> Curiously, Coverity did not notice the same error with memory_type_to_str().

I agree up to here.

> There was also a further error; the strings were not NULL terminated, which
> made the return type of memory_type_to_str() erronious.

What's erroneous here? I don't think there's any requirement
for a function returning char * to always return NUL-terminated
strings.

> Bump the 2D array to 3 characters, so the strings retain their NUL 
> characters,

I.e. I don't agree with this part of the change, even if the addition
of these few bytes doesn't make a whole lot of a difference. They
end up being "dead data" now, and if Coverity is smart it should
even be able to notice.

> and introduce an ASSERT() as requested on one thread of the original patch.

Whereas this part is again appreciated.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen/x86: Fix errors arising from c/s dab76ff

[Andrew Cooper]

On 12/02/16 15:13, Jan Beulich wrote:
 On 12.02.16 at 15:59,  wrote:
>> Coverity correctly identifies that the changes in mtrr_attrib_to_str()
>> introduce dead code.  strings[] is a 2d array, rather than an array of
>> strings, which means that strings[x] will never be a NULL pointer.
>>
>> Adjust the check to compenstate, by looking for a NUL in strings[x][0]
>> instead.
>>
>> Curiously, Coverity did not notice the same error with memory_type_to_str().
> I agree up to here.
>
>> There was also a further error; the strings were not NULL terminated, which
>> made the return type of memory_type_to_str() erronious.
> What's erroneous here? I don't think there's any requirement
> for a function returning char * to always return NUL-terminated
> strings.

The name of the function very clearly indicates that it is returning a
string.

>
>> Bump the 2D array to 3 characters, so the strings retain their NUL 
>> characters,
> I.e. I don't agree with this part of the change, even if the addition
> of these few bytes doesn't make a whole lot of a difference. They
> end up being "dead data" now, and if Coverity is smart it should
> even be able to notice.

It will produce something wrong if someone introduces a new path doing
something like printk("%s", memory_type_to_str()).  8 extra bytes is a
very small price to pay to make this work properly.

The alternative, const char (*memory_type_to_str(unsigned int x))[2] is
unrecognisable to most C programmers, and can't be used with printk().

~Andrew

>
>> and introduce an ASSERT() as requested on one thread of the original patch.
> Whereas this part is again appreciated.
>
> Jan
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel