Message-ID: <40531D3D.2090702@comhem.se>
Date: Sat, 13 Mar 2004 15:39:57 +0100
From: Danjel McGougan <danjel.mcgougan@comhem.se>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
MIME-Version: 1.0
To: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ppc32 copy_to_user dcbt fixup
References: <1z8Na-5hH-1@gated-at.bofh.it>
In-Reply-To: <1z8Na-5hH-1@gated-at.bofh.it>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1285
Lines: 29

Bryan Rittmeyer wrote:
> copy_tofrom_user and copy_page use dcbt to prefetch source data [1].
> Since at least 2.4.17, these functions have been prefetching
> beyond the end of the source buffer, leading to two problems:
> 
> 1. Subtly broken software cache coherency. If the area following src
> was invalidate_dcache_range'd prior to submitting for DMA,
> an out-of-bounds dcbt from copy_to_user of a separate slab object
> may read in the area before DMA completion. When the DMA does complete,
> data will not be loaded from RAM because stale data is already in cache.
> Thus you get a corrupt network packet, bogus audio capture, etc.
> 
[snip]

I am no expert on the ppc arch, but in my humble opinion it seems 
strange to invalidate the dcache *before* the memory-writing 
DMA-transaction. The obvious solution is to invalidate the dcache 
*after* DMA completion. It seems hard to guarantee that nobody will 
touch the memory area in question during the DMA.

Just some clue-less comments from a linux-kernel lurker.

Regards,
Danjel
-
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/