Re: [Patch net v2 2/2] net_sched: fix all the madness of tc filter chain

2017-09-11 Thread Cong Wang
On Mon, Sep 11, 2017 at 2:14 PM, Cong Wang  wrote:
>
> Looks like all due to the lack of locking on block->chain_list.
> I thought the rcu_barrier() could properly handle this,
> but seems still not, probably I need to move it in the loop,
> I am still not 100% sure if it is totally safe with
> list_for_each_safe():
>
>
> -   list_for_each_entry(chain, >chain_list, list)
> +   list_for_each_entry_safe(chain, tmp, >chain_list, list) {
> tcf_chain_flush(chain);
> -   rcu_barrier();
> +   rcu_barrier(); // are we safe now???
> +   }
>

Answer myself: No, this is not safe either, because we may
list_del() the next node, and apparently _safe() can't guarantee
that...

So either we have to use locking or use the trick you suggested.


Re: [Patch net v2 2/2] net_sched: fix all the madness of tc filter chain

2017-09-11 Thread Cong Wang
On Sun, Sep 10, 2017 at 7:33 AM, Jiri Pirko  wrote:
> Fri, Sep 08, 2017 at 06:37:55PM CEST, xiyou.wangc...@gmail.com wrote:
>>On Thu, Sep 7, 2017 at 1:52 PM, Jiri Pirko  wrote:
>>> Thu, Sep 07, 2017 at 07:45:49PM CEST, xiyou.wangc...@gmail.com wrote:
Yes it is for chain 0, because block holds a reference to chain 0 during
creation. Non-0 chains are created with refcnt==1 too but paired with
tcf_chain_put() rather than tcf_block_put(). This is what makes chain 0
not special w.r.t. refcnt.
>>>
>>> So you need to tcf_chain_put only chain 0 here, right? The rest of the
>>> chains get destroyed by the previous list_for_each_entry iteration when
>>> flush happens and actions destroy happens what decrements recnt to 0
>>> there.
>>
>>
>>This is correct. And it should be only chain 0 after flush.
>>
>>>
>>> What do I miss, who would still hold reference for non-0 chains when all
>>> tps and all goto_chain actions are gone?
>>
>>No one. This is totally correct and is exactly what this patch intends to do.
>>
>>Look, this is why we never need an object with refcnt==0 to exist. ;)
>
> So, I understand that correctly, good. But this is a problem.
>
> When you do:
>list_for_each_entry(chain, >chain_list, list)
> tcf_chain_flush(chain);
>
> The reference may get dropped for chains to 0 (for those that does not
> have a goto_chain action holding a ref), and therefore they get freed
> within the loop. That is problematic when you do the traversing of the
> list. You may use list_for_each_entry_safe, but there is another issue:
>
> As a part of tcf_chain_flush destruction, act goto_chain destruction may
> get scheduled by call_rcu. That may be the last reference held for the
> chain. So you race between this loop and rcu callback.
>
> Consider following example:
>
> chain0  - has only one rule with goto_chain 22 action
> chain22 - no rule (refcnt 1 because of the action mentioned above)
>
>  CPU0CPU1
>
> tcf_chain_flush(0)
>-> call_rcu(free_tcf)
>   free_tcf
>  ->tcf_chain_put(22)
>  ->tcf_chain_destroy(22)
>  ->kfree(22)


Looks like all due to the lack of locking on block->chain_list.
I thought the rcu_barrier() could properly handle this,
but seems still not, probably I need to move it in the loop,
I am still not 100% sure if it is totally safe with
list_for_each_safe():


-   list_for_each_entry(chain, >chain_list, list)
+   list_for_each_entry_safe(chain, tmp, >chain_list, list) {
tcf_chain_flush(chain);
-   rcu_barrier();
+   rcu_barrier(); // are we safe now???
+   }


> tcf_chain_flush(22)...use-after-free
>

Same race could happen with your code too, right?
chain 22 still has refcnt==1 so chain_put() will destroy
it in flush() too. So this is not a regression.

