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] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.1610242242320.4815@nanos>
Date:   Mon, 24 Oct 2016 22:54:14 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Marc Zyngier <marc.zyngier@....com>
cc:     Geetha sowjanya <gakula@...iumnetworks.com>, robin.murphy@....com,
        will.deacon@....com, mark.rutland@....com,
        Prasun.Kapoor@...ium.com, iommu@...ts.linux-foundation.org,
        Tirumalesh Chalamarla <Tirumalesh.Chalamarla@...ium.com>,
        linux-arm-kernel@...ts.infradead.org,
        Jason Cooper <jason@...edaemon.net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] arm64: SMMU-v2: Workaround for Cavium ThunderX erratum
 28168

On Mon, 24 Oct 2016, Marc Zyngier wrote:
> On 22/10/16 05:54, Geetha sowjanya wrote:
> > diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
> > index be3c34e..6add8da 100644
> > --- a/kernel/irq/chip.c
> > +++ b/kernel/irq/chip.c
> > @@ -585,6 +585,10 @@ void handle_fasteoi_irq(struct irq_desc *desc)
> >  		goto out;
> >  	}
> >  
> > +#ifdef CONFIG_CAVIUM_ERRATUM_28168
> > +	if (chip->irq_ack)
> > +		chip->irq_ack(&desc->irq_data);
> > +#endif
> >  	kstat_incr_irqs_this_cpu(desc);
> >  	if (desc->istate & IRQS_ONESHOT)
> >  		mask_irq(desc);
> > 
> 
> Overall, this workaround is not acceptable as it is.

Aside of being not acceptable this thing is completely broken. 

If that erratum is enabled then a interrupt chip which implements both EOI
and ACK callbacks will issue irq_ack when using the fasteoi handler. While
this might work on that cavium trainwreck, it will just make other
platforms pretty unhappy.

Platform specific hacks have no place in the core code at all. We have
enough options to handle oddball hardware, you just have to use them.

Thanks,

	tglx

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