mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Michael Dege <michael.dege@renesas.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
	"andrew+netdev@lunn.ch" <andrew+netdev@lunn.ch>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"edumazet@google.com" <edumazet@google.com>,
	"pabeni@redhat.com" <pabeni@redhat.com>,
	niklas.soderlund <niklas.soderlund@ragnatech.se>,
	"paul@pbarker.dev" <paul@pbarker.dev>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-renesas-soc@vger.kernel.org"
	<linux-renesas-soc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH net-next v4 05/13] net: renesas: rswitch: add exception path for packets with unknown dst MAC
Date: Fri, 22 May 2026 12:07:15 +0000	[thread overview]
Message-ID: <TY4PR01MB142826C4D8BFD45FB4D3D6EDC820F2@TY4PR01MB14282.jpnprd01.prod.outlook.com> (raw)
In-Reply-To: <20260513013551.1408389-1-kuba@kernel.org>

Hello Jakub,

Thank you for your comments.

> -----Original Message-----
> From: Jakub Kicinski <kuba@kernel.org>
> Sent: Wednesday, May 13, 2026 3:36 AM
> To: Michael Dege <michael.dege@renesas.com>
> Cc: Jakub Kicinski <kuba@kernel.org>; Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>;
> andrew+netdev@lunn.ch; davem@davemloft.net; edumazet@google.com; pabeni@redhat.com; niklas.soderlund
> <niklas.soderlund@ragnatech.se>; paul@pbarker.dev; netdev@vger.kernel.org; linux-renesas-
> soc@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH net-next v4 05/13] net: renesas: rswitch: add exception path for packets with
> unknown dst MAC
> 
> This is an AI-generated review of your patch. The human sending this email has considered the AI
> review valid, or at least plausible.
> ---
> net: renesas: rswitch: add exception path for packets with unknown dst MAC
> 
> Creates a queue for the exception path to handle packets with unknown MAC addresses. These packets are
> sent to the CPU for MAC learning and broadcast.
> 
> > diff --git a/drivers/net/ethernet/renesas/rswitch_main.c
> > b/drivers/net/ethernet/renesas/rswitch_main.c
> > index e05c42db5f4c8..bf26c1a3384aa 100644
> > --- a/drivers/net/ethernet/renesas/rswitch_main.c
> > +++ b/drivers/net/ethernet/renesas/rswitch_main.c
> > @@ -682,6 +682,34 @@ static int rswitch_rxdmac_init(struct
> > rswitch_private *priv, unsigned int index)
> [ ... ]
> > +static int rswitch_shared_rx_queue_alloc(struct rswitch_private
> > +*priv) {
> [ ... ]
> > +	err = rswitch_gwca_queue_alloc(NULL, priv, gwca->l2_shared_rx_queue, false, RX_RING_SIZE);
> > +	if (err < 0) {
> > +		rswitch_gwca_put(priv, gwca->l2_shared_rx_queue);
> > +		return err;
> > +	}
> > +
> > +	return rswitch_gwca_queue_ext_ts_format(dev, priv,
> > +gwca->l2_shared_rx_queue); }
> 
> If rswitch_gwca_queue_ext_ts_format() fails, does this leak the DMA resources allocated by
> rswitch_gwca_queue_alloc() and the queue bitmask index acquired via rswitch_gwca_get()?

