From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH v8.1 11/27] xsplice: Implement payload loading Date: Wed, 20 Apr 2016 13:36:35 -0400 Message-ID: References: <1460584928-32440-1-git-send-email-konrad.wilk@oracle.com> <1460584928-32440-12-git-send-email-konrad.wilk@oracle.com> <571489B102000078000E6B6C@prv-mh.provo.novell.com> <20160420155913.GA29455@localhost.localdomain> <5717C4D102000078000E6F7F@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7297720095800395188==" Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1asw3L-0005ZP-DG for xen-devel@lists.xenproject.org; Wed, 20 Apr 2016 17:36:39 +0000 Received: by mail-ig0-f196.google.com with SMTP id g8so7636193igr.0 for ; Wed, 20 Apr 2016 10:36:37 -0700 (PDT) In-Reply-To: <5717C4D102000078000E6F7F@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Jan Beulich Cc: sstabellini@kernel.org, Keir Fraser , andrew.cooper3@citrix.com, mpohlack@amazon.com, ross.lagerwall@citrix.com, julien.grall@arm.com, xen-devel@lists.xenproject.org, sasha.levin@oracle.com List-Id: xen-devel@lists.xenproject.org --===============7297720095800395188== Content-Type: multipart/alternative; boundary=047d7bd75c3a0fd8d20530ee098d --047d7bd75c3a0fd8d20530ee098d Content-Type: text/plain; charset=UTF-8 On Apr 20, 2016 6:05 PM, "Jan Beulich" wrote: > > >>> Konrad Rzeszutek Wilk 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. OK. Let me add the 'offset' member (in xsplice_elf_sec) to store the value. Albeit it only gets used during move_payload. And later that offset value can easily computed using ->load_addr minus ->data. Perhaps I should introduce an temporary array to hold this value instead? > > >> >+ /* 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. OK, will do. > > Jan > --047d7bd75c3a0fd8d20530ee098d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Apr 20, 2016 6:05 PM, "Jan Beulich" <jbeulich@suse.com> wrote:
>
> >>> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 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<= br> > >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, si= ze_t *size)
> >> >+{
> >> >+=C2=A0 =C2=A0 Elf_Shdr *s =3D sec->sec;
> >> >+=C2=A0 =C2=A0 size_t align_size;
> >> >+
> >> >+=C2=A0 =C2=A0 align_size =3D ROUNDUP(*size, s->sh_add= ralign);
> >> >+=C2=A0 =C2=A0 s->sh_entsize =3D align_size;
> >>
> >> So this is one of the places (the only one?) where the sectio= n header gets
> >> altered. Are you not expecting problems down the road resulti= ng from
> >> overwriting this field? After all it's used not just in c= ontrol sections...
> >
> >The 'man elf' tells me :
> >"Some=C2=A0 sections=C2=A0 hold a table of fixed-sized entrie= s, such as a symbol
> >table.=C2=A0 For such a section, this member gives the size in byt= es for each entry.
> >This member contains zero if the section does not hold=C2=A0 a=C2= =A0 table=C2=A0 of
> >fixed-size entries."
>
> My main concern is that SHF_MERGE sections (i.e. ordinary data ones) a= lso
> already use this field.

OK. Let me add the 'offset' member (in xsplice_elf_s= ec) to store the value.

Albeit it only gets used during move_payload. And later that= offset value can easily computed using ->load_addr minus ->data.

Perhaps I should introduce an temporary array to hold this v= alue instead?

>
> >> >+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Don't c= opy NOBITS - such as BSS. */
> >> >+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if ( elf->s= ec[i].sec->sh_type !=3D SHT_NOBITS )
> >> >+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {
> >> >+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = memcpy(elf->sec[i].load_addr, elf->sec[i].data,
> >> >+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0elf->sec[i].sec->sh_size);
> >> >+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = dprintk(XENLOG_DEBUG, XSPLICE "%s: Loaded %s at 0x%p\n",
> >> >+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 elf->name, elf->sec[i].name, elf->sec[= i].load_addr);
> >> >+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >>
> >> "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_xe= n?).
> >
> >Your call - memset or introduce vzalloc_xen ?
>
> The latter would be my preference.

OK, will do.
>
> Jan
>

--047d7bd75c3a0fd8d20530ee098d-- --===============7297720095800395188== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK --===============7297720095800395188==--