netdev - Re: [PATCH net] tcp: Fix -Wc23-extensions in tcp_options

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 1 Nov 2023 18:07:23 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Palmer Dabbelt <palmer@...belt.com>
Cc: edumazet@...gle.com, davem@...emloft.net, dsahern@...nel.org,
	kuba@...nel.org, pabeni@...hat.com, ndesaulniers@...gle.com,
	trix@...hat.com, 0x7f454c46@...il.com, fruggeri@...sta.com,
	noureddine@...sta.com, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, llvm@...ts.linux.dev,
	patches@...ts.linux.dev
Subject: Re: [PATCH net] tcp: Fix -Wc23-extensions in tcp_options_write()

On Wed, Nov 01, 2023 at 05:41:10PM -0700, Palmer Dabbelt wrote:
> On Tue, 31 Oct 2023 13:23:35 PDT (-0700), nathan@...nel.org wrote:
> > Clang warns (or errors with CONFIG_WERROR=y) when CONFIG_TCP_AO is set:
> > 
> >   net/ipv4/tcp_output.c:663:2: error: label at end of compound statement is a C23 extension [-Werror,-Wc23-extensions]
> >     663 |         }
> >         |         ^
> >   1 error generated.
> > 
> > On earlier releases (such as clang-11, the current minimum supported
> > version for building the kernel) that do not support C23, this was a
> > hard error unconditionally:
> > 
> >   net/ipv4/tcp_output.c:663:2: error: expected statement
> >           }
> >           ^
> >   1 error generated.
> > 
> > Add a semicolon after the label to create an empty statement, which
> > resolves the warning or error for all compilers.
> > 
> > Closes: https://github.com/ClangBuiltLinux/linux/issues/1953
> > Fixes: 1e03d32bea8e ("net/tcp: Add TCP-AO sign to outgoing packets")
> > Signed-off-by: Nathan Chancellor <nathan@...nel.org>
> > ---
> >  net/ipv4/tcp_output.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> > index f558c054cf6e..6064895daece 100644
> > --- a/net/ipv4/tcp_output.c
> > +++ b/net/ipv4/tcp_output.c
> > @@ -658,7 +658,7 @@ static void tcp_options_write(struct tcphdr *th, struct tcp_sock *tp,
> >  			memset(ptr, TCPOPT_NOP, sizeof(*ptr));
> >  			ptr++;
> >  		}
> > -out_ao:
> > +out_ao:;
> >  #endif
> >  	}
> >  	if (unlikely(opts->mss)) {
> > 
> > ---
> > base-commit: 55c900477f5b3897d9038446f72a281cae0efd86
> > change-id: 20231031-tcp-ao-fix-label-in-compound-statement-warning-ebd6c9978498
> > 
> > Best regards,
> 
> This gives me a
> 
> linux/net/ipv4/tcp_output.c:663:2: error: expected statement
>        }
> 
> on GCC for me.

What GCC version?

I cannot reproduce that error with my patch applied. I tested mainline
at commit deefd5024f07 ("Merge tag 'vfio-v6.7-rc1' of
https://github.com/awilliam/linux-vfio") using GCC 6 from kernel.org and
I can reproduce a similar failure with ARCH=x86_64 allyesconfig:

  net/ipv4/tcp_output.c: In function 'tcp_options_write':
  net/ipv4/tcp_output.c:661:1: error: label at end of compound statement
   out_ao:
   ^~~~~~

With this change applied, the error disappears for GCC 6 and GCC 13
continues to build without error. I can try the other supported versions
later, I just did an older and newer one for a quick test.

> So I think something like
> 
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index f558c054cf6e..ca09763acaa8 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -659,6 +659,11 @@ static void tcp_options_write(struct tcphdr *th, struct tcp_sock *tp,
> 			ptr++;
> 		}
> out_ao:
> +	/*
> +	 * Labels at the end of compound statements are a C23 feature, so
> +	 * introduce a block to avoid a warning/error on strict toolchains.
> +	 */
> +	{}
> #endif
> 	}
> 	if (unlikely(opts->mss)) {
> 
> should do it (though it's still build testing...)

I am not opposed to this once we understand what versions are affected
by this so that we have some timeline of removing this workaround.

Cheers,
Nathan