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: <4CBEA2D6.6050507@niisi.msk.ru>
Date:	Wed, 20 Oct 2010 12:05:42 +0400
From:	"Gleb O. Raiko" <raiko@...si.msk.ru>
To:	"Maciej W. Rozycki" <macro@...ux-mips.org>
CC:	Ralf Baechle <ralf@...ux-mips.org>,
	Kevin Cernekee <cernekee@...il.com>,
	Shinya Kuribayashi <skuribay@...ox.com>,
	linux-mips@...ux-mips.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH resend 5/9] MIPS: sync after cacheflush

On 20.10.2010 0:11, Maciej W. Rozycki wrote:
>   That said, R4k DECstations seem to perform aggressive write buffering in
> the chipset and to make sure a write has propagated to an MMIO register a
> SYNC and an uncached read operation are necessary.

Just uncached read may be enough. R4k shall pull data from its store 
buffer on uncached read.

>   I haven't investigated DMA dependencies and I think we currently only
> have one TURBOchannel device/driver only (that is the DEFTA/defxx FDDI
> thingy) making use of the generic DMA API on DECstations.  It seemed to
> work correctly the last time I tried; presumably either because the API
> Does The Right Thing, or by pure luck and right timings.

dfx_writel issues sync after store. BTW, it seems no uncached read 
issued here (just mb() is used, which seems to do sync only), so either 
those uncached read is not needed (unlikely) or data from dfx_writel 
wait somewhere in the chipset for being pulled by subsequent reads or 
writes.

Gleb.
--
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/