expectation mask handling in nfctnetlink

Yasuyuki KOZAKAI yasuyuki.kozakai at toshiba.co.jp
Wed Feb 1 14:35:17 CET 2006


Hi,

From: Patrick McHardy <kaber at trash.net>
Date: Wed, 01 Feb 2006 12:04:02 +0100

> Pablo Neira Ayuso wrote:
> > a) just remove the unlikely() statement.
> > Drawback: Not so efficient, since that checking isn't always required.
> 
> I'm not sure I understand the problem. Is it about the unlikely in
> __nf_ct_proto_find?

Yes.

>                     That one is most likely not making any difference
> at all, since there is no code to reorder.

Pablo pointed out ...

From: Pablo Neira Ayuso <pablo at netfilter.org>
Date: Fri, 13 Jan 2006 12:17:16 +0100

> Yasuyuki KOZAKAI wrote:
> > diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
> > index 62bb509..9a147dd 100644
> > --- a/net/netfilter/nf_conntrack_core.c
> > +++ b/net/netfilter/nf_conntrack_core.c
> > @@ -188,7 +188,7 @@ extern struct nf_conntrack_protocol nf_c
> >  struct nf_conntrack_protocol *
> >  __nf_ct_proto_find(u_int16_t l3proto, u_int8_t protocol)
> >  {
> > -	if (unlikely(nf_ct_protos[l3proto] == NULL))
> > +	if (unlikely(l3proto > AF_MAX || nf_ct_protos[l3proto] == NULL))
> 
> Could the unlikely statement be bad at expectation dumping?

I thought unlikely() was ok but current ctnetlink_exp_dump_expect() was
strange because it trys to find proto with 0xffff as address family and 0xff
as protocol number.

But I understood from Pablo's mail, that we have not decided what contents
should be included in netlink message for expectation mask yet, then I agreed
to remove unlikely() for now.

-- Yasuyuki Kozakai



More information about the netfilter-devel mailing list