On Wed, Nov 1, 2017 at 9:55 AM, Lucas Bates wrote:
> On Tue, Oct 31, 2017 at 7:02 PM, Cong Wang wrote:
>> On Tue, Oct 31, 2017 at 3:09 PM, Cong Wang wrote:
>>>
>>> This almost rules out the guilty of this patchset.
>>>
>>> I will provide a patch for you to test, since I can't reproduce it here.
On Tue, Oct 31, 2017 at 7:02 PM, Cong Wang wrote:
> On Tue, Oct 31, 2017 at 3:09 PM, Cong Wang wrote:
>>
>> This almost rules out the guilty of this patchset.
>>
>> I will provide a patch for you to test, since I can't reproduce it here.
>>
>
> Lucas, please test the attached patch, it applies to
On Tue, Oct 31, 2017 at 3:09 PM, Cong Wang wrote:
>
> This almost rules out the guilty of this patchset.
>
> I will provide a patch for you to test, since I can't reproduce it here.
>
Lucas, please test the attached patch, it applies to latest -net.
Note, it is a combination of 3 patches which t
On Tue, Oct 31, 2017 at 12:13 PM, Lucas Bates wrote:
> On Tue, Oct 31, 2017 at 2:55 PM, Lucas Bates wrote:
>> Unfortunately it doesn't seem to have had any effect, I'm still seeing
>> the same bug as yesterday. At Jamal's suggestion I put in a delay
As I replied to you privately, it is probably
On Tue, Oct 31, 2017 at 2:55 PM, Lucas Bates wrote:
> On Tue, Oct 31, 2017 at 7:00 AM, Jamal Hadi Salim wrote:
>> On 17-10-31 01:44 AM, Cong Wang wrote:
>>>
>>> Can you try this patch? From your stack trace it is not clear where
>>> the cause is, but we know that the crash is in __tcf_idr_release
On Tue, Oct 31, 2017 at 7:00 AM, Jamal Hadi Salim wrote:
> On 17-10-31 01:44 AM, Cong Wang wrote:
>>
>> Can you try this patch? From your stack trace it is not clear where
>> the cause is, but we know that the crash is in __tcf_idr_release(),
>> this is how I came up with the following patch:
>>
>
On 17-10-31 01:44 AM, Cong Wang wrote:
On Mon, Oct 30, 2017 at 6:03 PM, Lucas Bates wrote:
On Oct 30, 2017 19:13, "Cong Wang" wrote:
Can you try this patch? From your stack trace it is not clear where
the cause is, but we know that the crash is in __tcf_idr_release(),
this is how I came u
On Mon, Oct 30, 2017 at 6:03 PM, Lucas Bates wrote:
> On Oct 30, 2017 19:13, "Cong Wang" wrote:
>>
>> On Mon, Oct 30, 2017 at 3:39 PM, Lucas Bates wrote:
>> > e.On Thu, Oct 26, 2017 at 9:24 PM, Cong Wang
>> > wrote:
>> >> Recently, the RCU callbacks used in TC filters and TC actions keep
>> >>
On Mon, Oct 30, 2017 at 7:12 PM, Cong Wang wrote:
> On Mon, Oct 30, 2017 at 3:39 PM, Lucas Bates wrote:
>> e.On Thu, Oct 26, 2017 at 9:24 PM, Cong Wang
>> wrote:
>>> Recently, the RCU callbacks used in TC filters and TC actions keep
>>> drawing my attention, they introduce at least 4 race condi
On Mon, Oct 30, 2017 at 3:39 PM, Lucas Bates wrote:
> e.On Thu, Oct 26, 2017 at 9:24 PM, Cong Wang wrote:
>> Recently, the RCU callbacks used in TC filters and TC actions keep
>> drawing my attention, they introduce at least 4 race condition bugs:
>
>> As suggested by Paul, we could defer the wo
e.On Thu, Oct 26, 2017 at 9:24 PM, Cong Wang wrote:
> Recently, the RCU callbacks used in TC filters and TC actions keep
> drawing my attention, they introduce at least 4 race condition bugs:
> As suggested by Paul, we could defer the work to a workqueue and
> gain the permission of holding RTNL
From: Cong Wang
Date: Thu, 26 Oct 2017 18:24:27 -0700
> Recently, the RCU callbacks used in TC filters and TC actions keep
> drawing my attention, they introduce at least 4 race condition bugs:
...
> As suggested by Paul, we could defer the work to a workqueue and
> gain the permission of holdin
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:
13 matches
Mail list logo
