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

Re: [PATCH v7 7/9] xen/arm: unpopulate memory when domain is static


  • To: Penny Zheng <Penny.Zheng@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 22 Jun 2022 11:24:25 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; 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=AfCsUpOrZvhWMsOu9W4Q/7uuYdHvFdenfDSpKMmnifo=; b=aaaiijICug6/CqHooa3HkxTgRdPxRLIN2lHaN6BLpaWAC7LXvLs5cQBEpzDCU+meL2dNCQjfMHhxpzANmnr6xVLsHIw4K9ncAc9iOBkubO6RHepckT8VlZOcAcN/dTiaeQzIRDmPFzya/U/5P01FLPTRKTxZw8hRBPVs1TDL3d0Hedu8nG4O/Bm9WwDzrumJgyT9G7XTuMuuUcecf/XLIcO+XRMwGv5IlO0oOapM2HHsKNc1xDNzpvS/QN2ssRy6mT27M6lgW98uwlkUlzifE3pr2gB9gjFOvV3yhU1WMlmiYkj0j2nkh3TuFLuIPrBQUH3AsUQ+8SdbBoyiB/ldPQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hviing2ydUWTnaDdbjeMIfhmqKM4t9lI8ht1ptcDcLfsppaXduwwSDsv//b82fBzC+zambR++/SWANg+OJu/n32zqAYGxxHviCWOIsd5SDOglCJX3xwsw6rQPEh+S5fngwoklBO4qLz0Ls8Ht/X0YBsw5vbKgmHsAKWQwbl6yP35gsJXDtodCaSayFCL/qAZrFj1qUiAk7VJDJA4DWlyZgq3zG8ehzmIjedGui20v2zP5PROD4y7Fnx/VgUR+p5x0BeHpLPHl1eA500iQtOXfb6a01E6qZOS9+yt1rtfTgOlv2DOaasCIV0R+e90edHS7hb411qkky1Rz5e/M/+zaA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: wei.chen@xxxxxxx, 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: Wed, 22 Jun 2022 09:24:35 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 20.06.2022 04:44, Penny Zheng wrote:
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -2498,6 +2498,10 @@ void free_domheap_pages(struct page_info *pg, unsigned 
> int order)
>          }
>  
>          free_heap_pages(pg, order, scrub);
> +
> +        /* Add page on the resv_page_list *after* it has been freed. */
> +        if ( unlikely(pg->count_info & PGC_static) )
> +            put_static_pages(d, pg, order);

Unless I'm overlooking something the list addition done there / ...

> --- a/xen/include/xen/mm.h
> +++ b/xen/include/xen/mm.h
> @@ -90,6 +90,15 @@ void free_staticmem_pages(struct page_info *pg, unsigned 
> long nr_mfns,
>                            bool need_scrub);
>  int acquire_domstatic_pages(struct domain *d, mfn_t smfn, unsigned int 
> nr_mfns,
>                              unsigned int memflags);
> +#ifdef CONFIG_STATIC_MEMORY
> +#define put_static_pages(d, page, order) ({                 \
> +    unsigned int i;                                         \
> +    for ( i = 0; i < (1 << (order)); i++ )                  \
> +        page_list_add_tail((pg) + i, &(d)->resv_page_list); \
> +})

... here isn't guarded by any lock. Feels like we've been there before.
It's not really clear to me why the freeing of staticmem pages needs to
be split like this - if it wasn't split, the list addition would
"naturally" occur with the lock held, I think.

Furthermore careful with the local variable name used here. Consider
what would happen with an invocation of

    put_static_pages(d, page, i);

To common approach is to suffix an underscore to the variable name.
Such names are not supposed to be used outside of macros definitions,
and hence there's then no potential for such a conflict.

Finally I think you mean (1u << (order)) to be on the safe side against
UB if order could ever reach 31. Then again - is "order" as a parameter
needed here in the first place? Wasn't it that staticmem operations are
limited to order-0 regions?

Jan



 


Rackspace

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