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