linux-kernel - Re: [RFC PATCH] ARM: Assume new page cache pages have dirty D-cache

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: <20100305211629.GF4885@n2100.arm.linux.org.uk>
Date:	Fri, 5 Mar 2010 21:16:29 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	James Bottomley <James.Bottomley@...senPartnership.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Subject: Re: [RFC PATCH] ARM: Assume new page cache pages have dirty D-cache

On Fri, Mar 05, 2010 at 04:52:40PM +0000, Catalin Marinas wrote:
> As Ben said, I think we can set PG_dcache_clean in the
> clear/copy_user_page() functions. My doubt with these functions is the
> highmem cases where kunmap_atomic() only flushes the D-cache in one
> situation, the other just calling kunmap_high() which doesn't seem to do
> anything to the caches.

In which case you're totally missing the point with these functions.
The copy_user_page and clear_user_page functions specifically do tricks
to ensure that they can avoid additional cache maintainence - or any
cache maintainence at all.

For instance, on aliasing VIPT, they will map the user page in using
the same colour as the ultimate userspace address, ensuring that any
cache lines created will be visible to the userspace application.

So what kunmap_atomic() does with caches is not really relevant to the
coherency issue.
--
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/