netdev - Re: [PATCH v7 bpf-next 05/10] veth: Handle xdp

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]

Message-ID: <d7ef0a42-1ea0-587e-3dfc-20558ba0a428@gmail.com>
Date:   Thu, 2 Aug 2018 23:10:38 +0900
From:   Toshiaki Makita <toshiaki.makita1@...il.com>
To:     Jesper Dangaard Brouer <brouer@...hat.com>
Cc:     Toshiaki Makita <makita.toshiaki@....ntt.co.jp>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>, netdev@...r.kernel.org,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        John Fastabend <john.fastabend@...il.com>
Subject: Re: [PATCH v7 bpf-next 05/10] veth: Handle xdp_frames in xdp napi
 ring

On 18/08/02 (木) 22:53, Jesper Dangaard Brouer wrote:
> On Thu, 2 Aug 2018 22:17:53 +0900
> Toshiaki Makita <toshiaki.makita1@...il.com> wrote:
> 
>> On 18/08/02 (木) 20:45, Jesper Dangaard Brouer wrote:
>>> On Thu,  2 Aug 2018 19:55:09 +0900
>>> Toshiaki Makita <makita.toshiaki@....ntt.co.jp> wrote:
>>>    
>>>> +	headroom = frame->data - delta - (void *)frame;
>>>
>>> Your calculation of headroom is still adding an assumption that
>>> xdp_frame is located in the top of data area, that is unnecessary.
>>>
>>> The headroom can be calculated as:
>>>
>>>    headroom = sizeof(struct xdp_frame) + frame->headroom - delta;
>>
>> Thanks. But I'm not sure I get what you are requesting.
> 
> I'm simply requesting you do not use the (void *)frame pointer address,
> to calculate the headroom, as it can be calculated in another way.

I don't see difference, but ok I can change this calculation as you 
prefer a different way.

>> Supposing xdp_frame is not located in the top of data area, what ensures
>> that additional sizeof(struct xdp_frame) can be used?
> 
> The calculation in convert_to_xdp_frame() assures this.  If we later
> add an xdp_frame that is not located in the top of data area, and want
> to change the reserved headroom size, then we deal with it, and update
> the code.

I just thought you are requesting the change so that we don't need to 
change this code even when convert_to_xdp_frame() is changed. Now I see 
my guess was wrong.

will send v8.

Thanks,
Toshiaki Makita