Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <f847459dc0a0e2d8ffa1d290d06e0e4a226a6f39.1668075479.git.jamie.bainbridge@gmail.com>
 <Y20Bxc1gQ8nrFsvA@lunn.ch>
In-Reply-To: <Y20Bxc1gQ8nrFsvA@lunn.ch>
From:   Jamie Bainbridge <jamie.bainbridge@gmail.com>
Date:   Fri, 11 Nov 2022 08:20:18 +1100
Message-ID: <CAAvyFNg1F8ixrgy0YeL-TT5xLmk8N7dD=ZMLQ6VxsjHb_PU9bg@mail.gmail.com>
Subject: Re: [PATCH] tcp: Add listening address to SYN flood message
To:     Andrew Lunn <andrew@lunn.ch>
Cc:     Eric Dumazet <edumazet@google.com>,
        "David S. Miller" <davem@davemloft.net>,
        Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
        David Ahern <dsahern@kernel.org>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, 11 Nov 2022 at 00:51, Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Thu, Nov 10, 2022 at 09:21:06PM +1100, Jamie Bainbridge wrote:
> > The SYN flood message prints the listening port number, but on a system
> > with many processes bound to the same port on different IPs, it's
> > impossible to tell which socket is the problem.
> >
> > Add the listen IP address to the SYN flood message. It might have been
> > nicer to print the address first, but decades of monitoring tools are
> > watching for the string "SYN flooding on port" so don't break that.
> >
> > Tested with each protcol's "any" address and a host address:
> >
> >  Possible SYN flooding on port 9001. IP 0.0.0.0.
> >  Possible SYN flooding on port 9001. IP 127.0.0.1.
> >  Possible SYN flooding on port 9001. IP ::.
> >  Possible SYN flooding on port 9001. IP fc00::1.
> >
> > Signed-off-by: Jamie Bainbridge <jamie.bainbridge@gmail.com>
> > ---
> >  net/ipv4/tcp_input.c | 16 +++++++++++++---
> >  1 file changed, 13 insertions(+), 3 deletions(-)
> >
> > diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> > index 0640453fce54b6daae0861d948f3db075830daf6..fb86056732266fedc8ad574bbf799dbdd7a425a3 100644
> > --- a/net/ipv4/tcp_input.c
> > +++ b/net/ipv4/tcp_input.c
> > @@ -6831,9 +6831,19 @@ static bool tcp_syn_flood_action(const struct sock *sk, const char *proto)
> >               __NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPREQQFULLDROP);
> >
> >       if (!queue->synflood_warned && syncookies != 2 &&
> > -         xchg(&queue->synflood_warned, 1) == 0)
> > -             net_info_ratelimited("%s: Possible SYN flooding on port %d. %s.  Check SNMP counters.\n",
> > -                                  proto, sk->sk_num, msg);
> > +         xchg(&queue->synflood_warned, 1) == 0) {
> > +#if IS_ENABLED(CONFIG_IPV6)
> > +             if (sk->sk_family == AF_INET6) {
>
> Can the IS_ENABLED() go inside the if? You get better build testing
> that way.
>
>      Andrew

Are you sure? Why would the IS_ENABLED() be inside of a condition
which isn't compiled in? If IPv6 isn't compiled in then the condition
would never evaluate as true, so seems pointless a pointless
comparison to make? People not compiling in IPv6 have explicitly asked
*not* to have their kernel filled with a bunch of "if (family ==
AF_INET6)" haven't they?

There are many other examples of this pattern of "IS_ENABLED()" first
and "if (family == AF_INET6)" inside it, but I can't see any of the
inverse which I think you're suggesting, see:

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

Please let me know if I've misunderstood?

Jamie