All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.