linux-kernel - Re: [PATCH 0/2] Revert patches fixing probing of interrupts

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: <20191211112254.GC16450@linux.intel.com>
Date:   Wed, 11 Dec 2019 13:22:54 +0200
From:   Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To:     Stefan Berger <stefanb@...ux.ibm.com>,
        Stefan Berger <stefanb@...ux.vnet.ibm.com>,
        linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: [PATCH 0/2] Revert patches fixing probing of interrupts

On Mon, Dec 09, 2019 at 02:55:35PM -0700, Jerry Snitselaar wrote:
> On Mon Dec 09 19, Jarkko Sakkinen wrote:
> > On Mon, Dec 02, 2019 at 11:55:20AM -0700, Jerry Snitselaar wrote:
> > > On Sun Dec 01 19, Stefan Berger wrote:
> > > > On 11/29/19 5:37 PM, Jarkko Sakkinen wrote:
> > > > > On Tue, Nov 26, 2019 at 08:17:51AM -0500, Stefan Berger wrote:
> > > > > > From: Stefan Berger <stefanb@...ux.ibm.com>
> > > > > >
> > > > > > Revert the patches that were fixing the probing of interrupts due
> > > > > > to reports of interrupt stroms on some systems
> > > > > Can you explain how reverting is going to fix the issue?
> > > >
> > > >
> > > > The reverts fix 'the interrupt storm issue' that they are causing on
> > > > some systems but don't fix the issue with the interrupt mode not being
> > > > used. I was hoping Jerry would get access to a system faster but this
> > > > didn't seem to be the case. So sending these patches seemed the better
> > > > solution than leaving 5.4.x with the problem but going back to when it
> > > > worked 'better.'
> > > >
> > > 
> > > I finally heard back from IT support, and unfortunately they don't
> > > have any T490s systems to give out on temp loan. So I can only send
> > > patched kernels to the end user that had the problem.
> > 
> > At least it is a fact that tpm_chip_stop() is called too early and that
> > is destined to cause issues.
> > 
> > Should I bake a patch or do you have already something?
> > 
> > /Jarkko
> > 
> 
> This is what I'm currently building:

With a quick skim looks what I had in mind.

/Jarkko