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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8A66DCD1288 for ; Sun, 31 Mar 2024 08:35:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:Message-ID: In-Reply-To:Subject:cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=oA3FboyRM5BZ93b2TrNTaqLwwStmaBwOQ382lOCT0R8=; b=Hjj7h9MTZsmYjC 6xbL9cKxDSTcXVZaRmlNXBz5yurCPJf4zsSYxkWANh9I++CScquw5QVXQwAkaBqTePXIe5BEFqU2N cGjAvIvCfu/k8zfoRKUUP3maWDR0K347CfxHYTw1Fx4XsXA3/LUs8QxDXf/SH+fwyNfHs9yKH0QTY eYmPMG6ipdf8LgOiHQCx7PVV/C7C/jToXPBsWhowG07pEVIZa5hYMaX7goamZEThln+K+XIyr2iET 1XaoorapPBHi0PbRZEKScNRooyhVZ6M3VLl3N4xajE2Gew3U9cES/tR02mRR40h0qgt5EH4vlfYkG cQ0nwMBS0sR4NgkHfP8A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rqqek-000000052BV-1hGL; Sun, 31 Mar 2024 08:35:10 +0000 Received: from relay9-d.mail.gandi.net ([2001:4b98:dc4:8::229]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rqqeh-000000052A1-0fyl for linux-arm-kernel@lists.infradead.org; Sun, 31 Mar 2024 08:35:09 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id CDE87FF802; Sun, 31 Mar 2024 08:34:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1711874099; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bkZCTZa2SatyGqLS+NTU0GDbJQ+zI3N+D0QKibBZfFo=; b=QDlQrJbB2rfbs4C1sU9IDLdaWQ07Bwzdr9P4B5RCC+MWQIfcjVBaFGtDuBHlw0Dnmdc8iB qZFFdLSLc8dlSfJR9Xwkb5vLq4l37Lu4sDOycMhDCjE/ANGx8jXtnirdOd60VPGdJP1i9y KWZY7shJ0cUKpD1Hc1FpmWk5JMXFawMxeIhWPE/3wIVCQ8AVym5wGmRiVfMZwwwkwVU8z4 ftsot8rUb4bMoRVoYTuGKJkASlmJCri07zpmxPFP3h1NpijrAM2k4q+HLh2aXeWYC4vsH5 vGJf+6vwi54D5xqpg6hc2+CeFSc3dLitXSb/uQkZIlPKbpuoTsFCaV0Z93GWfg== Date: Sun, 31 Mar 2024 10:35:32 +0200 (CEST) From: Romain Gantois To: Cathy Cai cc: cathycai0714@gmail.com, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, mcoquelin.stm32@gmail.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, xuewen.yan94@gmail.com, cixi.geng1@unisoc.com, wade.shu@unisoc.com, zhiguo.niu@unisoc.com, alexandre.torgue@foss.st.com, joabreu@synopsys.com, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org Subject: Re: [RFC PATCH] net: stmmac: Fix the problem about interrupt storm In-Reply-To: <20240327110142.159851-1-cathy.cai@unisoc.com> Message-ID: References: <20240327110142.159851-1-cathy.cai@unisoc.com> MIME-Version: 1.0 X-GND-Sasl: romain.gantois@bootlin.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240331_013507_579409_541B881A X-CRM114-Status: GOOD ( 12.84 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hello Cathy, On Wed, 27 Mar 2024, Cathy Cai wrote: > Tx queue time out then reset adapter. When reset the adapter, stmmac driver > sets the state to STMMAC_DOWN and calls dev_close() function. If an interrupt > is triggered at this instant after setting state to STMMAC_DOWN, before the > dev_close() call. > ... > - set_bit(STMMAC_DOWN, &priv->state); > dev_close(priv->dev); > + set_bit(STMMAC_DOWN, &priv->state); > dev_open(priv->dev, NULL); > clear_bit(STMMAC_DOWN, &priv->state); > clear_bit(STMMAC_RESETING, &priv->state); If this IRQ issue can happen whenever STMMAC_DOWN is set while the net device is open, then it could also happen between the dev_open() and clear_bit(STMMAC_DOWN) calls right? So you'd have to clear STMMAC_DOWN before calling dev_open() but then I don't see the usefulness of setting STMMAC_DOWN and clearing it immediately. Maybe closing and opening the net device should be enough? Moreover, it seems strange to me that stmmac_interrupt() unconditionnally ignores interrupts when the driver is in STMMAC_DOWN state. This seems like dangerous behaviour, since it could cause IRQ storm issues whenever something in the driver sets this state. I'm not too familiar with the interrupt handling in this driver, but maybe stmmac_interrupt() could clear interrupts unconditionnally in the STMMAC_DOWN state? Best Regards, -- Romain Gantois, Bootlin Embedded Linux and Kernel engineering https://bootlin.com _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel