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 addresses modifications").
This bug can cause a
Hi, zhike,
It's difficult to give a very clear sequences about how this inconsistency
happens, but I can give you more details.
This is observed in our production environment. The correct megaflow should
encap packets with vxlan header and send out, but the action is drop.
This is usually
On 22 Sep 2022, at 12:03, Adrian Moreno wrote:
>>> I'm not a fan of this. Any updates to these structs needs to be
>>> mirrored across the codebase. I think it might be better to do
>>> something else.
>>
>> I agree with this, but for keeping things simple and not replicating this in
>>
Hi Michael,
On 21/09/2022 16:08, 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
On 22 Sep 2022, at 13:15, Adrian Moreno wrote:
> On 9/21/22 11:17, Eelco Chaudron wrote:
>>
>>
>> On 20 Sep 2022, at 20:52, Aaron Conole wrote:
>>
>>> Eelco Chaudron writes:
>>>
This patch adds a Python script that can be used to analyze the
revalidator runs by providing statistics
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 lflow "input context" to be used during
Hi Han,
On 9/21/22 23:06, Han Zhou wrote:
> Thanks Dumitru for this promising optimization!
>
Thanks for checking it out!
> On Thu, Aug 11, 2022 at 1:03 AM Dumitru Ceara wrote:
>>
>> On 8/10/22 19:54, Mark Michelson wrote:
>>> Hi Dumitru,
>>>
>>
>> Hi Mark,
>>
>>> I read the patch series, and
Bleep bloop. Greetings Michael Phelan, 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: Line is 102 characters long (recommended limit is 79)
#110 FILE: NEWS:19:
On Wed, Sep 14, 2022 at 6:09 AM Dumitru Ceara wrote:
>
> There's no need to explicitly cast the result of EN_OVSDB_GET() to the IDL
> table type. The only thing we need is to match constness. That's also
> fine because, as a matter of fact, IDL table objects should never be
> changed by IDL
Hi Thilak,
Thilak Raj Surendra Babu, Sep 22, 2022 at 07:16:
> Could we call rte_flow_validate() before calling flow_create ?
At first, I thought it would not be necessary hence skipped the
validation and I am only relying on the driver to reject the rule if not
supported. However, it may be a
Bleep bloop. Greetings Michael Phelan, 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: Line is 102 characters long (recommended limit is 79)
#111 FILE: NEWS:14:
On 9/21/22 11:17, Eelco Chaudron wrote:
On 20 Sep 2022, at 20:52, Aaron Conole wrote:
Eelco Chaudron writes:
This patch adds a Python script that can be used to analyze the
revalidator runs by providing statistics (including some real time
graphs).
The USDT events can also be captured
On 9/21/22 11:17, Eelco Chaudron wrote:
On 20 Sep 2022, at 20:52, Aaron Conole wrote:
Eelco Chaudron writes:
This patch adds a Python script that can be used to analyze the
revalidator runs by providing statistics (including some real time
graphs).
The USDT events can also be captured
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 addresses modifications").
This bug can cause a
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 reallocation of
the virtqueues happen.
A fix [1] has
Bleep bloop. Greetings Michael Phelan, 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: Line is 102 characters long (recommended limit is 79)
#97 FILE: NEWS:11:
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:
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
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: Alex Elder
Cc: "David S.
In preparation for reducing the use of ksize(), record the actual
allocation size for later memcpy(). This avoids copying extra
(uninitialized!) bytes into the patch buffer when the requested allocation
size isn't exactly the size of a kmalloc bucket. Additionally fixes
potential future issues
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
Hi,
This series fixes up the cases where callers of ksize() use it to
opportunistically grow their buffer sizes, which can run afoul of the
__alloc_size hinting that CONFIG_UBSAN_BOUNDS and CONFIG_FORTIFY_SOURCE
use to perform dynamic buffer bounds checking. Quoting the first patch:
In the
On 9/22/22 16:11, Adrian Moreno wrote:
On 9/22/22 13:15, Eelco Chaudron wrote:
On 22 Sep 2022, at 12:03, Adrian Moreno wrote:
I'm not a fan of this. Any updates to these structs needs to be
mirrored across the codebase. I think it might be better to do
something else.
I agree with
Bleep bloop. Greetings Michael Phelan, 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: Line is 84 characters long (recommended limit is 79)
#99 FILE: NEWS:12:
A
Backport e292e1376545 ("Bump required python version to 3.6.")
incorrectly changed the NEWS file. Fix it now.
Signed-off-by: Dumitru Ceara
---
NEWS | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/NEWS b/NEWS
index 1d236da14..0fd255942 100644
--- a/NEWS
+++
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 reallocation of
the virtqueues happen.
A fix [1] has
Problem Statement:
Before OVS 2.12 the OVS-DPDK datapath transmitted processed rx packet batches
directly to the wanted tx queues. In OVS 2.12 each PMD stores the processed
packets in an intermediate buffer per output port and flushes these output
buffers in a separate step. This buffering was
Am 22.09.22 um 05:10 schrieb Kees Cook:
Hi,
This series fixes up the cases where callers of ksize() use it to
opportunistically grow their buffer sizes, which can run afoul of the
__alloc_size hinting that CONFIG_UBSAN_BOUNDS and CONFIG_FORTIFY_SOURCE
use to perform dynamic buffer bounds
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 the scope
> of the compiler's ability to apply CONFIG_UBSAN_BOUNDS and (in the near
> future)
On 9/22/22 08:26, Han Zhou wrote:
> On Wed, Sep 14, 2022 at 6:09 AM Dumitru Ceara wrote:
>>
>> There's no need to explicitly cast the result of EN_OVSDB_GET() to the IDL
>> table type. The only thing we need is to match constness. That's also
>> fine because, as a matter of fact, IDL table
On 9/12/22 11:14, Ales Musil wrote:
> The load balancers can operate without specified protocol.
> Update the documentation for ovn-northd lflows with what is
> actually created by northd and change the output of
> ovn-nbctl lb-list to include protocol only if the
> port is specified. Without port
On Thu, Sep 22, 2022 at 08:45:19AM -0500, Alex Elder wrote:
> On 9/21/22 10:10 PM, Kees Cook wrote:
> > 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
On Wed, 21 Sep 2022 03:19:46 +0200 Michael Weiß wrote:
> 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
On 9/19/22 08:13, Ales Musil wrote:
> Looks good to me, thanks.
>
> Acked-by: Ales Musil
>
Thanks! Applied to main.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
On 9/19/22 08:41, Ales Musil wrote:
> On Fri, Sep 9, 2022 at 9:00 PM Han Zhou wrote:
>
>> This patch adjusts the order of adding tracked and untracked columns
>> to monitoring, to workaround a problem in OVS IDL that could end up
>> overwriting the track flag. A XXX comment is added for future
On 9/19/22 08:43, Ales Musil wrote:
> On Fri, Sep 9, 2022 at 9:00 PM Han Zhou wrote:
>
>> The column was not tracked before while it should. The column includes
>> many ovn-controller global configurations that could impact the way
>> flows are computed. It worked before because lots of the
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 having a mismatch between the requested allocation size and
the actual kmalloc bucket size, which is examined later via ksize(),
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
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
In preparation for reducing the use of ksize(), explicitly track the
size of scan_cmd allocations. This also allows for noticing if the scan
size changes unexpectedly. Note that using ksize() was already incorrect
here, in the sense that ksize() would not match the actual allocation
size, which
On Thu, Sep 22, 2022 at 07:18:51AM +0300, Kalle Valo wrote:
> Kees Cook writes:
>
> > In preparation for reducing the use of ksize(), explicitly track the
> > size of scan_cmd allocations. This also allows for noticing if the scan
> > size changes unexpectedly. Note that using ksize() was
On Thu, Sep 22, 2022 at 5:10 AM Kees Cook wrote:
>
> -#ifdef __alloc_size__
> -# define __alloc_size(x, ...) __alloc_size__(x, ## __VA_ARGS__) __malloc
> -#else
> -# define __alloc_size(x, ...) __malloc
> -#endif
> +#define __alloc_size(x, ...) __alloc_size__(x, ## __VA_ARGS__) __malloc
>
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.
Kees Cook writes:
> In preparation for reducing the use of ksize(), explicitly track the
> size of scan_cmd allocations. This also allows for noticing if the scan
> size changes unexpectedly. Note that using ksize() was already incorrect
> here, in the sense that ksize() would not match the
On Wed, Sep 21, 2022 at 08:10:05PM -0700, Kees Cook wrote:
> 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
On 9/21/22 10:10 PM, Kees Cook wrote:
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
Bleep bloop. Greetings Michael Phelan, 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: Line is 84 characters long (recommended limit is 79)
#101 FILE: NEWS:12:
A
Thanks, Dumitru.
Acked-by: Mark Michelson
I went ahead and merged this to branch-22.03
On 9/22/22 08:28, Dumitru Ceara wrote:
Backport e292e1376545 ("Bump required python version to 3.6.")
incorrectly changed the NEWS file. Fix it now.
Signed-off-by: Dumitru Ceara
---
NEWS | 13
Hi Ilya,
On 1/17/22 19:01, Ilya Maximets wrote:
On 1/5/22 09:19, Maxime Coquelin wrote:
Hash-based Tx steering feature will enable steering Tx
packets on transmit queues based on their hashes. In order
to test the feature, it is needed to be able to get the
per-queue statistics for Vhost-user
In OpenSSL 3.0 some functions were deprecated and replaced.
This commit adds some #ifdef to build without warning on both
OpenSSL 1.x and OpenSSL 3.x.
For OpenSSL 3.x, the default built-in DH parameters are used (as
suggested by SSL_CTX_set_dh_auto manpage).
Signed-off-by: Timothy Redaelli
---
Since OpenSSL upstream commit 1696b8909bbe
("Remove -C from dhparam,dsaparam,ecparam") "openssl dhparam" doesn't
support -C anymore.
This commit changes generate-dhparams-c to generate dhparams.c by parsing
"openssl dhparam -in "$1" -text -noout" output directly.
The generated file won't be used
Currently, it's not possible to build OVS using OpenSSL 3.0 with
--enable-Werror since OpenSSL 3.0 deprecated some functions.
Moreover, it's not possible to generate dhparams.c anymore on
OpenSSL 3.0 since -C option was removed from openssl dhparam tool.
With this series, it's possible to
Update OVS CLI and relevant documentation to use DPDK 19.11.13.
DPDK 19.11.13 contains fixes for the CVEs listed below:
CVE-2022-28199 [1]
CVE-2022-2132 [2]
A bug was introduced in DPDK 19.11.12 by the commit 1e68fe334ff0 ("vhost: fix
unsafe vring addresses modifications").
This bug can cause a
Update OVS CLI and relevant documentation to use DPDK 19.11.13.
DPDK 19.11.13 contains fixes for the CVEs listed below:
CVE-2022-28199 [1]
CVE-2022-2132 [2]
A bug was introduced in DPDK 19.11.12 by the commit 1e68fe334ff0 ("vhost: fix
unsafe vring addresses modifications").
This bug can cause a
On Thu, Sep 22, 2022 at 11:23:46AM +0200, Miguel Ojeda wrote:
> On Thu, Sep 22, 2022 at 5:10 AM Kees Cook wrote:
> >
> > -#ifdef __alloc_size__
> > -# define __alloc_size(x, ...) __alloc_size__(x, ## __VA_ARGS__) __malloc
> > -#else
> > -# define __alloc_size(x, ...) __malloc
> > -#endif
> >
On 9/22/22 13:15, Eelco Chaudron wrote:
On 22 Sep 2022, at 12:03, Adrian Moreno wrote:
I'm not a fan of this. Any updates to these structs needs to be
mirrored across the codebase. I think it might be better to do
something else.
I agree with this, but for keeping things simple and
On 8/18/22 20:57, Mark Michelson wrote:
> Hi Xavier. I think the only foolproof way to get the seq logic right in
> pinctrl is to perform all of the processing of pinctrl_handler
> (including reading the seq and waiting on the seq) with the
> pinctrl_mutex locked. However, this could cause a lot
On Thu, Sep 22, 2022 at 09:10:56AM +0200, Christian König wrote:
> Am 22.09.22 um 05:10 schrieb Kees Cook:
> > Hi,
> >
> > This series fixes up the cases where callers of ksize() use it to
> > opportunistically grow their buffer sizes, which can run afoul of the
> > __alloc_size hinting that
On Thu, Sep 22, 2022 at 03:56:54PM +, Ruhl, Michael J wrote:
> >From: dri-devel On Behalf Of Kees
> >Cook
> [...]
> >diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
> >b/drivers/net/ethernet/intel/igb/igb_main.c
> >index 2796e81d2726..4d70ee5b0f79 100644
> >---
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 out!
> >
> > > On Thu, Aug 11, 2022
On 8/5/22 22:34, Frode Nordahl wrote:
> As reported by Debian lintian.
>
> Signed-off-by: Frode Nordahl
> ---
I added Mark's ack and pushed this patch to the main branch.
Thanks,
Dumitru
___
dev mailing list
d...@openvswitch.org
>-Original Message-
>From: dri-devel On Behalf Of
>Kees Cook
>Sent: Wednesday, September 21, 2022 11:10 PM
>To: Vlastimil Babka
>Cc: linux-wirel...@vger.kernel.org; Jacob Shin ;
>l...@lists.linux.dev; dri-de...@lists.freedesktop.org; linux...@kvack.org;
>Eric Dumazet ; Nguyen, Anthony
On Thu, Sep 22, 2022 at 5:56 PM Kees Cook wrote:
>
> I wasn't sure if this "composite macro" was sane there, especially since
> it would be using __malloc before it was defined, etc. Would you prefer
> I move it?
Hmm... On one hand, they end up being attributes, so it could make
sense to have
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 out!
>
> > On Thu, Aug 11, 2022 at 1:03 AM Dumitru Ceara wrote:
> >>
> >> On 8/10/22 19:54, Mark Michelson
On Wed, 21 Sep 2022 20:10:03 -0700 Kees Cook wrote:
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 974e7138..4fe4c7544c1d 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -427,14 +427,15 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t
> gfp_mask,
>
On 9/22/22 17:55, Kees Cook wrote:
> On Thu, Sep 22, 2022 at 09:10:56AM +0200, Christian König wrote:
>> Am 22.09.22 um 05:10 schrieb Kees Cook:
>> > Hi,
>> >
>> > This series fixes up the cases where callers of ksize() use it to
>> > opportunistically grow their buffer sizes, which can run afoul
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
> > > probably
> > > also take care to
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 name looks good to me, but why does the new
69 matches
Mail list logo
