linux-kernel - Re: [PATCH] uvesafb,vesafb: create write-combining or write-back PAT entries

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]

Date:	Sun, 6 Feb 2011 12:02:05 +0100
From:	Thomas Schlichter <thomas.schlichter@....de>
To:	Paul Mundt <lethal@...ux-sh.org>
Cc:	Michal Januszewski <spock@...too.org>, linux-fbdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] uvesafb,vesafb: create write-combining or write-back PAT entries

Sorry for answering this late, unfortunately I was quite busy with my daily 
work...

Am Dienstag 30 November 2010, um 07:10:51 schrieb Paul Mundt:
> uvesafb presently has no special architecture dependencies, but
> ioremap_wc() is not as of yet a wholly generic interface. Some
> architectures that don't set ARCH_HAS_IOREMAP_WC get it by virtue of the
> asm-generic/iomap.h include, and most of the nommu architectures will
> stub it in via asm-generic/io.h, but this still leaves quite a long list
> of platforms that don't handle it at all.
> 
> Your options at this point are either to establish ioremap_wc() as a
> generic API, and layer this patch on top of that, or rework
> uvesafb_init_mtrr() to do the actual broken-out remapping and rework it
> in to something like a uvesafb_remap(), where you bury the MTRR details
> under CONFIG_MTRR.
> 
> While there's probably value in exposing ioremap_wc() as a generic
> interface, you're never going to hit any of the non-default ioremap()
> calls on platforms lacking MTRRs anyways, so special-casing it is ok.

Thank you for finding that problem and showing possibilities for fixing it. I 
prepared 3 patches, where the first essentially is my old patch with special-
casing via ifdef CONFIG_X86. The second patch establishes ioremap_cache() and 
ioremap_wc() for all architectures, and the third patch removed the special-
casing from uvesafb.

So the first patch can stand on its own and hopefully can be merged upstream. 
The third patch needs the second one, which may be merged for unifying 
purposes. But as these are mor cleanup-patches, they are not that important 
for me.

Best regards,
Thomas Schlichter

Download attachment "signature.asc " of type "application/pgp-signature" (199 bytes)