public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Laszlo Ersek" <lersek@redhat.com>
To: devel@edk2.groups.io, anthony.perard@citrix.com
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Julien Grall <julien.grall@arm.com>,
	Jordan Justen <jordan.l.justen@intel.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [edk2-devel] [PATCH 05/11] OvmfPkg/XenBusDxe: Construct paths without allocation
Date: Mon, 16 Sep 2019 17:39:21 +0200	[thread overview]
Message-ID: <59a12b9c-17ce-2e4c-96a9-f741858b2ba6@redhat.com> (raw)
In-Reply-To: <20190913145100.303433-6-anthony.perard@citrix.com>

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 <anthony.perard@citrix.com>
> ---
>  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 <lersek@redhat.com>

  reply	other threads:[~2019-09-16 15:39 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-13 14:50 [PATCH 00/11] OvmfPkg/XenBusDxe: Fix ExitBootServices handler to avoid allocation Anthony PERARD
2019-09-13 14:50 ` [PATCH 01/11] OvmfPkg/XenBusDxe: Fix missing \n in DEBUG messages Anthony PERARD
2019-09-16 14:24   ` [edk2-devel] " Laszlo Ersek
2019-09-13 14:50 ` [PATCH 02/11] OvmfPkg/XenBusDxe: Have XenStoreFindWatch take a pointer Anthony PERARD
2019-09-16 14:38   ` [edk2-devel] " Laszlo Ersek
2019-09-13 14:50 ` [PATCH 03/11] OvmfPkg/XenBusDxe: Rework watch events reception Anthony PERARD
2019-09-16 14:39   ` [edk2-devel] " Laszlo Ersek
2019-09-13 14:50 ` [PATCH 04/11] OvmfPkg/XenBusDxe: Avoid Allocate in XenStoreVSPrint Anthony PERARD
2019-09-16 14:45   ` [edk2-devel] " Laszlo Ersek
2019-09-13 14:50 ` [PATCH 05/11] OvmfPkg/XenBusDxe: Construct paths without allocation Anthony PERARD
2019-09-16 15:39   ` Laszlo Ersek [this message]
2019-09-16 15:43     ` [edk2-devel] " Laszlo Ersek
2019-09-13 14:50 ` [PATCH 06/11] OvmfPkg/XenBusDxe: Rework XenStoreProcessMessage to avoid allocating memory Anthony PERARD
2019-09-16 15:41   ` [edk2-devel] " Laszlo Ersek
2019-09-13 14:50 ` [PATCH 07/11] OvmfPkg/XenBusDxe: Use on stack buffer in internal functions Anthony PERARD
2019-09-16 16:11   ` [edk2-devel] " Laszlo Ersek
2019-09-13 14:50 ` [PATCH 08/11] OvmfPkg/XenBus: Change XENBUS_PROTOCOL to not return allocated memory Anthony PERARD
2019-09-16 16:16   ` [edk2-devel] " Laszlo Ersek
2019-09-13 14:50 ` [PATCH 09/11] OvmfPkg/XenBusDxe: Fix NotifyExitBoot to avoid Memory Allocation Services Anthony PERARD
2019-09-16 17:36   ` [edk2-devel] " Laszlo Ersek
2019-09-16 18:36     ` Andrew Fish
2019-09-16 19:31       ` Laszlo Ersek
2019-09-16 20:50         ` Andrew Fish
2019-09-13 14:50 ` [PATCH 10/11] OvmfPkg/XenPvBlkDxe: Use XenBusIo->RegisterExitCallback Anthony PERARD
2019-09-13 14:51 ` [PATCH 11/11] OvmfPkg/XenBusDxe: Fix XenStoreWaitForEvent use during EBS Anthony PERARD

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=59a12b9c-17ce-2e4c-96a9-f741858b2ba6@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox