All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefano Stabellini <sstabellini@kernel.org>
To: Julien Grall <julien.grall@arm.com>
Cc: edgar.iglesias@xilinx.com,
	Stefano Stabellini <sstabellini@kernel.org>,
	Mirela Simonovic <mirela.simonovic@aggios.com>,
	dm@aggios.com, xen-devel@lists.xen.org
Subject: Re: [PATCH 4/7] xen/arm: When CPU dies, free percpu area immediatelly
Date: Thu, 12 Apr 2018 14:31:46 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.10.1804121314410.3304@sstabellini-ThinkPad-X260> (raw)
In-Reply-To: <2acaa95a-84bd-a9fc-285c-3b2e2b098f4a@arm.com>

On Thu, 12 Apr 2018, Julien Grall wrote:
> On 12/04/18 00:46, Stefano Stabellini wrote:
> > On Wed, 11 Apr 2018, Julien Grall wrote:
> > > On 11/04/18 14:19, Mirela Simonovic wrote:
> > > > Freeing percpu area is done when a non-boot CPU is disabled upon
> > > > suspend.
> > > > This use to be scheduled for execution after a period of time, what
> > > > caused
> > > > the following racing issues. If CPU is enabled after it is disabled and
> > > > before the freeing of percpu area is performed, Xen would crash upon
> > > > initializing percpu area because per cpu offset is not marked as
> > > > INVALID_PERCPU_AREA (this suppose to happen when cpu area is freed).
> > > > To resolve the racing issue, free percpu area right away instead
> > > > scheduling it for later.
> > > 
> > > The reason of using the RCU is you want to make sure that none of the
> > > other
> > > CPUs will access that percpu data before freeing it. So I don't think this
> > > patch is valid.
> > > 
> > > It looks like to me a rcu barrier is missing after calling cpu_down
> > > somewhere
> > > in the CPU off path. I am not entirely sure where.
> > 
> > We need a rcu_barrier(). Perhaps, it could be added on cpu_on before
> > initializing the percpu area?
> 
> Do you mind giving a bit more details on your thought? cpu_up looks a strange
> place as no one should access the percpu area after the CPU is down. So it
> feels the rcu_barrier should be somewhere before PSCI_cpu_off is called.

Yes, it feels strange to do it on cpu_on, it would be more obvious on
cpu_off, but we don't actually need to _free_percpu_area on cpu_off,
right? We only need to make sure it is done before cpu_percpu_callback
is called on cpu_on.

My suggestion would be to evaluate if it is possible to introduce the
rcu_barrier() on the resume path before cpu_percpu_callback, maybe in
start_secondary.

