Re: vmalloc bugs in 2.4.5???

[Ralf Baechle <ralf@oss.sgi.com>]

On Wed, Nov 07, 2001 at 10:39:47AM +0900, Atsushi Nemoto wrote:

Time to revisit a pile of old problems in my mailfolder ...

> >>>>> 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;
>  }

Have you ever resolved this problem?  I've just doublechecked the
vmalloc code and it seems as if it should be entirely safe without these
two calls.  The tlb is flushed on vfree so no stale entries for a
vmalloc address can ever be in the tlb at vmalloc time, so this
flush_tlb_all() is just an expensive nop.  And the same it true for
flush_cache_all() no matter if caches are physically or virtually
indexed.

  Ralf