I know you have list_for_each_safe() but you lack of
rcu_barrier(). This is why I said the lack of locking is
the cause, not your code or my code.


>
> So what I suggest in order to prevent this is to change your code to
> something like:
>
> /* To avoid race between getting reference in the next loop and
>  * rcu callbacks from deleleted actions freeing the chain.
>  */
> rcu_barrier();
>
> list_for_each_entry(chain, >chain_list, list)
> if (chain->index) /* we already hold ref to chain 0 */
> tcf_chain_hold(chain);
>
> list_for_each_entry(chain, >chain_list, list)
> tcf_chain_flush(chain);
>
> /* Wait for rcu callbacks from deleleted actions that were
>  * sheduled as a result of tcf_chain_flush in the previous loop.
>  * This is not absolutelly necessary, as the chain may live after
>  * the tcf_chain_put is called in the next iteration and would
>  * get freed on tcf_chain_put call from rcu callback later on.
>  */
> rcu_barrier();
>
> /* Now we are sure that we are the only one holding a reference
>  * to all chains, drop it and let them go.
>  */
> list_for_each_entry_safe(chain, tmp, >chain_list, list)
> tcf_chain_put(chain);
> kfree(block);
>
> Does this make sense?

Yeah, but again this is all due to lack of locking. Do we really
have to to be such complex or just use either a) proper sync
with rcu_barrier() or b) proper locking on chain_list (with RCU
of course)?

Thanks.


Re: [Patch net v2 2/2] net_sched: fix all the madness of tc filter chain

2017-09-10 Thread Jiri Pirko
Fri, Sep 08, 2017 at 06:37:55PM CEST, xiyou.wangc...@gmail.com wrote:
>On Thu, Sep 7, 2017 at 1:52 PM, Jiri Pirko  wrote:
>> Thu, Sep 07, 2017 at 07:45:49PM CEST, xiyou.wangc...@gmail.com wrote:
>>>Yes it is for chain 0, because block holds a reference to chain 0 during
>>>creation. Non-0 chains are created with refcnt==1 too but paired with
>>>tcf_chain_put() rather than tcf_block_put(). This is what makes chain 0
>>>not special w.r.t. refcnt.
>>
>> So you need to tcf_chain_put only chain 0 here, right? The rest of the
>> chains get destroyed by the previous list_for_each_entry iteration when
>> flush happens and actions destroy happens what decrements recnt to 0
>> there.
>
>
>This is correct. And it should be only chain 0 after flush.
>
>>
>> What do I miss, who would still hold reference for non-0 chains when all
>> tps and all goto_chain actions are gone?
>
>No one. This is totally correct and is exactly what this patch intends to do.
>
>Look, this is why we never need an object with refcnt==0 to exist. ;)

So, I understand that correctly, good. But this is a problem.

When you do:
   list_for_each_entry(chain, >chain_list, list)
tcf_chain_flush(chain);

The reference may get dropped for chains to 0 (for those that does not
have a goto_chain action holding a ref), and therefore they get freed
within the loop. That is problematic when you do the traversing of the
list. You may use list_for_each_entry_safe, but there is another issue:

As a part of tcf_chain_flush destruction, act goto_chain destruction may
get scheduled by call_rcu. That may be the last reference held for the
chain. So you race between this loop and rcu callback.

Consider following example:

chain0  - has only one rule with goto_chain 22 action
chain22 - no rule (refcnt 1 because of the action mentioned above)

 CPU0CPU1

tcf_chain_flush(0)
   -> call_rcu(free_tcf)
  free_tcf
 ->tcf_chain_put(22)
 ->tcf_chain_destroy(22)
 ->kfree(22)
tcf_chain_flush(22)...use-after-free


So what I suggest in order to prevent this is to change your code to
something like:

/* To avoid race between getting reference in the next loop and
 * rcu callbacks from deleleted actions freeing the chain.
 */
rcu_barrier();

