Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750931AbWJTXaA (ORCPT ); Fri, 20 Oct 2006 19:30:00 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751104AbWJTX37 (ORCPT ); Fri, 20 Oct 2006 19:29:59 -0400 Received: from smtp.osdl.org ([65.172.181.4]:48033 "EHLO smtp.osdl.org") by vger.kernel.org with ESMTP id S1750931AbWJTX36 (ORCPT ); Fri, 20 Oct 2006 19:29:58 -0400 Date: Fri, 20 Oct 2006 16:28:37 -0700 (PDT) From: Linus Torvalds To: Ralf Baechle cc: David Miller , nickpiggin@yahoo.com.au, akpm@osdl.org, linux-kernel@vger.kernel.org, anemo@mba.ocn.ne.jp, linux-arch@vger.kernel.org, schwidefsky@de.ibm.com, James.Bottomley@SteelEye.com Subject: Re: [PATCH 1/3] Fix COW D-cache aliasing on fork In-Reply-To: <20061020225118.GA30965@linux-mips.org> Message-ID: References: <20061020214916.GA27810@linux-mips.org> <20061020.152247.111203913.davem@davemloft.net> <20061020225118.GA30965@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1486 Lines: 36 On Fri, 20 Oct 2006, Ralf Baechle wrote: > > > My understanding is that this works because in Ralf's original patch > > (which is the context in which he is removing the flush_cache_mm() > > call), he uses kmap()/kunmap() to map the page(s) being accessed at a > > kernel virtual address which will fall into the same cache color as > > the user virtual address --> no alias problems. > > > > Since he does this for every page touched on the kernel side during > > dup_mmap(), the existing flush_cache_mm() call in dup_mmap() does in > > fact become redundant. > > Correct. > > It means no cache flush operation to deal with aliases at all left in > fork and COW code. Umm. That would seem to only happen to work for a direct-mapped virtually indexed cache where the index is taken purely from the virtual address, and there are no "process context" bits in the virtually indexed D$. The moment there are process context bits involved, afaik you absolutely _need_ to flush, because otherwise the other process will never pick up the dirty state (which it would need to reload from memory). That said, maybe nobody does that. Virtual caches are a total braindamage in the first place, so hopefully they have limited use. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/