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 for Android: free password hash cracker in your pocket

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

Message-ID: <AANLkTinTaW87RGUZ+o4TL8gzUPGkoR8=7C1e7aYWC9=b@mail.gmail.com>
Date:	Mon, 18 Oct 2010 17:51:09 -0700
From:	Kevin Cernekee <cernekee@...il.com>
To:	Shinya Kuribayashi <shinya.kuribayashi.px@...esas.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 Mon, Oct 18, 2010 at 5:03 PM, Shinya Kuribayashi
<shinya.kuribayashi.px@...esas.com> wrote:
> IIUC, the problem is that write operation originating from step 5. seems
> to overtake the one originating from step 3., correct?

Correct.  This particular system makes no guarantees that data flushed
out through CACHE operations will not overtake subsequent uncached
stores.

For the case of DMA, it is possible that data that I am attempting to
send to a device (via DRAM) could still be in transit when
dma_cache_wback() returns, and may be incomplete when the DMA
operation starts.  Or that dirty cachelines that I am attempting to
"free up" for a DMA_FROM_DEVICE operation are still in transit when
dma_cache_wback_inv() returns, potentially clobbering whatever data
the peripheral is trying to write to memory.

Adding SYNC at the end of dma_cache_wback* guarantees that the write
buffers have been emptied out to DRAM and I do not have to worry
anymore about any of these cases.

> 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?

It is my recollection that the caller was the USB EHCI driver, and it
was allocating some sort of uncached descriptor block that contained
pointers.  Sometimes those pointers got inexplicably zeroed out, and
this is what we found to be the root cause.
--
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/