From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F118CC433FE for ; Mon, 7 Dec 2020 19:59:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C1DE021D7F for ; Mon, 7 Dec 2020 19:59:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726874AbgLGT72 (ORCPT ); Mon, 7 Dec 2020 14:59:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35228 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725808AbgLGT71 (ORCPT ); Mon, 7 Dec 2020 14:59:27 -0500 Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [IPv6:2607:fcd0:100:8a00::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9E2D7C061749; Mon, 7 Dec 2020 11:58:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id 9E3691280221; Mon, 7 Dec 2020 11:58:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1607371125; bh=k/Dd2cYrK28lrZ2qpukQjOHheuWRRxKEAwCopHSG05E=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=oWAhxkXjg6qRXeEQo0LSHh69muuIN//JVI5b76pfiGzTOFOSiSeerHyhJYkd13aLz vV+mTEvXUo0Xm5JPQSxmzIg7QGeHJurbI1samrBMs2MT85XklMBErr+1vtwRlr9RbH Mr1O+RF9DmddGa9u2oJf1yAmPZX/oNkCTcDqY9fQ= Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1wle3Jxpi4d; Mon, 7 Dec 2020 11:58:45 -0800 (PST) Received: from jarvis.int.hansenpartnership.com (unknown [IPv6:2601:600:8280:66d1::527]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id E939C128021B; Mon, 7 Dec 2020 11:58:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1607371125; bh=k/Dd2cYrK28lrZ2qpukQjOHheuWRRxKEAwCopHSG05E=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=oWAhxkXjg6qRXeEQo0LSHh69muuIN//JVI5b76pfiGzTOFOSiSeerHyhJYkd13aLz vV+mTEvXUo0Xm5JPQSxmzIg7QGeHJurbI1samrBMs2MT85XklMBErr+1vtwRlr9RbH Mr1O+RF9DmddGa9u2oJf1yAmPZX/oNkCTcDqY9fQ= Message-ID: Subject: Re: [PATCH v3 3/4] tpm_tis: Disable interrupts if interrupt storm detected From: James Bottomley To: Jason Gunthorpe , Thomas Gleixner Cc: Jerry Snitselaar , linux-kernel@vger.kernel.org, linux-integrity@vger.kernel.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, Jarkko Sakkinen , Peter Huewe , Matthew Garrett , Hans de Goede Date: Mon, 07 Dec 2020 11:58:44 -0800 In-Reply-To: <20201207192803.GH5487@ziepe.ca> References: <20201205014340.148235-1-jsnitsel@redhat.com> <20201205014340.148235-4-jsnitsel@redhat.com> <87tusy7n3b.fsf@nanos.tec.linutronix.de> <20201207192803.GH5487@ziepe.ca> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.4 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2020-12-07 at 15:28 -0400, Jason Gunthorpe wrote: > On Sun, Dec 06, 2020 at 08:26:16PM +0100, Thomas Gleixner wrote: > > Just as a side note. I was looking at tpm_tis_probe_irq_single() > > and that function is leaking the interrupt request if any of the > > checks afterwards fails, except for the final interrupt probe check > > which does a cleanup. That means on fail before that the interrupt > > handler stays requested up to the point where the module is > > removed. If that's a shared interrupt and some other device is > > active on the same line, then each interrupt from that device will > > call into the TPM code. Something like the below is needed. > > > > Also the X86 autoprobe mechanism is interesting: > > > > if (IS_ENABLED(CONFIG_X86)) > > for (i = 3; i <= 15; i++) > > if (!tpm_tis_probe_irq_single(chip, intmask, 0, > > i)) > > return; > > > > The third argument is 'flags' which is handed to request_irq(). So > > that won't ever be able to probe a shared interrupt. But if an > > interrupt number > 0 is handed to tpm_tis_core_init() the interrupt > > is requested with IRQF_SHARED. Same issue when the chip has an > > interrupt number in the register. It's also requested exclusive > > which is pretty likely to fail on ancient x86 machines. > > It is very likely none of this works any more, it has been repeatedly > reworked over the years and just left behind out of fear someone > needs it. I've thought it should be deleted for a while now. > > I suppose the original logic was to try and probe without SHARED > because a probe would need exclusive access to the interrupt to tell > if the TPM was actually the source, not some other device. > > It is all very old and very out of step with current thinking, IMHO. > I skeptical that TPM interrupts were ever valuable enough to deserve > this in the first place. For what it's worth, I agree. Trying to probe all 15 ISA interrupts is last millennium thinking we should completely avoid. If it's not described in ACPI then you don't get an interrupt full stop. James From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 315D9C4361B for ; Mon, 7 Dec 2020 19:58:51 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BC11021D7F for ; Mon, 7 Dec 2020 19:58:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BC11021D7F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=HansenPartnership.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 798C16E8B0; Mon, 7 Dec 2020 19:58:48 +0000 (UTC) Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [IPv6:2607:fcd0:100:8a00::2]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2A0106E8AC; Mon, 7 Dec 2020 19:58:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id 9E3691280221; Mon, 7 Dec 2020 11:58:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1607371125; bh=k/Dd2cYrK28lrZ2qpukQjOHheuWRRxKEAwCopHSG05E=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=oWAhxkXjg6qRXeEQo0LSHh69muuIN//JVI5b76pfiGzTOFOSiSeerHyhJYkd13aLz vV+mTEvXUo0Xm5JPQSxmzIg7QGeHJurbI1samrBMs2MT85XklMBErr+1vtwRlr9RbH Mr1O+RF9DmddGa9u2oJf1yAmPZX/oNkCTcDqY9fQ= Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1wle3Jxpi4d; Mon, 7 Dec 2020 11:58:45 -0800 (PST) Received: from jarvis.int.hansenpartnership.com (unknown [IPv6:2601:600:8280:66d1::527]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id E939C128021B; Mon, 7 Dec 2020 11:58:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1607371125; bh=k/Dd2cYrK28lrZ2qpukQjOHheuWRRxKEAwCopHSG05E=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=oWAhxkXjg6qRXeEQo0LSHh69muuIN//JVI5b76pfiGzTOFOSiSeerHyhJYkd13aLz vV+mTEvXUo0Xm5JPQSxmzIg7QGeHJurbI1samrBMs2MT85XklMBErr+1vtwRlr9RbH Mr1O+RF9DmddGa9u2oJf1yAmPZX/oNkCTcDqY9fQ= Message-ID: Subject: Re: [PATCH v3 3/4] tpm_tis: Disable interrupts if interrupt storm detected From: James Bottomley To: Jason Gunthorpe , Thomas Gleixner Date: Mon, 07 Dec 2020 11:58:44 -0800 In-Reply-To: <20201207192803.GH5487@ziepe.ca> References: <20201205014340.148235-1-jsnitsel@redhat.com> <20201205014340.148235-4-jsnitsel@redhat.com> <87tusy7n3b.fsf@nanos.tec.linutronix.de> <20201207192803.GH5487@ziepe.ca> User-Agent: Evolution 3.34.4 MIME-Version: 1.0 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: intel-gfx@lists.freedesktop.org, Jerry Snitselaar , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Hans de Goede , Jarkko Sakkinen , Matthew Garrett , linux-integrity@vger.kernel.org, Peter Huewe Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Mon, 2020-12-07 at 15:28 -0400, Jason Gunthorpe wrote: > On Sun, Dec 06, 2020 at 08:26:16PM +0100, Thomas Gleixner wrote: > > Just as a side note. I was looking at tpm_tis_probe_irq_single() > > and that function is leaking the interrupt request if any of the > > checks afterwards fails, except for the final interrupt probe check > > which does a cleanup. That means on fail before that the interrupt > > handler stays requested up to the point where the module is > > removed. If that's a shared interrupt and some other device is > > active on the same line, then each interrupt from that device will > > call into the TPM code. Something like the below is needed. > > > > Also the X86 autoprobe mechanism is interesting: > > > > if (IS_ENABLED(CONFIG_X86)) > > for (i = 3; i <= 15; i++) > > if (!tpm_tis_probe_irq_single(chip, intmask, 0, > > i)) > > return; > > > > The third argument is 'flags' which is handed to request_irq(). So > > that won't ever be able to probe a shared interrupt. But if an > > interrupt number > 0 is handed to tpm_tis_core_init() the interrupt > > is requested with IRQF_SHARED. Same issue when the chip has an > > interrupt number in the register. It's also requested exclusive > > which is pretty likely to fail on ancient x86 machines. > > It is very likely none of this works any more, it has been repeatedly > reworked over the years and just left behind out of fear someone > needs it. I've thought it should be deleted for a while now. > > I suppose the original logic was to try and probe without SHARED > because a probe would need exclusive access to the interrupt to tell > if the TPM was actually the source, not some other device. > > It is all very old and very out of step with current thinking, IMHO. > I skeptical that TPM interrupts were ever valuable enough to deserve > this in the first place. For what it's worth, I agree. Trying to probe all 15 ISA interrupts is last millennium thinking we should completely avoid. If it's not described in ACPI then you don't get an interrupt full stop. James _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A16FAC4361B for ; Mon, 7 Dec 2020 19:58:48 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3F0AA21D7F for ; Mon, 7 Dec 2020 19:58:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3F0AA21D7F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=HansenPartnership.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id DB1A26E8AC; Mon, 7 Dec 2020 19:58:47 +0000 (UTC) Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [IPv6:2607:fcd0:100:8a00::2]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2A0106E8AC; Mon, 7 Dec 2020 19:58:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id 9E3691280221; Mon, 7 Dec 2020 11:58:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1607371125; bh=k/Dd2cYrK28lrZ2qpukQjOHheuWRRxKEAwCopHSG05E=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=oWAhxkXjg6qRXeEQo0LSHh69muuIN//JVI5b76pfiGzTOFOSiSeerHyhJYkd13aLz vV+mTEvXUo0Xm5JPQSxmzIg7QGeHJurbI1samrBMs2MT85XklMBErr+1vtwRlr9RbH Mr1O+RF9DmddGa9u2oJf1yAmPZX/oNkCTcDqY9fQ= Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1wle3Jxpi4d; Mon, 7 Dec 2020 11:58:45 -0800 (PST) Received: from jarvis.int.hansenpartnership.com (unknown [IPv6:2601:600:8280:66d1::527]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id E939C128021B; Mon, 7 Dec 2020 11:58:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1607371125; bh=k/Dd2cYrK28lrZ2qpukQjOHheuWRRxKEAwCopHSG05E=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=oWAhxkXjg6qRXeEQo0LSHh69muuIN//JVI5b76pfiGzTOFOSiSeerHyhJYkd13aLz vV+mTEvXUo0Xm5JPQSxmzIg7QGeHJurbI1samrBMs2MT85XklMBErr+1vtwRlr9RbH Mr1O+RF9DmddGa9u2oJf1yAmPZX/oNkCTcDqY9fQ= Message-ID: From: James Bottomley To: Jason Gunthorpe , Thomas Gleixner Date: Mon, 07 Dec 2020 11:58:44 -0800 In-Reply-To: <20201207192803.GH5487@ziepe.ca> References: <20201205014340.148235-1-jsnitsel@redhat.com> <20201205014340.148235-4-jsnitsel@redhat.com> <87tusy7n3b.fsf@nanos.tec.linutronix.de> <20201207192803.GH5487@ziepe.ca> User-Agent: Evolution 3.34.4 MIME-Version: 1.0 Subject: Re: [Intel-gfx] [PATCH v3 3/4] tpm_tis: Disable interrupts if interrupt storm detected X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: intel-gfx@lists.freedesktop.org, Jerry Snitselaar , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Jarkko Sakkinen , Matthew Garrett , linux-integrity@vger.kernel.org, Peter Huewe Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Mon, 2020-12-07 at 15:28 -0400, Jason Gunthorpe wrote: > On Sun, Dec 06, 2020 at 08:26:16PM +0100, Thomas Gleixner wrote: > > Just as a side note. I was looking at tpm_tis_probe_irq_single() > > and that function is leaking the interrupt request if any of the > > checks afterwards fails, except for the final interrupt probe check > > which does a cleanup. That means on fail before that the interrupt > > handler stays requested up to the point where the module is > > removed. If that's a shared interrupt and some other device is > > active on the same line, then each interrupt from that device will > > call into the TPM code. Something like the below is needed. > > > > Also the X86 autoprobe mechanism is interesting: > > > > if (IS_ENABLED(CONFIG_X86)) > > for (i = 3; i <= 15; i++) > > if (!tpm_tis_probe_irq_single(chip, intmask, 0, > > i)) > > return; > > > > The third argument is 'flags' which is handed to request_irq(). So > > that won't ever be able to probe a shared interrupt. But if an > > interrupt number > 0 is handed to tpm_tis_core_init() the interrupt > > is requested with IRQF_SHARED. Same issue when the chip has an > > interrupt number in the register. It's also requested exclusive > > which is pretty likely to fail on ancient x86 machines. > > It is very likely none of this works any more, it has been repeatedly > reworked over the years and just left behind out of fear someone > needs it. I've thought it should be deleted for a while now. > > I suppose the original logic was to try and probe without SHARED > because a probe would need exclusive access to the interrupt to tell > if the TPM was actually the source, not some other device. > > It is all very old and very out of step with current thinking, IMHO. > I skeptical that TPM interrupts were ever valuable enough to deserve > this in the first place. For what it's worth, I agree. Trying to probe all 15 ISA interrupts is last millennium thinking we should completely avoid. If it's not described in ACPI then you don't get an interrupt full stop. James _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx