On Thu, Oct 26, 2017 at 6:58 AM, Paul E. McKenney
wrote:
>
> So when removing an entire chain, you flush any queued workqueue handlers
> to make sure that any operations using elements on that chain have also
> completed, correct? This might also motivate the rcu_barrier() calls.
Yes, we can onl
On Wed, Oct 25, 2017 at 09:49:09PM -0700, Cong Wang wrote:
> On Wed, Oct 25, 2017 at 5:19 PM, Paul E. McKenney
> wrote:
> > On Wed, Oct 25, 2017 at 03:37:40PM -0700, Cong Wang wrote:
> >> My solution is introducing a workqueue for tc filters
> >> and let each RCU callback defer the work to this
>
On Wed, Oct 25, 2017 at 5:19 PM, Paul E. McKenney
wrote:
> On Wed, Oct 25, 2017 at 03:37:40PM -0700, Cong Wang wrote:
>> My solution is introducing a workqueue for tc filters
>> and let each RCU callback defer the work to this
>> workqueue. I solve the flush_workqueue() deadlock
>> by queuing anot
On Wed, Oct 25, 2017 at 03:37:40PM -0700, Cong Wang wrote:
> On Tue, Oct 24, 2017 at 6:43 PM, David Miller wrote:
> > From: Cong Wang
> > Date: Mon, 23 Oct 2017 15:02:49 -0700
> >
> >> Recently, the RCU callbacks used in TC filters and TC actions keep
> >> drawing my attention, they introduce at
On Tue, Oct 24, 2017 at 6:43 PM, David Miller wrote:
> From: Cong Wang
> Date: Mon, 23 Oct 2017 15:02:49 -0700
>
>> Recently, the RCU callbacks used in TC filters and TC actions keep
>> drawing my attention, they introduce at least 4 race condition bugs:
>
> Like Eric, I think doing a full RCU sy
On Mon, Oct 23, 2017 at 4:31 PM, Eric Dumazet wrote:
>
> I did not pretend to give a bug fix, I simply said your patch series was
> probably not the right way.
Generally I agree with you on avoid synchronize_rcu(), but this case
is very special, you need to consider case by case, not just talking
From: Cong Wang
Date: Mon, 23 Oct 2017 15:02:49 -0700
> Recently, the RCU callbacks used in TC filters and TC actions keep
> drawing my attention, they introduce at least 4 race condition bugs:
Like Eric, I think doing a full RCU sync on every delete is too big
a pill to swallow. This is a majo
On Mon, 2017-10-23 at 16:23 -0700, Cong Wang wrote:
> On Mon, Oct 23, 2017 at 4:16 PM, Eric Dumazet wrote:
> > On Mon, 2017-10-23 at 15:02 -0700, Cong Wang wrote:
> >
> >> b) As suggested by Paul, we could defer the work to a workqueue and
> >> gain the permission of holding RTNL again without any
On Mon, Oct 23, 2017 at 4:16 PM, Eric Dumazet wrote:
> On Mon, 2017-10-23 at 15:02 -0700, Cong Wang wrote:
>
>> b) As suggested by Paul, we could defer the work to a workqueue and
>> gain the permission of holding RTNL again without any performance
>> impact, however, this seems impossible too, be
On Mon, 2017-10-23 at 15:02 -0700, Cong Wang wrote:
> b) As suggested by Paul, we could defer the work to a workqueue and
> gain the permission of holding RTNL again without any performance
> impact, however, this seems impossible too, because as lockdep
> complains we have a deadlock when flushin
Recently, the RCU callbacks used in TC filters and TC actions keep
drawing my attention, they introduce at least 4 race condition bugs:
1. A simple one fixed by Daniel:
commit c78e1746d3ad7d548bdf3fe491898cc453911a49
Author: Daniel Borkmann
Date: Wed May 20 17:13:33 2015 +0200
net: sched:
11 matches
Mail list logo