linux-kernel - Re: [PATCH v4 2/2] IB/qib: use arch_phys_wc

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:	Wed, 22 Apr 2015 13:48:27 -0400
From:	Doug Ledford <dledford@...hat.com>
To:	"Luis R. Rodriguez" <mcgrof@...e.com>
Cc:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>,
	infinipath@...el.com, roland@...nel.org, sean.hefty@...el.com,
	hal.rosenstock@...il.com, linux-rdma@...r.kernel.org,
	luto@...capital.net, mst@...hat.com, linux-kernel@...r.kernel.org,
	cocci@...teme.lip6.fr, Toshi Kani <toshi.kani@...com>,
	Rickard Strandqvist <rickard_strandqvist@...ctrumdigital.se>,
	Mike Marciniszyn <mike.marciniszyn@...el.com>,
	Roland Dreier <roland@...estorage.com>,
	Dennis Dalessandro <dennis.dalessandro@...el.com>,
	Suresh Siddha <sbsiddha@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Juergen Gross <jgross@...e.com>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Dave Airlie <airlied@...hat.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Antonino Daplas <adaplas@...il.com>,
	Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>,
	Tomi Valkeinen <tomi.valkeinen@...com>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	Arnd Bergmann <arnd@...db.de>,
	Stefan Bader <stefan.bader@...onical.com>,
	konrad.wilk@...cle.com, ville.syrjala@...ux.intel.com,
	david.vrabel@...rix.com, jbeulich@...e.com,
	Roger Pau Monné <roger.pau@...rix.com>,
	linux-fbdev@...r.kernel.org, xen-devel@...ts.xensource.com
Subject: Re: [PATCH v4 2/2] IB/qib: use arch_phys_wc_add()

On Wed, 2015-04-22 at 19:37 +0200, Luis R. Rodriguez wrote:
> On Wed, Apr 22, 2015 at 12:57:18PM -0400, Doug Ledford wrote:
> > On Wed, 2015-04-22 at 17:33 +0200, Luis R. Rodriguez wrote:
> > > On Wed, Apr 22, 2015 at 09:54:38AM -0400, Doug Ledford wrote:
> > > > On Tue, 2015-04-21 at 14:50 -0700, Luis R. Rodriguez wrote:
> > > > 
> > > > This:
> > > > > +	/* MTRR was used if this is non-zero */
> > > > > +	if (!dd->wc_cookie)
> > > > >  		vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> > > > 
> > > > And this:
> > > > > +		dd->wc_cookie = arch_phys_wc_add(pioaddr, piolen);
> > > > > +		if (dd->wc_cookie < 0)
> > > > > +			ret = -EINVAL;
> > > > 
> > > > don't agree on what wc_cookie will be on error.
> > > 
> > > Can you elaborate? The one below is the one that starts things,
> > > and arch_phys_wc_add() will return 0 on PAT systems. For non-PAT
> > > systems it will return a number > 0 *iff* a valid MTRR was added.
> > > It will return negative onloy on error then.
> > > 
> > > The change above is meant to replace a check put in place to see
> > > if PAT was enabled. The way we replace this is to ensure that
> > > arch_phys_wc_add() returned 0.
> > > 
> > > If you disagree it'd be great if you can elaborate why.
> > 
> > Maybe I'm missing something, but in qib_enable_wc() you store the return
> > from arch_phys_wc_add into wc_cookie.  That return is negative,
> 
> If and only if the system was non-PAT and mtrr_add() failed.
> 
> >  so you
> > return from qib_enable_wc() to qib_init_one(), they see the ret value,
> > they print out a warning about bad performance, then they clear the
> > return value and continue with device initialization.
> > 
> > In all of this though, wc_cookie is never cleared and so it still has
> > the error condition in it.  Then, much later at run time, you call
> > mmap_piobufs() and you check the contents of wc_cookie, and if it's
> > non-0 (which is still will be), you do the wrong thing, right?
> 
> Originally the code had it to run pgprot_writecombine() if PAT was going to be
> used. After the code changes we check for !cookie which will be true when
> cookie is 0 only. In case the cookie was an error, that is if mtrr_add()
> failed, then this code would not run because (!negative) is false. The goal was
> to trigger a run if the cookie was 0, which can only happen if PAT was enabled.

OK, the logic works, but as much as anything, it's the comment that's
misleading.  The code would be clearer with a comment like this:

/* We used PAT if wc_cookie == 0 */
if (!dd->wc_cookie) {

That would be more accurate as well since the original comment didn't
account for the possible error code in wc_cookie, so it's possible you
didn't use either PAT or wc if you have that error code.

> Please let me know, I'd like to get this right too.
> 
> > And what
> > about at shutdown when you call qib_disable_wc() and your cookie still
> > has an error code in it as well?
> 
> Well fortunately arch_phys_wc_del(negative) and arch_phys_wc_del(0) will be
> a no-op. Its what helps us remove so much clutter.

OK.

-- 
Doug Ledford <dledford@...hat.com>
              GPG KeyID: 0E572FDD



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