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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 27 Sep 2013 15:41:44 -0400
From:	Neil Horman <nhorman@...driver.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	Joerg Roedel <joro@...tes.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Sebastian Andrzej Siewior <sebastian@...akpoint.cc>
Subject: Re: [PATCH] iommu: Remove stack trace from broken irq remapping
 warning

On Fri, Sep 27, 2013 at 12:24:10PM -0700, Andy Lutomirski wrote:
> On Fri, Sep 27, 2013 at 9:53 AM, Neil Horman <nhorman@...driver.com> wrote:
> > The warning for the irq remapping broken check in intel_irq_remapping.c is
> > pretty pointless.  We need the warning, but we know where its comming from, the
> > stack trace will always be the same, and it needlessly triggers things like
> > Abrt.  This changes the warning to just print a text warning about BIOS being
> > broken, without the stack trace, then sets the appropriate taint bit.  Since we
> > automatically disable irq remapping, theres no need to contiue making Abrt jump
> > at this problem
> >
> > Signed-off-by: Neil Horman <nhorman@...driver.com>
> > CC: Joerg Roedel <joro@...tes.org>
> > CC: Bjorn Helgaas <bhelgaas@...gle.com>
> > CC: Andy Lutomirski <luto@...capital.net>
> > CC: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
> > CC: Sebastian Andrzej Siewior <sebastian@...akpoint.cc>
> > ---
> >  drivers/iommu/intel_irq_remapping.c | 13 +++++++------
> >  1 file changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/iommu/intel_irq_remapping.c b/drivers/iommu/intel_irq_remapping.c
> > index f71673d..b97d70b 100644
> > --- a/drivers/iommu/intel_irq_remapping.c
> > +++ b/drivers/iommu/intel_irq_remapping.c
> > @@ -525,12 +525,13 @@ static int __init intel_irq_remapping_supported(void)
> >         if (disable_irq_remap)
> >                 return 0;
> >         if (irq_remap_broken) {
> > -               WARN_TAINT(1, TAINT_FIRMWARE_WORKAROUND,
> > -                          "This system BIOS has enabled interrupt remapping\n"
> > -                          "on a chipset that contains an erratum making that\n"
> > -                          "feature unstable.  To maintain system stability\n"
> > -                          "interrupt remapping is being disabled.  Please\n"
> > -                          "contact your BIOS vendor for an update\n");
> > +               printk(KERN_WARNING
> > +                       "This system BIOS has enabled interrupt remapping\n"
> > +                       "on a chipset that contains an erratum making that\n"
> > +                       "feature unstable.  To maintain system stability\n"
> > +                       "interrupt remapping is being disabled.  Please\n"
> > +                       "contact your BIOS vendor for an update\n");
> > +               add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK);
> 
> Is the taint bit actually useful?  It seems like functionality will be
> missing if this workaround happens, but everything should be stable.
> 
I think its useful yes.  The system will be stable, an in fact should run
exactly as it did before, but since the errata indicates this should be fixed in
BIOS, its a reminder to the admin that you should investigate an update, or take
action in manually disabling iommu on the command line

Its also in keeping with the way this was structured previously.
Neil

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