[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM_iQpW1z+dNLiazr87HupqzYPeBnFR5fyVfsXkhwZcRW0LrSA@mail.gmail.com>
Date: Fri, 7 Sep 2018 12:12:27 -0700
From: Cong Wang <xiyou.wangcong@...il.com>
To: Vlad Buslov <vladbu@...lanox.com>
Cc: Linux Kernel Network Developers <netdev@...r.kernel.org>,
Jamal Hadi Salim <jhs@...atatu.com>,
Jiri Pirko <jiri@...nulli.us>,
David Miller <davem@...emloft.net>
Subject: Re: [PATCH net-next v2] net: sched: change tcf_del_walker() to take idrinfo->lock
On Fri, Sep 7, 2018 at 6:52 AM Vlad Buslov <vladbu@...lanox.com> wrote:
>
> Action API was changed to work with actions and action_idr in concurrency
> safe manner, however tcf_del_walker() still uses actions without taking a
> reference or idrinfo->lock first, and deletes them directly, disregarding
> possible concurrent delete.
>
> Add tc_action_wq workqueue to action API. Implement
> tcf_idr_release_unsafe() that assumes external synchronization by caller
> and delays blocking action cleanup part to tc_action_wq workqueue. Extend
> tcf_action_cleanup() with 'async' argument to indicate that function should
> free action asynchronously.
Where exactly is blocking in tcf_action_cleanup()?
>From your code, it looks like free_tcf(), but from my observation,
the only blocking function inside is tcf_action_goto_chain_fini()
which calls __tcf_chain_put(). But, __tcf_chain_put() is blocking
_ONLY_ when tc_chain_notify() is called, for tc action it is never
called.
So, what else is blocking?
Powered by blists - more mailing lists