Re: [PATCH net-next] tcp: Fix tcp_syn_flood_action() if CONFIG_IPV6=n

[Jamie Bainbridge]

On Thu, 17 Nov 2022 at 07:31, Jakub Kicinski <kuba@xxxxxxxxxx> wrote:
>
> On Tue, 15 Nov 2022 11:12:16 +0100 Geert Uytterhoeven wrote:
> > If CONFIG_IPV6=n:
> >
> >     net/ipv4/tcp_input.c: In function ‘tcp_syn_flood_action’:
> >     include/net/sock.h:387:37: error: ‘const struct sock_common’ has no member named ‘skc_v6_rcv_saddr’; did you mean ‘skc_rcv_saddr’?
> >       387 | #define sk_v6_rcv_saddr __sk_common.skc_v6_rcv_saddr
> >         |                                     ^~~~~~~~~~~~~~~~
> >     include/linux/printk.h:429:19: note: in definition of macro ‘printk_index_wrap’
> >       429 |   _p_func(_fmt, ##__VA_ARGS__);    \
> >         |                   ^~~~~~~~~~~
> >     include/linux/printk.h:530:2: note: in expansion of macro ‘printk’
> >       530 |  printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
> >         |  ^~~~~~
> >     include/linux/net.h:272:3: note: in expansion of macro ‘pr_info’
> >       272 |   function(__VA_ARGS__);    \
> >         |   ^~~~~~~~
> >     include/linux/net.h:288:2: note: in expansion of macro ‘net_ratelimited_function’
> >       288 |  net_ratelimited_function(pr_info, fmt, ##__VA_ARGS__)
> >         |  ^~~~~~~~~~~~~~~~~~~~~~~~
> >     include/linux/net.h:288:43: note: in expansion of macro ‘sk_v6_rcv_saddr’
> >       288 |  net_ratelimited_function(pr_info, fmt, ##__VA_ARGS__)
> >         |                                           ^~~~~~~~~~~
> >     net/ipv4/tcp_input.c:6847:4: note: in expansion of macro ‘net_info_ratelimited’
> >      6847 |    net_info_ratelimited("%s: Possible SYN flooding on port [%pI6c]:%u. %s.\n",
> >         |    ^~~~~~~~~~~~~~~~~~~~
> >
> > Fix this by using "#if" instead of "if", like is done for all other
> > checks for CONFIG_IPV6.
> >
> > Fixes: d9282e48c6088105 ("tcp: Add listening address to SYN flood message")
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>
>
> Sorry for the late reaction, this now conflicts with bf36267e3ad3df8
>
> I was gonna hand edit but perhaps we can do better with the ifdef
> formation.
>
> Instead of
>
> #ifdef v6
>         if (v6) {
>                 expensive_call6();
>         } else    //  d k
> #endif            //  o i
>         {         //  o e
>                 expensive_call4();
>         }

I actually started off using this way in my v1. I did that
intentionally because that pattern already exists in other places,
discussed at:

 https://lore.kernel.org/netdev/CAAvyFNg1F8ixrgy0YeL-TT5xLmk8N7dD=ZMLQ6VxsjHb_PU9bg@xxxxxxxxxxxxxx/

or just see:

 grep -C1 -ERHn "IS_ENABLED\(CONFIG_IPV6\)" net | grep -C1 "family == AF_INET6"

Geert's patch adheres to existing style, which seems the better option?

> Can we go with:
>
> #ifdef v6
>         if (v6)
>                 expensive_call6();
>         else
> #endif
>                 expensive_call4();

This is a nested if, so it really should have braces to prevent
dangling else, both now and in the future.

> or
>
>         if (v4) {
>                 expensive_call4();
> #ifdef v6
>         } else {
>                 expensive_call6();
> #endif
>         }
> or
>
>         if (v6) {
> #ifdef v6
>                 expensive_call6();
> #endif
>         } else {
>                 expensive_call6();
>         }

These should work, but I expect they cause a comparison which can't be
optimised out at compile time. This is probably why the first style
exists.

In this SYN flood codepath optimisation doesn't matter because we're
doing ratelimited logging anyway. But if we're breaking with existing
style, then wouldn't the others also have to change to this style? I
haven't reviewed all the other usage to tell if they're in an oft-used
fastpath where such a thing might matter.

It seems Geert's patch style is the best way.

Jamie