Date: Fri, 20 Oct 2006 12:58:51 -0700 (PDT)
Message-Id: <20061020.125851.115909797.davem@davemloft.net>
To: torvalds@osdl.org
Cc: nickpiggin@yahoo.com.au, ralf@linux-mips.org, akpm@osdl.org,
       linux-kernel@vger.kernel.org, anemo@mba.ocn.ne.jp
Subject: Re: [PATCH 1/3] Fix COW D-cache aliasing on fork
From: David Miller <davem@davemloft.net>
In-Reply-To: <Pine.LNX.4.64.0610201251440.3962@g5.osdl.org>
References: <Pine.LNX.4.64.0610200846260.3962@g5.osdl.org>
	<20061020.123635.95058911.davem@davemloft.net>
	<Pine.LNX.4.64.0610201251440.3962@g5.osdl.org>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 994
Lines: 24

From: Linus Torvalds <torvalds@osdl.org>
Date: Fri, 20 Oct 2006 12:54:17 -0700 (PDT)

> Well, sparc always was crud. I can see the missing tlb entry, but if it's 
> been turned read-only, the write-back should still work (it clearly _was_ 
> writable when the write that dirtied the cacheline happened).

I did some more digging, here's what I think the hardware actually
does:

1) On L2 cacheline load, the "user" and "writable" protection
   bits are propagated from the TLB entry into the L2 cache
   line.  Access checks are done on L2 cache hit using this
   cached copy of the two protection bits.

2) On L2 dirty cacheline writeback, the physical address is
   obtained from the TLB

So what you guys are suggesting should probably work fine.
-
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/