public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Florian Westphal <fw@strlen.de>
Cc: lvxiafei <xiafei_xupt@163.com>,
	coreteam@netfilter.org, davem@davemloft.net, edumazet@google.com,
	horms@kernel.org, kadlec@netfilter.org, kuba@kernel.org,
	linux-kernel@vger.kernel.org, lvxiafei@sensetime.com,
	netdev@vger.kernel.org, netfilter-devel@vger.kernel.org,
	pabeni@redhat.com
Subject: Re: [PATCH V2] netfilter: nf_conntrack: table full detailed log
Date: Fri, 25 Jul 2025 01:34:08 +0200	[thread overview]
Message-ID: <aILC8COcZTQsj6sG@calendula> (raw)
In-Reply-To: <aIJQqacIH7jAzoEa@strlen.de>

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

  reply	other threads:[~2025-07-24 23:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-08  8:13 [PATCH] netfilter: nf_conntrack: table full detailed log lvxiafei
2025-05-21 10:28 ` Pablo Neira Ayuso
2025-05-22  9:13   ` lvxiafei
2025-05-22  9:19 ` [PATCH V2] " lvxiafei
2025-07-23  1:02   ` Pablo Neira Ayuso
2025-07-24 15:26     ` Florian Westphal
2025-07-24 23:34       ` Pablo Neira Ayuso [this message]
2025-07-24 23:55         ` Florian Westphal
2025-07-25  9:55           ` Pablo Neira Ayuso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aILC8COcZTQsj6sG@calendula \
    --to=pablo@netfilter.org \
    --cc=coreteam@netfilter.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=fw@strlen.de \
    --cc=horms@kernel.org \
    --cc=kadlec@netfilter.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lvxiafei@sensetime.com \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=xiafei_xupt@163.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox