netdev - Re: [PATCH net-next] bpf, i40e: Report bpf_prog id during XDP_QUERY

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 21 Jun 2017 20:33:41 +0200
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Alexander Duyck <alexander.duyck@...il.com>,
        John Fastabend <john.fastabend@...il.com>
CC:     David Miller <davem@...emloft.net>,
        Netdev <netdev@...r.kernel.org>, Martin KaFai Lau <kafai@...com>,
        Alexander Duyck <alexander.h.duyck@...el.com>
Subject: Re: [PATCH net-next] bpf, i40e: Report bpf_prog id during XDP_QUERY_PROG

On 06/21/2017 08:23 PM, Alexander Duyck wrote:
> On Wed, Jun 21, 2017 at 10:54 AM, John Fastabend
> <john.fastabend@...il.com> wrote:
>> On 06/21/2017 10:27 AM, Daniel Borkmann wrote:
[...]
>>>   drivers/net/ethernet/intel/i40e/i40e_main.c | 1 +
>>>   1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
>>> index 2db93d3..6f5adb5 100644
>>> --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
>>> +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
>>> @@ -9589,6 +9589,7 @@ static int i40e_xdp(struct net_device *dev,
>>>                return i40e_xdp_setup(vsi, xdp->prog);
>>>        case XDP_QUERY_PROG:
>>>                xdp->prog_attached = i40e_enabled_xdp_vsi(vsi);
>>> +             xdp->prog_id = xdp->prog_attached ? vsi->xdp_prog->aux->id : 0;
>>>                return 0;
>>>        default:
>>>                return -EINVAL;
>>>
>>
>> Looks good to me.
>>
>> Acked-by: John Fastabend <john.fastabend@...il.com>
>
> My preference would be to test for vsi->xdp_prog instead of
> xdp->prog_attached since it is more obvious what is going on in that
> case. We might even want to look at getting rid of the call to
> i40e_enabled_xdp_vsi eventually. But that is probably follow-up work
> for later.

Yeah, given i40e_enabled_xdp_vsi() is just returning !!vsi->xdp_prog
anyway.

> This should work assuming the RTNL lock is always held when this call is made.

That is guaranteed from call-sites, it's strictly required.

> Acked-by: Alexander Duyck <alexander.h.duyck@...el.com>