From: Tejun Heo <tj@kernel.org>
To: zijun_hu <zijun_hu@zoho.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
zijun_hu@htc.com, cl@linux.com
Subject: Re: [RFC v2 PATCH] mm/percpu.c: fix panic triggered by BUG_ON() falsely
Date: Thu, 13 Oct 2016 19:29:02 -0400 [thread overview]
Message-ID: <20161013232902.GD32534@mtj.duckdns.org> (raw)
In-Reply-To: <57FCF07C.2020103@zoho.com>
On Tue, Oct 11, 2016 at 10:00:28PM +0800, zijun_hu wrote:
> From: zijun_hu <zijun_hu@htc.com>
>
> as shown by pcpu_build_alloc_info(), the number of units within a percpu
> group is educed by rounding up the number of CPUs within the group to
> @upa boundary, therefore, the number of CPUs isn't equal to the units's
> if it isn't aligned to @upa normally. however, pcpu_page_first_chunk()
> uses BUG_ON() to assert one number is equal the other roughly, so a panic
> is maybe triggered by the BUG_ON() falsely.
>
> in order to fix this issue, the number of CPUs is rounded up then compared
> with units's, the BUG_ON() is replaced by warning and returning error code
> as well to keep system alive as much as possible.
I really can't decode what the actual issue is here. Can you please
give an example of a concrete case?
> @@ -2113,21 +2120,22 @@ int __init pcpu_page_first_chunk(size_t reserved_size,
>
> /* allocate pages */
> j = 0;
> - for (unit = 0; unit < num_possible_cpus(); unit++)
> + for (unit = 0; unit < num_possible_cpus(); unit++) {
> + unsigned int cpu = ai->groups[0].cpu_map[unit];
> for (i = 0; i < unit_pages; i++) {
> - unsigned int cpu = ai->groups[0].cpu_map[unit];
> void *ptr;
>
> ptr = alloc_fn(cpu, PAGE_SIZE, PAGE_SIZE);
> if (!ptr) {
> pr_warn("failed to allocate %s page for cpu%u\n",
> - psize_str, cpu);
> + psize_str, cpu);
And stop making gratuitous changes?
Thanks.
--
tejun
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Tejun Heo <tj@kernel.org>
To: zijun_hu <zijun_hu@zoho.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
zijun_hu@htc.com, cl@linux.com
Subject: Re: [RFC v2 PATCH] mm/percpu.c: fix panic triggered by BUG_ON() falsely
Date: Thu, 13 Oct 2016 19:29:02 -0400 [thread overview]
Message-ID: <20161013232902.GD32534@mtj.duckdns.org> (raw)
In-Reply-To: <57FCF07C.2020103@zoho.com>
On Tue, Oct 11, 2016 at 10:00:28PM +0800, zijun_hu wrote:
> From: zijun_hu <zijun_hu@htc.com>
>
> as shown by pcpu_build_alloc_info(), the number of units within a percpu
> group is educed by rounding up the number of CPUs within the group to
> @upa boundary, therefore, the number of CPUs isn't equal to the units's
> if it isn't aligned to @upa normally. however, pcpu_page_first_chunk()
> uses BUG_ON() to assert one number is equal the other roughly, so a panic
> is maybe triggered by the BUG_ON() falsely.
>
> in order to fix this issue, the number of CPUs is rounded up then compared
> with units's, the BUG_ON() is replaced by warning and returning error code
> as well to keep system alive as much as possible.
I really can't decode what the actual issue is here. Can you please
give an example of a concrete case?
> @@ -2113,21 +2120,22 @@ int __init pcpu_page_first_chunk(size_t reserved_size,
>
> /* allocate pages */
> j = 0;
> - for (unit = 0; unit < num_possible_cpus(); unit++)
> + for (unit = 0; unit < num_possible_cpus(); unit++) {
> + unsigned int cpu = ai->groups[0].cpu_map[unit];
> for (i = 0; i < unit_pages; i++) {
> - unsigned int cpu = ai->groups[0].cpu_map[unit];
> void *ptr;
>
> ptr = alloc_fn(cpu, PAGE_SIZE, PAGE_SIZE);
> if (!ptr) {
> pr_warn("failed to allocate %s page for cpu%u\n",
> - psize_str, cpu);
> + psize_str, cpu);
And stop making gratuitous changes?
Thanks.
--
tejun
next prev parent reply other threads:[~2016-10-13 23:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-11 14:00 [RFC v2 PATCH] mm/percpu.c: fix panic triggered by BUG_ON() falsely zijun_hu
2016-10-11 14:00 ` zijun_hu
2016-10-12 21:41 ` Andrew Morton
2016-10-12 21:41 ` Andrew Morton
2016-10-13 0:05 ` zijun_hu
2016-10-13 0:05 ` zijun_hu
2016-10-13 0:09 ` zijun_hu
2016-10-13 0:09 ` zijun_hu
2016-10-13 23:29 ` Tejun Heo [this message]
2016-10-13 23:29 ` Tejun Heo
2016-10-14 0:06 ` zijun_hu
2016-10-14 0:06 ` zijun_hu
2016-10-14 0:24 ` Tejun Heo
2016-10-14 0:24 ` Tejun Heo
2016-10-14 0:52 ` zijun_hu
2016-10-14 0:15 ` zijun_hu
2016-10-14 0:15 ` zijun_hu
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=20161013232902.GD32534@mtj.duckdns.org \
--to=tj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=zijun_hu@htc.com \
--cc=zijun_hu@zoho.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.