I added a call to rswitch_gwca_queue_free() for cases when rswitch_gwca_queue_alloc() fails.
This cleans up the DMA resources and the bitmask.
> 
> [ ... ]
> > @@ -954,15 +993,40 @@ static int rswitch_poll(struct napi_struct
> > *napi, int budget)
> [ ... ]
> > -static void rswitch_queue_interrupt(struct net_device *ndev)
> > +static void rswitch_queue_interrupt(struct rswitch_private *priv,
> > +struct rswitch_gwca_queue *gq)
> >  {
> > -	struct rswitch_device *rdev = netdev_priv(ndev);
> > +	struct rswitch_ext_ts_desc *desc;
> > +	struct rswitch_device *rdev;
> > +	struct net_device *ndev;
> > +	unsigned int rx_q_index;
> > +	u32 spn;
> > +
> > +	rdev = netdev_priv(gq->ndev);
> 
> Since gq->ndev is initialized to NULL for the shared exception queue, does this unconditionally
> dereference a NULL pointer?
> 
> > +	rx_q_index = rdev->rx_queue->index;
> 
> And compute an invalid memory address here?

I reworked this to make this more robust. This should not happen any more.
> 
> > +
> > +/* If we receive a shared queue through the exception path, it will
> > +be missing the ndev
> > + * pointer. This needs to be added to be able to determine from which
> > +port the packet was
> > + * received. Then we temporarily exchange the rx_queue pointer in
> > +rdev. This will be
> > + * restored after the packet has been processed.
> > + */
> > +
> > +	if (gq->index == priv->gwca.l2_shared_rx_queue->index) {
> > +		desc = &gq->rx_ring[gq->cur];
> > +		spn = FIELD_GET(SPN, desc->info1);
> 
> Because desc->info1 is a little-endian 64-bit field (__le64), will applying a host-endian bitfield
> mask without converting it via le64_to_cpu() first yield garbage values on big-endian architectures?
> 
> > +		ndev = priv->rdev[spn]->ndev;
> 

I added the conversion le64_to_cpu(). This also removed the error from the sparse compilation.

> Can a malformed or byte-swapped descriptor result in an out-of-bounds memory read (spn >=
> RSWITCH_NUM_PORTS) here?
> 
> > +		rdev = netdev_priv(ndev);
> > +		gq->ndev = ndev;
> > +		/* store original rx_queue */
> > +		rdev->rx_old_queue = rdev->rx_queue;
> > +		rdev->rx_queue = gq;
> 
> Does this lockless swap of queue pointers in hardirq context create a data race with rswitch_poll(),
> which reads and restores them in NAPI softirq context?
> 
> Furthermore, if napi_schedule_prep() returns false because NAPI is already running, the interrupt is
> not disabled. If a subsequent interrupt for the same port executes this swap again, will it overwrite
> rdev->rx_old_queue with the shared queue pointer (gq) and permanently lose the normal RX queue?
> 
> Also, l2_shared_rx_queue aggregates packets from all physical ports. Since this reads the source port
> (spn) of only the first pending packet and schedules NAPI for that specific network interface, won't
> the NAPI polling loop consume subsequent packets in the batch and incorrectly attribute them to the
> first packet's interface?

Since this is the slow path, I don't expect too many packets using this path. Especially since the 
environment inside a vehicle is very homogeneous I would not expect this to happen.

The vast majority of packets will not be seen by the CPU, because they will be handled in HW.

> 
> > +	}
> >
> >  	if (napi_schedule_prep(&rdev->napi)) {
> [ ... ]
> > @@ -1646,6 +1721,7 @@ static int rswitch_stop(struct net_device *ndev)
> [ ... ]
> >  	spin_lock_irqsave(&rdev->priv->lock, flags);
> >  	rswitch_enadis_data_irq(rdev->priv, rdev->tx_queue->index, false);
> >  	rswitch_enadis_data_irq(rdev->priv, rdev->rx_queue->index, false);
> > +	rswitch_enadis_data_irq(rdev->priv,
> > +rdev->priv->gwca.l2_shared_rx_queue->index, false);
> 
> Since l2_shared_rx_queue is a global resource used for MAC learning exception packets across all
> ports, does stopping a single network interface break the globally shared exception path for all other
> active interfaces?

No, this has been tested and this has not been observed.

Best regards,

Michael

  reply	other threads:[~2026-05-22 12:07 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-11  8:52 [net-next PATCH v4 00/13] net: renesas: rswitch: R-Car S4 add VLAN aware switching Michael Dege
2026-05-11  8:52 ` [PATCH net-next v4 01/13] net: renesas: rswitch: improve port change mode functions Michael Dege
2026-05-11  8:52 ` [PATCH net-next v4 02/13] net: renesas: rswitch: use device instead of net_device Michael Dege
2026-05-13  1:35   ` Jakub Kicinski
2026-05-22 12:10     ` Michael Dege
2026-05-11  8:52 ` [PATCH net-next v4 03/13] net: renesas: rswitch: fix FWPC2 register access macros Michael Dege
2026-05-11  8:52 ` [PATCH net-next v4 04/13] net: renesas: rswitch: add register definitions for vlan support Michael Dege
2026-05-11  8:52 ` [PATCH net-next v4 05/13] net: renesas: rswitch: add exception path for packets with unknown dst MAC Michael Dege
2026-05-13  1:35   ` Jakub Kicinski
2026-05-22 12:07     ` Michael Dege [this message]
2026-05-13  1:37   ` Jakub Kicinski
2026-05-22 10:47     ` Michael Dege
2026-05-11  8:52 ` [PATCH net-next v4 06/13] net: renesas: rswitch: add forwarding rules for gwca Michael Dege
2026-05-11  8:52 ` [PATCH net-next v4 07/13] net: renesas: rswitch: make helper functions available to whole driver Michael Dege
2026-05-13  1:35   ` Jakub Kicinski
2026-05-22 11:53     ` Michael Dege
2026-05-11  8:52 ` [PATCH net-next v4 08/13] net: renesas: rswitch: add basic vlan init to rswitch_fwd_init Michael Dege
2026-05-11  8:52 ` [PATCH net-next v4 09/13] net: renesas: rswitch: update port HW init Michael Dege
2026-05-13  1:35   ` Jakub Kicinski
2026-05-22 11:51     ` Michael Dege
2026-05-11  8:52 ` [PATCH net-next v4 10/13] net: renesas: rswitch: clean up is_rdev rswitch_device checking Michael Dege
2026-05-13  1:35   ` Jakub Kicinski
2026-05-22 11:14     ` Michael Dege
2026-05-11  8:52 ` [PATCH net-next v4 11/13] net: renesas: rswitch: add passing of rswitch_private into notifiers Michael Dege
2026-05-13  1:35   ` Jakub Kicinski
2026-05-22 11:16     ` Michael Dege
2026-05-11  8:52 ` [PATCH net-next v4 12/13] net: renesas: rswitch: add handler for FDB notification Michael Dege
2026-05-13  1:35   ` Jakub Kicinski
2026-05-22 11:02     ` Michael Dege
2026-05-11  8:52 ` [PATCH net-next v4 13/13] net: renesas: rswitch: add vlan aware switching Michael Dege

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=TY4PR01MB142826C4D8BFD45FB4D3D6EDC820F2@TY4PR01MB14282.jpnprd01.prod.outlook.com \
    --to=michael.dege@renesas.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=niklas.soderlund@ragnatech.se \
    --cc=pabeni@redhat.com \
    --cc=paul@pbarker.dev \
    --cc=yoshihiro.shimoda.uh@renesas.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

all inboxes | Powered by JetHome®