From: Joe Damato <joe@dama.to>
To: Koichiro Den <den@valinux.co.jp>
Cc: Jon Mason <jdmason@kudzu.us>, Dave Jiang <dave.jiang@intel.com>,
Allen Hubbe <allenbh@gmail.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
ntb@lists.linux.dev, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v4 02/10] NTB: ntb_transport: Use little-endian shared fields
Date: Fri, 18 Sep 2026 17:54:34 -0700 [thread overview]
Message-ID: <aq3dSqE2euoxQeQr@devvm20253.cco0.facebook.com> (raw)
In-Reply-To: <20260914084838.2158249-3-den@valinux.co.jp>
On Mon, Sep 14, 2026 at 05:48:30PM +0900, Koichiro Den wrote:
> ntb_transport writes payload headers and the RX ring tail with
> iowrite32(), but reads peer-written copies from coherent memory as native
> integers. The values are therefore byte-swapped when read on a big-endian
> system.
>
> Mark the shared fields as __le32 and convert coherent-memory accesses
> accordingly. Read hdr->ver and hdr->len once so their checks and later
> uses see the same values.
>
> Fixes: 74465645cdb4 ("NTB: Fix Sparse Warnings")
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Link: https://lore.kernel.org/r/20260815032932.151F11F000E9@smtp.kernel.org/
> Link: https://lore.kernel.org/r/20260818064951.7EA231F000E9@smtp.kernel.org/
> Reviewed-by: Dave Jiang <dave.jiang@intel.com>
> Signed-off-by: Koichiro Den <den@valinux.co.jp>
> ---
> Changes in v4:
> - No changes.
>
> drivers/ntb/ntb_transport.c | 47 +++++++++++++++++++++----------------
> 1 file changed, 27 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/ntb/ntb_transport.c b/drivers/ntb/ntb_transport.c
> index 74f4f8c1c7be..3f497a62673f 100644
> --- a/drivers/ntb/ntb_transport.c
> +++ b/drivers/ntb/ntb_transport.c
[...]
> @@ -514,7 +514,8 @@ static int ntb_qp_debugfs_stats_show(struct seq_file *s, void *v)
> seq_printf(s, "tx_err_no_buf - %llu\n", qp->tx_err_no_buf);
> seq_printf(s, "tx_mw - \t0x%p\n", qp->tx_mw);
> seq_printf(s, "tx_index (H) - \t%u\n", qp->tx_index);
> - seq_printf(s, "RRI (T) - \t%u\n", qp->remote_rx_info->entry);
> + seq_printf(s, "RRI (T) - \t%u\n",
> + le32_to_cpu(qp->remote_rx_info->entry));
it looks like the code READ_ONCE's this field below.... is that needed here
too?
> seq_printf(s, "tx_max_entry - \t%u\n", qp->tx_max_entry);
> seq_printf(s, "free tx - \t%u\n", ntb_transport_tx_free_entry(qp));
> seq_putc(s, '\n');
> @@ -633,7 +634,7 @@ static int ntb_transport_setup_qp_mw(struct ntb_transport_ctx *nt,
> qp->rx_alloc_entry++;
> }
>
> - qp->remote_rx_info->entry = qp->rx_max_entry - 1;
> + qp->remote_rx_info->entry = cpu_to_le32(qp->rx_max_entry - 1);
you read_once below, do you need a write_once too ?
i wonder if the read_once / write_once with endian conversion can be wrapped
up in a helper or something to simplify? not sure, it might introduce more
code than really necessary.
> /* setup the hdr offsets with 0's */
> for (i = 0; i < qp->rx_max_entry; i++) {
> @@ -919,7 +920,7 @@ static void ntb_qp_link_down_reset(struct ntb_transport_qp *qp)
> {
> ntb_qp_link_context_reset(qp);
> if (qp->remote_rx_info)
> - qp->remote_rx_info->entry = qp->rx_max_entry - 1;
> + qp->remote_rx_info->entry = cpu_to_le32(qp->rx_max_entry - 1);
same as above with the onces ?
> }
>
> static void ntb_qp_link_cleanup(struct ntb_transport_qp *qp)
> @@ -1445,7 +1446,7 @@ static void ntb_complete_rxc(struct ntb_transport_qp *qp)
> if (!(entry->flags & DESC_DONE_FLAG))
> break;
>
> - entry->rx_hdr->flags = 0;
> + entry->rx_hdr->flags = cpu_to_le32(0);
this looked weird to me but grep says this is a common idiom, so TIL
cpu_to_le32(0) is a thing.
[...]
> @@ -2490,7 +2495,9 @@ EXPORT_SYMBOL_GPL(ntb_transport_max_size);
> unsigned int ntb_transport_tx_free_entry(struct ntb_transport_qp *qp)
> {
> unsigned int head = qp->tx_index;
> - unsigned int tail = qp->remote_rx_info->entry;
> + unsigned int tail;
> +
> + tail = le32_to_cpu(READ_ONCE(qp->remote_rx_info->entry));
see above re: read_once and write_once on this field...
i didn't really try prototyping anything but seeing this repeated pattern
makes me wonder if
static inline u32 ntb_remote_rx_entry(blah)
{
return le32_to_cpu(READ_ONCE(....));
}
would make the code clearer ... or less clear. not sure.
next prev parent reply other threads:[~2026-09-19 0:54 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-14 8:48 [PATCH net-next v4 00/10] net: ntb_netdev: Preserve checksum offload across NTB Koichiro Den
2026-09-14 8:48 ` [PATCH net-next v4 01/10] NTB: ntb_transport: Order RX descriptor reads after completion Koichiro Den
2026-09-19 0:36 ` Joe Damato
2026-09-19 12:37 ` Koichiro Den
2026-09-14 8:48 ` [PATCH net-next v4 02/10] NTB: ntb_transport: Use little-endian shared fields Koichiro Den
2026-09-19 0:54 ` Joe Damato [this message]
2026-09-19 13:06 ` Koichiro Den
2026-09-14 8:48 ` [PATCH net-next v4 03/10] NTB: ntb_transport: Order RX entry completion Koichiro Den
2026-09-19 1:10 ` Joe Damato
2026-09-19 12:53 ` Koichiro Den
2026-09-14 8:48 ` [PATCH net-next v4 04/10] NTB: ntb_transport: Keep local QP link requests separate Koichiro Den
2026-09-17 20:49 ` netdev-bot+sashiko
2026-09-14 8:48 ` [PATCH net-next v4 05/10] NTB: ntb_transport: Exchange client capabilities at link-up Koichiro Den
2026-09-15 8:50 ` sashiko-bot
2026-09-19 12:51 ` Koichiro Den
2026-09-17 20:49 ` netdev-bot+sashiko
2026-09-14 8:48 ` [PATCH net-next v4 06/10] NTB: ntb_transport: Add per-payload client metadata Koichiro Den
2026-09-14 8:48 ` [PATCH net-next v4 07/10] net: ntb_netdev: Reject short RX frames Koichiro Den
2026-09-19 1:14 ` Joe Damato
2026-09-14 8:48 ` [PATCH net-next v4 08/10] net: ntb_netdev: Factor out RX statistics update Koichiro Den
2026-09-14 8:48 ` [PATCH net-next v4 09/10] net: ntb_netdev: Introduce an optional packet header, ntb_netdev_hdr Koichiro Den
2026-09-17 20:49 ` netdev-bot+sashiko
2026-09-14 8:48 ` [PATCH net-next v4 10/10] net: ntb_netdev: Preserve CHECKSUM_PARTIAL across NTB Koichiro Den
2026-09-17 20:49 ` netdev-bot+sashiko
2026-10-09 5:10 ` [PATCH net-next v4 00/10] net: ntb_netdev: Preserve checksum offload " Koichiro Den
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=aq3dSqE2euoxQeQr@devvm20253.cco0.facebook.com \
--to=joe@dama.to \
--cc=allenbh@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=dave.jiang@intel.com \
--cc=davem@davemloft.net \
--cc=den@valinux.co.jp \
--cc=edumazet@google.com \
--cc=jdmason@kudzu.us \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=ntb@lists.linux.dev \
--cc=pabeni@redhat.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.