I was also looking at xen/arch/x86/acpi/power.c:enter_state and noticed
that they chose to call rcu_barrier() on enable_cpu before
enable_nonboot_cpus().


 
> > > > 
> > > > Signed-off-by: Mirela Simonovic <mirela.simonovic@aggios.com>
> > > > ---
> > > >    xen/arch/arm/percpu.c | 2 +-
> > > >    1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/xen/arch/arm/percpu.c b/xen/arch/arm/percpu.c
> > > > index 25442c48fe..e4e8405f43 100644
> > > > --- a/xen/arch/arm/percpu.c
> > > > +++ b/xen/arch/arm/percpu.c
> > > > @@ -46,7 +46,7 @@ static void free_percpu_area(unsigned int cpu)
> > > >    {
> > > >        struct free_info *info = &per_cpu(free_info, cpu);
> > > >        info->cpu = cpu;
> > > > -    call_rcu(&info->rcu, _free_percpu_area);
> > > > +    _free_percpu_area(&info->rcu);
> > > >    }
> > > >      static int cpu_percpu_callback(
> > > > 
> > > 
> > > -- 
> > > Julien Grall
> > > 
> 
> -- 
> Julien Grall
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2018-04-12 21:31 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-11 13:19 [PATCH 0/7] xen/arm: CPU hotplug fixes Mirela Simonovic
2018-04-11 13:19 ` [PATCH 1/7] xen/arm: Added handling of the trapped access to OSLSR register Mirela Simonovic
2018-04-11 14:39   ` Julien Grall
2018-04-11 23:28     ` Stefano Stabellini
2018-04-11 13:19 ` [PATCH 2/7] xen/arm/vgic-v2: Ignore write to GICD_ISACTIVERn registers Mirela Simonovic
2018-04-11 14:43   ` Julien Grall
2018-04-11 23:31     ` Stefano Stabellini
2018-04-12 11:15       ` Mirela Simonovic
2018-04-11 13:19 ` [PATCH 3/7] xen/arm/psci: Implement CPU_OFF PSCI call (physical interface) Mirela Simonovic
2018-04-11 14:46   ` Julien Grall
2018-04-12 11:33     ` Mirela Simonovic
2018-04-12 13:31       ` Julien Grall
2018-04-16 10:02         ` Mirela Simonovic
2018-04-16 14:26           ` Julien Grall
2018-04-16 16:52             ` Mirela Simonovic
2018-04-16 17:02               ` Julien Grall
2018-04-11 13:19 ` [PATCH 4/7] xen/arm: When CPU dies, free percpu area immediatelly Mirela Simonovic
2018-04-11 14:53   ` Julien Grall
2018-04-11 23:46     ` Stefano Stabellini
2018-04-12  8:53       ` Julien Grall
2018-04-12 21:31         ` Stefano Stabellini [this message]
2018-04-16 13:14           ` Julien Grall
2018-04-16 13:41             ` Mirela Simonovic
2018-04-16 15:21               ` Julien Grall
2018-04-17 10:52                 ` Mirela Simonovic
2018-04-17 11:02                   ` Julien Grall
2018-04-18 22:52                     ` Stefano Stabellini
2018-04-19  9:32                       ` Julien Grall
2018-04-11 13:19 ` [PATCH 5/7] xen/arm: Remove __initdata and __init to enable CPU hotplug Mirela Simonovic
2018-04-12  0:07   ` Stefano Stabellini
2018-04-12  9:03     ` Julien Grall
2018-04-12 12:50       ` Mirela Simonovic
2018-04-12 12:56         ` Julien Grall
2018-04-12 13:55           ` Mirela Simonovic
2018-04-11 13:19 ` [PATCH 6/7] xen/arm: Setup virtual paging for secondary CPUs in non-boot scenario Mirela Simonovic
2018-04-11 15:11   ` Julien Grall
2018-04-17 12:54     ` Mirela Simonovic
2018-04-17 14:11       ` Julien Grall
2018-04-17 15:22         ` Mirela Simonovic
2018-04-18  9:48           ` Julien Grall
2018-04-18 10:34             ` Mirela Simonovic
2018-04-18 10:45         ` Mirela Simonovic
2018-04-18 10:58           ` Julien Grall
2018-04-18 22:56             ` Stefano Stabellini
2018-04-11 13:19 ` [PATCH 7/7] xen/arm: Restore IRQ affinity after hotplugging a CPU Mirela Simonovic
2018-04-11 14:55   ` Julien Grall
2018-04-12  0:20   ` Stefano Stabellini
2018-04-12  7:38     ` Mirela Simonovic
2018-04-12 16:49   ` Dario Faggioli
2018-04-13 10:11     ` Mirela Simonovic
2018-04-16 12:38       ` Dario Faggioli
2018-04-11 15:07 ` [PATCH 0/7] xen/arm: CPU hotplug fixes Julien Grall
2018-04-11 15:58   ` Mirela Simonovic
2018-04-11 16:02     ` Julien Grall
2018-04-11 16:37       ` Mirela Simonovic
2018-04-12  8:43         ` Julien Grall
2018-04-13 10:19           ` Mirela Simonovic
2018-04-16 11:33             ` Julien Grall
2018-04-16 14:06               ` Mirela Simonovic
2018-04-16 15:05                 ` Julien Grall
2018-04-11 15:13 ` Julien Grall

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=alpine.DEB.2.10.1804121314410.3304@sstabellini-ThinkPad-X260 \
    --to=sstabellini@kernel.org \
    --cc=dm@aggios.com \
    --cc=edgar.iglesias@xilinx.com \
    --cc=julien.grall@arm.com \
    --cc=mirela.simonovic@aggios.com \
    --cc=xen-devel@lists.xen.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.