All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Yanmin Zhang <yanmin_zhang@linux.intel.com>,
	Joerg Roedel <jroedel@suse.de>,
	Peter Zijlstra <peterz@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	xiao jin <jin.xiao@intel.com>, Peter Anvin <hpa@zytor.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Borislav Petkov <bp@suse.de>, Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [patch 1/4] hotplug: Prevent alloc/free of irq descriptors during cpu up/down
Date: Mon, 14 Mar 2016 09:12:31 -0400	[thread overview]
Message-ID: <56E6B8BF.3020603@oracle.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1603121017500.3657@nanos>

On 03/12/2016 04:19 AM, Thomas Gleixner wrote:
> Boris,
>
> On Tue, 14 Jul 2015, Boris Ostrovsky wrote:
>> On 07/14/2015 04:15 PM, Thomas Gleixner wrote:
>>>>> The issue here is that all architectures need that protection and just
>>>>> Xen does irq allocations in cpu_up.
>>>>>
>>>>> So moving that protection into architecture code is not really an
>>>>> option.
>>>>>
>>>>>>>> Otherwise we will need to have something like arch_post_cpu_up()
>>>>>>>> after the lock is released.
>>>>> I'm not sure, that this will work. You probably want to do this in the
>>>>> cpu prepare stage, i.e. before calling __cpu_up().
>>>> For PV guests (the ones that use xen_cpu_up()) it will work either before
>>>> or
>>>> after __cpu_up(). At least my (somewhat limited) testing didn't show any
>>>> problems so far.
>>>>
>>>> However, HVM CPUs use xen_hvm_cpu_up() and if you read comments there you
>>>> will
>>>> see that xen_smp_intr_init() needs to be called before native_cpu_up() but
>>>> xen_init_lock_cpu() (which eventually calls irq_alloc_descs()) needs to be
>>>> called after.
>>>>
>>>> I think I can split xen_init_lock_cpu() so that the part that needs to be
>>>> called after will avoid going into irq core code. And then the rest will
>>>> go
>>>> into arch_cpu_prepare().
>>> I think we should revisit this for 4.3. For 4.2 we can do the trivial
>>> variant and move the locking in native_cpu_up() and x86 only. x86 was
>>> the only arch on which such wreckage has been seen in the wild, but we
>>> should have that protection for all archs in the long run.
>>>
>>> Patch below should fix the issue.
>> Thanks! Most of my tests passed, I had a couple of failures but I will need to
>> see whether they are related to this patch.
> Did you ever come around to address that irq allocation from within cpu_up()?
>
> I really want to generalize the protection instead of carrying that x86 only
> hack forever.

Sorry, I completely forgot about this. Let me see how I can take 
allocations from under the lock. I might just be able to put them in CPU 
notifiers --- most into CPU_UP_PREPARE but spinlock interrupt may need 
to go into CPU_ONLINE.

-boris

  reply	other threads:[~2016-03-14 13:13 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-05 17:12 [patch 0/4] x86/irq: Plug a couple of cpu hotplug races Thomas Gleixner
2015-07-05 17:12 ` [patch 1/4] hotplug: Prevent alloc/free of irq descriptors during cpu up/down Thomas Gleixner
2015-07-07  9:48   ` [tip:irq/urgent] hotplug: Prevent alloc/ free " tip-bot for Thomas Gleixner
2015-07-07 20:06   ` tip-bot for Thomas Gleixner
2015-07-08  9:37   ` tip-bot for Thomas Gleixner
2015-07-14 14:39   ` [patch 1/4] hotplug: Prevent alloc/free " Boris Ostrovsky
2015-07-14 14:39   ` Boris Ostrovsky
2015-07-14 15:44     ` Thomas Gleixner
2015-07-14 15:44     ` Thomas Gleixner
2015-07-14 16:03       ` Boris Ostrovsky
2015-07-14 16:03       ` Boris Ostrovsky
2015-07-14 17:32         ` Thomas Gleixner
2015-07-14 17:32         ` Thomas Gleixner
2015-07-14 20:04           ` [Xen-devel] " Boris Ostrovsky
2015-07-14 20:15             ` Thomas Gleixner
2015-07-14 21:07               ` Boris Ostrovsky
2015-07-14 21:07               ` [Xen-devel] " Boris Ostrovsky
2016-03-12  9:19                 ` Thomas Gleixner
2016-03-12  9:19                 ` [Xen-devel] " Thomas Gleixner
2016-03-14 13:12                   ` Boris Ostrovsky [this message]
2016-03-14 13:12                   ` Boris Ostrovsky
2015-07-14 20:15             ` Thomas Gleixner
2015-07-14 20:04           ` Boris Ostrovsky
2015-07-05 17:12 ` [patch 2/4] x86: Plug irq vector hotplug race Thomas Gleixner
2015-07-07  9:57   ` [tip:x86/urgent] x86/irq: " tip-bot for Thomas Gleixner
2015-07-05 17:12 ` [patch 3/4] x86/irq: Use proper locking in check_irq_vectors_for_cpu_disable() Thomas Gleixner
2015-07-07  9:57   ` [tip:x86/urgent] " tip-bot for Thomas Gleixner
2015-07-05 17:12 ` [patch 4/4] x86/irq: Retrieve irq data after locking irq_desc Thomas Gleixner
2015-07-07  9:58   ` [tip:x86/urgent] " tip-bot for Thomas Gleixner

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=56E6B8BF.3020603@oracle.com \
    --to=boris.ostrovsky@oracle.com \
    --cc=bp@suse.de \
    --cc=hpa@zytor.com \
    --cc=jin.xiao@intel.com \
    --cc=jroedel@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=xen-devel@lists.xenproject.org \
    --cc=yanmin_zhang@linux.intel.com \
    /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.