linux-kernel - Re: [PATCH] x86: PAT: Documentation: update overlapping ioremap hack recommendation

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: <20160304210900.GT3577@linux.vnet.ibm.com>
Date:	Fri, 4 Mar 2016 13:09:00 -0800
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	"Luis R. Rodriguez" <mcgrof@...nel.org>
Cc:	bp@...en8.de, mingo@...nel.org, tglx@...utronix.de, hpa@...or.com,
	toshi.kani@...com, airlied@...hat.com, benh@...nel.crashing.org,
	mst@...hat.com, vinod.koul@...el.com, jgross@...e.com,
	daniel.vetter@...ll.ch, luto@...capital.net,
	linux-fbdev@...r.kernel.org, linux-arch@...r.kernel.org,
	linux-kernel@...r.kernel.org, x86@...nel.org,
	linux-doc@...r.kernel.org, corbet@....net
Subject: Re: [PATCH] x86: PAT: Documentation: update overlapping ioremap hack
 recommendation

On Fri, Mar 04, 2016 at 08:23:26PM +0100, Luis R. Rodriguez wrote:
> On Thu, Mar 03, 2016 at 01:42:33PM -0800, Paul E. McKenney wrote:
> > On Thu, Mar 03, 2016 at 01:21:48PM -0800, Luis R. Rodriguez wrote:
> > > The current documentation refers to using set_memor_wc() as a
> > > possible hole strategy when you have overlapping ioremap() regions,
> > > that's incorrect as set_memory_*() helpers can only be used on RAM,
> > > not IO memory. This fixes that, and updates the documention to
> > > *strongly* discourage overlapping ioremap() memory uses, but also
> > > documents a possible solution should there really be no other
> > > option.
> > > 
> > > Signed-off-by: Luis R. Rodriguez <mcgrof@...nel.org>
> > 
> > Given an Acked-by or better from the guys on the TO line, I would be
> > happy to queue it.
> 
> I'll need to respin as fortunately I ended up actually not needing
> to do an overlap on atyfb, and instead just let MTRR be effective
> over an entire range that included both write-combining and strong
> UC attributes. It was a bit fuzzy as this while ago, and since its
> also obscure, its more reason to document now.
> 
> Will spin a v2.

Sounds good!

							Thanx, Paul