From: Tejun Heo <tj@kernel.org>
To: CAI Qian <caiqian@redhat.com>, lkml <linux-kernel@vger.kernel.org>
Cc: graff yang <graff.yang@gmail.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
kexec <kexec@lists.infradead.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
dhowells@redhat.com, sonic adi <sonic.adi@gmail.com>,
Chris Lalancette <clalance@redhat.com>,
Avi Kivity <avi@redhat.com>
Subject: [PATCH] percpu: fix pcpu_last_unit_cpu
Date: Tue, 21 Sep 2010 08:13:59 +0200 [thread overview]
Message-ID: <4C984D27.3050102@kernel.org> (raw)
In-Reply-To: <1848241872.1438141285029613564.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
pcpu_first/last_unit_cpu are used to track which cpu has the first and
last units assigned. This in turn is used to determine the span of a
chunk for man/unmap cache flushes and whether an address belongs to
the first chunk or not in per_cpu_ptr_to_phys().
When the number of possible CPUs isn't power of two, a chunk may
contain unassigned units towards the end of a chunk. The logic to
determine pcpu_last_unit_cpu was incorrect when there was an unused
unit at the end of a chunk. It failed to ignore the unused unit and
assigned the unused marker NR_CPUS to pcpu_last_unit_cpu.
This was discovered through kdump failure which was caused by
malfunctioning per_cpu_ptr_to_phys() on a kvm setup with 50 possible
CPUs by CAI Qian.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: CAI Qian <caiqian@redhat.com>
Cc: stable@kernel.org
---
This is pretty subtle and has the potential to cause mysterious
problems on vcache architectuers. Thanks a lot for discovering it and
your patience. I'll put it out in linux-next for a couple of days and
push it to Linus and stable.
Thanks.
mm/percpu.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mm/percpu.c b/mm/percpu.c
index 58c572b..c76ef38 100644
--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -1401,9 +1401,9 @@ int __init pcpu_setup_first_chunk(const struct pcpu_alloc_info *ai,
if (pcpu_first_unit_cpu == NR_CPUS)
pcpu_first_unit_cpu = cpu;
+ pcpu_last_unit_cpu = cpu;
}
}
- pcpu_last_unit_cpu = cpu;
pcpu_nr_units = unit;
for_each_possible_cpu(cpu)
--
1.7.1
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Tejun Heo <tj@kernel.org>
To: CAI Qian <caiqian@redhat.com>, lkml <linux-kernel@vger.kernel.org>
Cc: graff yang <graff.yang@gmail.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
kexec <kexec@lists.infradead.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
dhowells@redhat.com, sonic adi <sonic.adi@gmail.com>,
Chris Lalancette <clalance@redhat.com>,
Avi Kivity <avi@redhat.com>
Subject: [PATCH] percpu: fix pcpu_last_unit_cpu
Date: Tue, 21 Sep 2010 08:13:59 +0200 [thread overview]
Message-ID: <4C984D27.3050102@kernel.org> (raw)
In-Reply-To: <1848241872.1438141285029613564.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
pcpu_first/last_unit_cpu are used to track which cpu has the first and
last units assigned. This in turn is used to determine the span of a
chunk for man/unmap cache flushes and whether an address belongs to
the first chunk or not in per_cpu_ptr_to_phys().
When the number of possible CPUs isn't power of two, a chunk may
contain unassigned units towards the end of a chunk. The logic to
determine pcpu_last_unit_cpu was incorrect when there was an unused
unit at the end of a chunk. It failed to ignore the unused unit and
assigned the unused marker NR_CPUS to pcpu_last_unit_cpu.
This was discovered through kdump failure which was caused by
malfunctioning per_cpu_ptr_to_phys() on a kvm setup with 50 possible
CPUs by CAI Qian.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: CAI Qian <caiqian@redhat.com>
Cc: stable@kernel.org
---
This is pretty subtle and has the potential to cause mysterious
problems on vcache architectuers. Thanks a lot for discovering it and
your patience. I'll put it out in linux-next for a couple of days and
push it to Linus and stable.
Thanks.
mm/percpu.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mm/percpu.c b/mm/percpu.c
index 58c572b..c76ef38 100644
--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -1401,9 +1401,9 @@ int __init pcpu_setup_first_chunk(const struct pcpu_alloc_info *ai,
if (pcpu_first_unit_cpu == NR_CPUS)
pcpu_first_unit_cpu = cpu;
+ pcpu_last_unit_cpu = cpu;
}
}
- pcpu_last_unit_cpu = cpu;
pcpu_nr_units = unit;
for_each_possible_cpu(cpu)
--
1.7.1
next prev parent reply other threads:[~2010-09-21 6:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1888861854.1349971284977836487.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
2010-09-20 10:17 ` kvm kdump regression caiqian
2010-09-20 10:17 ` caiqian
2010-09-20 23:09 ` Tejun Heo
2010-09-20 23:09 ` Tejun Heo
2010-09-21 0:40 ` CAI Qian
2010-09-21 0:40 ` CAI Qian
2010-09-21 6:13 ` Tejun Heo [this message]
2010-09-21 6:13 ` [PATCH] percpu: fix pcpu_last_unit_cpu Tejun Heo
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=4C984D27.3050102@kernel.org \
--to=tj@kernel.org \
--cc=avi@redhat.com \
--cc=caiqian@redhat.com \
--cc=clalance@redhat.com \
--cc=dhowells@redhat.com \
--cc=graff.yang@gmail.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=sonic.adi@gmail.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.