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

Re: [PATCH v8 2/9] xen: do not free reserved memory into heap


  • To: Penny Zheng <Penny.Zheng@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 8 Jul 2022 14:47:30 +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=eVyHVNHwCl4ADOxL1R+EKqCtpgikFenruIqKwPh0kqM=; b=G8gkSgmadp5A6zNHocxcwD01U6nvvUtj2SQJ6WbZmhVOE2Y8XkRe+c9IQC8LzvrlHh6Yk74y9Z/esQy32cX3S+R3RlqtbIvi85DMnjxaLo8v0QTBsZKcDx+87HMd7dB1TJzvdXVF2Ut9Pv/ti0/tH40vBaOGlAbTzZaoQpoSSLP+Ftz22Wu/D4jTDT/bX2Qu7CQsf6NWWt5uNrDL1jBFu8jLpWrT7dxuD2masR/qk0ZczJpcuzDX5ZeF3vtUFDp+YOQiEociJvpbQX+Y6qJ9E0mDQ/0jaPUg6dhlxm+HHJVpN4YpXHv4i+c4v08LoC5MLhsKLoD4I8l4ksPnuWoKJw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FRJS0N/M9NrPVqXJ37EsuD9va6dhsKzEuwQ+skpuZJNs7VMsM7688980sLfZjQl8Qs47n+dZHbIHnvISkV/W5bT5cNooIvw90GUC7BhsMWpa6ibyfewiM/nX6oOX9WJP3+BdRAKBCfRV/xp1hubC0s+WKT0AOEPa5VXE22Dnn1k21b0IN+B351YCdBPC+8B2x+QDdzZVBtI2GTdyhfqljZjaCW1YVE5aLSKR7rt9K/wa/xQoyAi/7ynh1TfFs9s1zgs4f/b1/tGygu5QFECzuEbS+uCGessAytRZ2z2lsFhoITDYL5QiHfIb8sds6MwEBkmebAeSx/SLm687LEPYdw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: wei.chen@xxxxxxx, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 08 Jul 2022 12:47:45 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 07.07.2022 11:22, Penny Zheng wrote:
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1622,6 +1622,8 @@ void put_page(struct page_info *page)
>  
>      if ( unlikely((nx & PGC_count_mask) == 0) )
>      {
> +        if ( unlikely(nx & PGC_static) )
> +            free_domstatic_page(page);
>          free_domheap_page(page);

Didn't you have "else" there in the proposal you made while discussing
v7? You also don't alter free_domheap_page() to skip static pages.

> @@ -2652,9 +2650,48 @@ void __init free_staticmem_pages(struct page_info *pg, 
> unsigned long nr_mfns,
>              scrub_one_page(pg);
>          }
>  
> -        /* In case initializing page of static memory, mark it PGC_static. */
>          pg[i].count_info |= PGC_static;
>      }
> +
> +    spin_unlock(&heap_lock);
> +}
> +
> +void free_domstatic_page(struct page_info *page)
> +{
> +    struct domain *d = page_get_owner(page);
> +    bool drop_dom_ref, need_scrub;
> +
> +    ASSERT_ALLOC_CONTEXT();
> +
> +    if ( likely(d) )
> +    {
> +        /* NB. May recursively lock from relinquish_memory(). */
> +        spin_lock_recursive(&d->page_alloc_lock);
> +
> +        arch_free_heap_page(d, page);
> +
> +        /*
> +         * Normally we expect a domain to clear pages before freeing them,
> +         * if it cares about the secrecy of their contents. However, after
> +         * a domain has died we assume responsibility for erasure. We do
> +         * scrub regardless if option scrub_domheap is set.
> +         */
> +        need_scrub = d->is_dying || scrub_debug || opt_scrub_domheap;

May I suggest that instead of copying the comment you simply add
one here referring to the other one? Otoh I'm not sure about the
"dying" case: What happens to a domain's static pages after its
death? Isn't it that they cannot be re-used? If so, scrubbing is
pointless. And whether the other reasons to scrub actually apply
to static pages also isn't quite clear to me.

> +        drop_dom_ref = !domain_adjust_tot_pages(d, -1);
> +
> +        spin_unlock_recursive(&d->page_alloc_lock);
> +    }
> +    else
> +    {
> +        drop_dom_ref = false;
> +        need_scrub = true;
> +    }

Why this "else"? I can't see any way unowned paged would make it here.
Instead you could e.g. have another ASSERT() at the top of the function.

Jan



 


Rackspace

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