From: Jakub Kicinski <kuba@kernel.org> Date: 2026-09-12 23:43:42
TCP_FASTOPEN_COOKIE_MAX is the longest cookie we accept, not the shortest
one. Cookies are even sized, from 4 bytes up, and the ones Linux itself
generates are 8 bytes, so a 16 byte minimum declares all but the longest
cookie invalid. The reference policy kept under #if 0 in tcp_metrics.c
spells it as a maximum, which is what .len means for NLA_BINARY.
The IPv6 addresses err the other way. The policy uses
NLA_POLICY_EXACT_LEN() for both, so a request carrying a longer address is
rejected with -ERANGE, even though the spec advertises 16 bytes as a mere
minimum. Were the policy generated from this spec, as kernel-policy: global
promises, the check would turn into NLA_POLICY_MIN_LEN() and start
accepting over-long addresses, of which nla_get_in6_addr() would take the
first 16 bytes.
Nothing generated changes. fopen-cookie is reply-only so it never gets a
policy entry, and exact-len only feeds the policy (and the fixed size array
form, which needs a sub-type).
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
Documentation/netlink/specs/tcp_metrics.yaml | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
From: Jakub Kicinski <kuba@kernel.org> Date: 2026-09-12 23:43:42
All four RTT attributes tell the reader to left-shift, which inflates the
value by 16 to 64 times, and the two usec ones say the result is in msecs.
The attributes carry srtt_us and mdev_us, which hold 3 and 2 fractional
bits. The shift to get the integer part would be a right shift.
Drop the instructions instead of turning them around. The number of
fractional bits is the part worth documenting, whether to shift, divide or
convert to a double is up to the caller.
While at it fix the acronym on the two variance attributes.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
Documentation/netlink/specs/tcp_metrics.yaml | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
@@ -93,14 +93,12 @@ kernel-policy: globalname:rtttype:u32doc:|-Round Trip Time (RTT), in msecs with 3 bits fractional-(left-shift by 3 to get the msec value).+Round Trip Time (RTT), in msecs with 3 bits fractional.-name:rttvartype:u32doc:|-Round Trip Time VARiance (RTT), in msecs with 2 bits fractional-(left-shift by 2 to get the msec value).+Round Trip Time VARiance (RTTVAR), in msecs with 2 bits fractional.-name:ssthreshtype:u32
@@ -117,14 +115,12 @@ kernel-policy: globalname:rtt-ustype:u32doc:|-Round Trip Time (RTT), in usecs, with 3 bits fractional-(left-shift by 3 to get the msec value).+Round Trip Time (RTT), in usecs, with 3 bits fractional.-name:rttvar-ustype:u32doc:|-Round Trip Time (RTT), in usecs, with 2 bits fractional-(left-shift by 3 to get the msec value).+Round Trip Time VARiance (RTTVAR), in usecs, with 2 bits fractional.operations:list:
From: Hangbin Liu <hidden> Date: 2026-09-14 06:41:36
On Sat, Sep 12, 2026 at 04:43:36PM -0700, Jakub Kicinski wrote:
quoted hunk
TCP_FASTOPEN_COOKIE_MAX is the longest cookie we accept, not the shortest
one. Cookies are even sized, from 4 bytes up, and the ones Linux itself
generates are 8 bytes, so a 16 byte minimum declares all but the longest
cookie invalid. The reference policy kept under #if 0 in tcp_metrics.c
spells it as a maximum, which is what .len means for NLA_BINARY.
The IPv6 addresses err the other way. The policy uses
NLA_POLICY_EXACT_LEN() for both, so a request carrying a longer address is
rejected with -ERANGE, even though the spec advertises 16 bytes as a mere
minimum. Were the policy generated from this spec, as kernel-policy: global
promises, the check would turn into NLA_POLICY_MIN_LEN() and start
accepting over-long addresses, of which nla_get_in6_addr() would take the
first 16 bytes.
Nothing generated changes. fopen-cookie is reply-only so it never gets a
policy entry, and exact-len only feeds the policy (and the fixed size array
form, which needs a sub-type).
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
Documentation/netlink/specs/tcp_metrics.yaml | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
From: Hangbin Liu <hidden> Date: 2026-09-14 06:49:43
On Sat, Sep 12, 2026 at 04:43:37PM -0700, Jakub Kicinski wrote:
quoted hunk
All four RTT attributes tell the reader to left-shift, which inflates the
value by 16 to 64 times, and the two usec ones say the result is in msecs.
The attributes carry srtt_us and mdev_us, which hold 3 and 2 fractional
bits. The shift to get the integer part would be a right shift.
Drop the instructions instead of turning them around. The number of
fractional bits is the part worth documenting, whether to shift, divide or
convert to a double is up to the caller.
While at it fix the acronym on the two variance attributes.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
Documentation/netlink/specs/tcp_metrics.yaml | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
@@ -93,14 +93,12 @@ kernel-policy: globalname:rtttype:u32doc:|-Round Trip Time (RTT), in msecs with 3 bits fractional-(left-shift by 3 to get the msec value).+Round Trip Time (RTT), in msecs with 3 bits fractional.-name:rttvartype:u32doc:|-Round Trip Time VARiance (RTT), in msecs with 2 bits fractional-(left-shift by 2 to get the msec value).+Round Trip Time VARiance (RTTVAR), in msecs with 2 bits fractional.-name:ssthreshtype:u32
@@ -117,14 +115,12 @@ kernel-policy: globalname:rtt-ustype:u32doc:|-Round Trip Time (RTT), in usecs, with 3 bits fractional-(left-shift by 3 to get the msec value).+Round Trip Time (RTT), in usecs, with 3 bits fractional.-name:rttvar-ustype:u32doc:|-Round Trip Time (RTT), in usecs, with 2 bits fractional-(left-shift by 3 to get the msec value).+Round Trip Time VARiance (RTTVAR), in usecs, with 2 bits fractional.operations:list:
Hello:
This series was applied to netdev/net-next.git (main)
by Paolo Abeni [off-list ref]:
On Sat, 12 Sep 2026 16:43:36 -0700 you wrote:
TCP_FASTOPEN_COOKIE_MAX is the longest cookie we accept, not the shortest
one. Cookies are even sized, from 4 bytes up, and the ones Linux itself
generates are 8 bytes, so a 16 byte minimum declares all but the longest
cookie invalid. The reference policy kept under #if 0 in tcp_metrics.c
spells it as a maximum, which is what .len means for NLA_BINARY.
The IPv6 addresses err the other way. The policy uses
NLA_POLICY_EXACT_LEN() for both, so a request carrying a longer address is
rejected with -ERANGE, even though the spec advertises 16 bytes as a mere
minimum. Were the policy generated from this spec, as kernel-policy: global
promises, the check would turn into NLA_POLICY_MIN_LEN() and start
accepting over-long addresses, of which nla_get_in6_addr() would take the
first 16 bytes.
[...]