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: <20160304192326.GU25240@wotan.suse.de>
Date:	Fri, 4 Mar 2016 20:23:26 +0100
From:	"Luis R. Rodriguez" <mcgrof@...nel.org>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:	"Luis R. Rodriguez" <mcgrof@...nel.org>, 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 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.

  Luis

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