[ Making this a different thread, since unrelated to the other one. ]
On 11/25/2016 07:23 AM, Cong Wang wrote:
On Thu, Nov 24, 2016 at 4:17 PM, Daniel Borkmann wrote:
[...]
(Btw, matchall is still broken besides this fix. mall_delete() sets the
RCU_INIT_POINTER(head->filter, NULL), so that
On Thu, Nov 24, 2016 at 4:17 PM, Daniel Borkmann wrote:
>
>
> I'm not sure if setting a dummy object for each affected classifier is
> making things better. Are you having this in mind as a target for -net?
>
> We do kfree_rcu() the head (tp->root) and likewise do we kfree_rcu() the
> tp immediate
On 11/24/2016 09:25 PM, David Miller wrote:
From: Cong Wang
Date: Tue, 22 Nov 2016 11:28:37 -0800
On Tue, Nov 22, 2016 at 8:11 AM, Jiri Pirko wrote:
Tue, Nov 22, 2016 at 05:04:11PM CET, dan...@iogearbox.net wrote:
Hmm, I don't think we want to have such an additional test in fast
path for e
From: Cong Wang
Date: Tue, 22 Nov 2016 11:28:37 -0800
> On Tue, Nov 22, 2016 at 8:11 AM, Jiri Pirko wrote:
>> Tue, Nov 22, 2016 at 05:04:11PM CET, dan...@iogearbox.net wrote:
>>>Hmm, I don't think we want to have such an additional test in fast
>>>path for each and every classifier. Can we think
On Wed, Nov 23, 2016 at 3:29 AM, Daniel Borkmann wrote:
>
> Can't we drop the 'force' parameter from tcf_destroy() and related cls
> destroy() callbacks, and change the logic roughly like this:
>
> [...]
> case RTM_DELTFILTER:
> err = tp->ops->delete(tp, fh, &drop_tp);
>
On 11/23/2016 06:24 AM, Cong Wang wrote:
On Tue, Nov 22, 2016 at 3:36 PM, John Fastabend
wrote:
On 16-11-22 12:41 PM, Daniel Borkmann wrote:
On 11/22/2016 08:28 PM, Cong Wang wrote:
On Tue, Nov 22, 2016 at 8:11 AM, Jiri Pirko wrote:
Tue, Nov 22, 2016 at 05:04:11PM CET, dan...@iogearbox.net
On Tue, Nov 22, 2016 at 3:36 PM, John Fastabend
wrote:
> On 16-11-22 12:41 PM, Daniel Borkmann wrote:
>> On 11/22/2016 08:28 PM, Cong Wang wrote:
>>> On Tue, Nov 22, 2016 at 8:11 AM, Jiri Pirko wrote:
Tue, Nov 22, 2016 at 05:04:11PM CET, dan...@iogearbox.net wrote:
> Hmm, I don't think w
On 16-11-22 12:41 PM, Daniel Borkmann wrote:
> On 11/22/2016 08:28 PM, Cong Wang wrote:
>> On Tue, Nov 22, 2016 at 8:11 AM, Jiri Pirko wrote:
>>> Tue, Nov 22, 2016 at 05:04:11PM CET, dan...@iogearbox.net wrote:
Hmm, I don't think we want to have such an additional test in fast
path for e
On 11/22/2016 08:28 PM, Cong Wang wrote:
On Tue, Nov 22, 2016 at 8:11 AM, Jiri Pirko wrote:
Tue, Nov 22, 2016 at 05:04:11PM CET, dan...@iogearbox.net wrote:
Hmm, I don't think we want to have such an additional test in fast
path for each and every classifier. Can we think of ways to avoid that
On Tue, Nov 22, 2016 at 8:11 AM, Jiri Pirko wrote:
> Tue, Nov 22, 2016 at 05:04:11PM CET, dan...@iogearbox.net wrote:
>>Hmm, I don't think we want to have such an additional test in fast
>>path for each and every classifier. Can we think of ways to avoid that?
>>
>>My question is, since we unlink
Tue, Nov 22, 2016 at 04:37:42PM CET, da...@davemloft.net wrote:
>From: Jiri Pirko
>Date: Tue, 22 Nov 2016 15:48:44 +0100
>
>> Tue, Nov 22, 2016 at 03:25:26PM CET, r...@mellanox.com wrote:
>>>tp->root is being allocated in init() time and kfreed in destroy()
>>>however it is being dereferenced in c
Tue, Nov 22, 2016 at 05:04:11PM CET, dan...@iogearbox.net wrote:
>[ + John ]
>
>On 11/22/2016 03:48 PM, Jiri Pirko wrote:
>> Tue, Nov 22, 2016 at 03:25:26PM CET, r...@mellanox.com wrote:
>> > tp->root is being allocated in init() time and kfreed in destroy()
>> > however it is being dereferenced in
[ + John ]
On 11/22/2016 03:48 PM, Jiri Pirko wrote:
Tue, Nov 22, 2016 at 03:25:26PM CET, r...@mellanox.com wrote:
tp->root is being allocated in init() time and kfreed in destroy()
however it is being dereferenced in classify() path.
We could be in classify() path after destroy() was called a
From: Jiri Pirko
Date: Tue, 22 Nov 2016 15:48:44 +0100
> Tue, Nov 22, 2016 at 03:25:26PM CET, r...@mellanox.com wrote:
>>tp->root is being allocated in init() time and kfreed in destroy()
>>however it is being dereferenced in classify() path.
>>
>>We could be in classify() path after destroy() wa
Tue, Nov 22, 2016 at 03:25:26PM CET, r...@mellanox.com wrote:
>tp->root is being allocated in init() time and kfreed in destroy()
>however it is being dereferenced in classify() path.
>
>We could be in classify() path after destroy() was called and thus
>tp->root is null. Verifying if tp->root is
tp->root is being allocated in init() time and kfreed in destroy()
however it is being dereferenced in classify() path.
We could be in classify() path after destroy() was called and thus
tp->root is null. Verifying if tp->root is null in classify() path
is enough because it's being freed with kf
16 matches
Mail list logo
