netdev - Re: [PATCH v2 net-next 08/12] inet: frags: use rhashtables for reassembly units

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]

Message-ID: <6677a301-eacb-8dc3-f780-d59306c9e421@gmail.com>
Date:   Fri, 30 Mar 2018 15:54:48 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Kirill Tkhai <ktkhai@...tuozzo.com>,
        Eric Dumazet <edumazet@...gle.com>,
        "David S . Miller" <davem@...emloft.net>
Cc:     netdev <netdev@...r.kernel.org>, Florian Westphal <fw@...len.de>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Thomas Graf <tgraf@...g.ch>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Alexander Aring <alex.aring@...il.com>,
        Stefan Schmidt <stefan@....samsung.com>,
        Eric Dumazet <eric.dumazet@...il.com>,
        Nikolay Aleksandrov <nikolay@...hat.com>
Subject: Re: [PATCH v2 net-next 08/12] inet: frags: use rhashtables for
 reassembly units



On 03/30/2018 03:44 PM, Kirill Tkhai wrote:
> Hi, Eric,
> 
> thanks for more small patches in v2. One comment below.
> 

>> -
>> -struct inet_frag_bucket {
>> -	struct hlist_head	chain;
>> -	spinlock_t		chain_lock;
>> +	struct netns_frags      *net;
>> +	struct rcu_head		rcu;
> 
> inet_frag_destroy() calls call_rcu() after frags are destroyed.
> It looks like we may place this rcu in union with fragments and
> fragments_tail and to sa

No, because I am planning to free skbs in the rcu call back very shortly.

As I mentioned, I believe we could use pure RCU lookups, without grabing a
reference and then release it after packet is processed/added to the queue.

This is not urgent, I wanted to get the first patches for review before doing
this final step, as I do not expect more than 5 % improvement from this optimization.

Also note that the ipq structure is 192 bytes, nicely using 3 cache lines.

Trying to save 16 bytes will likely reduce performance,  unless we force padding
to reach 192 bytes again :)