Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

[Julien Grall <julien.grall@xxxxxxx>]

On 11/05/18 11:41, Mirela Simonovic wrote:
> Hi Dario,
>
> On Thu, May 10, 2018 at 6:24 PM, Dario Faggioli <dfaggioli@xxxxxxxx> wrote:
> > On Thu, 2018-05-10 at 17:49 +0200, Mirela Simonovic wrote:
> > > Regardless of the fact that the notifier returns an error or not, I
> > > believe it would be good and safe to set priority and document that
> > > priority zero would cause racing issue in the scenario I debugged
> > > today. I'm pretty sure that this discussion would be forgotten soon
> > > and it really should be documented in code/comment.
> > I may very well be missing or misunderstanding something, but I
> > continue to think that the problem here is that CPU_STARTING can't,
> > right now, fail, while you need it to be able to.
> >
> > If that is the case, giving different priorities to the notifier, is
> > not a solution.
> Let me try to clarify. The assumption is that the starting CPU can
> fail. Additional requirement set by Julien is that panic or BUG_ON is
> not acceptable.
Please don't twist my word. I never said it was not acceptable to have 
the BUG_ON in notify_cpu_starting().
I am going to repeat the content of my answer to your last e-mail:

I was aware about it since the beginning. The whole point of the 
conversation was we should avoid to take the decision at the lower level 
and let the upper layer decide what to do.
If the system is failing today then that's fine and still fit what I 
said in my first e-mail of that thread. For reminder:
"We should really avoid to use panic(...) if this is something the 
system can survive. In that specific case, it would only affect the 
current CPU. So it would be better to return an error and let the caller 
decide what to do."
To summarize:
	1) Notifiers should only report an error and let the upper caller (here 
notify_cpu_starting()) deciding what to do.
        2) I am OK with the BUG_ON in notify_cpu_starting() for now.

Cheers,

--
Julien Grall

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