ssn_offset field is u32 and is placed into the netlink response with
nla_put_u32(), but only 2 bytes are reserved for the attribute payload
in subflow_get_info_size() (even though it makes no difference
in the end, as it is aligned up to 4 bytes).  Supply the correct
argument to the relevant nla_total_size() call to make it less
confusing.

Fixes: 5147dfb50832 ("mptcp: allow dumping subflow context to userspace")
Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
---
v2:
  - Added prefix to the patch subject
  - Fixed commit message formatting (line width, "Fixes:" commit hash
    prefix size)
v1: https://lore.kernel.org/mptcp/20240809094321.GA8122@asgard.redhat.com/
---
 net/mptcp/diag.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mptcp/diag.c b/net/mptcp/diag.c
index 3ae46b545d2c..2d3efb405437 100644
--- a/net/mptcp/diag.c
+++ b/net/mptcp/diag.c
@@ -94,7 +94,7 @@ static size_t subflow_get_info_size(const struct sock *sk)
 		nla_total_size(4) +	/* MPTCP_SUBFLOW_ATTR_RELWRITE_SEQ */
 		nla_total_size_64bit(8) +	/* MPTCP_SUBFLOW_ATTR_MAP_SEQ */
 		nla_total_size(4) +	/* MPTCP_SUBFLOW_ATTR_MAP_SFSEQ */
-		nla_total_size(2) +	/* MPTCP_SUBFLOW_ATTR_SSN_OFFSET */
+		nla_total_size(4) +	/* MPTCP_SUBFLOW_ATTR_SSN_OFFSET */
 		nla_total_size(2) +	/* MPTCP_SUBFLOW_ATTR_MAP_DATALEN */
 		nla_total_size(4) +	/* MPTCP_SUBFLOW_ATTR_FLAGS */
 		nla_total_size(1) +	/* MPTCP_SUBFLOW_ATTR_ID_REM */
-- 
2.28.0

Hi Eugene,

Thank you for your modifications, that's great!

Our CI did some validations and here is its report:

- KVM Validation: normal: Success! ✅
- KVM Validation: debug: Success! ✅
- KVM Validation: btf (only bpftest_all): Success! ✅
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/10347391530

Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/986721c2093b
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=878657


If there are some issues, you can reproduce them using the same environment as
the one used by the CI thanks to a docker image, e.g.:

    $ cd [kernel source code]
    $ docker run -v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it \
        --pull always mptcp/mptcp-upstream-virtme-docker:latest \
        auto-normal

For more details:

    https://github.com/multipath-tcp/mptcp-upstream-virtme-docker


Please note that despite all the efforts that have been already done to have a
stable tests suite when executed on a public CI like here, it is possible some
reported issues are not due to your modifications. Still, do not hesitate to
help us improve that ;-)

Cheers,
MPTCP GH Action bot
Bot operated by Matthieu Baerts (NGI0 Core)

Hi Eugene, Network maintainers,

On 12/08/2024 08:51, Eugene Syromiatnikov wrote:
> ssn_offset field is u32 and is placed into the netlink response with
> nla_put_u32(), but only 2 bytes are reserved for the attribute payload
> in subflow_get_info_size() (even though it makes no difference
> in the end, as it is aligned up to 4 bytes).  Supply the correct
> argument to the relevant nla_total_size() call to make it less
> confusing.
> 
> Fixes: 5147dfb50832 ("mptcp: allow dumping subflow context to userspace")
> Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
> ---
> v2:
>   - Added prefix to the patch subject
>   - Fixed commit message formatting (line width, "Fixes:" commit hash
>     prefix size)

Thank you for the v2!

The patch looks good to me:

Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>

Because it is a fix, I think it is a candidate for -net, not net-next.

@Network maintainers: is it OK for you to apply this v2 in "net", not
"net-next"? Or is it easier for you to have a v3 with a different prefix?

(No conflicts to apply this patch on -net, the code didn't change for 4
years.)

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.

On Mon, 12 Aug 2024 09:43:29 +0200 Matthieu Baerts wrote:
> @Network maintainers: is it OK for you to apply this v2 in "net", not
> "net-next"? Or is it easier for you to have a v3 with a different prefix?
> 
> (No conflicts to apply this patch on -net, the code didn't change for 4
> years.)

Looks trivial, should be safe to cross-apply, no need for v3.