On Thu, May 22, 2025 at 05:19:54PM +0800, lvxiafei wrote:
> From: lvxiafei <lvxiafei@xxxxxxxxxxxxx>
>
> Add the netns field in the "nf_conntrack: table full,
> dropping packet" log to help locate the specific netns
> when the table is full.
>
> Signed-off-by: lvxiafei <lvxiafei@xxxxxxxxxxxxx>
> ---
> net/netfilter/nf_conntrack_core.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
> index 7f8b245e287a..47036a9d4acc 100644
> --- a/net/netfilter/nf_conntrack_core.c
> +++ b/net/netfilter/nf_conntrack_core.c
> @@ -1659,7 +1659,11 @@ __nf_conntrack_alloc(struct net *net,
> if (!conntrack_gc_work.early_drop)
> conntrack_gc_work.early_drop = true;
> atomic_dec(&cnet->count);
> - net_warn_ratelimited("nf_conntrack: table full, dropping packet\n");
> + if (net == &init_net)
> + net_warn_ratelimited("nf_conntrack: table full, dropping packet\n");
> + else
> + net_warn_ratelimited("nf_conntrack: table full in netns %u, dropping packet\n",
> + net->ns.inum);
This is slightly better, but it still does not say what packet has
been dropped, right?
Probably a similar approach to nf_tcp_log_invalid() would better here.
Thus, nf_log infrastructure could be used as logging hub.
Logging the packet probably provides more context information than
simply logging the netns inode number.
