From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cong Wang Subject: Re: [PATCH net-next v2] net: sched: don't disable bh when accessing action idr Date: Tue, 22 May 2018 18:10:28 -0700 Message-ID: References: <20180519.230258.1374885458106197707.davem@davemloft.net> <1526932984-11544-1-git-send-email-vladbu@mellanox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: David Miller , Linux Kernel Network Developers , Jamal Hadi Salim , Jiri Pirko , LKML To: Vlad Buslov Return-path: Received: from mail-pl0-f65.google.com ([209.85.160.65]:34278 "EHLO mail-pl0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752654AbeEWBKt (ORCPT ); Tue, 22 May 2018 21:10:49 -0400 In-Reply-To: <1526932984-11544-1-git-send-email-vladbu@mellanox.com> Sender: netdev-owner@vger.kernel.org List-ID: On Mon, May 21, 2018 at 1:03 PM, Vlad Buslov wrote: > Initial net_device implementation used ingress_lock spinlock to synchronize > ingress path of device. This lock was used in both process and bh context. > In some code paths action map lock was obtained while holding ingress_lock. > Commit e1e992e52faa ("[NET_SCHED] protect action config/dump from irqs") > modified actions to always disable bh, while using action map lock, in > order to prevent deadlock on ingress_lock in softirq. This lock was removed > from net_device, so disabling bh, while accessing action map, is no longer > necessary. > > Replace all action idr spinlock usage with regular calls that do not > disable bh. While your patch is probably fine, the above justification seems not. In the past, tc actions could be released in BH context because tc filters use call_rcu(). However, I moved them to a workqueue recently. So before my change I don't think you can remove the BH protection, otherwise race with idr_remove()...