Re: [PATCH v2 nf-next 5/5] netfilter: nft: rt nexthop for inet family

["Anders K. Pedersen | Cohaesio" <akp@cohaesio.com>]

Hi Liping,

On fre, 2016-10-21 at 10:06 +0800, Liping Zhang wrote:
> Hi Anders,
> 
> 2016-10-20 21:52 GMT+08:00 Anders K. Pedersen | Cohaesio <akp@cohaesi
> o.com>:
> > OK, so would it be okay to replace it with
> > 
> > printk_once(KERN_WARNING KBUILD_MODNAME " Address families do not
> > match\n");
> > 
> > ?

> To this question, I think it's better to do NFT_BREAK sliently, the
> warning
> message seems useless. Actually this can be avoided in userspace,
> i.e. in nft.

Well, as mentioned the suggested userspace implementation for nft does
avoid it by requiring 'ether type' to be specified, when rt nexthop is
used from the inet family, so I found it reasonable to issue a warning,
if it happened anyway.

But okay, I see your point, and I'll remove the warning.

> For example, if you add the following rule in the inet family:
>   # nft add rule inet filter output ip daddr 1.1.1.1
> 
> An implict rule will be added, and this can also be applied to rt
> expr,
> we should first compare nfproto is AF_INET or not:
>    [ meta load nfproto => reg 1 ]
>    [ cmp eq reg 1 0x00000002 ]
> 
> But after I think it carefully, I think the NFTA_RT_FAMILY attr
> seems useless, we can combine these four files nft_rt.c,
> nft_rt_ipv4.c, nft_rt_ipv6.c and nft_rt_inet.c into a single one
> file nft_rt.c.

My implementation is based on the suggestion from Pablo at
http://marc.info/?l=netfilter-devel&m=147438531502686&w=4 .

> For eval, we can use pkt->pf to decide which rt or rt6 nexthop
> to be loaded, so ip/ip6/inet family has the same logical now,
> for example:

Yes, but pkt->pf is not available in init, where we have to answer what
the data size will be.

Regards,
Anders