[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20180322.151414.425331877216053698.davem@davemloft.net>
Date: Thu, 22 Mar 2018 15:14:14 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: ktkhai@...tuozzo.com
Cc: yoshfuji@...ux-ipv6.org, edumazet@...gle.com,
yanhaishuang@...s.chinamobile.com, nikolay@...ulusnetworks.com,
yotamg@...lanox.com, soheil@...gle.com, avagin@...tuozzo.com,
nicolas.dichtel@...nd.com, ebiederm@...ssion.com, fw@...len.de,
roman.kapl@...go.com, netdev@...r.kernel.org,
xiyou.wangcong@...il.com, dvyukov@...gle.com,
andreyknvl@...gle.com, lkp@...el.com
Subject: Re: [PATCH net-next v3 0/5] Rework ip_ra_chain protection
From: Kirill Tkhai <ktkhai@...tuozzo.com>
Date: Thu, 22 Mar 2018 12:44:46 +0300
> Commit 1215e51edad1 "ipv4: fix a deadlock in ip_ra_control"
> made rtnl_lock() be used in raw_close(). This function is called
> on every RAW socket destruction, so that rtnl_mutex is taken
> every time. This scales very sadly. I observe cleanup_net()
> spending a lot of time in rtnl_lock() and raw_close() is one
> of the biggest rtnl user (since we have percpu net->ipv4.icmp_sk).
>
> This patchset reworks the locking: reverts the problem commit
> and its descendant, and introduces rtnl-independent locking.
> This may have a continuation, and someone may work on killing
> rtnl_lock() in mrtsock_destruct() in the future.
>
> Thanks,
> Kirill
>
> ---
> v3: Change patches order: [2/5] and [3/5].
> v2: Fix sparse warning [4/5], as reported by kbuild test robot.
This looks a lot better, series applied, thank you.
Powered by blists - more mailing lists