Re: [Xen-devel] [PATCH v8.1 11/27] xsplice: Implement payload loading

["Jan Beulich" <jbeulich@xxxxxxxx>]

>>> Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> 04/20/16 6:00 PM >>>
>> >+ size_t pages; /* Total pages for [text,rw,ro]_addr */
>> 
>> Why size_t and not just unsigned int?
>
>Oh. I was somehow under the impression you liked size_t more than
>unsignged int! I will change it over.

When used where actually talking about sizes, I indeed prefer size_t. But
here we have a count which we know will be much lower than UINT_MAX.

>> >+static void calc_section(struct xsplice_elf_sec *sec, size_t *size)
>> >+{
>> >+    Elf_Shdr *s = sec->sec;
>> >+    size_t align_size;
>> >+
>> >+    align_size = ROUNDUP(*size, s->sh_addralign);
>> >+    s->sh_entsize = align_size;
>> 
>> So this is one of the places (the only one?) where the section header gets
>> altered. Are you not expecting problems down the road resulting from
>> overwriting this field? After all it's used not just in control sections...
>
>The 'man elf' tells me :
>"Some  sections  hold a table of fixed-sized entries, such as a symbol
>table.  For such a section, this member gives the size in bytes for each entry.
>This member contains zero if the section does not hold  a  table  of 
>fixed-size entries."

My main concern is that SHF_MERGE sections (i.e. ordinary data ones) also
already use this field.

>> >+            /* Don't copy NOBITS - such as BSS. */
>> >+            if ( elf->sec[i].sec->sh_type != SHT_NOBITS )
>> >+            {
>> >+                memcpy(elf->sec[i].load_addr, elf->sec[i].data,
>> >+                       elf->sec[i].sec->sh_size);
>> >+                dprintk(XENLOG_DEBUG, XSPLICE "%s: Loaded %s at 0x%p\n",
>> >+                        elf->name, elf->sec[i].name, 
>> >elf->sec[i].load_addr);
>> >+            }
>> 
>> "else memset();" is what I would have expected here. Now I see that the
>> allocation function clears the pages (in a bogusly open coded way, instead
>> of using vzalloc()), but why is that so?
>
>B/c we end up having vzalloc_xen (oh wait, we made that go away). Yes
>we do need an memset or introduce vzalloc_xen (and keep vmalloc_xen?).
>
>Your call - memset or introduce vzalloc_xen ?

The latter would be my preference.

Jan


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