Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <c25691a0-96ab-34de-4739-524cd3ab1875@gmail.com>
Date:   Tue, 22 Feb 2022 07:39:49 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.6.0
Subject: Re: [PATCH net-next v3 4/4] net: tun: track dropped skb via
 kfree_skb_reason()
Content-Language: en-US
To:     Dongli Zhang <dongli.zhang@oracle.com>, netdev@vger.kernel.org,
        bpf@vger.kernel.org
Cc:     linux-kernel@vger.kernel.org, davem@davemloft.net, kuba@kernel.org,
        rostedt@goodmis.org, mingo@redhat.com, ast@kernel.org,
        daniel@iogearbox.net, andrii@kernel.org, imagedong@tencent.com,
        joao.m.martins@oracle.com, joe.jin@oracle.com, edumazet@google.com
References: <20220221053440.7320-1-dongli.zhang@oracle.com>
 <20220221053440.7320-5-dongli.zhang@oracle.com>
 <877dfc5d-c3a1-463f-3abc-15e5827cfdb6@gmail.com>
 <6eab223b-028d-c822-01ad-47e5869e0fe8@oracle.com>
From:   David Ahern <dsahern@gmail.com>
In-Reply-To: <6eab223b-028d-c822-01ad-47e5869e0fe8@oracle.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 2/21/22 9:45 PM, Dongli Zhang wrote:
> Hi David,
> 
> On 2/21/22 7:28 PM, David Ahern wrote:
>> On 2/20/22 10:34 PM, Dongli Zhang wrote:
>>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>>> index aa27268..bf7d8cd 100644
>>> --- a/drivers/net/tun.c
>>> +++ b/drivers/net/tun.c
>>> @@ -1062,13 +1062,16 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
>>>  	struct netdev_queue *queue;
>>>  	struct tun_file *tfile;
>>>  	int len = skb->len;
>>> +	enum skb_drop_reason drop_reason;
>>
>> this function is already honoring reverse xmas tree style, so this needs
>> to be moved up.
> 
> I will move this up to before "int txq = skb->queue_mapping;".
> 
>>
>>>  
>>>  	rcu_read_lock();
>>>  	tfile = rcu_dereference(tun->tfiles[txq]);
>>>  
>>>  	/* Drop packet if interface is not attached */
>>> -	if (!tfile)
>>> +	if (!tfile) {
>>> +		drop_reason = SKB_DROP_REASON_DEV_READY;
>>>  		goto drop;
>>> +	}
>>>  
>>>  	if (!rcu_dereference(tun->steering_prog))
>>>  		tun_automq_xmit(tun, skb);
>>> @@ -1078,22 +1081,32 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
>>>  	/* Drop if the filter does not like it.
>>>  	 * This is a noop if the filter is disabled.
>>>  	 * Filter can be enabled only for the TAP devices. */
>>> -	if (!check_filter(&tun->txflt, skb))
>>> +	if (!check_filter(&tun->txflt, skb)) {
>>> +		drop_reason = SKB_DROP_REASON_DEV_FILTER;
>>>  		goto drop;
>>> +	}
>>>  
>>>  	if (tfile->socket.sk->sk_filter &&
>>> -	    sk_filter(tfile->socket.sk, skb))
>>> +	    sk_filter(tfile->socket.sk, skb)) {
>>> +		drop_reason = SKB_DROP_REASON_SOCKET_FILTER;
>>>  		goto drop;
>>> +	}
>>>  
>>>  	len = run_ebpf_filter(tun, skb, len);
>>> -	if (len == 0)
>>> +	if (len == 0) {
>>> +		drop_reason = SKB_DROP_REASON_BPF_FILTER;
>>
>> how does this bpf filter differ from SKB_DROP_REASON_SOCKET_FILTER? I
>> think the reason code needs to be a little clearer on the distinction.
>>
> 
> 
> While there is a diff between BPF_FILTER (here) and SOCKET_FILTER ...
> 
> ... indeed the issue is: there is NO diff between BPF_FILTER (here) and
> DEV_FILTER (introduced by the patch).
> 
> 
> The run_ebpf_filter() is to run the bpf filter attached to the TUN device (not
> socket). This is similar to DEV_FILTER, which is to run a device specific filter.
> 
> Initially, I would use DEV_FILTER at both locations. This makes trouble to me as
> there would be two places with same reason=DEV_FILTER. I will not be able to
> tell where the skb is dropped.
> 
> 
> I was thinking about to introduce a SKB_DROP_REASON_DEV_BPF. While I have
> limited experience in device specific bpf, the TUN is the only device I know
> that has a device specific ebpf filter (by commit aff3d70a07ff ("tun: allow to
> attach ebpf socket filter")). The SKB_DROP_REASON_DEV_BPF is not generic enough
> to be re-used by other drivers.
> 
> 
> Would you mind sharing your suggestion if I would re-use (1)
> SKB_DROP_REASON_DEV_FILTER or (2) introduce a new SKB_DROP_REASON_DEV_BPF, which
> is for sk_buff dropped by ebpf attached to device (not socket).
> 
> 
> To answer your question, the SOCKET_FILTER is for filter attached to socket, the
> BPF_FILTER was supposed for ebpf filter attached to device (tun->filter_prog).
> 
> 

tun/tap does have some unique filtering options. The other sets focused
on the core networking stack is adding a drop reason of
SKB_DROP_REASON_BPF_CGROUP_EGRESS for cgroup based egress filters.

For tun unique filters, how about using a shortened version of the ioctl
name used to set the filter.