netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
To: Eyal Birger <eyal.birger@gmail.com>
Cc: netdev@vger.kernel.org, roopa@cumulusnetworks.com,
	pablo@netfilter.org, xiyou.wangcong@gmail.com,
	davem@davemloft.net, jiri@resnulli.us, jhs@mojatatu.com
Subject: Re: [PATCH net-next 2/5] net: sched: em_ipt: set the family based on the protocol when matching
Date: Wed, 26 Jun 2019 16:45:28 +0300	[thread overview]
Message-ID: <9a3be271-af15-3fef-9612-7a3232d09b32@cumulusnetworks.com> (raw)
In-Reply-To: <20190626163353.6d5535cb@jimi>

On 26/06/2019 16:33, Eyal Birger wrote:
> Hi Nikolay,
>    
> On Wed, 26 Jun 2019 14:58:52 +0300
> Nikolay Aleksandrov <nikolay@cumulusnetworks.com> wrote:
> 
>> Set the family based on the protocol otherwise protocol-neutral
>> matches will have wrong information (e.g. NFPROTO_UNSPEC). In
>> preparation for using NFPROTO_UNSPEC xt matches.
>>
>> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
>> ---
>>  net/sched/em_ipt.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/sched/em_ipt.c b/net/sched/em_ipt.c
>> index 64dbafe4e94c..23965a071177 100644
>> --- a/net/sched/em_ipt.c
>> +++ b/net/sched/em_ipt.c
>> @@ -189,10 +189,12 @@ static int em_ipt_match(struct sk_buff *skb,
>> struct tcf_ematch *em, case htons(ETH_P_IP):
>>  		if (!pskb_network_may_pull(skb, sizeof(struct
>> iphdr))) return 0;
>> +		state.pf = NFPROTO_IPV4;
>>  		break;
>>  	case htons(ETH_P_IPV6):
>>  		if (!pskb_network_may_pull(skb, sizeof(struct
>> ipv6hdr))) return 0;
>> +		state.pf = NFPROTO_IPV6;
>>  		break;
>>  	default:
>>  		return 0;
>> @@ -203,7 +205,7 @@ static int em_ipt_match(struct sk_buff *skb,
>> struct tcf_ematch *em, if (skb->skb_iif)
>>  		indev = dev_get_by_index_rcu(em->net, skb->skb_iif);
>>  
>> -	nf_hook_state_init(&state, im->hook, im->match->family,
>> +	nf_hook_state_init(&state, im->hook, state.pf,
>>  			   indev ?: skb->dev, skb->dev, NULL,
>> em->net, NULL); 
>>  	acpar.match = im->match;
> 
> I think this change is incompatible with current behavior.
> 
> Consider the 'policy' match which matches the packet's xfrm state (sec_path)
> with the provided user space parameters. The sec_path includes information
> about the encapsulating packet's parameters whereas the current skb points to
> the encapsulated packet, and the match is done on the encapsulating
> packet's info.
> 
> So if you have an IPv6 packet encapsulated within an IPv4 packet, the match
> parameters should be done using IPv4 parameters, not IPv6.
> 
> Maybe use the packet's family only if the match family is UNSPEC?
> 
> Eyal.
> 

Hi Eyal,
I see your point, I was wondering about the xfrm cases. :)
In such case I think we can simplify the set and do it only on UNSPEC matches as you suggest.

Maybe we should enforce the tc protocol based on the user-specified nfproto at least from
iproute2 otherwise people can add mismatching rules (e.g. nfproto == v6, tc proto == v4).

Thanks,
 Nik

  reply	other threads:[~2019-06-26 13:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-26 11:58 [PATCH net-next 0/5] em_ipt: add support for addrtype Nikolay Aleksandrov
2019-06-26 11:58 ` [PATCH net-next 1/5] net: sched: em_ipt: match only on ip/ipv6 traffic Nikolay Aleksandrov
2019-06-26 11:58 ` [PATCH net-next 2/5] net: sched: em_ipt: set the family based on the protocol when matching Nikolay Aleksandrov
2019-06-26 13:33   ` Eyal Birger
2019-06-26 13:45     ` Nikolay Aleksandrov [this message]
2019-06-26 16:22       ` Eyal Birger
2019-06-26 16:38         ` nikolay
2019-06-26 11:58 ` [PATCH net-next 3/5] net: sched: em_ipt: restrict matching to the respective protocol Nikolay Aleksandrov
2019-06-26 11:58 ` [PATCH net-next 4/5] net: sched: em_ipt: keep the user-specified nfproto and use it Nikolay Aleksandrov
2019-06-26 11:58 ` [PATCH net-next 5/5] net: sched: em_ipt: add support for addrtype matching Nikolay Aleksandrov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9a3be271-af15-3fef-9612-7a3232d09b32@cumulusnetworks.com \
    --to=nikolay@cumulusnetworks.com \
    --cc=davem@davemloft.net \
    --cc=eyal.birger@gmail.com \
    --cc=jhs@mojatatu.com \
    --cc=jiri@resnulli.us \
    --cc=netdev@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=roopa@cumulusnetworks.com \
    --cc=xiyou.wangcong@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).