When PMDs perform upcalls, the newly generated ukey will replace
the old, however, the newly generated mageflow will be discard
to reuse the old one without checking if the actions of new and
old are equal.
This code prevents in case someone runs dpctl/add-flow to add
a dp flow with inconsistent
The userspace datapath mananges all the magaflows by a cmap. The cmap
data structrue will grow/shrink during the datapath processing and it
will re-position megaflows. This might result in two revalidator threads
might process a same megaflow during one dump stage.
Consider a situation that,
There is a race condition between the revalidator threads and
the handler/pmd threads.
revalidator PMD threads
push_dp_ops deletes a key and tries
to del the dp magaflow.
does the upcall, generates a new ukey,
push_dp_ops only handles delete ops errors but ignores the modify
ops results. It's better to handle all the dp operation errors in
a consistent way.
We observe in the production environment that sometimes a megaflow
with wrong actions keep staying in datapath. The coverage command shows
Bleep bloop. Greetings Kees Cook, I am a robot and I have tried out your patch.
Thanks for your contribution.
I encountered some error that I wasn't expecting. See the details below.
Patch skipped due to previous failure.
Please check this out. If you feel there has been an error, please
Bleep bloop. Greetings Kees Cook, I am a robot and I have tried out your patch.
Thanks for your contribution.
I encountered some error that I wasn't expecting. See the details below.
git-am:
error: sha1 information is lacking or useless (include/linux/compiler_types.h).
error: could not build
With all "silently resizing" callers of ksize() refactored, remove the
logic in ksize() that would allow it to be used to effectively change
the size of an allocation (bypassing __alloc_size hints, etc). Users
wanting this feature need to either use kmalloc_size_roundup() before an
allocation, or
With skbuff's post-allocation use of ksize() rearranged to use
kmalloc_size_round() prior to allocation, the compiler can correctly
reason about the size of these allocations. The prior mismatch had caused
buffer overflow mitigations to erroneously fire under CONFIG_UBSAN_BOUNDS,
requiring a
Round up allocations with kmalloc_size_roundup() so that devres's use
of ksize() is always accurate and no special handling of the memory is
needed by KASAN, UBSAN_BOUNDS, nor FORTIFY_SOURCE.
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wysocki"
Signed-off-by: Kees Cook
---
drivers/base/devres.c | 3
In preparation for no longer unpoisoning in ksize(), remove the behavioral
self-tests for ksize().
Cc: Andrey Ryabinin
Cc: Alexander Potapenko
Cc: Andrey Konovalov
Cc: Dmitry Vyukov
Cc: Vincenzo Frascino
Cc: Andrew Morton
Cc: kasan-...@googlegroups.com
Cc: linux...@kvack.org
Signed-off-by:
Round up allocations with kmalloc_size_roundup() so that mempool's use
of ksize() is always accurate and no special handling of the memory is
needed by KASAN, UBSAN_BOUNDS, nor FORTIFY_SOURCE.
Cc: Andrew Morton
Cc: linux...@kvack.org
Signed-off-by: Kees Cook
---
mm/mempool.c | 2 +-
1 file
Round up allocations with kmalloc_size_roundup() so that openvswitch's
use of ksize() is always accurate and no special handling of the memory
is needed by KASAN, UBSAN_BOUNDS, nor FORTIFY_SOURCE.
Cc: Pravin B Shelar
Cc: "David S. Miller"
Cc: Eric Dumazet
Cc: Jakub Kicinski
Cc: Paolo Abeni
Round up allocations with kmalloc_size_roundup() so that the verifier's
use of ksize() is always accurate and no special handling of the memory
is needed by KASAN, UBSAN_BOUNDS, nor FORTIFY_SOURCE. Pass the new size
information back up to callers so they can use the space immediately,
so array
Instead of discovering the kmalloc bucket size _after_ allocation, round
up proactively so the allocation is explicitly made for the full size,
allowing the compiler to correctly reason about the resulting size of
the buffer through the existing __alloc_size() hint.
Cc:
Instead of discovering the kmalloc bucket size _after_ allocation, round
up proactively so the allocation is explicitly made for the full size,
allowing the compiler to correctly reason about the resulting size of
the buffer through the existing __alloc_size() hint.
Cc: Sumit Semwal
Cc:
Instead of discovering the kmalloc bucket size _after_ allocation, round
up proactively so the allocation is explicitly made for the full size,
allowing the compiler to correctly reason about the resulting size of
the buffer through the existing __alloc_size() hint.
Cc: "David S. Miller"
Cc:
Instead of discovering the kmalloc bucket size _after_ allocation, round
up proactively so the allocation is explicitly made for the full size,
allowing the compiler to correctly reason about the resulting size of
the buffer through the existing __alloc_size() hint.
Cc: Chris Mason
Cc: Josef
Instead of discovering the kmalloc bucket size _after_ allocation, round
up proactively so the allocation is explicitly made for the full size,
allowing the compiler to correctly reason about the resulting size of
the buffer through the existing __alloc_size() hint.
This will allow for kernels
All callers of APIs that allowed a 0-sized frag_size appear to be
passing actual size information already, so this use of ksize() can
be removed. However, just in case there is something still depending
on this behavior, issue a WARN and fall back to as before to ksize()
which means we'll also
In preparation for removing the "silently change allocation size"
users of ksize(), explicitly round up all q_vector allocations so that
allocations can be correctly compared to ksize().
Additionally fix potential use-after-free in the case of new allocation
failure: only free memory if the
Hi,
The main details on this series are in patch #2's commit log. It's long,
so I won't repeat it again here for the v2. As before, I've tried to
trim the CC list.
v2:
- _keep_ ksize(), but remove instrumentation (makes patch series smaller)
- reorganized skbuff logic to avoid yet more
In the effort to help the compiler reason about buffer sizes, the
__alloc_size attribute was added to allocators. This improves the scope
of the compiler's ability to apply CONFIG_UBSAN_BOUNDS and (in the near
future) CONFIG_FORTIFY_SOURCE. For most allocations, this works well,
as the vast
The __malloc attribute should not be applied to "realloc" functions, as
the returned pointer may alias the storage of the prior pointer. Instead
of splitting __malloc from __alloc_size, which would be a huge amount of
churn, just create __realloc_size for the few cases where it is needed.
On Fri, Sep 23, 2022 at 09:17:25AM +0800, Feng Tang wrote:
> On Thu, Sep 22, 2022 at 07:12:21PM +0800, Hyeonggon Yoo wrote:
> > On Wed, Sep 21, 2022 at 08:10:02PM -0700, Kees Cook wrote:
> > > [...]
> > > Introduce kmalloc_size_roundup(), to serve this function so we can start
> > > replacing the
On Fri, Sep 23, 2022 at 8:10 AM Dumitru Ceara wrote:
>
> On 9/22/22 19:55, Han Zhou wrote:
> > On Thu, Sep 22, 2022 at 10:38 AM Han Zhou wrote:
> >>
> >>
> >>
> >> On Thu, Sep 22, 2022 at 1:00 AM Dumitru Ceara
wrote:
> >>>
> >>> Hi Han,
> >>>
> >>> On 9/21/22 23:06, Han Zhou wrote:
>
Hi, Zhike,
First I am trying to explain why this fix is not fixing it.
This lock-and-lookup code is actually for the case when all megaflows are
not per-PMD stored according to the ovs commit history.
So it's necessary to check if the megaflow is installed by another PMD.
Now megaflows are
On Fri, Sep 23, 2022 at 1:42 AM Dumitru Ceara wrote:
>
> On 9/23/22 01:07, Han Zhou wrote:
> > On Wed, Sep 14, 2022 at 6:10 AM Dumitru Ceara wrote:
> >>
> >> This is actually more in line with how the callback is used. It's
called
> >> every the incremental engine preparese for the next engine
> -Original Message-
> From: David Marchand
> Sent: Wednesday 21 September 2022 11:26
> To: Finn, Emma
> Cc: d...@openvswitch.org; i.maxim...@ovn.org
> Subject: Re: [ovs-dev] [v2] odp-execute: Add ISA implementation of
> set_masked IPv6 action
>
> On Tue, Sep 20, 2022 at 3:19 PM Emma
On 9/22/22 19:55, Han Zhou wrote:
> On Thu, Sep 22, 2022 at 10:38 AM Han Zhou wrote:
>>
>>
>>
>> On Thu, Sep 22, 2022 at 1:00 AM Dumitru Ceara wrote:
>>>
>>> Hi Han,
>>>
>>> On 9/21/22 23:06, Han Zhou wrote:
Thanks Dumitru for this promising optimization!
>>>
>>> Thanks for checking it
Hi,
On Mon, Sep 12, 2022 at 05:11:32PM +0200, Ilya Maximets wrote:
> On 8/29/22 12:04, Roi Dayan via dev wrote:
...
> > Hi,
> >
> > we are also running some ovs/ovn tests with this patch.
> > we didn't encounter breaking issues with current tests we have.
> >
> > Thanks,
> > Roi
>
> Thanks, Roi,
On Fri, Sep 23, 2022 at 2:43 PM Kevin Traynor wrote:
>
> On 22/09/2022 13:40, Michael Phelan wrote:
> > Update OVS CLI and relevant documentation to use DPDK 20.11.6.
> >
> > A bug was introduced in DPDK 20.11.5 by the commit 33f2e3756186 ("vhost:
> > fix unsafe vring addresses modifications").
Similar to the previous commit, the Netlink interface of the OVS
conntrack module was restricted to global CAP_NET_ADMIN by using
GENL_ADMIN_PERM. This is changed to GENL_UNS_ADMIN_PERM to support
unprivileged containers in non-initial user namespace.
Signed-off-by: Michael Weiß
---
The Netlink interface for metering was restricted to global CAP_NET_ADMIN
by using GENL_ADMIN_PERM. To allow metring in a non-inital user namespace,
e.g., a container, this is changed to GENL_UNS_ADMIN_PERM.
Signed-off-by: Michael Weiß
---
net/openvswitch/meter.c | 14 +++---
1 file
Hi Peng,
Right, I also met this issue, and wondering the sequence for this
inconsistence, and would like to hear your “new cause”.
Anyway I believe your below patch should fix this issue.
[ovs-dev,ovs-dev,v2,1/4] ofproto-dpif-upcall: fix push_dp_ops
Br,
Zhike
From: ".贺鹏"
Date: Friday,
Currently using openvswitch in a non-initial user namespace, e.g., an
unprivileged container, is possible but without metering and conntrack
support. This is due to the restriction of the corresponding Netlink
interfaces to the global CAP_NET_ADMIN.
This simple patches switch from GENL_ADMIN_PERM
On 23 Sep 2022, at 10:35, Simon Horman wrote:
> From: Yifan Li
>
> Allow revalidator for hardware offload of meters via OVS-TC.
> Without revalidator, tc meter action can not be deleted while
> flow exists. The revalidator fix this bug by continuously
> checking existing meters and delete the
Hi, Zhike,
After receiving your email, I was becoming curious about this code and did
more investigation on it.
and I found some problems with the code and now I believe this inconsistent
processing is NOT the root cause for the inconsistent actions between ukey
and datapath.
and I found a new
On 22/09/2022 13:40, Michael Phelan wrote:
Update OVS CLI and relevant documentation to use DPDK 20.11.6.
A bug was introduced in DPDK 20.11.5 by the commit 33f2e3756186 ("vhost: fix unsafe
vring addresses modifications").
This bug can cause a deadlock when vIOMMU is enabled and NUMA
On 23 Sep 2022, at 12:35, Ales Musil wrote:
> On Fri, Sep 23, 2022 at 12:29 PM Eelco Chaudron wrote:
>
>>
>>
>> On 7 Sep 2022, at 8:54, Ales Musil wrote:
>>
>>> Through out the code there is the same pattern that occurs
>>> in regards to to finish_freezing when ctx->freezing=true or
>>>
On 7 Sep 2022, at 8:54, Ales Musil wrote:
> When the packet was traveling through patch port boundary
> OvS would check if any of the actions is reversible,
> if not it would clone the packet. However, the check
> was only at the first level of the second bridge.
> That caused some issues when
On 22/09/2022 10:39, Michael Phelan wrote:
Update OVS CLI and relevant documentation to use DPDK 21.11.2.
DPDK 21.11.2 contains fixes for the CVEs listed below:
CVE-2022-28199 [1]
CVE-2022-2132 [2]
A bug was introduced in DPDK 21.11.1 by the commit 01e3dee29c02 ("vhost: fix unsafe
vring
On 22/09/2022 10:35, Michael Phelan wrote:
Update OVS CLI and relevant documentation to use DPDK 21.11.2.
DPDK 21.11.2 contains fixes for the CVEs listed below:
CVE-2022-28199 [1]
CVE-2022-2132 [2]
A bug was introduced in DPDK 21.11.1 by the commit 01e3dee29c02 ("vhost: fix unsafe
vring
On Fri, Sep 23, 2022 at 12:29 PM Eelco Chaudron wrote:
>
>
> On 7 Sep 2022, at 8:54, Ales Musil wrote:
>
> > Through out the code there is the same pattern that occurs
> > in regards to to finish_freezing when ctx->freezing=true or
> > xlate_action_set when ctx->freezing=false. Extract it to
On 7 Sep 2022, at 8:54, Ales Musil wrote:
> Through out the code there is the same pattern that occurs
> in regards to to finish_freezing when ctx->freezing=true or
> xlate_action_set when ctx->freezing=false. Extract it to common
> function that is called from those places instead.
>
>
On 9/22/22 08:24, Han Zhou wrote:
> On Wed, Sep 14, 2022 at 6:09 AM Dumitru Ceara wrote:
>>
>
> Thanks Dumitru for the improvement.
>
>> The nd_ra_opts and controller_event_ops are actually static they never
>> change at runtime. DHCP records can instead be computed when populating
>> the
Thanks Hyeonggon for looping in me.
On Thu, Sep 22, 2022 at 07:12:21PM +0800, Hyeonggon Yoo wrote:
> On Wed, Sep 21, 2022 at 08:10:02PM -0700, Kees Cook wrote:
> > In the effort to help the compiler reason about buffer sizes, the
> > __alloc_size attribute was added to allocators. This improves
On 9/22/22 23:49, Kees Cook wrote:
> On Thu, Sep 22, 2022 at 11:05:47PM +0200, Vlastimil Babka wrote:
>> On 9/22/22 17:55, Kees Cook wrote:
>> > On Thu, Sep 22, 2022 at 09:10:56AM +0200, Christian König wrote:
>> > [...]
>> > > So when this patch set is about to clean up this use case it should
References: <20220923083514.296638-1-simon.hor...@corigine.com>
Bleep bloop. Greetings Simon Horman, I am a robot and I have tried out your
patch.
Thanks for your contribution.
I encountered some error that I wasn't expecting. See the details below.
checkpatch:
WARNING: Unexpected
On 9/23/22 01:07, Han Zhou wrote:
> On Wed, Sep 14, 2022 at 6:10 AM Dumitru Ceara wrote:
>>
>> This is actually more in line with how the callback is used. It's called
>> every the incremental engine preparese for the next engine run.
>>
>> Signed-off-by: Dumitru Ceara
>
> Thanks Dumtru. The
From: Yifan Li
Allow revalidator for hardware offload of meters via OVS-TC.
Without revalidator, tc meter action can not be deleted while
flow exists. The revalidator fix this bug by continuously
checking existing meters and delete the unneeded ones. The
autotest cases of revalidator are also
On Tue, Aug 30, 2022 at 6:05 PM Mike Pattrick wrote:
>
> Add additional logging for debug and info level with a focus on code
> related to bond members coming up, go down, and changing.
>
> Several existing log messages were modified to handle sub 1kB log
> messages with more grace. Instead of
51 matches
Mail list logo
