linux-kernel - Re: [PATCH v2 1/2] x86/mm/pat, drivers/infiniband/ipath: replace WARN() with pr

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: <20150626084438.GC26303@gmail.com>
Date:	Fri, 26 Jun 2015 10:44:39 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	"Luis R. Rodriguez" <mcgrof@...e.com>
Cc:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>, bp@...e.de,
	andy@...verblocksystems.net, mchehab@....samsung.com,
	dledford@...hat.com, fengguang.wu@...el.com,
	linux-media@...r.kernel.org, linux-rdma@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] x86/mm/pat, drivers/infiniband/ipath: replace
 WARN() with pr_warn()


* Luis R. Rodriguez <mcgrof@...e.com> wrote:

> On Thu, Jun 25, 2015 at 08:49:22AM +0200, Ingo Molnar wrote:
> > 
> > * Luis R. Rodriguez <mcgrof@...not-panic.com> wrote:
> > 
> > > From: "Luis R. Rodriguez" <mcgrof@...e.com>
> > > 
> > > WARN() may confuse users, fix that. ipath_init_one() is part the
> > > device's probe so this would only be triggered if a corresponding
> > > device was found.
> > > 
> > > Signed-off-by: Luis R. Rodriguez <mcgrof@...e.com>
> > > ---
> > >  drivers/infiniband/hw/ipath/ipath_driver.c | 6 ++++--
> > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/infiniband/hw/ipath/ipath_driver.c b/drivers/infiniband/hw/ipath/ipath_driver.c
> > > index 2d7e503..871dbe5 100644
> > > --- a/drivers/infiniband/hw/ipath/ipath_driver.c
> > > +++ b/drivers/infiniband/hw/ipath/ipath_driver.c
> > > @@ -31,6 +31,8 @@
> > >   * SOFTWARE.
> > >   */
> > >  
> > > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> > > +
> > >  #include <linux/sched.h>
> > >  #include <linux/spinlock.h>
> > >  #include <linux/idr.h>
> > > @@ -399,8 +401,8 @@ static int ipath_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> > >  	u32 bar0 = 0, bar1 = 0;
> > >  
> > >  #ifdef CONFIG_X86_64
> > > -	if (WARN(pat_enabled(),
> > > -		 "ipath needs PAT disabled, boot with nopat kernel parameter\n")) {
> > > +	if (pat_enabled()) {
> > > +		pr_warn("ipath needs PAT disabled, boot with nopat kernel parameter\n");
> > >  		ret = -ENODEV;
> > >  		goto bail;
> > >  	}
> > 
> > So driver init will always fail with this on modern kernels.
> 
> Nope, I double checked this, ipath_init_one() is the PCI probe routine,
> not the module init call. It should probably be renamed.
> 
> > Btw., on a second thought, ipath uses MTRRs to enable WC:
> > 
> >         ret = ipath_enable_wc(dd);
> >         if (ret)
> >                 ret = 0;
> > 
> > Note how it ignores any failures - the driver still works even if WC was not 
> > enabled.
> 
> Ah, well WC strategy requires a split of the MMIO registers and the desired
> WC area, right now they are combined for some type of ipath devices. There
> are two things to consider when thinking about whether or not we want to
> do the work required to do the split:

But ... why doing the 'split'?

With my suggested approach the driver will behave in two ways:

  - if booted with 'nopat' it will behave as always and have the WC MTRR entries 
    added

  - if booted with a modern kernel without 'nopat' then instead of getting WC MTRR 
    entries it will not get them - we'll fall back to UC. No 'split' or any other 
    change is needed to the driver AFAICS: it might be slower, but it will still 
    be functional. It will _not_ get PAT WC mappings - it will fall back to UC - 
    which is still much better for any potential user than not working at all.

Same suggestion for the other affected driver.

what am I missing?

Thanks,

	Ingo
--
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/