linux-mips
[Top] [All Lists]

Re: vmalloc bugs in 2.4.5???

To: ralf@oss.sgi.com
Subject: Re: vmalloc bugs in 2.4.5???
From: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>
Date: Wed, 07 Nov 2001 10:39:47 +0900 (JST)
Cc: dony.he@huawei.com, linux-mips@oss.sgi.com
In-reply-to: <20011106130839.B30219@dea.linux-mips.net>
Organization: TOSHIBA Personal Computer System Corporation
References: <013301c165cc$5d030fa0$4a1c690a@huawei.com> <20011106130839.B30219@dea.linux-mips.net>
Sender: owner-linux-mips@oss.sgi.com
>>>>> On Tue, 6 Nov 2001 13:08:39 -0800, Ralf Baechle <ralf@oss.sgi.com> said:
ralf> Vmalloc is probably innocent I'd rather guess cache flushing is
ralf> broken on your platform.

In 2.4.5, flush_cache_all() (and flush_tlb_all()) is called in
vmalloc_area_pages().  I think this call protect us from virtual
aliasing problem.

By the way, does anybody have any problem with vmalloc on recent
kernel?

In somewhere between 2.4.6 and 2.4.9, the call to flush_cache_all()
disappered from vmalloc_area_pages().  I have a data corruption
problem in vmalloc()ed area without this call.  I think we still need
this call.

--- linux-sgi-cvs/mm/vmalloc.c  Tue Sep 18 05:16:31 2001
+++ linux.new/mm/vmalloc.c      Wed Nov  7 10:33:47 2001
@@ -144,6 +144,7 @@
        int ret;
 
        dir = pgd_offset_k(address);
+       flush_cache_all();
        spin_lock(&init_mm.page_table_lock);
        do {
                pmd_t *pmd;
@@ -163,6 +164,7 @@
                ret = 0;
        } while (address && (address < end));
        spin_unlock(&init_mm.page_table_lock);
+       flush_tlb_all();
        return ret;
 }
 
---
Atsushi Nemoto

<Prev in Thread] Current Thread [Next in Thread>