From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ido Schimmel Subject: Re: [Patch net-next] net_sched: convert idrinfo->lock from spinlock to a mutex Date: Wed, 3 Oct 2018 08:31:12 +0300 Message-ID: <20181003053112.GA15357@splinter> References: <20181002195019.13522-1-xiyou.wangcong@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netdev@vger.kernel.org, jiri@resnulli.us, jhs@mojatatu.com, vladbu@mellanox.com, Jiri Pirko To: Cong Wang Return-path: Received: from out3-smtp.messagingengine.com ([66.111.4.27]:50559 "EHLO out3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726405AbeJCMSD (ORCPT ); Wed, 3 Oct 2018 08:18:03 -0400 Content-Disposition: inline In-Reply-To: <20181002195019.13522-1-xiyou.wangcong@gmail.com> Sender: netdev-owner@vger.kernel.org List-ID: On Tue, Oct 02, 2018 at 12:50:19PM -0700, Cong Wang wrote: > In commit ec3ed293e766 ("net_sched: change tcf_del_walker() to take idrinfo->lock") > we move fl_hw_destroy_tmplt() to a workqueue to avoid blocking > with the spinlock held. Unfortunately, this causes a lot of > troubles here: > > 1. tcf_chain_destroy() could be called right after we queue the work > but before the work runs. This is a use-after-free. > > 2. The chain refcnt is already 0, we can't even just hold it again. > We can check refcnt==1 but it is ugly. > > 3. The chain with refcnt 0 is still visible in its block, which means > it could be still found and used! > > 4. The block has a refcnt too, we can't hold it without introducing a > proper API either. > > We can make it working but the end result is ugly. Instead of wasting > time on reviewing it, let's just convert the troubling spinlock to > a mutex, which allows us to use non-atomic allocations too. > > Fixes: ec3ed293e766 ("net_sched: change tcf_del_walker() to take idrinfo->lock") > Reported-by: Ido Schimmel > Cc: Jamal Hadi Salim > Cc: Vlad Buslov > Cc: Jiri Pirko > Signed-off-by: Cong Wang Tested-by: Ido Schimmel Thanks a lot!