Re: [RFC net-next v10] mptcp: normalize seq numbers reported in mptcp_info

[Matthieu Baerts <matttbe@kernel.org>]

Hi Kalpan,

On 27/10/2026 14:42, Matthieu Baerts wrote:
> Hi Kalpan,
> 
> Thank you for your reply.
> 
> On 27/10/2026 13:29, Kalpan Jani wrote:
>> Hi Matt,
>>
>> I investigated the existing byte counters and the diagnostic
>> capability path.
>>
>> The existing byte counters are not direct replacements for the
>> normalized sequence fields:
>>
>> - write_seq advances when application data is queued and when
>> DATA_FIN is added. bytes_sent tracks send progress, and the
>> retransmission path can update snd_nxt directly without updating
>> bytes_sent. - snd_una is assigned directly during connection setup,
>> outside __mptcp_snd_una_update(). Therefore, bytes_acked cannot be
>> assumed to reproduce snd_una - local_idsn. - ack_seq advances when
>> processing DATA_FIN, whereas bytes_received counts payload bytes.
>> Their initial values also differ.
> 
> OK, let's not use the bytes counters then.
> 
>> Regarding the capability check, the normal MPTCP diagnostic dump
>> paths have access to the original request skb and can check
>> netlink_net_capable(cb->skb, CAP_NET_ADMIN).
> 
> Good!
> 
>> However, inet_diag_handler_get_info() is also called for socket-
>> destruction notifications. In that path,
>> sock_diag_broadcast_destroy_work() creates a new skb and invokes the
>> callback without an original diagnostic request. Therefore, the
>> requester's capability cannot be recovered from that skb. Passing
>> false in this notification path appears to be the appropriate
>> conservative behavior.
> 
> OK to pass false in this case.
> 
>> Based on this investigation, I will keep the capability/privacy
>> change separate from sequence normalization. I will also address the
>> stale remote_idsn after disconnect and the inconsistent sequence
>> snapshot reported by Sashiko before sending another normalization
>> revision.
> 
> Just to be sure it is clear: the main goal here is not to show the seq
> counters to everybody from the same netns. This can be done either by
> "normalising" them -- i.e. starting from 0 -- or by not presenting them
> to some users.
> 
> Just thinking about that: for the normalisation, we can also just
> add/remove an offset the userspace cannot predict and different per
> connection. In fact, why not using the address of the msk pointer? I
> guess that should prevent the different issues reported by Sashiko, no?

Was this workaround using the msk address not working?

BTW, please next time don't send new series as a reply to an email,
start a new email thread instead.

> (In case of "other" existing issues, please split them and move them in
> a dedicated patch not to mix the fix and the main patch here.)
> 
> If the "normalisation" is not possible, better not displaying them to
> non cap-admin users. But we don't need both.
> 
> Cheers,
> Matt

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