From: Ralf Baechle <ralf@linux-mips.org>
To: Greg Ungerer <gerg@snapgear.com>
Cc: linux-mips@linux-mips.org
Subject: Re: system lockup with 2.6.29 on Cavium/Octeon
Date: Wed, 20 May 2009 15:26:04 +0100 [thread overview]
Message-ID: <20090520142604.GA29677@linux-mips.org> (raw)
In-Reply-To: <4A139F50.7050409@snapgear.com>
On Wed, May 20, 2009 at 04:12:32PM +1000, Greg Ungerer wrote:
> I have a system lockup problem that I have been looking at on a custom
> Cavium/Octeon 5010 based design. I am running on linux-2.6.29 with
> David Daney's latest round of PCI and ethernet patches (posted here
> on this list).
>
> I have tracked the problem back to local_flush_tlb_kernel_range() in
> arch/mips/mm/tlb-r4k.c. At the top of this function is:
>
> void local_flush_tlb_kernel_range(unsigned long start, unsigned long
> end)
> {
> unsigned long flags;
> int size;
>
> ENTER_CRITICAL(flags);
> size = (end - start + (PAGE_SIZE - 1)) >> PAGE_SHIFT;
> size = (size + 1) >> 1;
> if (size <= current_cpu_data.tlbsize / 2) {
>
> The problem is that typical example values I see passed in for start
> and end are:
>
> start = c000000000006000
> end = ffffffffc01d8000
>
> Now the vmalloc area starts at 0xc000000000000000 and the kernel code
> and data is all at 0xffffffff80000000 and above. I don't know if the
> start and end are reasonable values, but I can see some logic as to
> where they come from. The code path that leads to this is via
> __vunmap() and __purge_vmap_area_lazy(). So it is not too difficult
> to see how we end up with values like this.
Either start or end address is sensible but not the combination - both
addresses should be in the same segment. Start is in XKSEG, end in CKSEG2
and in between there are vast wastelands of unused address space exabytes
in size.
> But the size calculation above with these types of values will result
> in still a large number. Larger than the 32bit "int" that is "size".
> I see large negative values fall out as size, and so the following
> tlbsize check becomes true, and the code spins inside the loop inside
> that if statement for a _very_ long time trying to flush tlb entries.
>
> This is of course easily fixed, by making that size "unsigned long".
> The patch below trivially does this.
>
> But is this analysis correct?
Yes - but I think we have two issues here. The one is the calculation
overflowing int for the arguments you're seeing. The other being that
the arguments simply are looking wrong.
There are a few more instances of the same overflow issue which the patch
below is fixing.
Ralf
arch/mips/mm/tlb-r3k.c | 6 ++----
arch/mips/mm/tlb-r4k.c | 6 ++----
arch/mips/mm/tlb-r8k.c | 3 +--
3 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/arch/mips/mm/tlb-r3k.c b/arch/mips/mm/tlb-r3k.c
index f0cf46a..1c0048a 100644
--- a/arch/mips/mm/tlb-r3k.c
+++ b/arch/mips/mm/tlb-r3k.c
@@ -82,8 +82,7 @@ void local_flush_tlb_range(struct vm_area_struct *vma, unsigned long start,
int cpu = smp_processor_id();
if (cpu_context(cpu, mm) != 0) {
- unsigned long flags;
- int size;
+ unsigned long size, flags;
#ifdef DEBUG_TLB
printk("[tlbrange<%lu,0x%08lx,0x%08lx>]",
@@ -121,8 +120,7 @@ void local_flush_tlb_range(struct vm_area_struct *vma, unsigned long start,
void local_flush_tlb_kernel_range(unsigned long start, unsigned long end)
{
- unsigned long flags;
- int size;
+ unsigned long size, flags;
#ifdef DEBUG_TLB
printk("[tlbrange<%lu,0x%08lx,0x%08lx>]", start, end);
diff --git a/arch/mips/mm/tlb-r4k.c b/arch/mips/mm/tlb-r4k.c
index 9619f66..892be42 100644
--- a/arch/mips/mm/tlb-r4k.c
+++ b/arch/mips/mm/tlb-r4k.c
@@ -117,8 +117,7 @@ void local_flush_tlb_range(struct vm_area_struct *vma, unsigned long start,
int cpu = smp_processor_id();
if (cpu_context(cpu, mm) != 0) {
- unsigned long flags;
- int size;
+ unsigned long size, flags;
ENTER_CRITICAL(flags);
size = (end - start + (PAGE_SIZE - 1)) >> PAGE_SHIFT;
@@ -160,8 +159,7 @@ void local_flush_tlb_range(struct vm_area_struct *vma, unsigned long start,
void local_flush_tlb_kernel_range(unsigned long start, unsigned long end)
{
- unsigned long flags;
- int size;
+ unsigned long size, flags;
ENTER_CRITICAL(flags);
size = (end - start + (PAGE_SIZE - 1)) >> PAGE_SHIFT;
diff --git a/arch/mips/mm/tlb-r8k.c b/arch/mips/mm/tlb-r8k.c
index 4f01a3b..4ec95cc 100644
--- a/arch/mips/mm/tlb-r8k.c
+++ b/arch/mips/mm/tlb-r8k.c
@@ -111,8 +111,7 @@ out_restore:
/* Usable for KV1 addresses only! */
void local_flush_tlb_kernel_range(unsigned long start, unsigned long end)
{
- unsigned long flags;
- int size;
+ unsigned long size, flags;
size = (end - start + (PAGE_SIZE - 1)) >> PAGE_SHIFT;
size = (size + 1) >> 1;
next prev parent reply other threads:[~2009-05-20 14:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-20 6:12 system lockup with 2.6.29 on Cavium/Octeon Greg Ungerer
2009-05-20 14:26 ` Ralf Baechle [this message]
2009-05-21 5:29 ` Greg Ungerer
2009-05-21 6:28 ` Ralf Baechle
2009-05-21 14:50 ` Atsushi Nemoto
2009-05-22 1:19 ` Greg Ungerer
2009-05-22 9:23 ` Ralf Baechle
2009-05-22 11:53 ` Atsushi Nemoto
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=20090520142604.GA29677@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=gerg@snapgear.com \
--cc=linux-mips@linux-mips.org \
/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.