Re: [PATCH nf] netfilter: ctnetlink: remove expired entries first

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Dec 9, 2021 at 4:39 PM Florian Westphal <fw@xxxxxxxxx> wrote:
>
> When dumping conntrack table to userspace via ctnetlink, check if the ct has
> already expired before doing any of the 'skip' checks.
>
> This expires dead entries faster.
> /proc handler also removes outdated entries first.
>
> Reported-by: Vitaly Zuevsky <vzuevsky@xxxxxxx>
> Signed-off-by: Florian Westphal <fw@xxxxxxxxx>
> ---
>  Vitaly, I suspect this might be related to the issue you reported,
>  I suspect we skip the NAT-clash entries instead of evicting them from
>  ctnetlink path too.
>
>  net/netfilter/nf_conntrack_netlink.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c
> index 81d03acf68d4..ec4164c32d27 100644
> --- a/net/netfilter/nf_conntrack_netlink.c
> +++ b/net/netfilter/nf_conntrack_netlink.c
> @@ -1195,8 +1195,6 @@ ctnetlink_dump_table(struct sk_buff *skb, struct netlink_callback *cb)
>                 }
>                 hlist_nulls_for_each_entry(h, n, &nf_conntrack_hash[cb->args[0]],
>                                            hnnode) {
> -                       if (NF_CT_DIRECTION(h) != IP_CT_DIR_ORIGINAL)
> -                               continue;
>                         ct = nf_ct_tuplehash_to_ctrack(h);
>                         if (nf_ct_is_expired(ct)) {
>                                 if (i < ARRAY_SIZE(nf_ct_evict) &&
> @@ -1208,6 +1206,9 @@ ctnetlink_dump_table(struct sk_buff *skb, struct netlink_callback *cb)
>                         if (!net_eq(net, nf_ct_net(ct)))
>                                 continue;
>
> +                       if (NF_CT_DIRECTION(h) != IP_CT_DIR_ORIGINAL)
> +                               continue;
> +
>                         if (cb->args[1]) {
>                                 if (ct != last)
>                                         continue;
> --
> 2.32.0
>

Florian, thanks for prompt turnaround on this. Seeing
conntrack -C
107530
mandates the check what flows consume this many entries. I cannot do
this if conntrack -L skips anything while kernel defaults to not
exposing conntrack table via /proc. This server is not supposed to NAT
anything by the way. We use some -j NOTRACK rules and I'd like to see
what flows evade those rules and consume so many slots. Could you
perhaps recommend a way to achieve this other than reconfiguring the
kernel?



[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux