| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID:
<PAXPR07MB7984A9327EF12B0E011511CCA357A@PAXPR07MB7984.eurprd07.prod.outlook.com>
Date: Tue, 15 Jul 2025 09:08:12 +0000
From: "Chia-Yu Chang (Nokia)" <chia-yu.chang@...ia-bell-labs.com>
To: Paolo Abeni <pabeni@...hat.com>, "edumazet@...gle.com"
<edumazet@...gle.com>, "linux-doc@...r.kernel.org"
<linux-doc@...r.kernel.org>, "corbet@....net" <corbet@....net>,
"horms@...nel.org" <horms@...nel.org>, "dsahern@...nel.org"
<dsahern@...nel.org>, "kuniyu@...zon.com" <kuniyu@...zon.com>,
"bpf@...r.kernel.org" <bpf@...r.kernel.org>, "netdev@...r.kernel.org"
<netdev@...r.kernel.org>, "dave.taht@...il.com" <dave.taht@...il.com>,
"jhs@...atatu.com" <jhs@...atatu.com>, "kuba@...nel.org" <kuba@...nel.org>,
"stephen@...workplumber.org" <stephen@...workplumber.org>,
"xiyou.wangcong@...il.com" <xiyou.wangcong@...il.com>, "jiri@...nulli.us"
<jiri@...nulli.us>, "davem@...emloft.net" <davem@...emloft.net>,
"andrew+netdev@...n.ch" <andrew+netdev@...n.ch>, "donald.hunter@...il.com"
<donald.hunter@...il.com>, "ast@...erby.net" <ast@...erby.net>,
"liuhangbin@...il.com" <liuhangbin@...il.com>, "shuah@...nel.org"
<shuah@...nel.org>, "linux-kselftest@...r.kernel.org"
<linux-kselftest@...r.kernel.org>, "ij@...nel.org" <ij@...nel.org>,
"ncardwell@...gle.com" <ncardwell@...gle.com>, "Koen De Schepper (Nokia)"
<koen.de_schepper@...ia-bell-labs.com>, "g.white@...lelabs.com"
<g.white@...lelabs.com>, "ingemar.s.johansson@...csson.com"
<ingemar.s.johansson@...csson.com>, "mirja.kuehlewind@...csson.com"
<mirja.kuehlewind@...csson.com>, "cheshire@...le.com" <cheshire@...le.com>,
"rs.ietf@....at" <rs.ietf@....at>, "Jason_Livingood@...cast.com"
<Jason_Livingood@...cast.com>, "vidhi_goel@...le.com" <vidhi_goel@...le.com>
Subject: RE: [PATCH v12 net-next 09/15] tcp: accecn: AccECN needs to know
delivered bytes
> -----Original Message-----
> From: Paolo Abeni <pabeni@...hat.com>
> Sent: Monday, July 14, 2025 3:34 PM
> To: Chia-Yu Chang (Nokia) <chia-yu.chang@...ia-bell-labs.com>; edumazet@...gle.com; linux-doc@...r.kernel.org; corbet@....net; horms@...nel.org; dsahern@...nel.org; kuniyu@...zon.com; bpf@...r.kernel.org; netdev@...r.kernel.org; dave.taht@...il.com; jhs@...atatu.com; kuba@...nel.org; stephen@...workplumber.org; xiyou.wangcong@...il.com; jiri@...nulli.us; davem@...emloft.net; andrew+netdev@...n.ch; donald.hunter@...il.com; ast@...erby.net; liuhangbin@...il.com; shuah@...nel.org; linux-kselftest@...r.kernel.org; ij@...nel.org; ncardwell@...gle.com; Koen De Schepper (Nokia) <koen.de_schepper@...ia-bell-labs.com>; g.white@...lelabs.com; ingemar.s.johansson@...csson.com; mirja.kuehlewind@...csson.com; cheshire@...le.com; rs.ietf@....at; Jason_Livingood@...cast.com; vidhi_goel@...le.com
> Subject: Re: [PATCH v12 net-next 09/15] tcp: accecn: AccECN needs to know delivered bytes
>
>
> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
>
>
>
> On 7/4/25 10:53 AM, chia-yu.chang@...ia-bell-labs.com wrote:
> > diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index
> > eea790295e54..f7d7649612a2 100644
> > --- a/net/ipv4/tcp_input.c
> > +++ b/net/ipv4/tcp_input.c
> > @@ -1050,6 +1050,7 @@ struct tcp_sacktag_state {
> > u64 last_sackt;
> > u32 reord;
> > u32 sack_delivered;
> > + u32 delivered_bytes;
>
> Explicitly mentioning in the commit message that the above fills a 4 bytes hole could be helpful for reviewers.
>
Hi Paolo,
Just want to ask to clarify on "the above fills a 4 bytes hole".
Now I see if I move the delivered_bytes to the end of this struct, the pahole results of ARM32 bit compilation:
[BEFORE PATCH]
struct tcp_sacktag_state {
u64 first_sackt; /* 0 8 */
u64 last_sackt; /* 8 8 */
u32 reord; /* 16 4 */
u32 sack_delivered; /* 20 4 */
int flag; /* 24 4 */
unsigned int mss_now; /* 28 4 */
struct rate_sample * rate; /* 32 4 */
/* size: 40, cachelines: 1, members: 7 */
/* padding: 4 */
/* last cacheline: 40 bytes */
};
[AFTER PATCH]
struct tcp_sacktag_state {
u64 first_sackt; /* 0 8 */
u64 last_sackt; /* 8 8 */
u32 reord; /* 16 4 */
u32 sack_delivered; /* 20 4 */
int flag; /* 24 4 */
unsigned int mss_now; /* 28 4 */
struct rate_sample * rate; /* 32 4 */
u32 delivered_bytes; /* 36 4 */
/* size: 40, cachelines: 1, members: 8 */
/* last cacheline: 40 bytes */
};
And the 64 bit results are:
[BEFORE PATCH]
struct tcp_sacktag_state {
u64 first_sackt; /* 0 8 */
u64 last_sackt; /* 8 8 */
u32 reord; /* 16 4 */
u32 sack_delivered; /* 20 4 */
int flag; /* 24 4 */
unsigned int mss_now; /* 28 4 */
struct rate_sample * rate; /* 32 8 */
/* size: 40, cachelines: 1, members: 7 */
/* last cacheline: 40 bytes */
};
[AFTER PATCH]
struct tcp_sacktag_state {
u64 first_sackt; /* 0 8 */
u64 last_sackt; /* 8 8 */
u32 reord; /* 16 4 */
u32 sack_delivered; /* 20 4 */
int flag; /* 24 4 */
unsigned int mss_now; /* 28 4 */
struct rate_sample * rate; /* 32 8 */
u32 delivered_bytes; /* 40 4 */
/* size: 48, cachelines: 1, members: 8 */
/* padding: 4 */
/* last cacheline: 48 bytes */
};
I see this patch does not create any extra hole and it can reuse the existing padding 4 Bytes for ARM32 architecture.
Does it match when you mentioned?
BRs,
Chia-Yu
Powered by blists - more mailing lists