list_for_each_entry(chain, >chain_list, list)
if (chain->index) /* we already hold ref to chain 0 */
tcf_chain_hold(chain);

list_for_each_entry(chain, >chain_list, list)
tcf_chain_flush(chain);

/* Wait for rcu callbacks from deleleted actions that were
 * sheduled as a result of tcf_chain_flush in the previous loop.
 * This is not absolutelly necessary, as the chain may live after
 * the tcf_chain_put is called in the next iteration and would
 * get freed on tcf_chain_put call from rcu callback later on.
 */
rcu_barrier();

/* Now we are sure that we are the only one holding a reference
 * to all chains, drop it and let them go.
 */
list_for_each_entry_safe(chain, tmp, >chain_list, list)
tcf_chain_put(chain);
kfree(block);

Does this make sense?

Thanks!

Jiri


Re: [Patch net v2 2/2] net_sched: fix all the madness of tc filter chain

2017-09-08 Thread Cong Wang
On Thu, Sep 7, 2017 at 1:52 PM, Jiri Pirko  wrote:
> Thu, Sep 07, 2017 at 07:45:49PM CEST, xiyou.wangc...@gmail.com wrote:
>>Yes it is for chain 0, because block holds a reference to chain 0 during
>>creation. Non-0 chains are created with refcnt==1 too but paired with
>>tcf_chain_put() rather than tcf_block_put(). This is what makes chain 0
>>not special w.r.t. refcnt.
>
> So you need to tcf_chain_put only chain 0 here, right? The rest of the
> chains get destroyed by the previous list_for_each_entry iteration when
> flush happens and actions destroy happens what decrements recnt to 0
> there.


This is correct. And it should be only chain 0 after flush.

>
> What do I miss, who would still hold reference for non-0 chains when all
> tps and all goto_chain actions are gone?

No one. This is totally correct and is exactly what this patch intends to do.

Look, this is why we never need an object with refcnt==0 to exist. ;)


Re: [Patch net v2 2/2] net_sched: fix all the madness of tc filter chain

2017-09-07 Thread Jiri Pirko
Thu, Sep 07, 2017 at 07:45:49PM CEST, xiyou.wangc...@gmail.com wrote:
>On Wed, Sep 6, 2017 at 11:32 PM, Jiri Pirko  wrote:
>> Thu, Sep 07, 2017 at 06:26:07AM CEST, xiyou.wangc...@gmail.com wrote:
>>>This patch fixes the following madness of tc filter chain:
>>
>> Could you avoid expressive words like "madness" and such?
>> Please be technical.
>>
>
>If the following 2a) 2b) 2c) 2d) are not enough to show the madness,
>I don't know any other to show it. Madness is for code, not for you
>or any other person, so 100% technical.

We hav eto agree to disagree. You want to be expressive, apparently
there is no way to talk you out of that. Sigh...


