From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesper Dangaard Brouer Subject: Re: [net PATCH] netfilter: only warn once on wrong seqadj usage Date: Mon, 6 Jan 2014 08:32:39 +0100 Message-ID: <20140106083239.7811ac9e@redhat.com> References: <20140104130944.28481.30891.stgit@dragon> <20140104131648.GA18176@macbook.localnet> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Jesper Dangaard Brouer , Pablo Neira Ayuso , "David S. Miller" , netdev@vger.kernel.org, netfilter-devel@vger.kernel.org, Florian Westphal , Daniel Borkmann , Flavio Leitner , "lvs-devel@vger.kernel.org" To: Patrick McHardy Return-path: In-Reply-To: <20140104131648.GA18176@macbook.localnet> Sender: lvs-devel-owner@vger.kernel.org List-Id: netfilter-devel.vger.kernel.org On Sat, 4 Jan 2014 13:16:48 +0000 Patrick McHardy wrote: > On Sat, Jan 04, 2014 at 02:10:43PM +0100, Jesper Dangaard Brouer wrote: > > Avoid potentially spamming the kernel log with WARN splash messages > > when catching wrong usage of seqadj, by simply using WARN_ONCE. > > > > This is a followup to commit db12cf274353 (netfilter: WARN about > > wrong usage of sequence number adjustments) > > > > Suggested-by: Flavio Leitner > > Suggested-by: Daniel Borkmann > > Suggested-by: Florian Westphal > > Signed-off-by: Jesper Dangaard Brouer > > --- > > Nitpick found by internal RedHat review process ;-) > > > > net/netfilter/nf_conntrack_seqadj.c | 2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/net/netfilter/nf_conntrack_seqadj.c b/net/netfilter/nf_conntrack_seqadj.c > > index b2d38da..f6e2ae9 100644 > > --- a/net/netfilter/nf_conntrack_seqadj.c > > +++ b/net/netfilter/nf_conntrack_seqadj.c > > @@ -37,7 +37,7 @@ int nf_ct_seqadj_set(struct nf_conn *ct, enum ip_conntrack_info ctinfo, > > return 0; > > > > if (unlikely(!seqadj)) { > > - WARN(1, "Wrong seqadj usage, missing nfct_seqadj_ext_add()\n"); > > + WARN_ONCE(1, "Missing nfct_seqadj_ext_add() setup call\n"); > > return 0; > > I missed the patch that added the WARN. Since when do we add runtime checks > for API misuse instead of simply letting it crash? We changed an existing API which broke IPVS. And I think we still have a use-case in IPVS, which can hit this case/bug, thus I added a stack dump warning (instead of crashing), so I can catch this use-case and fix it later. -- Best regards, Jesper Dangaard Brouer MSc.CS, Sr. Network Kernel Developer at Red Hat Author of http://www.iptv-analyzer.org LinkedIn: http://www.linkedin.com/in/brouer