All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxime Chevallier <maxime.chevallier@bootlin.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Tobias Waldekranz <tobias@waldekranz.com>,
	davem@davemloft.net, kuba@kernel.org, marcin.s.wojtas@gmail.com,
	linux@armlinux.org.uk, edumazet@google.com, pabeni@redhat.com,
	ezequiel.garcia@free-electrons.com, netdev@vger.kernel.org
Subject: Re: [PATCH net] net: mvpp2: Prevent parser TCAM memory corruption
Date: Thu, 20 Mar 2025 18:27:38 +0100	[thread overview]
Message-ID: <20250320182738.67108ea4@fedora.home> (raw)
In-Reply-To: <16143c70-de5a-4f30-ad29-eae33d2e5b0b@lunn.ch>

On Thu, 20 Mar 2025 14:14:16 +0100
Andrew Lunn <andrew@lunn.ch> wrote:

> > We still need to disable bottom halves though, right?  Because otherwise
> > we could reach mvpp2_set_rx_mode() from net-rx by processing an IGMP/MLD
> > frame, for example.  
> 
> Ah, that answers the question i was asking myself. Why does RTNL not
> cover this...
> 
> Maybe the design was that RTNL is supposed to protect this, but things
> are happening outside of it? It would of helped if the code had put in
> some ASSERT_RTNL() calls to both indicate this was the idea, and to
> find cases where it was not actually true.

I think this was definitely missed. I added some of it back then, and I
certainly didn't consider non-rtnl protected paths. an ASSERT_RTNL
would've been a good idea indeed :(

With netdev_lock closing in, I think Tobias's approach is better. We
can't rely on a netdev_lock to protect the parser as it's shared
accross multiple netdevs.

Maxime

      parent reply	other threads:[~2025-03-20 17:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-20  9:17 [PATCH net] net: mvpp2: Prevent parser TCAM memory corruption Tobias Waldekranz
2025-03-20  9:57 ` Maxime Chevallier
2025-03-20 10:47   ` Tobias Waldekranz
2025-03-20 13:14     ` Andrew Lunn
2025-03-20 13:38       ` Tobias Waldekranz
2025-03-20 17:27       ` Maxime Chevallier [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=20250320182738.67108ea4@fedora.home \
    --to=maxime.chevallier@bootlin.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=ezequiel.garcia@free-electrons.com \
    --cc=kuba@kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=marcin.s.wojtas@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=tobias@waldekranz.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.