All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrei Gherzan <andrei.gherzan@canonical.com>
To: Jakub Kicinski <kuba@kernel.org>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
	Shuah Khan <shuah@kernel.org>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-kselftest@vger.kernel.org,
	Kleber Sacilotto de Souza <kleber.souza@canonical.com>,
	Hangbin Liu <liuhangbin@gmail.com>
Subject: Re: [PATCH net 0/2] netdevsim: fix IPsec debugfs byte order
Date: Wed, 9 Sep 2026 14:37:41 +0100	[thread overview]
Message-ID: <aqFhJbNp5qqlehD0@sprawlopolis> (raw)
In-Reply-To: <20260908140325.13367-1-andrei.gherzan@canonical.com>

[-- Attachment #1: Type: text/plain, Size: 2335 bytes --]

On 26/09/08 03:03PM, Andrei Gherzan wrote:
> The netdevsim IPsec debugfs file (used by selftests/net/rtnetlink.sh's
> ipsec_offload subtest) prints the SA salt and key in host CPU byte
> order instead of network byte order, because nsim_sa.key[]/salt are
> typed as plain u32 and printed directly with "%08x". This makes the
> reported values differ between little-endian and big-endian hosts for
> the same underlying key material, and breaks the selftest on
> big-endian (e.g. s390x), which hardcodes the little-endian output.
> 
> A driver-side fix was proposed in 2022 but stalled in review: keeping
> the fields as plain u32 meant sparse could not validate the added
> ntohl()/be32_to_cpu() conversions.
> 
>   https://lore.kernel.org/netdev/20220308135106.890270-1-kleber.souza@canonical.com/
> 
> This series:
> 
>   1/2 retypes nsim_sa.key[]/salt to __be32 (matching the existing
>       __be32 ipaddr[] field) and converts with be32_to_cpu() before
>       printing, so the debugfs output is now network-order on every
>       host, independent of endianness.
> 
>   2/2 updates the selftest's expected output to match the new,
>       endianness-independent values. It depends on 1/2: applied on
>       its own it would regress little-endian hosts (though it happens
>       to have no effect on big-endian hosts, whose old host-order
>       output already matched the new expected values).
> 

I forgot to add Cc: stable@vger.kernel.org to these patches. Should I
send a v2 for that, given patch 2/2 only makes sense together with
patch 1/2 (applying just one regresses the test on one endianness or
the other)?

> Tested on real booted kernels, both patches applied:
>   - x86_64 (little-endian): PASS: ipsec_offload
>   - s390x (big-endian):     PASS: ipsec_offload
> 
> checkpatch.pl --strict and sparse (make C=2) are clean on both patches.
> 
> Andrei Gherzan (2):
>   netdevsim: print IPsec salt/key in network byte order
>   selftests: rtnetlink: update ipsec_offload expected output
> 
>  drivers/net/netdevsim/ipsec.c            | 10 +++++-----
>  drivers/net/netdevsim/netdevsim.h        |  4 ++--
>  tools/testing/selftests/net/rtnetlink.sh |  8 ++++----
>  3 files changed, 11 insertions(+), 11 deletions(-)

-- 
Andrei Gherzan
gpg: rsa4096/D4D94F67AD0E9640

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2026-09-09 13:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-08 14:03 [PATCH net 0/2] netdevsim: fix IPsec debugfs byte order Andrei Gherzan
2026-09-08 14:03 ` [PATCH net 1/2] netdevsim: print IPsec salt/key in network " Andrei Gherzan
2026-09-08 14:03 ` [PATCH net 2/2] selftests: rtnetlink: update ipsec_offload expected output Andrei Gherzan
2026-09-09 13:37 ` Andrei Gherzan [this message]
2026-09-09 20:38   ` [PATCH net 0/2] netdevsim: fix IPsec debugfs byte order Jakub Kicinski
2026-09-09 20:40 ` patchwork-bot+netdevbpf

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=aqFhJbNp5qqlehD0@sprawlopolis \
    --to=andrei.gherzan@canonical.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kleber.souza@canonical.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=liuhangbin@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=shuah@kernel.org \
    /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.