From patchwork Tue Sep 29 10:57:44 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 290873 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=-10.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable 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 73918C4727C for ; Tue, 29 Sep 2020 12:20:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 326F62075A for ; Tue, 29 Sep 2020 12:20:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1601382006; bh=dPoeP0hDVsWCT7c1Rh/kT0y9ZWG2OOghemE7kf3aP9Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=sQYL0TBQt2jabnUCaOsJeqPYLUYeo8buTw4swcKt1XpBxjn2uGibSJH2UGhI6iw/s fTRamMwmACQ1HgbBIBQXDGNmyOeNuRGtCDvw/239AeBSYPXSwM6OYJ8svT8Gei5rqm yZOHNXdyBeie99aHn0I/n8Xtgdce3u8OtexUoVn0= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732341AbgI2MTz (ORCPT ); Tue, 29 Sep 2020 08:19:55 -0400 Received: from mail.kernel.org ([198.145.29.99]:53442 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729875AbgI2Lfg (ORCPT ); Tue, 29 Sep 2020 07:35:36 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 148AF2376F; Tue, 29 Sep 2020 11:21:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1601378520; bh=dPoeP0hDVsWCT7c1Rh/kT0y9ZWG2OOghemE7kf3aP9Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=B9oe9bKPM6OqNUcYQJYQ9erGrRNCaRlG7WAxuO9CrWfEZb6Dhs0JBknImcm5JQhf2 cRgTCF4mgaiauyto7PublBlZ0pXkKnU1oOKyiQBL6+N8z5aFr65ra00uXwff76Gnl4 D/MbmT+RIB+AD6e0aLWfKNi0xGzN/2wtGdaXhd/g= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, p_c_chan@hotmail.com, ecm4@mail.com, perdigao1@yahoo.com, matzes@users.sourceforge.net, rvelascog@gmail.com, Thomas Gleixner Subject: [PATCH 4.19 013/245] x86/ioapic: Unbreak check_timer() Date: Tue, 29 Sep 2020 12:57:44 +0200 Message-Id: <20200929105947.638440157@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200929105946.978650816@linuxfoundation.org> References: <20200929105946.978650816@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Thomas Gleixner commit 86a82ae0b5095ea24c55898a3f025791e7958b21 upstream. Several people reported in the kernel bugzilla that between v4.12 and v4.13 the magic which works around broken hardware and BIOSes to find the proper timer interrupt delivery mode stopped working for some older affected platforms which need to fall back to ExtINT delivery mode. The reason is that the core code changed to keep track of the masked and disabled state of an interrupt line more accurately to avoid the expensive hardware operations. That broke an assumption in i8259_make_irq() which invokes disable_irq_nosync(); irq_set_chip_and_handler(); enable_irq(); Up to v4.12 this worked because enable_irq() unconditionally unmasked the interrupt line, but after the state tracking improvements this is not longer the case because the IO/APIC uses lazy disabling. So the line state is unmasked which means that enable_irq() does not call into the new irq chip to unmask it. In principle this is a shortcoming of the core code, but it's more than unclear whether the core code should try to reset state. At least this cannot be done unconditionally as that would break other existing use cases where the chip type is changed, e.g. when changing the trigger type, but the callers expect the state to be preserved. As the way how check_timer() is switching the delivery modes is truly unique, the obvious fix is to simply unmask the i8259 manually after changing the mode to ExtINT delivery and switching the irq chip to the legacy PIC. Note, that the fixes tag is not really precise, but identifies the commit which broke the assumptions in the IO/APIC and i8259 code and that's the kernel version to which this needs to be backported. Fixes: bf22ff45bed6 ("genirq: Avoid unnecessary low level irq function calls") Reported-by: p_c_chan@hotmail.com Reported-by: ecm4@mail.com Reported-by: perdigao1@yahoo.com Reported-by: matzes@users.sourceforge.net Reported-by: rvelascog@gmail.com Signed-off-by: Thomas Gleixner Tested-by: p_c_chan@hotmail.com Tested-by: matzes@users.sourceforge.net Cc: stable@vger.kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=197769 Signed-off-by: Greg Kroah-Hartman --- arch/x86/kernel/apic/io_apic.c | 1 + 1 file changed, 1 insertion(+) --- a/arch/x86/kernel/apic/io_apic.c +++ b/arch/x86/kernel/apic/io_apic.c @@ -2250,6 +2250,7 @@ static inline void __init check_timer(vo legacy_pic->init(0); legacy_pic->make_irq(0); apic_write(APIC_LVT0, APIC_DM_EXTINT); + legacy_pic->unmask(0); unlock_ExtINT_logic();