>
>>
>>>
>>>1) tcf_chain_destroy() is called by both tcf_block_put() and
>>>   tcf_chain_put().  tcf_chain_put() is correctly refcnt'ed and paired
>>>   with tcf_chain_get(), but tcf_block_put() is not, it should be paired
>>>   with tcf_block_get() which means we still need to decrease the refcnt.
>>>   Think it in another way: if we call tcf_bock_put() immediately after
>>>   tcf_block_get(), could we get effectively a nop? This causes a memory
>>>   leak as reported by Jakub.
>>>
>>>2) tp proto should hold a refcnt to the chain too. This significantly
>>>   simplifies the logic:
>>>
>>>2a) Chain 0 is no longer special, it is created and refcnted by tp
>>>like any other chains. All the ugliness in tcf_chain_put() can be
>>>gone!
>>>
>>>2b) No need to handle the flushing oddly, because block still holds
>>>chain 0, it can not be released, this guarantees block is the last
>>>user.
>>>
>>>2c) The race condition with RCU callbacks is easier to handle with just
>>>a rcu_barrier()! Much easier to understand, nothing to hide! Thanks
>>>to the previous patch. Please see also the comments in code.
>>>
>>>2d) Make the code understandable by humans, much less error-prone.
>>>
>>>Fixes: 744a4cf63e52 ("net: sched: fix use after free when tcf_chain_destroy 
>>>is called multiple times")
>>>Fixes: 5bc1701881e3 ("net: sched: introduce multichain support for filters")
>>>Reported-by: Jakub Kicinski 
>>>Cc: Jiri Pirko 
>>>Signed-off-by: Cong Wang 
>>>---
>>> net/sched/cls_api.c | 38 ++
>>> 1 file changed, 22 insertions(+), 16 deletions(-)
>>>
>>>diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
>>>index 6c5ea84d2682..e9060dc36519 100644
>>>--- a/net/sched/cls_api.c
>>>+++ b/net/sched/cls_api.c
>>>@@ -209,21 +209,20 @@ static void tcf_chain_flush(struct tcf_chain *chain)
>>>   RCU_INIT_POINTER(*chain->p_filter_chain, NULL);
>>>   while ((tp = rtnl_dereference(chain->filter_chain)) != NULL) {
>>>   RCU_INIT_POINTER(chain->filter_chain, tp->next);
>>>+  tcf_chain_put(chain);
>>>   tcf_proto_destroy(tp);
>>>   }
>>> }
>>>
>>> static void tcf_chain_destroy(struct tcf_chain *chain)
>>> {
>>>-  /* May be already removed from the list by the previous call. */
>>>-  if (!list_empty(>list))
>>>-  list_del_init(>list);
>>>+  list_del(>list);
>>>+  kfree(chain);
>>>+}
>>>
>>>-  /* There might still be a reference held when we got here from
>>>-   * tcf_block_put. Wait for the user to drop reference before free.
>>>-   */
>>>-  if (!chain->refcnt)
>>>-  kfree(chain);
>>>+static void tcf_chain_hold(struct tcf_chain *chain)
>>>+{
>>>+  ++chain->refcnt;
>>> }
>>>
>>> struct tcf_chain *tcf_chain_get(struct tcf_block *block, u32 chain_index,
>>>@@ -233,7 +232,7 @@ struct tcf_chain *tcf_chain_get(struct tcf_block *block, 
>>>u32 chain_index,
>>>
>>>   list_for_each_entry(chain, >chain_list, list) {
>>>   if (chain->index == chain_index) {
>>>-  chain->refcnt++;
>>>+  tcf_chain_hold(chain);
>>>   return chain;
>>>   }
>>>   }
>>>@@ -246,10 +245,7 @@ EXPORT_SYMBOL(tcf_chain_get);
>>>
>>> void tcf_chain_put(struct tcf_chain *chain)
>>> {
>>>-  /* Destroy unused chain, with exception of chain 0, which is the
>>>-   * default one and has to be always present.
>>>-   */
>>>-  if (--chain->refcnt == 0 && !chain->filter_chain && chain->index != 0)
>>>+  if (--chain->refcnt == 0)
>>
>> Okay, so you take the reference for every goto_chain action and every
>> tp, right? Note that for chain 0, you hold one more reference (due to
>> the creation). That is probably ok as we need chain 0 not to go away
>> even if all tps and goto_chain actions are gone.
>
>Yeah, this is the core of the patch.
>
>>
>>
>>>   tcf_chain_destroy(chain);
>>> }
>>> EXPORT_SYMBOL(tcf_chain_put);
>>>@@ -294,10 +290,18 @@ void tcf_block_put(struct tcf_block *block)
>>>   if (!block)
>>>   return;
>>>
>>>-  list_for_each_entry_safe(chain, tmp, >chain_list, list) {
>>>+  /* Standalone actions are not allowed to jump to any chain, 

Re: [Patch net v2 2/2] net_sched: fix all the madness of tc filter chain

2017-09-07 Thread Cong Wang
On Wed, Sep 6, 2017 at 11:32 PM, Jiri Pirko  wrote:
> Thu, Sep 07, 2017 at 06:26:07AM CEST, xiyou.wangc...@gmail.com wrote:
>>This patch fixes the following madness of tc filter chain:
>
> Could you avoid expressive words like "madness" and such?
> Please be technical.
>

If the following 2a) 2b) 2c) 2d) are not enough to show the madness,
I don't know any other to show it. Madness is for code, not for you
or any other person, so 100% technical.

>
>>
>>1) tcf_chain_destroy() is called by both tcf_block_put() and
>>   tcf_chain_put().  tcf_chain_put() is correctly refcnt'ed and paired
>>   with tcf_chain_get(), but tcf_block_put() is not, it should be paired
>>   with tcf_block_get() which means we still need to decrease the refcnt.
>>   Think it in another way: if we call tcf_bock_put() immediately after
>>   tcf_block_get(), could we get effectively a nop? This causes a memory
>>   leak as reported by Jakub.
>>
>>2) tp proto should hold a refcnt to the chain too. This significantly
>>   simplifies the logic:
>>
>>2a) Chain 0 is no longer special, it is created and refcnted by tp
>>like any other chains. All the ugliness in tcf_chain_put() can be
>>gone!
>>
>>2b) No need to handle the flushing oddly, because block still holds
>>chain 0, it can not be released, this guarantees block is the last
>>user.
>>
>>2c) The race condition with RCU callbacks is easier to handle with just
>>a rcu_barrier()! Much easier to understand, nothing to hide! Thanks
>>to the previous patch. Please see also the comments in code.
>>
>>2d) Make the code understandable by humans, much less error-prone.
>>
>>Fixes: 744a4cf63e52 ("net: sched: fix use after free when tcf_chain_destroy 
>>is called multiple times")
>>Fixes: 5bc1701881e3 ("net: sched: introduce multichain support for filters")
>>Reported-by: Jakub Kicinski 
>>Cc: Jiri Pirko 
>>Signed-off-by: Cong Wang 
>>---
>> net/sched/cls_api.c | 38 ++
>> 1 file changed, 22 insertions(+), 16 deletions(-)
>>
>>diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
>>index 6c5ea84d2682..e9060dc36519 100644
>>--- a/net/sched/cls_api.c
>>+++ b/net/sched/cls_api.c
>>@@ -209,21 +209,20 @@ static void tcf_chain_flush(struct tcf_chain *chain)
>>   RCU_INIT_POINTER(*chain->p_filter_chain, NULL);
>>   while ((tp = rtnl_dereference(chain->filter_chain)) != NULL) {
>>   RCU_INIT_POINTER(chain->filter_chain, tp->next);
>>+  tcf_chain_put(chain);
>>   tcf_proto_destroy(tp);
>>   }
>> }
>>
>> static void tcf_chain_destroy(struct tcf_chain *chain)
>> {
>>-  /* May be already removed from the list by the previous call. */
>>-  if (!list_empty(>list))
>>-  list_del_init(>list);
>>+  list_del(>list);
>>+  kfree(chain);
>>+}
>>
>>-  /* There might still be a reference held when we got here from
>>-   * tcf_block_put. Wait for the user to drop reference before free.
>>-   */
>>-  if (!chain->refcnt)
>>-  kfree(chain);
>>+static void tcf_chain_hold(struct tcf_chain *chain)
>>+{
>>+  ++chain->refcnt;
>> }
>>
>> struct tcf_chain *tcf_chain_get(struct tcf_block *block, u32 chain_index,
>>@@ -233,7 +232,7 @@ struct tcf_chain *tcf_chain_get(struct tcf_block *block, 
>>u32 chain_index,
>>
>>   list_for_each_entry(chain, >chain_list, list) {
>>   if (chain->index == chain_index) {
>>-  chain->refcnt++;
>>+  tcf_chain_hold(chain);
>>   return chain;
>>   }
>>   }
>>@@ -246,10 +245,7 @@ EXPORT_SYMBOL(tcf_chain_get);
>>
>> void tcf_chain_put(struct tcf_chain *chain)
>> {
>>-  /* Destroy unused chain, with exception of chain 0, which is the
>>-   * default one and has to be always present.
>>-   */
>>-  if (--chain->refcnt == 0 && !chain->filter_chain && chain->index != 0)
>>+  if (--chain->refcnt == 0)
>
> Okay, so you take the reference for every goto_chain action and every
> tp, right? Note that for chain 0, you hold one more reference (due to
> the creation). That is probably ok as we need chain 0 not to go away
> even if all tps and goto_chain actions are gone.

Yeah, this is the core of the patch.

>
>
>>   tcf_chain_destroy(chain);
>> }
>> EXPORT_SYMBOL(tcf_chain_put);
>>@@ -294,10 +290,18 @@ void tcf_block_put(struct tcf_block *block)
>>   if (!block)
>>   return;
>>
>>-  list_for_each_entry_safe(chain, tmp, >chain_list, list) {
>>+  /* Standalone actions are not allowed to jump to any chain, and
>>+   * bound actions should be all removed after flushing. However,
>>+   * filters are destroyed in RCU callbacks, we have to flush and wait
>>+   * for them before releasing this refcnt, otherwise we race with RCU
>>+   * callbacks!!!
>
> Why the "!!!"? Please avoid that. Not necessary 

Re: [Patch net v2 2/2] net_sched: fix all the madness of tc filter chain

2017-09-07 Thread Jiri Pirko
Thu, Sep 07, 2017 at 06:26:07AM CEST, xiyou.wangc...@gmail.com wrote:
>This patch fixes the following madness of tc filter chain:

Could you avoid expressive words like "madness" and such?
Please be technical.


>
>1) tcf_chain_destroy() is called by both tcf_block_put() and
>   tcf_chain_put().  tcf_chain_put() is correctly refcnt'ed and paired
>   with tcf_chain_get(), but tcf_block_put() is not, it should be paired
>   with tcf_block_get() which means we still need to decrease the refcnt.
>   Think it in another way: if we call tcf_bock_put() immediately after
>   tcf_block_get(), could we get effectively a nop? This causes a memory
>   leak as reported by Jakub.
>
>2) tp proto should hold a refcnt to the chain too. This significantly
>   simplifies the logic:
>
>2a) Chain 0 is no longer special, it is created and refcnted by tp
>like any other chains. All the ugliness in tcf_chain_put() can be
>gone!
>
>2b) No need to handle the flushing oddly, because block still holds
>chain 0, it can not be released, this guarantees block is the last
>user.
>
>2c) The race condition with RCU callbacks is easier to handle with just
>a rcu_barrier()! Much easier to understand, nothing to hide! Thanks
>to the previous patch. Please see also the comments in code.
>
>2d) Make the code understandable by humans, much less error-prone.
>
>Fixes: 744a4cf63e52 ("net: sched: fix use after free when tcf_chain_destroy is 
>called multiple times")
>Fixes: 5bc1701881e3 ("net: sched: introduce multichain support for filters")
>Reported-by: Jakub Kicinski 
>Cc: Jiri Pirko 
>Signed-off-by: Cong Wang 
>---
> net/sched/cls_api.c | 38 ++
> 1 file changed, 22 insertions(+), 16 deletions(-)
>
>diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
>index 6c5ea84d2682..e9060dc36519 100644
>--- a/net/sched/cls_api.c
>+++ b/net/sched/cls_api.c
>@@ -209,21 +209,20 @@ static void tcf_chain_flush(struct tcf_chain *chain)
>   RCU_INIT_POINTER(*chain->p_filter_chain, NULL);
>   while ((tp = rtnl_dereference(chain->filter_chain)) != NULL) {
>   RCU_INIT_POINTER(chain->filter_chain, tp->next);
>+  tcf_chain_put(chain);
>   tcf_proto_destroy(tp);
>   }
> }
> 
> static void tcf_chain_destroy(struct tcf_chain *chain)
> {
>-  /* May be already removed from the list by the previous call. */
>-  if (!list_empty(>list))
>-  list_del_init(>list);
>+  list_del(>list);
>+  kfree(chain);
>+}
> 
>-  /* There might still be a reference held when we got here from
>-   * tcf_block_put. Wait for the user to drop reference before free.
>-   */
>-  if (!chain->refcnt)
>-  kfree(chain);
>+static void tcf_chain_hold(struct tcf_chain *chain)
>+{
>+  ++chain->refcnt;
> }
> 
> struct tcf_chain *tcf_chain_get(struct tcf_block *block, u32 chain_index,
>@@ -233,7 +232,7 @@ struct tcf_chain *tcf_chain_get(struct tcf_block *block, 
>u32 chain_index,
> 
>   list_for_each_entry(chain, >chain_list, list) {
>   if (chain->index == chain_index) {
>-  chain->refcnt++;
>+  tcf_chain_hold(chain);
>   return chain;
>   }
>   }
>@@ -246,10 +245,7 @@ EXPORT_SYMBOL(tcf_chain_get);
> 
> void tcf_chain_put(struct tcf_chain *chain)
> {
>-  /* Destroy unused chain, with exception of chain 0, which is the
>-   * default one and has to be always present.
>-   */
>-  if (--chain->refcnt == 0 && !chain->filter_chain && chain->index != 0)
>+  if (--chain->refcnt == 0)

Okay, so you take the reference for every goto_chain action and every
tp, right? Note that for chain 0, you hold one more reference (due to
the creation). That is probably ok as we need chain 0 not to go away
even if all tps and goto_chain actions are gone.


>   tcf_chain_destroy(chain);
> }
> EXPORT_SYMBOL(tcf_chain_put);
>@@ -294,10 +290,18 @@ void tcf_block_put(struct tcf_block *block)
>   if (!block)
>   return;
> 
>-  list_for_each_entry_safe(chain, tmp, >chain_list, list) {
>+  /* Standalone actions are not allowed to jump to any chain, and
>+   * bound actions should be all removed after flushing. However,
>+   * filters are destroyed in RCU callbacks, we have to flush and wait
>+   * for them before releasing this refcnt, otherwise we race with RCU
>+   * callbacks!!!

Why the "!!!"? Please avoid that. Not necessary at all.


>+   */
>+  list_for_each_entry(chain, >chain_list, list)
>   tcf_chain_flush(chain);
>-  tcf_chain_destroy(chain);
>-  }
>+  rcu_barrier();

This actually tries to fix another bug I discovered yesterday. Good.


>+
>+  list_for_each_entry_safe(chain, tmp, >chain_list, list)
>+  tcf_chain_put(chain);

Which reference are you putting here? 

[Patch net v2 2/2] net_sched: fix all the madness of tc filter chain

2017-09-06 Thread Cong Wang
This patch fixes the following madness of tc filter chain:

1) tcf_chain_destroy() is called by both tcf_block_put() and
   tcf_chain_put().  tcf_chain_put() is correctly refcnt'ed and paired
   with tcf_chain_get(), but tcf_block_put() is not, it should be paired
   with tcf_block_get() which means we still need to decrease the refcnt.
   Think it in another way: if we call tcf_bock_put() immediately after
   tcf_block_get(), could we get effectively a nop? This causes a memory
   leak as reported by Jakub.

2) tp proto should hold a refcnt to the chain too. This significantly
   simplifies the logic:

2a) Chain 0 is no longer special, it is created and refcnted by tp
like any other chains. All the ugliness in tcf_chain_put() can be
gone!

2b) No need to handle the flushing oddly, because block still holds
chain 0, it can not be released, this guarantees block is the last
user.

2c) The race condition with RCU callbacks is easier to handle with just
a rcu_barrier()! Much easier to understand, nothing to hide! Thanks
to the previous patch. Please see also the comments in code.

2d) Make the code understandable by humans, much less error-prone.

