From: Jakub Kicinski <kuba@kernel.org>
To: xuanzhuo@linux.alibaba.com
Cc: Jakub Kicinski <kuba@kernel.org>,
guwen@linux.alibaba.com, andrew+netdev@lunn.ch,
hkallweit1@gmail.com, edumazet@google.com,
lulie@linux.alibaba.com, andrew@lunn.ch,
vadim.fedorenko@linux.dev, lorenzo@kernel.org, pabeni@redhat.com,
lukas.bulwahn@redhat.com, dust.li@linux.alibaba.com,
netdev@vger.kernel.org, dong100@mucse.com, davem@davemloft.net
Subject: Re: [net-next,v27,5/8] eea: implement packet receive logic
Date: Sat, 28 Feb 2026 15:55:37 -0800 [thread overview]
Message-ID: <20260228235537.31102-1-kuba@kernel.org> (raw)
In-Reply-To: <20260227015546.47336-6-xuanzhuo@linux.alibaba.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
eea: implement packet receive logic
Implement the core logic for receiving packets in the EEA RX path,
including packet buffering and basic validation.
> diff --git a/drivers/net/ethernet/alibaba/eea/eea_net.h b/drivers/net/ethernet/alibaba/eea/eea_net.h
> index 0398e781dfdb..5a607947a76e 100644
> --- a/drivers/net/ethernet/alibaba/eea/eea_net.h
> +++ b/drivers/net/ethernet/alibaba/eea/eea_net.h
[ ... ]
> diff --git a/drivers/net/ethernet/alibaba/eea/eea_rx.c b/drivers/net/ethernet/alibaba/eea/eea_rx.c
> index a8695704d67d..db74580f296c 100644
> --- a/drivers/net/ethernet/alibaba/eea/eea_rx.c
> +++ b/drivers/net/ethernet/alibaba/eea/eea_rx.c
[ ... ]
> @@ -88,12 +180,391 @@ static int eea_alloc_rx_hdr(struct eea_net_init_ctx *ctx, struct eea_net_rx *rx)
> return 0;
> }
>
> +static void eea_rx_meta_dma_sync_for_cpu(struct eea_net_rx *rx,
> + struct eea_rx_meta *meta, u32 len)
> +{
> + dma_sync_single_for_cpu(rx->enet->edev->dma_dev,
> + meta->dma + meta->offset + meta->headroom,
> + len, DMA_FROM_DEVICE);
> +}
> +
> +static int eea_harden_check_overflow(struct eea_rx_ctx *ctx,
> + struct eea_net *enet)
> +{
> + u32 max_len;
> +
> + max_len = ctx->meta->truesize - ctx->meta->headroom -
> + ctx->meta->tailroom;
> +
> + if (unlikely(ctx->len > max_len)) {
> + pr_debug("%s: rx error: len %u exceeds truesize %u\n",
> + enet->netdev->name, ctx->len, max_len);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static int eea_harden_check_size(struct eea_rx_ctx *ctx, struct eea_net *enet)
> +{
> + int err;
> +
> + err = eea_harden_check_overflow(ctx, enet);
> + if (err)
> + return err;
> +
> + if (ctx->hdr_len) {
> + if (unlikely(ctx->hdr_len < ETH_HLEN)) {
> + pr_debug("%s: short packet %u\n", enet->netdev->name,
> + ctx->len);
> + return -EINVAL;
> + }
> +
> + if (unlikely(ctx->hdr_len > enet->cfg.split_hdr)) {
> + pr_debug("%s: rx error: hdr len %u exceeds hdr buffer size %u\n",
> + enet->netdev->name, ctx->len,
> + enet->cfg.split_hdr);
Should the second pr_debug argument be ctx->hdr_len instead of ctx->len?
The condition checks 'ctx->hdr_len > enet->cfg.split_hdr', and the format
string says 'hdr len %u exceeds hdr buffer size %u', but the argument
passed is ctx->len (the data payload length) rather than ctx->hdr_len (the
header length that actually triggered the error). This would print the
wrong value when debugging split-header overflow issues.
> + return -EINVAL;
> + }
> +
> + return 0;
> + }
> +
> + if (unlikely(ctx->len < ETH_HLEN)) {
> + pr_debug("%s: short packet %u\n", enet->netdev->name, ctx->len);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
[ ... ]
next prev parent reply other threads:[~2026-02-28 23:55 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-27 1:55 [PATCH net-next v27 0/8] eea: Add basic driver framework for Alibaba Elastic Ethernet Adaptor Xuan Zhuo
2026-02-27 1:55 ` [PATCH net-next v27 1/8] eea: introduce PCI framework Xuan Zhuo
2026-02-27 1:55 ` [PATCH net-next v27 2/8] eea: introduce ring and descriptor structures Xuan Zhuo
2026-02-27 1:55 ` [PATCH net-next v27 3/8] eea: probe the netdevice and create adminq Xuan Zhuo
2026-02-27 1:55 ` [PATCH net-next v27 4/8] eea: create/destroy rx,tx queues for netdevice open and stop Xuan Zhuo
2026-02-28 23:55 ` [net-next,v27,4/8] " Jakub Kicinski
2026-02-27 1:55 ` [PATCH net-next v27 5/8] eea: implement packet receive logic Xuan Zhuo
2026-02-28 23:55 ` Jakub Kicinski [this message]
2026-02-27 1:55 ` [PATCH net-next v27 6/8] eea: implement packet transmit logic Xuan Zhuo
2026-02-27 1:55 ` [PATCH net-next v27 7/8] eea: introduce ethtool support Xuan Zhuo
2026-02-27 1:55 ` [PATCH net-next v27 8/8] eea: introduce callback for ndo_get_stats64 Xuan Zhuo
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=20260228235537.31102-1-kuba@kernel.org \
--to=kuba@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=dong100@mucse.com \
--cc=dust.li@linux.alibaba.com \
--cc=edumazet@google.com \
--cc=guwen@linux.alibaba.com \
--cc=hkallweit1@gmail.com \
--cc=lorenzo@kernel.org \
--cc=lukas.bulwahn@redhat.com \
--cc=lulie@linux.alibaba.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=vadim.fedorenko@linux.dev \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox