public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: Wei Fang <wei.fang@nxp.com>
Cc: claudiu.manoil@nxp.com, xiaoning.wang@nxp.com,
	andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
	kuba@kernel.org, pabeni@redhat.com, ioana.ciornei@nxp.com,
	yangbo.lu@nxp.com, michal.swiatkowski@linux.intel.com,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	imx@lists.linux.dev, stable@vger.kernel.org
Subject: Re: [PATCH v2 net 1/9] net: enetc: fix the off-by-one issue in enetc_map_tx_buffs()
Date: Thu, 20 Feb 2025 15:01:21 +0200	[thread overview]
Message-ID: <20250220130121.fq3irlaunowyvfc4@skbuf> (raw)
In-Reply-To: <20250219054247.733243-2-wei.fang@nxp.com>

On Wed, Feb 19, 2025 at 01:42:39PM +0800, Wei Fang wrote:
> When a DMA mapping error occurs while processing skb frags, it will free
> one more tx_swbd than expected, so fix this off-by-one issue.
> 
> Fixes: d4fd0404c1c9 ("enetc: Introduce basic PF and VF ENETC ethernet drivers")
> Cc: stable@vger.kernel.org
> Signed-off-by: Wei Fang <wei.fang@nxp.com>
> ---

After running with some test data, I agree that the bug exists and that
the fix is correct.

Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>

It's just that there's yet one more (correct) dma_err snippet in
enetc_lso_hw_offload() which achieves the same thing, but expressed
differently, added by you in December 2024.

For fixing a bug from 2019, I agree that you've made the right choice in
not creating a dependency on that later code. But I like slightly less
the fact that it leaves 2 slightly different, both non-obvious, code
paths for unmapping DMA buffers. You could have at least copied the
dma_err handling from enetc_lso_hw_offload(), to make it obvious that
one is correct and the other is not, and not complicate things with yet
a 3rd implementation.

You don't need to change this unless there's some other reason to resend
the patch set, but at least, once "net" merges back into "net-next",
could you please make a mental note to consolidate the 2 code snippets
into a single function?

Also, the first dma_mapping_error() from enetc_map_tx_buffs() does not
need to "goto dma_err". It would be dead code. Maybe you could simplify
that as well. In general, the convention of naming error path labels is
to name them after what they do, rather than after the function that
failed when you jump to them. It's easier to manually verify correctness
this way.

Also, the dev_err(tx_ring->dev, "DMA map error"); message should be rate
limited, since it's called from a fast path and can kill the console if
the error is persistent.

A lot of things to improve still, thanks for doing this :)

  parent reply	other threads:[~2025-02-20 13:01 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-19  5:42 [PATCH v2 net 0/9] net: enetc: fix some known issues Wei Fang
2025-02-19  5:42 ` [PATCH v2 net 1/9] net: enetc: fix the off-by-one issue in enetc_map_tx_buffs() Wei Fang
2025-02-19 10:48   ` Claudiu Manoil
2025-02-20 13:01   ` Vladimir Oltean [this message]
2025-02-21  1:26     ` Wei Fang
2025-02-19  5:42 ` [PATCH v2 net 2/9] net: enetc: correct the tx_swbd statistics Wei Fang
2025-02-20  8:31   ` Ioana Ciornei
2025-02-20 16:01   ` Vladimir Oltean
2025-02-21  1:42     ` Wei Fang
2025-02-21  8:03       ` Claudiu Manoil
2025-02-21  8:34         ` Wei Fang
2025-02-21  9:22           ` Claudiu Manoil
2025-02-21  9:18       ` Vladimir Oltean
2025-02-24  3:27         ` Wei Fang
2025-02-19  5:42 ` [PATCH v2 net 3/9] net: enetc: correct the xdp_tx statistics Wei Fang
2025-02-20  8:37   ` Ioana Ciornei
2025-02-20 16:58   ` Vladimir Oltean
2025-02-19  5:42 ` [PATCH v2 net 4/9] net: enetc: VFs do not support HWTSTAMP_TX_ONESTEP_SYNC Wei Fang
2025-02-20 16:52   ` Vladimir Oltean
2025-02-19  5:42 ` [PATCH v2 net 5/9] net: enetc: update UDP checksum when updating originTimestamp field Wei Fang
2025-02-20 15:50   ` Vladimir Oltean
2025-02-19  5:42 ` [PATCH v2 net 6/9] net: enetc: add missing enetc4_link_deinit() Wei Fang
2025-02-20 16:50   ` Vladimir Oltean
2025-02-19  5:42 ` [PATCH v2 net 7/9] net: enetc: remove the mm_lock from the ENETC v4 driver Wei Fang
2025-02-20 16:03   ` Vladimir Oltean
2025-02-19  5:42 ` [PATCH v2 net 8/9] net: enetc: correct the EMDIO base offset for ENETC v4 Wei Fang
2025-02-19 20:42   ` Andrew Lunn
2025-02-20  8:05     ` Wei Fang
2025-02-20 15:58   ` Vladimir Oltean
2025-02-19  5:42 ` [PATCH v2 net 9/9] net: enetc: fix the off-by-one issue in enetc_map_tx_tso_buffs() Wei Fang
2025-02-19 11:04   ` Michal Swiatkowski
2025-02-19 17:46   ` Claudiu Manoil
2025-02-20  5:06     ` Wei Fang
2025-02-20  8:39       ` Claudiu Manoil
2025-02-20 16:32   ` Vladimir Oltean
2025-02-20 16:46     ` Vladimir Oltean
2025-02-21  2:56     ` Wei Fang
2025-02-21  9:30       ` Vladimir Oltean
2025-02-24  4:42         ` Wei Fang

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=20250220130121.fq3irlaunowyvfc4@skbuf \
    --to=vladimir.oltean@nxp.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=claudiu.manoil@nxp.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=imx@lists.linux.dev \
    --cc=ioana.ciornei@nxp.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.swiatkowski@linux.intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=wei.fang@nxp.com \
    --cc=xiaoning.wang@nxp.com \
    --cc=yangbo.lu@nxp.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