From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Mon, 16 Sep 2019 08:39:24 -0700 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D708A18C8939; Mon, 16 Sep 2019 15:39:23 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-124-96.rdu2.redhat.com [10.10.124.96]) by smtp.corp.redhat.com (Postfix) with ESMTP id 37C4A5C1D6; Mon, 16 Sep 2019 15:39:22 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH 05/11] OvmfPkg/XenBusDxe: Construct paths without allocation To: devel@edk2.groups.io, anthony.perard@citrix.com Cc: Ard Biesheuvel , Julien Grall , Jordan Justen , xen-devel@lists.xenproject.org References: <20190913145100.303433-1-anthony.perard@citrix.com> <20190913145100.303433-6-anthony.perard@citrix.com> From: "Laszlo Ersek" Message-ID: <59a12b9c-17ce-2e4c-96a9-f741858b2ba6@redhat.com> Date: Mon, 16 Sep 2019 17:39:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190913145100.303433-6-anthony.perard@citrix.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.70]); Mon, 16 Sep 2019 15:39:23 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 09/13/19 16:50, Anthony PERARD wrote: > When doing an action with a path and subpath in the xenstore, > XenStoreJoin is called to generate "$path/$subpath". But this function > do an allocation of memory which isn't necessary. Instead we will > construct the path with WRITE_REQUEST and data used to generate the > path will be copied directly to the xenstore shared ring. > > Also change WRITE_REQUEST.Len type, it only contain sizes and doesn't > need to be exactly 32bits. > > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2190 > Signed-off-by: Anthony PERARD > --- > OvmfPkg/XenBusDxe/XenStore.c | 78 +++++++++++++++++++++--------------- > 1 file changed, 46 insertions(+), 32 deletions(-) > > diff --git a/OvmfPkg/XenBusDxe/XenStore.c b/OvmfPkg/XenBusDxe/XenStore.c > index 7b71dc156d..ca7be12d68 100644 > --- a/OvmfPkg/XenBusDxe/XenStore.c > +++ b/OvmfPkg/XenBusDxe/XenStore.c > @@ -53,7 +53,7 @@ > > typedef struct { > CONST VOID *Data; > - UINT32 Len; > + UINTN Len; > } WRITE_REQUEST; > > /* Register callback to watch subtree (node) in the XenStore. */ > @@ -260,6 +260,35 @@ XenStoreFindWatch ( > return NULL; > } > > +/** > + Fill the first three slots of a WRITE_REQUEST array. > + > + When those three slots are concatenated to generate a string, the resulting > + string will be "$Path\0" or "$Path/$SubPath\0" if SubPath is provided. > +**/ > +STATIC > +VOID > +XenStorePrepareWriteRequest ( > + IN OUT WRITE_REQUEST *WriteRequest, > + IN CONST CHAR8 *Path, > + IN CONST CHAR8 *SubPath OPTIONAL > + ) > +{ > + SetMem(WriteRequest, 3 * sizeof (WRITE_REQUEST), 0); (1) ZeroMem() is more idiomatic. Also, please insert a space before the opening paren. > + WriteRequest[0].Data = Path; > + WriteRequest[0].Len = AsciiStrSize (Path); > + if (SubPath != NULL && SubPath[0] != '\0') { > + // > + // Remove the \0 from the first part of the request. > + // > + WriteRequest[0].Len--; > + WriteRequest[1].Data = "/"; > + WriteRequest[1].Len = 1; > + WriteRequest[2].Data = SubPath; > + WriteRequest[2].Len = AsciiStrSize (SubPath); > + } > +} > + So this suggests that only the last element in the array should point to a NUL-terminated string. Strings pointed-to by earlier elements in the array should not be NUL-terminated. Is that correct? > // > // Public Utility Functions > // API comments for these methods can be found in XenStore.h > @@ -842,6 +871,7 @@ XenStoreTalkv ( > @param Transaction The transaction to use for this request. > @param RequestType The type of message to send. > @param Body The body of the request. > + @param SubPath If !NULL and not "", "/$SubPath" is append to Body. > @param LenPtr The returned length of the reply. > @param Result The returned body of the reply. > > @@ -854,16 +884,16 @@ XenStoreSingle ( > IN CONST XENSTORE_TRANSACTION *Transaction, > IN enum xsd_sockmsg_type RequestType, > IN CONST CHAR8 *Body, > + IN CONST CHAR8 *SubPath OPTIONAL, > OUT UINT32 *LenPtr OPTIONAL, > OUT VOID **Result OPTIONAL > ) > { > - WRITE_REQUEST WriteRequest; > + WRITE_REQUEST WriteRequest[3]; > > - WriteRequest.Data = (VOID *) Body; > - WriteRequest.Len = (UINT32)AsciiStrSize (Body); > + XenStorePrepareWriteRequest (WriteRequest, Body, SubPath); > > - return XenStoreTalkv (Transaction, RequestType, &WriteRequest, 1, > + return XenStoreTalkv (Transaction, RequestType, WriteRequest, 3, > LenPtr, Result); (2) It would be slightly more idiomatic to pass ARRAY_SIZE (WriteRequest) in place of the naked 3. > } > > @@ -1113,15 +1143,12 @@ XenStoreListDirectory ( > OUT CONST CHAR8 ***DirectoryListPtr > ) > { > - CHAR8 *Path; > CHAR8 *TempStr; > UINT32 Len = 0; > XENSTORE_STATUS Status; > > - Path = XenStoreJoin (DirectoryPath, Node); > - Status = XenStoreSingle (Transaction, XS_DIRECTORY, Path, &Len, > + Status = XenStoreSingle (Transaction, XS_DIRECTORY, DirectoryPath, Node, &Len, > (VOID **) &TempStr); > - FreePool (Path); > if (Status != XENSTORE_STATUS_SUCCESS) { > return Status; > } > @@ -1160,13 +1187,11 @@ XenStoreRead ( > OUT VOID **Result > ) > { > - CHAR8 *Path; > VOID *Value; > XENSTORE_STATUS Status; > > - Path = XenStoreJoin (DirectoryPath, Node); > - Status = XenStoreSingle (Transaction, XS_READ, Path, LenPtr, &Value); > - FreePool (Path); > + Status = XenStoreSingle (Transaction, XS_READ, DirectoryPath, Node, > + LenPtr, &Value); (3) Indentation. > if (Status != XENSTORE_STATUS_SUCCESS) { > return Status; > } > @@ -1183,21 +1208,13 @@ XenStoreWrite ( > IN CONST CHAR8 *Str > ) > { > - CHAR8 *Path; > - WRITE_REQUEST WriteRequest[2]; > - XENSTORE_STATUS Status; > + WRITE_REQUEST WriteRequest[4]; > > - Path = XenStoreJoin (DirectoryPath, Node); > + XenStorePrepareWriteRequest (WriteRequest, DirectoryPath, Node); > + WriteRequest[3].Data = Str; > + WriteRequest[3].Len = AsciiStrLen (Str); Now we have two strings, pointed-to by elements in the array, that are NUL-terminated: the element at offset 2, and the one at offset 3. Is that intentional? Is that part of the message framing? Hmmm... From the original code: > > - WriteRequest[0].Data = (VOID *) Path; > - WriteRequest[0].Len = (UINT32)AsciiStrSize (Path); > - WriteRequest[1].Data = (VOID *) Str; > - WriteRequest[1].Len = (UINT32)AsciiStrLen (Str); That seems to be the case. I guess the first run (offsets 0 through 2) is parsed until the first NUL is encountered, for "path", then the second run (3 and onwards) is parsed until the second NUL for "data". Sounds plausible; OK. > - > - Status = XenStoreTalkv (Transaction, XS_WRITE, WriteRequest, 2, NULL, NULL); > - FreePool (Path); > - > - return Status; > + return XenStoreTalkv (Transaction, XS_WRITE, WriteRequest, 4, NULL, NULL); (4) Please use ARRAY_SIZE(); it's more robust. > } > > XENSTORE_STATUS > @@ -1207,12 +1224,9 @@ XenStoreRemove ( > IN CONST CHAR8 *Node > ) > { > - CHAR8 *Path; > XENSTORE_STATUS Status; > > - Path = XenStoreJoin (DirectoryPath, Node); > - Status = XenStoreSingle (Transaction, XS_RM, Path, NULL, NULL); > - FreePool (Path); > + Status = XenStoreSingle (Transaction, XS_RM, DirectoryPath, Node, NULL, NULL); > > return Status; > } > @@ -1226,7 +1240,7 @@ XenStoreTransactionStart ( > XENSTORE_STATUS Status; > > Status = XenStoreSingle (XST_NIL, XS_TRANSACTION_START, "", NULL, > - (VOID **) &IdStr); > + NULL, (VOID **) &IdStr); (5) Indentation. > if (Status == XENSTORE_STATUS_SUCCESS) { > Transaction->Id = (UINT32)AsciiStrDecimalToUintn (IdStr); > FreePool (IdStr); > @@ -1246,7 +1260,7 @@ XenStoreTransactionEnd ( > AbortStr[0] = Abort ? 'F' : 'T'; > AbortStr[1] = '\0'; > > - return XenStoreSingle (Transaction, XS_TRANSACTION_END, AbortStr, NULL, NULL); > + return XenStoreSingle (Transaction, XS_TRANSACTION_END, AbortStr, NULL, NULL, NULL); > } > > XENSTORE_STATUS > With the above addressed: Reviewed-by: Laszlo Ersek