netdev - Re: [PATCH net-next v8 02/14] net: skb: introduce skb_data_area

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: <CAHNKnsTmH-rGgWi3jtyC=ktM1DW2W1VJkYoTMJV2Z_Bt498bsg@mail.gmail.com>
Date:   Tue, 10 May 2022 16:37:27 +0300
From:   Sergey Ryazanov <ryazanov.s.a@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Ricardo Martinez <ricardo.martinez@...ux.intel.com>,
        netdev@...r.kernel.org, linux-wireless@...r.kernel.org,
        David Miller <davem@...emloft.net>,
        Johannes Berg <johannes@...solutions.net>,
        Loic Poulain <loic.poulain@...aro.org>,
        M Chetan Kumar <m.chetan.kumar@...el.com>,
        "Devegowda, Chandrashekar" <chandrashekar.devegowda@...el.com>,
        Intel Corporation <linuxwwan@...el.com>,
        chiranjeevi.rapolu@...ux.intel.com,
        Haijun Liu ( 刘海军) 
        <haijun.liu@...iatek.com>,
        "Hanania, Amir" <amir.hanania@...el.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        "Sharma, Dinesh" <dinesh.sharma@...el.com>,
        "Lee, Eliot" <eliot.lee@...el.com>,
        "Jarvinen, Ilpo Johannes" <ilpo.johannes.jarvinen@...el.com>,
        "Veleta, Moises" <moises.veleta@...el.com>,
        "Bossart, Pierre-louis" <pierre-louis.bossart@...el.com>,
        "Sethuraman, Muralidharan" <muralidharan.sethuraman@...el.com>,
        "Mishra, Soumya Prakash" <Soumya.Prakash.Mishra@...el.com>,
        "Kancharla, Sreehari" <sreehari.kancharla@...el.com>,
        "Sahu, Madhusmita" <madhusmita.sahu@...el.com>
Subject: Re: [PATCH net-next v8 02/14] net: skb: introduce skb_data_area_size()

On Mon, May 9, 2022 at 10:50 PM Jakub Kicinski <kuba@...nel.org> wrote:
> On Mon, 9 May 2022 21:34:58 +0300 Sergey Ryazanov wrote:
>>>> +static inline unsigned int skb_data_area_size(struct sk_buff *skb)
>>>> +{
>>>> +     return skb_end_pointer(skb) - skb->data;
>>>> +}
>>>
>>> Not a great name, skb->data_len is the length of paged data.
>>> There is no such thing as "data area", data is just a pointer
>>> somewhere into skb->head.
>>
> > What name would you recommend for this helper?
>
> We are assuming that skb->data is where we want to start to write
> to so we own the skb. If it's a fresh skb skb->data == skb->tail.
> If it's not fresh but recycled - skb->data is presumably reset
> correctly, and then skb_reset_tail_pointer() has to be called. Either
> way we give HW empty skbs, tailroom is an existing concept we can use.
>
>>> Why do you need this? Why can't you use the size you passed
>>> to the dev_alloc_skb() like everyone else?
>>
>> It was I who suggested to Ricardo to make this helper a common
>> function [1]. So let me begin the discussion, perhaps Ricardo will add
>> to my thoughts as the driver author.
>>
>> There are many other places where authors do the same but without a
>> helper function:
>>
>> [...]
>>
>> There are at least two reasons to evaluate the linear data size from skb:
>> 1) it is difficult to access the same variable that contains a size
>> during skb allocation (consider skb in a queue);
>
> Usually all the Rx skbs on the queue are equally sized so no need to
> save the length per buffer, but perhaps that's not universally true.
>
>> 2) you may not have access to an allocation size because a driver does
>> not allocate that skb (consider a xmit path).
>
> On Tx you should only map the data that's actually populated, for that
> we have skb_headlen().
>
>> Eventually you found themself in a position where you need to carry
>> additional info along with skb. But, on the other hand, you can simply
>> calculate this value from the skb pointers themselves.
>>
>> 1. https://lore.kernel.org/netdev/CAHNKnsTr3aq1sgHnZQFL7-0uHMp3Wt4PMhVgTMSAiiXT=8p35A@mail.gmail.com/
>
> Fair enough, I didn't know more drivers are doing this.
>
> We have two cases:
>  - for Tx - drivers should use skb_headlen();
>  - for Rx - I presume we are either dealing with fresh or correctly
>    reset skbs, so we can use skb_tailroom().

Make sense! Especially your remark that on Tx we should only map
populated data. This short API usage guide even answers my wonder why
the kernel still does not have something like skb_data_area_size().
Thank you for this short and clear clarification.

-- 
Sergey