From: Daniel Borkmann
Date: Wed, 21 Dec 2016 18:04:11 +0100
> Shahar reported a soft lockup in tc_classify(), where we run into an
> endless loop when walking the classifier chain due to tp->next == tp
> which is a state we should never run into. The issue only seems to
> trigger under load in th
On 12/24/2016 08:34 AM, Cong Wang wrote:
On Thu, Dec 22, 2016 at 4:26 PM, Daniel Borkmann wrote:
On 12/22/2016 08:05 PM, Cong Wang wrote:
On Wed, Dec 21, 2016 at 1:07 PM, Daniel Borkmann
wrote:
Ok, you mean for net. In that case I prefer the smaller sized fix to be
honest. It also covers ev
On Thu, Dec 22, 2016 at 4:26 PM, Daniel Borkmann wrote:
> On 12/22/2016 08:05 PM, Cong Wang wrote:
>>
>> On Wed, Dec 21, 2016 at 1:07 PM, Daniel Borkmann
>> wrote:
>>>
>>>
>>> Ok, you mean for net. In that case I prefer the smaller sized fix to be
>>> honest. It also covers everything from the po
On 12/22/2016 08:05 PM, Cong Wang wrote:
On Wed, Dec 21, 2016 at 1:07 PM, Daniel Borkmann wrote:
Ok, you mean for net. In that case I prefer the smaller sized fix to be
honest. It also covers everything from the point where we fetch the chain
via cops->tcf_chain() to the end of the function, w
On 12/22/2016 06:50 PM, John Fastabend wrote:
On 16-12-22 08:53 AM, David Miller wrote:
From: Daniel Borkmann
Date: Wed, 21 Dec 2016 22:07:48 +0100
Ok, you mean for net. In that case I prefer the smaller sized fix to
be honest. It also covers everything from the point where we fetch
the chain
On 12/22/2016 02:16 PM, Shahar Klein wrote:
On 12/21/2016 7:04 PM, Daniel Borkmann wrote:
Shahar reported a soft lockup in tc_classify(), where we run into an
endless loop when walking the classifier chain due to tp->next == tp
which is a state we should never run into. The issue only seems to
t
On Wed, Dec 21, 2016 at 1:07 PM, Daniel Borkmann wrote:
>
> Ok, you mean for net. In that case I prefer the smaller sized fix to be
> honest. It also covers everything from the point where we fetch the chain
> via cops->tcf_chain() to the end of the function, which is where most of
> the complexit
On 16-12-22 08:53 AM, David Miller wrote:
> From: Daniel Borkmann
> Date: Wed, 21 Dec 2016 22:07:48 +0100
>
>> Ok, you mean for net. In that case I prefer the smaller sized fix to
>> be honest. It also covers everything from the point where we fetch
>> the chain via cops->tcf_chain() to the end o
From: Daniel Borkmann
Date: Wed, 21 Dec 2016 22:07:48 +0100
> Ok, you mean for net. In that case I prefer the smaller sized fix to
> be honest. It also covers everything from the point where we fetch
> the chain via cops->tcf_chain() to the end of the function, which is
> where most of the comple
On 12/21/2016 7:04 PM, Daniel Borkmann wrote:
Shahar reported a soft lockup in tc_classify(), where we run into an
endless loop when walking the classifier chain due to tp->next == tp
which is a state we should never run into. The issue only seems to
trigger under load in the tc control path.
On 12/21/2016 09:47 PM, Cong Wang wrote:
On Wed, Dec 21, 2016 at 12:02 PM, Daniel Borkmann wrote:
On 12/21/2016 08:10 PM, Cong Wang wrote:
On Wed, Dec 21, 2016 at 10:51 AM, Cong Wang
wrote:
On Wed, Dec 21, 2016 at 9:04 AM, Daniel Borkmann
wrote:
What happens is that in tc_ctl_tfilter(), t
On Wed, Dec 21, 2016 at 12:02 PM, Daniel Borkmann wrote:
> On 12/21/2016 08:10 PM, Cong Wang wrote:
>>
>> On Wed, Dec 21, 2016 at 10:51 AM, Cong Wang
>> wrote:
>>>
>>> On Wed, Dec 21, 2016 at 9:04 AM, Daniel Borkmann
>>> wrote:
What happens is that in tc_ctl_tfilter(), thread A allocat
On 12/21/2016 08:10 PM, Cong Wang wrote:
On Wed, Dec 21, 2016 at 10:51 AM, Cong Wang wrote:
On Wed, Dec 21, 2016 at 9:04 AM, Daniel Borkmann wrote:
What happens is that in tc_ctl_tfilter(), thread A allocates a new
tp, initializes it, sets tp_created to 1, and calls into tp->ops->change()
wit
On Wed, Dec 21, 2016 at 10:51 AM, Cong Wang wrote:
> On Wed, Dec 21, 2016 at 9:04 AM, Daniel Borkmann wrote:
>> What happens is that in tc_ctl_tfilter(), thread A allocates a new
>> tp, initializes it, sets tp_created to 1, and calls into tp->ops->change()
>> with it. In that classifier callback
On 12/21/2016 07:51 PM, Cong Wang wrote:
On Wed, Dec 21, 2016 at 9:04 AM, Daniel Borkmann wrote:
What happens is that in tc_ctl_tfilter(), thread A allocates a new
tp, initializes it, sets tp_created to 1, and calls into tp->ops->change()
with it. In that classifier callback we had to unlock/lo
On Wed, Dec 21, 2016 at 9:04 AM, Daniel Borkmann wrote:
> What happens is that in tc_ctl_tfilter(), thread A allocates a new
> tp, initializes it, sets tp_created to 1, and calls into tp->ops->change()
> with it. In that classifier callback we had to unlock/lock the rtnl
> mutex and returned with
On Wed, 2016-12-21 at 18:04 +0100, Daniel Borkmann wrote:
> Shahar reported a soft lockup in tc_classify(), where we run into an
> endless loop when walking the classifier chain due to tp->next == tp
> which is a state we should never run into. The issue only seems to
> trigger under load in the tc
Shahar reported a soft lockup in tc_classify(), where we run into an
endless loop when walking the classifier chain due to tp->next == tp
which is a state we should never run into. The issue only seems to
trigger under load in the tc control path.
What happens is that in tc_ctl_tfilter(), thread A
18 matches
Mail list logo