Fixes: 744a4cf63e52 ("net: sched: fix use after free when tcf_chain_destroy is 
called multiple times")
Fixes: 5bc1701881e3 ("net: sched: introduce multichain support for filters")
Reported-by: Jakub Kicinski 
Cc: Jiri Pirko 
Signed-off-by: Cong Wang 
---
 net/sched/cls_api.c | 38 ++
 1 file changed, 22 insertions(+), 16 deletions(-)

diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
index 6c5ea84d2682..e9060dc36519 100644
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -209,21 +209,20 @@ static void tcf_chain_flush(struct tcf_chain *chain)
RCU_INIT_POINTER(*chain->p_filter_chain, NULL);
while ((tp = rtnl_dereference(chain->filter_chain)) != NULL) {
RCU_INIT_POINTER(chain->filter_chain, tp->next);
+   tcf_chain_put(chain);
tcf_proto_destroy(tp);
}
 }
 
 static void tcf_chain_destroy(struct tcf_chain *chain)
 {
-   /* May be already removed from the list by the previous call. */
-   if (!list_empty(>list))
-   list_del_init(>list);
+   list_del(>list);
+   kfree(chain);
+}
 
-   /* There might still be a reference held when we got here from
-* tcf_block_put. Wait for the user to drop reference before free.
-*/
-   if (!chain->refcnt)
-   kfree(chain);
+static void tcf_chain_hold(struct tcf_chain *chain)
+{
+   ++chain->refcnt;
 }
 
 struct tcf_chain *tcf_chain_get(struct tcf_block *block, u32 chain_index,
@@ -233,7 +232,7 @@ struct tcf_chain *tcf_chain_get(struct tcf_block *block, 
u32 chain_index,
 
list_for_each_entry(chain, >chain_list, list) {
if (chain->index == chain_index) {
-   chain->refcnt++;
+   tcf_chain_hold(chain);
return chain;
}
}
@@ -246,10 +245,7 @@ EXPORT_SYMBOL(tcf_chain_get);
 
 void tcf_chain_put(struct tcf_chain *chain)
 {
-   /* Destroy unused chain, with exception of chain 0, which is the
-* default one and has to be always present.
-*/
-   if (--chain->refcnt == 0 && !chain->filter_chain && chain->index != 0)
+   if (--chain->refcnt == 0)
tcf_chain_destroy(chain);
 }
 EXPORT_SYMBOL(tcf_chain_put);
@@ -294,10 +290,18 @@ void tcf_block_put(struct tcf_block *block)
if (!block)
return;
 
-   list_for_each_entry_safe(chain, tmp, >chain_list, list) {
+   /* Standalone actions are not allowed to jump to any chain, and
+* bound actions should be all removed after flushing. However,
+* filters are destroyed in RCU callbacks, we have to flush and wait
+* for them before releasing this refcnt, otherwise we race with RCU
+* callbacks!!!
+*/
+   list_for_each_entry(chain, >chain_list, list)
tcf_chain_flush(chain);
-   tcf_chain_destroy(chain);
-   }
+   rcu_barrier();
+
+   list_for_each_entry_safe(chain, tmp, >chain_list, list)
+   tcf_chain_put(chain);
kfree(block);
 }
 EXPORT_SYMBOL(tcf_block_put);
@@ -375,6 +379,7 @@ static void tcf_chain_tp_insert(struct tcf_chain *chain,
rcu_assign_pointer(*chain->p_filter_chain, tp);
RCU_INIT_POINTER(tp->next, tcf_chain_tp_prev(chain_info));
rcu_assign_pointer(*chain_info->pprev, tp);
+   tcf_chain_hold(chain);
 }
 
 static void tcf_chain_tp_remove(struct tcf_chain *chain,
@@ -386,6 +391,7 @@ static void tcf_chain_tp_remove(struct tcf_chain *chain,
if (chain->p_filter_chain && tp == chain->filter_chain)
RCU_INIT_POINTER(*chain->p_filter_chain, next);