linux-kernel - Re: [PATCH resend 5/9] MIPS: sync after cacheflush

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4CBCE05E.20408@renesas.com>
Date:	Tue, 19 Oct 2010 09:03:42 +0900
From:	Shinya Kuribayashi <shinya.kuribayashi.px@...esas.com>
To:	Kevin Cernekee <cernekee@...il.com>
CC:	Shinya Kuribayashi <skuribay@...ox.com>,
	Ralf Baechle <ralf@...ux-mips.org>, linux-mips@...ux-mips.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH resend 5/9] MIPS: sync after cacheflush

On 10/19/2010 3:34 AM, Kevin Cernekee wrote:
> On Mon, Oct 18, 2010 at 6:44 AM, Shinya Kuribayashi <skuribay@...ox.com> wrote:
>> I suspect that SYNC insn alone is still not enough, insn't it?  In
>> such systems with that 'deep' write buffer and data incoherency is
>> visibly observed, there sill may be data write transactions floating
>> in the internal bus system.
>>
>> To make sure that all data (data inside processor's write buffer and
>> data floating in the internal bus system), we need the following
>> three steps:
>>
>> 1. Flush data cache
>> 2. Uncached, dummy load operation from _DRAM_ (not somewhere else)
>> 3. then SYNC instruction
> 
> Some systems do require additional steps along those lines, e.g.
> 
> # ifdef CONFIG_SGI_IP28
> #  define fast_iob()				\
> 	__asm__ __volatile__(			\
> 		".set	push\n\t"		\
> 		".set	noreorder\n\t"		\
> 		"lw	$0,%0\n\t"		\
> 		"sync\n\t"			\
> 		"lw	$0,%0\n\t"		\
> 		".set	pop"			\
> 		: /* no output */		\
> 		: "m" (*(int *)CKSEG1ADDR(0x1fa00004)) \
> 		: "memory")
> 
> Maybe it would be better to use iob() instead of __sync() directly, so
> that it is easy to add extra steps for the CPUs that need them.  DEC
> and Loongson have custom __wbflush() implementations, and something
> similar could be added for your processor to implement the uncached
> dummy load.

I was jumping to conclusions the issue you're facing with is related to
DMA operation.  If so, yes, we need to sync with I/O systems (namely
with DRAM in this case) at some point, prior to initiating DMA.

But getting back to your original scenario, it seems not; at least, I
failed to see a connection with DMA operations.  I wonder why and how
steps through 1-to-7 will be problem.

> Actual problem seen in the wild:
> 
> 1) dma_alloc_coherent() allocates cached memory
> 
> 2) memset() is called to clear the new pages
> 
> 3) dma_cache_wback_inv() is called to flush the zero data out to memory

At this point, write-backed data will go into a queue of 'deep' write
buffer, and will be pushed out to the internal bus system (queued).

> 4) dma_alloc_coherent() returns an uncached (kseg1) pointer to the
> freshly allocated pages
> 
> 5) Caller writes data through the kseg1 pointer

This 'write through KSEG1 segment' operation also goes into a queue of
'deep' write buffer, doesn't it?

> 6) Buffered writeback data finally gets flushed out to DRAM
> 
> 7) Part of caller's data is inexplicably zeroed out
> 
> This patch adds SYNC between steps 3 and 4, which fixed the problem.

IIUC, the problem is that write operation originating from step 5. seems
to overtake the one originating from step 3., correct?

Then we'd like to know, what is that 'Caller mentioned at step 5.', and
what kind of operation will be done by the Caller?
-- 
Shinya Kuribayashi
Renesas Electronics
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/