From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: [net PATCH] netfilter: only warn once on wrong seqadj usage Date: Sat, 4 Jan 2014 13:16:48 +0000 Message-ID: <20140104131648.GA18176@macbook.localnet> References: <20140104130944.28481.30891.stgit@dragon> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Pablo Neira Ayuso , "David S. Miller" , netdev@vger.kernel.org, netfilter-devel@vger.kernel.org, Florian Westphal , Daniel Borkmann , Flavio Leitner To: Jesper Dangaard Brouer Return-path: Received: from stinky.trash.net ([213.144.137.162]:34945 "EHLO stinky.trash.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752042AbaADNRH (ORCPT ); Sat, 4 Jan 2014 08:17:07 -0500 Content-Disposition: inline In-Reply-To: <20140104130944.28481.30891.stgit@dragon> Sender: netfilter-devel-owner@vger.kernel.org List-ID: 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?