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 rep
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 fun
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 remo
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 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
https://mail.openvswi
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 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 at
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 the
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 wrot
>-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 L
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
> >--- a/drivers/net/ethernet/i
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 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
> > +#d
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 CONFI
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 fi
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 fix
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 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
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 objec
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 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 confi
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: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/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 __alloc_size(
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 through
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
> +#de
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 already
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 actua
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.
Addition
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 wou
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 partia
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: linux-me...@vger.kernel.org
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 t
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 bui
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. M
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 wher
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 t
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: linux-fsde...@vger.kernel.o
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 majorit
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: linux-bt...@vger.kernel.org
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 effor
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 checkin
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) CONFIG_FORTIFY
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 no
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
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
---
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 generate
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
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:
htt
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 intr
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 p
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 +
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 b
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 b
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
+++ b/NE
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 of
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 (i
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
>> all
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 t
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 because
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:
ht
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 t
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:
ht
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 dea
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 dea
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
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
68 matches
Mail list logo