All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Rosen Penev <rosenp@gmail.com>
Cc: Jacob Keller <jacob.e.keller@intel.com>,
	netdev@vger.kernel.org, Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>, Jeff Garzik <jeff@garzik.org>,
	Roland Dreier <rdreier@cisco.com>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net] net: ibm: emac: mal: fix potential system hang in mal_remove()
Date: Mon, 8 Jun 2026 17:36:38 -0700	[thread overview]
Message-ID: <20260608173638.74da73fe@kernel.org> (raw)
In-Reply-To: <CAKxU2N8oh03r2-zJhbOXF0Qqx7RzNSX=zq+i6Ld1c9YXJqDfKQ@mail.gmail.com>

On Thu, 4 Jun 2026 16:03:43 -0700 Rosen Penev wrote:
> > > -     if (!list_empty(&mal->list))
> > > +     if (!list_empty(&mal->list)) {
> > > +             napi_disable(&mal->napi);
> > >               /* This is *very* bad */
> > >               WARN(1, KERN_EMERG
> > >                      "mal%d: commac list is not empty on remove!\n",
> > >                      mal->index);  
> >
> > This one doesn't make sense to me. The list_empty check does a WARN()
> > indicating that this is not supposed to happen.
> >
> > This implies that list_empty should be true, otherwise we'd see a WARN
> > every time mal_remove is called.
> >
> > But in that case, we'd have been calling napi_disable incorrectly in
> > most cases where it was previously unsafe according to your claim.
> >
> > At best, this list_empty check is the wrong way to tell if the napi is
> > disabled, at worst, this whole change is pointless.  
> I asked the AI. It doesn't agree:

FTR I agree with Jake, the patch seems to indicate bigger structural
issues. Then again I don't want to encourage the stream of patches
to this driver so let me just apply this..

  reply	other threads:[~2026-06-09  0:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-03 23:08 [PATCH net] net: ibm: emac: mal: fix potential system hang in mal_remove() Rosen Penev
2026-06-04 18:52 ` Jacob Keller
2026-06-04 23:03   ` Rosen Penev
2026-06-09  0:36     ` Jakub Kicinski [this message]
2026-06-09  1:13       ` Jacob Keller
2026-06-09  1:13       ` Jacob Keller
2026-06-09  1:51         ` Rosen Penev
2026-06-09  0:40 ` patchwork-bot+netdevbpf

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=20260608173638.74da73fe@kernel.org \
    --to=kuba@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=jacob.e.keller@intel.com \
    --cc=jeff@garzik.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rdreier@cisco.com \
    --cc=rosenp@gmail.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.