linux-kernel - Re: Reported regressions for 4.7 as of Sunday, 2016-06-19

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: <874m8jd3ox.fsf@x220.int.ebiederm.org>
Date:	Thu, 23 Jun 2016 15:56:46 -0500
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Quinn Tran <quinn.tran@...gic.com>,
	Johannes Thumshirn <jthumshirn@...e.de>,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Josh Boyer <jwboyer@...oraproject.org>,
	Thorsten Leemhuis <regressions@...mhuis.info>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-scsi <linux-scsi@...r.kernel.org>
Subject: Re: Reported regressions for 4.7 as of Sunday, 2016-06-19

Linus Torvalds <torvalds@...ux-foundation.org> writes:

> On Thu, Jun 23, 2016 at 9:13 AM, Quinn Tran <quinn.tran@...gic.com> wrote:
>>
>>
>> QT: setting up the interrupt vector does not mean the interrupt starts firing immediately.
>
> Actually, it very much can mean that. If the interrupt can possibly be
> shared, there is a very real possibility of it fiding immediately.
>
> Now, with MSI(-X) I guess that isn't a worry, so I suspect your patch
> that handles just the legacy INTx case anyway is sufficient, but in
> general I would like people to always act as if interrupts can happen
> immediately after request_irq().
>
> We have had *tons* of situations where the firmware left a device
> active, for example. Or where some random interrupt controller ended
> up having stale interrupts pending, even.
>
> So in general, it's just good practice to say "spurious interrupts can
> and do happen" - the shared irq case is the most obvious case, but
> there have been other sources of unexpected spurious interrupts
> firing.

One case that occassionally bytes even for MSI-X is the case of kexec on
panic where the hardware was not shut down before the kernel starts, and
the start of the kernel masks the irq.  Then when the driver initializes
and calls request_irq it is possible for an irq to be pending as soon as
the MSI-X irq is actually enabled to the hardware.

And there is always CONFIG_IRQ_DEBUG which always acts like an interrupt
happens right when after request_irq finishes.

Eric