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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 9 May 2022 21:34:58 +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()

Hello Jakub,

On Mon, May 9, 2022 at 7:49 PM Jakub Kicinski <kuba@...nel.org> wrote:
> On Fri,  6 May 2022 11:12:58 -0700 Ricardo Martinez wrote:
>> Helper to calculate the linear data space in the skb.
>>
>> Signed-off-by: Ricardo Martinez <ricardo.martinez@...ux.intel.com>
>> Reviewed-by: Sergey Ryazanov <ryazanov.s.a@...il.com>
>> ---
>>  include/linux/skbuff.h | 5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
>> index 5c2599e3fe7d..d58669d6cb91 100644
>> --- a/include/linux/skbuff.h
>> +++ b/include/linux/skbuff.h
>> @@ -1665,6 +1665,11 @@ static inline void skb_set_end_offset(struct sk_buff *skb, unsigned int offset)
>>  }
>>  #endif
>>
>> +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?

> 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:

$ grep -rn 'skb_end_pointer(.*) [-]' drivers/net/ | sort
drivers/net/ethernet/marvell/mv643xx_eth.c:628: size =
skb_end_pointer(skb) - skb->data;
drivers/net/ethernet/marvell/pxa168_eth.c:322: size =
skb_end_pointer(skb) - skb->data;
drivers/net/ethernet/micrel/ksz884x.c:4764: if (skb_end_pointer(skb) -
skb->data >= 50) {
drivers/net/ethernet/netronome/nfp/ccm_mbox.c:492: undersize =
max_reply_size - (skb_end_pointer(skb) - skb->data);
drivers/net/ethernet/nvidia/forcedeth.c:2073:
(skb_end_pointer(np->rx_skb[i].skb) -
drivers/net/ethernet/nvidia/forcedeth.c:5244: (skb_end_pointer(tx_skb)
- tx_skb->data),
drivers/net/veth.c:775: frame_sz = skb_end_pointer(skb) - skb->head;

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);
2) you may not have access to an allocation size because a driver does
not allocate that skb (consider a xmit path).

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/

--
Sergey