[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aRuOzelPTiwaoNop@horms.kernel.org>
Date: Mon, 17 Nov 2025 21:08:29 +0000
From: Simon Horman <horms@...nel.org>
To: Parvathi Pudi <parvathi@...thit.com>
Cc: andrew+netdev@...n.ch, davem@...emloft.net, edumazet@...gle.com,
kuba@...nel.org, pabeni@...hat.com, danishanwar@...com,
rogerq@...nel.org, pmohan@...thit.com, basharath@...thit.com,
afd@...com, linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, alok.a.tiwari@...cle.com,
pratheesh@...com, j-rameshbabu@...com, vigneshr@...com,
praneeth@...com, srk@...com, rogerq@...com, krishna@...thit.com,
mohan@...thit.com
Subject: Re: [PATCH net-next v5 2/3] net: ti: icssm-prueth: Adds switchdev
support for icssm_prueth driver
On Thu, Nov 13, 2025 at 03:40:22PM +0530, Parvathi Pudi wrote:
...
> @@ -222,12 +229,14 @@ struct prueth_emac {
> const char *phy_id;
> u32 msg_enable;
> u8 mac_addr[6];
> + unsigned char mc_filter_mask[ETH_ALEN]; /* for multicast filtering */
> phy_interface_t phy_if;
>
> /* spin lock used to protect
> * during link configuration
> */
> spinlock_t lock;
> + spinlock_t addr_lock; /* serialize access to VLAN/MC filter table */
addr_lock does not appear to be initialised anywhere.
...
> +static int icssm_prueth_switchdev_obj_del(struct net_device *ndev,
> + const void *ctx,
> + const struct switchdev_obj *obj)
> +{
> + struct switchdev_obj_port_mdb *mdb = SWITCHDEV_OBJ_PORT_MDB(obj);
> + struct prueth_emac *emac = netdev_priv(ndev);
> + struct prueth *prueth = emac->prueth;
> + struct netdev_hw_addr *ha;
> + u8 hash, tmp_hash;
> + int ret = 0;
> +
> + switch (obj->id) {
> + case SWITCHDEV_OBJ_ID_HOST_MDB:
> + dev_dbg(prueth->dev, "MDB del: %s: vid %u:%pM port: %x\n",
> + ndev->name, mdb->vid, mdb->addr, emac->port_id);
> + hash = icssm_emac_get_mc_hash(mdb->addr, emac->mc_filter_mask);
> + netdev_for_each_mc_addr(ha, prueth->hw_bridge_dev) {
Is there anything stopping this event from occurring when
the port is not the lower device of a bridge - before being added
or after being removed?
If not, then passing prueth->hw_bridge_dev to netdev_for_each_mc_addr()
will result in a null pointer dereference.
...
Powered by blists - more mailing lists