From: Thomas Gleixner <tglx@linutronix.de>
To: "Huang, Ying" <ying.huang@intel.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH -v2] IRQ, cpu-hotplug: Fix a race between CPU hotplug and IRQ desc alloc/free
Date: Tue, 5 Sep 2017 10:12:20 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.20.1709050919070.1900@nanos> (raw)
In-Reply-To: <20170905021758.8530-1-ying.huang@intel.com>
On Tue, 5 Sep 2017, Huang, Ying wrote:
> From: Huang Ying <ying.huang@intel.com>
>
> When developing code to bootup some APs (Application CPUs)
> asynchronously, the following kernel panic is encountered. After
> checking the code, it is found that the irq_to_desc() may return NULL
> during CPU hotplug. So the NULL pointer checking is added to fix
> this.
You forgot to describe why this can happen. "After checking the code" is
not really helpful for someone who looks at that commit.
for_each_active_irq() is iterated with the sparse lock held in both cases
(cpu up and down). So if there is an active bit in the sparse map and the
the radix tree entry is empty then there is an inconsistency. The
inconsistency originates from the way the irq descriptor allocation/free is
implemented. The bitmap is set/cleared seperately from the actual pointer
store/remove in the radix tree:
The allocation side:
irq_sparse_lock();
bitmap_set();
irq_sparse_unlock();
desc = alloc();
irq_sparse_lock();
store_in_radix_tree(irq, desc);
irq_sparse_unlock();
The deallocation side:
irq_sparse_lock();
store_in_radix_tree(irq, NULL);
irq_sparse_unlock();
irq_sparse_lock();
bitmap_clear();
irq_sparse_unlock();
So the real question is, whether we keep it that way and have the extra
checks all over the place or simply extend the protected sections in the
alloc/free path.
Untested patch below.
Thanks,
tglx
8<----------------
kernel/irq/irqdesc.c | 17 ++++-------------
1 file changed, 4 insertions(+), 13 deletions(-)
Index: b/kernel/irq/irqdesc.c
===================================================================
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -421,10 +421,8 @@ static void free_desc(unsigned int irq)
* The sysfs entry must be serialized against a concurrent
* irq_sysfs_init() as well.
*/
- mutex_lock(&sparse_irq_lock);
kobject_del(&desc->kobj);
delete_irq_desc(irq);
- mutex_unlock(&sparse_irq_lock);
/*
* We free the descriptor, masks and stat fields via RCU. That
@@ -462,20 +460,14 @@ static int alloc_descs(unsigned int star
desc = alloc_desc(start + i, node, flags, mask, owner);
if (!desc)
goto err;
- mutex_lock(&sparse_irq_lock);
irq_insert_desc(start + i, desc);
irq_sysfs_add(start + i, desc);
- mutex_unlock(&sparse_irq_lock);
}
return start;
err:
for (i--; i >= 0; i--)
free_desc(start + i);
-
- mutex_lock(&sparse_irq_lock);
- bitmap_clear(allocated_irqs, start, cnt);
- mutex_unlock(&sparse_irq_lock);
return -ENOMEM;
}
@@ -670,10 +662,10 @@ void irq_free_descs(unsigned int from, u
if (from >= nr_irqs || (from + cnt) > nr_irqs)
return;
+ mutex_lock(&sparse_irq_lock);
for (i = 0; i < cnt; i++)
free_desc(from + i);
- mutex_lock(&sparse_irq_lock);
bitmap_clear(allocated_irqs, from, cnt);
mutex_unlock(&sparse_irq_lock);
}
@@ -727,10 +719,9 @@ int __ref
if (ret)
goto err;
}
-
- bitmap_set(allocated_irqs, start, cnt);
- mutex_unlock(&sparse_irq_lock);
- return alloc_descs(start, cnt, node, affinity, owner);
+ ret = alloc_descs(start, cnt, node, affinity, owner);
+ if (ret >= 0)
+ bitmap_set(allocated_irqs, start, cnt);
err:
mutex_unlock(&sparse_irq_lock);
next prev parent reply other threads:[~2017-09-05 8:13 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-05 2:17 Huang, Ying
2017-09-05 8:12 ` Thomas Gleixner [this message]
2017-09-05 8:54 ` Huang, Ying
2017-09-05 10:59 ` Huang, Ying
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.20.1709050919070.1900@nanos \
--to=tglx@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=ying.huang@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®