Netdev List
 help / color / mirror / Atom feed
From: Romain Gantois <romain.gantois@bootlin.com>
To: Cathy Cai <cathy.cai@unisoc.com>
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
Date: Sun, 31 Mar 2024 10:35:32 +0200 (CEST)	[thread overview]
Message-ID: <d1da7fdb-10f6-7f69-4820-520469c0193c@bootlin.com> (raw)
In-Reply-To: <20240327110142.159851-1-cathy.cai@unisoc.com>

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

  reply	other threads:[~2024-03-31  8:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-27 11:01 [RFC PATCH] net: stmmac: Fix the problem about interrupt storm Cathy Cai
2024-03-31  8:35 ` Romain Gantois [this message]
2024-04-03  2:01   ` cathy cai
     [not found] <CAKKbWA7e0TmU4z4O8tHfwE=dvqPFaZbSPjxR-==fQSsNq6ELCQ@mail.gmail.com>
2024-11-03 19:00 ` Avi Fishman
2024-11-12 15:12   ` Romain Gantois

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d1da7fdb-10f6-7f69-4820-520469c0193c@bootlin.com \
    --to=romain.gantois@bootlin.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=cathy.cai@unisoc.com \
    --cc=cathycai0714@gmail.com \
    --cc=cixi.geng1@unisoc.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=joabreu@synopsys.com \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=wade.shu@unisoc.com \
    --cc=xuewen.yan94@gmail.com \
    --cc=zhiguo.niu@unisoc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox