netdev - Re: [RFC 4/4] net/ipv4/fib: Don't synchronise

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: <dbcd803c-3347-335e-bc5e-299c33f02b9f@arista.com>
Date:   Tue, 26 Mar 2019 18:17:12 +0000
From:   Dmitry Safonov <dima@...sta.com>
To:     David Ahern <dsahern@...il.com>, linux-kernel@...r.kernel.org
Cc:     Alexander Duyck <alexander.h.duyck@...ux.intel.com>,
        Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        Ido Schimmel <idosch@...lanox.com>, netdev@...r.kernel.org
Subject: Re: [RFC 4/4] net/ipv4/fib: Don't synchronise_rcu() every 512Kb

On 3/26/19 5:57 PM, David Ahern wrote:
> On 3/26/19 11:15 AM, Dmitry Safonov wrote:
>> I still wonder if it's good to expose it to userspace rather than
>> shrinker, but this probably should work for me - I'll test it in near days.
> 
> I did not know about the shrinker, so can not comment if it is better or
> not. If so, my patch can always be reverted since it was just applied.

Oh, don't misunderstand me - I didn't mean to say your patch is wrong,
but I wondered what made this preferable for you.
I've sent my patches as RFC, so probably - it's a place to discuss
what's better, rather than running, rushing and reverting you commit.

Initially, I was also thinking about introducing some sysctl like that,
but thought it's a bit "dirty" solution to expose it to userspace for
tuning, rather than make it work automatically in OOM.

On other side with your sysctl, there are some minor bits, those are
not-yet-perfect and asking to be improved if we go this way:

1. I've noticed that the limit is only being increased or set to zero.
   Which in turn can result in more calls to synchronise rcu than
   needed.
2. The memory summed up under the limit is only tnodes in tnode_free(),
   while nodes are not summed there. Also some tnodes are being freed
   with node_free(), if I'm not mistaken.

So please, don't take me wrong, your patch may also work for me, but
probably worth to discuss both ways and I very much value your opinion here.

Thanks,
          Dmitry