* merge 8xx longstanding MM bug workaround
@ 2005-06-25 15:11 Marcelo Tosatti
2005-06-25 22:27 ` Dan Malek
0 siblings, 1 reply; 2+ messages in thread
From: Marcelo Tosatti @ 2005-06-25 15:11 UTC (permalink / raw)
To: Dan Malek; +Cc: Tom Rini, Kumar Gala, linux-ppc-embedded
Lets agree on something and merge please
The proposed _tlbie call at update_mmu_cache() is safe because:
Addresses for which update_mmu_cache() gets invocated are never inside the
static kernel virtual mapping, meaning that there is no risk for the _tlbie()
here to be thrashing the pinned entry, as Dan suspected.
The intermediate TLB state in which this bug can be triggered is not visible
by userspace or any other contexts, except the page fault handling path.
So there is no need to worry about userspace dcbxxx users.
The other solution to this is to avoid dcbst misbehaviour in the first place,
which involves changing in-kernel "dcbst" callers to use 8xx specific SPR's
instead, as noted by Dan.
What are the arguments in favour of it? Is it worth doing that?
[PATCH] 8xx: avoid "dcbst" misbehaviour with unpopulated TLB
On 8xx, cache control instructions (particularly "dcbst" from
flush_dcache_icache) fault as write operation if there is an
unpopulated TLB entry for the address in question. To workaround
that, we invalidate the TLB here, thus avoiding dcbst misbehaviour.
diff --git a/arch/ppc/mm/init.c b/arch/ppc/mm/init.c
--- a/arch/ppc/mm/init.c
+++ b/arch/ppc/mm/init.c
@@ -622,6 +622,14 @@ void update_mmu_cache(struct vm_area_str
if (!PageReserved(page)
&& !test_bit(PG_arch_1, &page->flags)) {
if (vma->vm_mm == current->active_mm)
+#ifdef CONFIG_8xx
+/* On 8xx, cache control instructions (particularly "dcbst" from
+ * flush_dcache_icache) fault as write operation if there is an
+ * unpopulated TLB entry for the address in question. To workaround
+ * that, we invalidate the TLB here, thus avoiding dcbst misbehaviour.
+ */
+ _tlbie(address);
+#endif
__flush_dcache_icache((void *) address);
else
flush_dcache_icache_page(page);
^ permalink raw reply [flat|nested] 2+ messages in thread* Re: merge 8xx longstanding MM bug workaround
2005-06-25 15:11 merge 8xx longstanding MM bug workaround Marcelo Tosatti
@ 2005-06-25 22:27 ` Dan Malek
0 siblings, 0 replies; 2+ messages in thread
From: Dan Malek @ 2005-06-25 22:27 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Tom Rini, Kumar Gala, linux-ppc-embedded
On Jun 25, 2005, at 11:11 AM, Marcelo Tosatti wrote:
> if (!PageReserved(page)
> && !test_bit(PG_arch_1, &page->flags)) {
> if (vma->vm_mm == current->active_mm)
> +#ifdef CONFIG_8xx
> +/* On 8xx, cache control instructions (particularly "dcbst" from
> + * flush_dcache_icache) fault as write operation if there is an
> + * unpopulated TLB entry for the address in question. To workaround
> + * that, we invalidate the TLB here, thus avoiding dcbst misbehaviour.
> + */
> + _tlbie(address);
> +#endif
> __flush_dcache_icache((void *) address);
> else
> flush_dcache_icache_page(page);
You need some { } and proper indenting here :-)
Thanks.
-- Dan
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2005-06-25 22:27 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-06-25 15:11 merge 8xx longstanding MM bug workaround Marcelo Tosatti
2005-06-25 22:27 ` Dan Malek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).