[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] xen/public: partially revert commit 7c7f7e8fba01


  • To: Juergen Gross <jgross@xxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 7 Feb 2022 11:46:36 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=cUjpp8UpJffA04V3EbdopeSNBUXOJLg4fXPA0jqT3xk=; b=Ze9NZYzWFvuBtWlyBYt4iPD+swc0x2XSAiXM04SK7yK5Fpq51nfnCdBwGB4DHz4KHFBLfsksi6s8DvwW3+iKHbHIJwd0RWIJqBN5cqx/Ng9Adohx/B1zX0NXWCHCyid//Lg6abN0USLwKh9WnQjw6I5S3vJ4ZWatO+rx0WmMGcI4o+JIrSP5U45Y3Q2GSixkinuFpd3AI3DkNWe4DQpiCQ4U1hf+rxaVA3jPjn/IYPc2kl8xCXmJQKjb33ULgPmDwy3IAbDqV9RPOV/exm3GyrMpx1MkR0Isn6pktxH/pvWWIoFLLWui91GNGMoJT6jtmUFm9SVxOP/EQtMwHIGXQg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fR7y2og+GQNLkB6bF6Njb+baSoGekstzngIqby7smq5sgZWo7tpGx5Vfn0DyHAkk8zNGFEEV6hhsAgo0ZBkvYoJK1kXrZUi2ZmTSDd39XrWqWKXjSd78ngz/2UxqbQG/UzVrhljsHM97paaYwIGAY+cywonp6+0ciuqjYOtmdRKWgQ3BzGiPWEH+Xsr6YwpYtNVkq2cypepZ/gjMZOaDuOfHGTMOkdDjyQdhgZla64N3sWMjJIL98gLMg+FhaZtYRFl1kAvHVHnA77VXJ1Y4+rTX59YjdrURMcWIshRuMA/ZVsFvy8SRQ8mWE5w361wS+vLIP6yD9Dw9M40SZo/uMw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 07 Feb 2022 10:46:49 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 07.02.2022 11:36, Juergen Gross wrote:
> Commit 7c7f7e8fba01 changed xen/include/public/memory.h in an incompatible
> way. Unfortunately the changed parts were already in use in the Linux
> kernel, so an update of the header in the kernel would result in a build
> breakage.
> 
> Even when removing its usage from the kernel the used flag bit should be
> marked as reserved in order to avoid to give it a different semantic in
> the future.
> 
> Do a partial revert of said commit in order to enable the kernel to take
> an updated version of memory.h.

I don't think it should be a partial revert, and as said on irc I'm of
the opinion that ...

> Fixes: 7c7f7e8fba01 ("include/public/memory.h: remove the 
> XENMEM_rsrc_acq_caller_owned flag")

... it's 0e2e54966af5 which should have taken measures to protect
against re-use of the flag as an output.

> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -662,7 +662,17 @@ struct xen_mem_acquire_resource {
>       * two calls.
>       */
>      uint32_t nr_frames;
> -    uint32_t pad;
> +
> +    /*
> +     * OUT - Must be zero on entry. On return this may contain a bitwise
> +     *       OR of the following values.
> +     */
> +    uint32_t flags;
> +
> +    /* No longer supported - will be never set */
> +#define _XENMEM_rsrc_acq_caller_owned 0
> +#define XENMEM_rsrc_acq_caller_owned (1u << _XENMEM_rsrc_acq_caller_owned)

I think this goes too far: Neither do we want to re-introduce the
#define-s, nor should we re-fix the purpose of the padding field
to be OUT (only). All we need to make sure is that the field
coming in as zero won't get responded to by setting bit 0 of it.
Imo this can only reasonably be done by way of adding a comment.
This comment may, in turn, mention XENMEM_rsrc_acq_caller_owned
of course.

Btw., if the field was to become OUT-only again, I think you'd
also need to revert the change to xen/common/compat/memory.c. At
least to not leave a trap for someone to later fall into.

Jan




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.