All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
To: Alexander Lobakin <alexandr.lobakin@intel.com>
Cc: "David S. Miller" <davem@davemloft.net>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Jesse Brandeburg" <jesse.brandeburg@intel.com>,
	"Maciej Fijalkowski" <maciej.fijalkowski@intel.com>,
	"Michal Swiatkowski" <michal.swiatkowski@intel.com>,
	"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
	"Antoine Tenart" <atenart@kernel.org>,
	"Eric Dumazet" <edumazet@google.com>,
	"Wei Wang" <weiwan@google.com>, "Björn Töpel" <bjorn@kernel.org>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 net] net: fix premature exit from NAPI state polling in napi_disable()
Date: Thu, 11 Nov 2021 12:50:44 -0800	[thread overview]
Message-ID: <YY2CJL+dQ3fgK82Y@us.ibm.com> (raw)
In-Reply-To: <20211110195605.1304-1-alexandr.lobakin@intel.com>

Alexander Lobakin [alexandr.lobakin@intel.com] wrote:
> Commit 719c57197010 ("net: make napi_disable() symmetric with
> enable") accidentally introduced a bug sometimes leading to a kernel
> BUG when bringing an iface up/down under heavy traffic load.
> 
> Prior to this commit, napi_disable() was polling n->state until
> none of (NAPIF_STATE_SCHED | NAPIF_STATE_NPSVC) is set and then
> always flip them. Now there's a possibility to get away with the
> NAPIF_STATE_SCHE unset as 'continue' drops us to the cmpxchg()
> call with an unitialized variable, rather than straight to
> another round of the state check.

Thanks. Tested v1 and it fixes the problem discussed at:

https://lore.kernel.org/netdev/dc6902364a8f91c4292fe1c5e01b24be@imap.linux.ibm.com/

Sukadev

      parent reply	other threads:[~2021-11-11 20:51 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-10 19:56 [PATCH v2 net] net: fix premature exit from NAPI state polling in napi_disable() Alexander Lobakin
2021-11-10 20:11 ` Eric Dumazet
2021-11-11  2:00 ` patchwork-bot+netdevbpf
2021-11-11 20:50 ` Sukadev Bhattiprolu [this message]

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=YY2CJL+dQ3fgK82Y@us.ibm.com \
    --to=sukadev@linux.ibm.com \
    --cc=alexandr.lobakin@intel.com \
    --cc=atenart@kernel.org \
    --cc=bjorn@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maciej.fijalkowski@intel.com \
    --cc=michal.swiatkowski@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=weiwan@google.com \
    --cc=xuanzhuo@linux.alibaba.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.