On 4/10/21 2:22 PM, Aaron Conole wrote:
> Ilya Maximets writes:
>
>> On 4/8/21 10:41 PM, Aaron Conole wrote:
>>> Joe Stringer writes:
>>>
>>>> Hey Aaron, long time no chat :)
>>>
>>> Same :)
>>>
>>>> On Fri, Mar
On 4/8/21 10:41 PM, Aaron Conole wrote:
> Joe Stringer writes:
>
>> Hey Aaron, long time no chat :)
>
> Same :)
>
>> On Fri, Mar 19, 2021 at 1:43 PM Aaron Conole wrote:
>>>
>>> When a user instructs a flow pipeline to perform connection tracking,
>>> there is an implicit L3 operation that occu
CC: ovs-dev
On 4/4/21 7:50 PM, Ilya Maximets wrote:
> 'struct ovs_zone_limit' has more members than initialized in
> ovs_ct_limit_get_default_limit(). The rest of the memory is a random
> kernel stack content that ends up being sent to userspace.
>
> Fix that by usi
efd5cb04a1 ("openvswitch: Support conntrack zone limit")
Signed-off-by: Ilya Maximets
---
net/openvswitch/conntrack.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
index c29b0ef1fc27..cadb6a29b
Hi, Louis. Thanks for your report!
Marcelo, Paul, could you, please, take a look?
Best regards, Ilya Maximets.
On 3/10/21 8:51 AM, Louis Peens wrote:
> Hi all
>
> We've recently encountered an interesting situation with OVS conntrack
> when offloading to the TC datapath, an
Cc: netdev
On 11/13/20 3:28 PM, Eelco Chaudron wrote:
>
>
> On 13 Nov 2020, at 13:06, Ilya Maximets wrote:
>
>> On 11/13/20 11:04 AM, Eelco Chaudron wrote:
>>> Add support for the dec_ttl action. Instead of programming the datapath with
>>> a flow that match
On 10/15/20 1:04 PM, Ilya Maximets wrote:
> On 10/15/20 12:54 PM, Eelco Chaudron wrote:
>>
>>
>> On 15 Oct 2020, at 12:27, Ilya Maximets wrote:
>>
>>> On 10/15/20 11:46 AM, Eelco Chaudron wrote:
>>>> The flow_lookup() function uses per CPU variables,
On 10/15/20 12:54 PM, Eelco Chaudron wrote:
>
>
> On 15 Oct 2020, at 12:27, Ilya Maximets wrote:
>
>> On 10/15/20 11:46 AM, Eelco Chaudron wrote:
>>> The flow_lookup() function uses per CPU variables, which must not be
>>> preempted. However, this is fin
On 10/15/20 11:46 AM, Eelco Chaudron wrote:
> The flow_lookup() function uses per CPU variables, which must not be
> preempted. However, this is fine in the general napi use case where
> the local BH is disabled. But, it's also called in the netlink
> context, which is preemptible. The below patch
On 26.08.2019 9:10, Björn Töpel wrote:
> From: Björn Töpel
>
> The state variable was read, and written outside the control mutex
> (struct xdp_sock, mutex), without proper barriers and {READ,
> WRITE}_ONCE correctness.
>
> In this commit this issue is addressed, and the state member is now
> us
10 matches
Mail list logo
