All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Alejandro Vallejo <alejandro.vallejo@cloud.com>
Subject: Re: [PATCH] xen/page_alloc: Simplify domain_adjust_tot_pages
Date: Wed, 26 Feb 2025 15:28:53 +0100	[thread overview]
Message-ID: <Z78lJfzqH9btDMrM@macbook.local> (raw)
In-Reply-To: <a9d4384c-770b-4947-b099-cf4bba1583a5@suse.com>

On Wed, Feb 26, 2025 at 03:08:33PM +0100, Jan Beulich wrote:
> On 26.02.2025 14:56, Roger Pau Monné wrote:
> > On Mon, Feb 24, 2025 at 01:27:24PM +0000, Alejandro Vallejo wrote:
> >> --- a/xen/common/page_alloc.c
> >> +++ b/xen/common/page_alloc.c
> >> @@ -490,13 +490,11 @@ static long outstanding_claims; /* total outstanding claims by all domains */
> >>  
> >>  unsigned long domain_adjust_tot_pages(struct domain *d, long pages)
> >>  {
> >> -    long dom_before, dom_after, dom_claimed, sys_before, sys_after;
> >> -
> >>      ASSERT(rspin_is_locked(&d->page_alloc_lock));
> >>      d->tot_pages += pages;
> >>  
> >>      /*
> >> -     * can test d->claimed_pages race-free because it can only change
> >> +     * can test d->outstanding_pages race-free because it can only change
> >>       * if d->page_alloc_lock and heap_lock are both held, see also
> >>       * domain_set_outstanding_pages below
> >>       */
> >> @@ -504,17 +502,16 @@ unsigned long domain_adjust_tot_pages(struct domain *d, long pages)
> >>          goto out;
> > 
> > I think you can probably short-circuit the logic below if pages == 0?
> > (and avoid taking the heap_lock)
> 
> Are there callers passing in 0?

Not sure, but if there are no callers expected we might add an ASSERT
to that effect then.

> >>      spin_lock(&heap_lock);
> >> -    /* adjust domain outstanding pages; may not go negative */
> >> -    dom_before = d->outstanding_pages;
> >> -    dom_after = dom_before - pages;
> >> -    BUG_ON(dom_before < 0);
> >> -    dom_claimed = dom_after < 0 ? 0 : dom_after;
> >> -    d->outstanding_pages = dom_claimed;
> >> -    /* flag accounting bug if system outstanding_claims would go negative */
> >> -    sys_before = outstanding_claims;
> >> -    sys_after = sys_before - (dom_before - dom_claimed);
> >> -    BUG_ON(sys_after < 0);
> >> -    outstanding_claims = sys_after;
> >> +    BUG_ON(outstanding_claims < d->outstanding_pages);
> >> +    if ( pages > 0 && d->outstanding_pages < pages )
> >> +    {
> >> +        /* `pages` exceeds the domain's outstanding count. Zero it out. */
> >> +        outstanding_claims -= d->outstanding_pages;
> >> +        d->outstanding_pages = 0;
> >> +    } else {
> >> +        outstanding_claims -= pages;
> >> +        d->outstanding_pages -= pages;
> > 
> > I wonder if it's intentional for a pages < 0 value to modify
> > outstanding_claims and d->outstanding_pages, I think those values
> > should only be set from domain_set_outstanding_pages().
> > domain_adjust_tot_pages() should only decrease the value, but never
> > increase either outstanding_claims or d->outstanding_pages.
> > 
> > At best the behavior is inconsistent, because once
> > d->outstanding_pages reaches 0 there will be no further modification
> > from domain_adjust_tot_pages().
> 
> Right, at that point the claim has run out. While freeing pages with an
> active claim means that the claim gets bigger (which naturally needs
> reflecting in the global).

domain_adjust_tot_pages() is not exclusively called when freeing
pages, see steal_page() for example.

When called from steal_page() it's wrong to increase the claim, as
it assumes that the page removed from d->tot_pages is freed, but
that's not the case.  The domain might end up in a situation where
the claim is bigger than the available amount of memory.

Thanks, Roger.


  reply	other threads:[~2025-02-26 14:29 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-24 13:27 [PATCH] xen/page_alloc: Simplify domain_adjust_tot_pages Alejandro Vallejo
2025-02-24 14:49 ` Alejandro Vallejo
2025-02-26 14:05   ` Jan Beulich
2025-02-27 14:36     ` Alejandro Vallejo
2025-03-05 10:49       ` Jan Beulich
2025-03-05 13:22         ` Alejandro Vallejo
2025-03-05 13:39           ` Jan Beulich
2025-03-05 14:55             ` Alejandro Vallejo
2025-03-11  9:46             ` Alejandro Vallejo
2025-03-11 10:06               ` Jan Beulich
2025-02-26 14:18   ` Roger Pau Monné
2025-02-26 13:56 ` Roger Pau Monné
2025-02-26 14:08   ` Jan Beulich
2025-02-26 14:28     ` Roger Pau Monné [this message]
2025-02-26 14:36       ` Jan Beulich
2025-02-26 16:04         ` Roger Pau Monné
2025-02-26 16:06           ` Jan Beulich
2025-02-26 16:34             ` Andrew Cooper
2025-02-26 16:42               ` Jan Beulich
2025-02-26 16:51                 ` Andrew Cooper
2025-02-27 14:39                   ` Alejandro Vallejo
2025-02-27 14:50       ` Alejandro Vallejo
2025-03-05 10:50         ` Jan Beulich
2025-02-26 14:02 ` Jan Beulich
2025-02-27 14:59   ` Alejandro Vallejo
2025-03-05 10:52     ` Jan Beulich

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-all 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=Z78lJfzqH9btDMrM@macbook.local \
    --to=roger.pau@citrix.com \
    --cc=alejandro.vallejo@cloud.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony.perard@vates.tech \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.