hash_size is declared but never read. The MD5 path always uses a
fixed size of 16, and the TCP-AO path uses tcp_ao_maclen().

Suggested-by: Jakub Sitnicki <jakub@cloudflare.com>
Signed-off-by: Keita Morisaki <kmta1236@gmail.com>
---
 net/ipv4/tcp_output.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 63ee037f46e50..f0e04ebd8b723 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -441,7 +441,6 @@ struct tcp_out_options {
 	u8 ws;			/* window scale, 0 to disable */
 	u8 num_accecn_fields:7,	/* number of AccECN fields needed */
 	   use_synack_ecn_bytes:1; /* Use synack_ecn_bytes or not */
-	u8 hash_size;		/* bytes in hash_location */
 	__u8 *hash_location;	/* temporary pointer, overloaded */
 	__u32 tsval, tsecr;	/* need to include OPTION_TS */
 	struct tcp_fastopen_cookie *fastopen_cookie;	/* Fast open cookie */

base-commit: 21fc6b53f12379f3f9b29830be3597a322261df8
-- 
2.34.1

On Thu, Mar 05, 2026 at 11:27 AM +09, Keita Morisaki wrote:
> hash_size is declared but never read. The MD5 path always uses a
> fixed size of 16, and the TCP-AO path uses tcp_ao_maclen().
>
> Suggested-by: Jakub Sitnicki <jakub@cloudflare.com>
> Signed-off-by: Keita Morisaki <kmta1236@gmail.com>
> ---
>  net/ipv4/tcp_output.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 63ee037f46e50..f0e04ebd8b723 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -441,7 +441,6 @@ struct tcp_out_options {
>  	u8 ws;			/* window scale, 0 to disable */
>  	u8 num_accecn_fields:7,	/* number of AccECN fields needed */
>  	   use_synack_ecn_bytes:1; /* Use synack_ecn_bytes or not */
> -	u8 hash_size;		/* bytes in hash_location */
>  	__u8 *hash_location;	/* temporary pointer, overloaded */
>  	__u32 tsval, tsecr;	/* need to include OPTION_TS */
>  	struct tcp_fastopen_cookie *fastopen_cookie;	/* Fast open cookie */
>
> base-commit: 21fc6b53f12379f3f9b29830be3597a322261df8

Worth noting that this closes a 7-byte hole we had there:

        u8                         num_accecn_fields:7;  /*     7: 0  1 */
        u8                         use_synack_ecn_bytes:1; /*     7: 7  1 */
        u8                         hash_size;            /*     8     1 */

        /* XXX 7 bytes hole, try to pack */

        __u8 *                     hash_location;        /*    16     8 */

Struct size went down from 96B to 88B.

On Wed, Mar 4, 2026 at 6:27 PM Keita Morisaki <kmta1236@gmail.com> wrote:
>
> hash_size is declared but never read. The MD5 path always uses a
> fixed size of 16, and the TCP-AO path uses tcp_ao_maclen().
>
> Suggested-by: Jakub Sitnicki <jakub@cloudflare.com>
> Signed-off-by: Keita Morisaki <kmta1236@gmail.com>

Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>

On Wed, Mar 4, 2026 at 8:37 PM Kuniyuki Iwashima <kuniyu@google.com> wrote:
>
> On Wed, Mar 4, 2026 at 6:27 PM Keita Morisaki <kmta1236@gmail.com> wrote:
> >
> > hash_size is declared but never read. The MD5 path always uses a
> > fixed size of 16, and the TCP-AO path uses tcp_ao_maclen().
> >
> > Suggested-by: Jakub Sitnicki <jakub@cloudflare.com>
> > Signed-off-by: Keita Morisaki <kmta1236@gmail.com>
>
> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>

btw, AFAIU, patchwork does not use git am -3, and this does
not cleanly apply after your another patch and you'll need to respin.

> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Thank you so much for the quick review!

> btw, AFAIU, patchwork does not use git am -3, and this does
> not cleanly apply after your another patch and you'll need to respin.
You're right. Since the first patch (https://lore.kernel.org/netdev/20260304111517.2088694-1-kmta1236@gmail.com/) seems to be close to being merged,
maybe I should rebase this patch on top of the first one after the first one is merged?

On Wed, Mar 4, 2026 at 8:53 PM Keita Morisaki <kmta1236@gmail.com> wrote:
>
> > Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
> Thank you so much for the quick review!
>
> > btw, AFAIU, patchwork does not use git am -3, and this does
> > not cleanly apply after your another patch and you'll need to respin.
> You're right. Since the first patch (https://lore.kernel.org/netdev/20260304111517.2088694-1-kmta1236@gmail.com/) seems to be close to being merged,
> maybe I should rebase this patch on top of the first one after the first one is merged?

Yes, please rebase and send v2 after the patch is merged
(and 24h passes from v1).