netdev - Re: [PATCH V2] netfilter: nf_conntrack: table full detailed log

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]

Message-ID: <aILC8COcZTQsj6sG@calendula>
Date: Fri, 25 Jul 2025 01:34:08 +0200
From: Pablo Neira Ayuso <pablo@...filter.org>
To: Florian Westphal <fw@...len.de>
Cc: lvxiafei <xiafei_xupt@....com>, coreteam@...filter.org,
	davem@...emloft.net, edumazet@...gle.com, horms@...nel.org,
	kadlec@...filter.org, kuba@...nel.org, linux-kernel@...r.kernel.org,
	lvxiafei@...setime.com, netdev@...r.kernel.org,
	netfilter-devel@...r.kernel.org, pabeni@...hat.com
Subject: Re: [PATCH V2] netfilter: nf_conntrack: table full detailed log

On Thu, Jul 24, 2025 at 05:26:33PM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@...filter.org> wrote:
> > > +				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.
> 
> Hmm, the conntrack table is full, and packet creates a new flow.
> What would logging the packet tell us what the printk message doesn't?

I was thinking, does the packet logging exposes already the
net->ns.inum? IIUC the goal is to find what netns is dropping what
packet and the reason for the packet drop, not only in this case but
in every case, to ease finding the needle in the stack. If so, then it
probably makes sense to consolidate this around nf_log()
infrastructure.

Anyway, maybe I'm overdoing, I'll be fine with this approach if you
consider it good enough to improve the situation.

Thanks.