On Thu, Jul 24, 2025 at 05:26:33PM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> 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.
