From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751762AbcFWVJG (ORCPT ); Thu, 23 Jun 2016 17:09:06 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:34789 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750919AbcFWVJE (ORCPT ); Thu, 23 Jun 2016 17:09:04 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Linus Torvalds Cc: Quinn Tran , Johannes Thumshirn , "Martin K. Petersen" , Josh Boyer , Thorsten Leemhuis , linux-kernel , linux-scsi References: <7cc588b7-f1cf-62a8-e45b-ec7d863ba51e@leemhuis.info> <20160622115131.4bh7sh6uhmmhw44v@c203.arch.suse.de> <20160623072240.gt4wdjok27venxgr@c203.arch.suse.de> <1957A3C6-C4C2-4E7A-84E1-31A48F1469CD@qlogic.com> Date: Thu, 23 Jun 2016 15:56:46 -0500 In-Reply-To: (Linus Torvalds's message of "Thu, 23 Jun 2016 09:35:42 -0700") Message-ID: <874m8jd3ox.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1bGBrt-0003cY-EV;;;mid=<874m8jd3ox.fsf@x220.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=67.3.204.119;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+LK8Eiyrm4zRzWThuYuZeVGVYNS+REtiI= X-SA-Exim-Connect-IP: 67.3.204.119 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa07 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Linus Torvalds X-Spam-Relay-Country: X-Spam-Timing: total 1360 ms - load_scoreonly_sql: 0.11 (0.0%), signal_user_changed: 4.7 (0.3%), b_tie_ro: 3.6 (0.3%), parse: 1.00 (0.1%), extract_message_metadata: 17 (1.3%), get_uri_detail_list: 1.88 (0.1%), tests_pri_-1000: 6 (0.4%), tests_pri_-950: 1.19 (0.1%), tests_pri_-900: 0.99 (0.1%), tests_pri_-400: 22 (1.6%), check_bayes: 21 (1.5%), b_tokenize: 6 (0.4%), b_tok_get_all: 7 (0.5%), b_comp_prob: 2.1 (0.2%), b_tok_touch_all: 3.5 (0.3%), b_finish: 0.77 (0.1%), tests_pri_0: 1298 (95.5%), check_dkim_signature: 0.49 (0.0%), check_dkim_adsp: 3.0 (0.2%), tests_pri_500: 6 (0.4%), rewrite_mail: 0.00 (0.0%) Subject: Re: Reported regressions for 4.7 as of Sunday, 2016-06-19 X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Linus Torvalds writes: > On Thu, Jun 23, 2016 at 9:13 AM, Quinn Tran 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