As discussed in [1] max value of variable offset has to be checked for
overflow on stack access otherwise verifier would accept code like this:
0: (b7) r2 = 6
1: (b7) r3 = 28
2: (7a) *(u64 *)(r10 -16) = 0
3: (7a) *(u64 *)(r10 -8) = 0
4: (79) r4 = *(u64 *)(r1 +168)
5: (c5) if r4 s< 0x0
Test that verifier rejects indirect access to uninitialized stack with
variable offset.
Example of output:
# ./test_verifier
...
#859/p indirect variable-offset stack access, uninitialized OK
Signed-off-by: Andrey Ignatov
---
.../testing/selftests/bpf/verifier/var_off.c | 27
Proper support of indirect stack access with variable offset in
unprivileged mode (!root) requires corresponding support in Spectre
masking for stack ALU in retrieve_ptr_limit().
There are no use-case for variable offset in unprivileged mode though so
make verifier reject such accesses for simplic
check_stack_access() that prints verbose log is used in
adjust_ptr_min_max_vals() that prints its own verbose log and now they
stick together, e.g.:
variable stack access var_off=(0xfff0; 0x4) off=-16
size=1R2 stack pointer arithmetic goes out of range, prohibited for
!root
Add
Test that verifier rejects indirect stack access with variable offset in
unprivileged mode and accepts same code in privileged mode.
Since pointer arithmetics is prohibited in unprivileged mode verifier
should reject the program even before it gets to helper call that uses
variable offset, at the
Test the case when reg->smax_value is too small/big and can overflow,
and separately min and max values outside of stack bounds.
Example of output:
# ./test_verifier
#856/p indirect variable-offset stack access, unbounded OK
#857/p indirect variable-offset stack access, max out of bound OK
v2->v3:
- sanity check max value for variable offset.
v1->v2:
- rely on meta = NULL to reject var_off stack access to uninit buffer.
This patch set is a follow-up for discussion [1].
It fixes variable offset stack access handling for raw and unprivileged
mode, rejecting both of them, and sanity
It's hard to guarantee that whole memory is marked as initialized on
helper return if uninitialized stack is accessed with variable offset
since specific bounds are unknown to verifier. This may cause
uninitialized stack leaking.
Reject such an access in check_stack_boundary to prevent possible
le
On Wed, Apr 03, 2019 at 08:43:38AM -0700, Peter Oskolkov wrote:
> This patch adds tests validating that VRF and BPF-LWT
> encap work together well, as requested by David Ahern.
LGTM. David Ahern, please review also.
Acked-by: Martin KaFai Lau
On Wed, Apr 03, 2019 at 01:53:18PM -0700, Stanislav Fomichev wrote:
> Rename bpf_flow_dissector.txt to bpf_flow_dissector.rst and fix
> formatting. Also, link it from the Documentation/networking/index.rst.
Acked-by: Martin KaFai Lau
From: Saeed Mahameed
Date: Tue, 2 Apr 2019 16:03:42 -0700
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
> b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
> index 7c1ea0a17024..d3a507be72d4 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
> +++ b/drivers/net/ethe
From: David Ahern
Date: Tue, 2 Apr 2019 14:11:53 -0700
> From: David Ahern
>
> Second set of three with the end goal of enabling IPv6 gateways with IPv4
> routes.
>
> This set moves:
> - the ipv4 tracepoint to take a fib_nh_common and updates it to handle
> a v6 gateway.
> - consolidates ro
From: Tetsuo Handa
Date: Wed, 3 Apr 2019 06:07:40 +0900
> On 2019/04/03 5:23, David Miller wrote:
>> Please fix RDS and other protocols to examine the length properly
>> instead.
>
> Do you prefer adding branches only for allow reading the family of socket
> address?
If the length is zero, the
From: Heiner Kallweit
Date: Tue, 2 Apr 2019 20:43:30 +0200
> The original patch didn't consider the case that autoneg process
> finishes successfully but both link partners have no mode in common.
> In this case there's no link, nevertheless we may be interested in
> what the link partner adverti
From: Steffen Klassert
Date: Tue, 2 Apr 2019 08:16:03 +0200
> Currently we may merge incorrectly a received GSO packet
> or a packet with frag_list into a packet sitting in the
> gro_hash list. skb_segment() may crash in this case because
> the assumptions on the skb layout are not met in this ca
> On Apr 3, 2019, at 17:13, Daniel Borkmann wrote:
>
> [ +Jeff ]
>
> Given these two are contained to ixgbe, I presume Jeff wants to pick
> these up instead via his tree?
Yes, I will be picking them up.
>
>> On 04/03/2019 11:57 PM, William Tu wrote:
>> The tx bytecount is done twice. When
From: David Ahern
pmtu.sh script runs a number of tests and dumps a summary of pass/fail.
If a test fails, it is near impossible to debug why. For example:
TEST: ipv6: PMTU exceptions [FAIL]
There are a lot of commands run behind the scenes for this test. Which
one is
Daniel Borkmann [Wed, 2019-04-03 16:19 -0700]:
> On 04/03/2019 11:57 PM, Andrey Ignatov wrote:
> > Daniel Borkmann [Wed, 2019-04-03 09:46 -0700]:
> >> On 04/03/2019 06:21 PM, Daniel Borkmann wrote:
> >>> On 04/02/2019 10:19 PM, Andrey Ignatov wrote:
...
> >>>
> min_off = reg
Em Wed, Apr 03, 2019 at 11:12:58AM +0200, Jiri Olsa escreveu:
> On Wed, Apr 03, 2019 at 11:04:28AM +0200, Daniel Borkmann wrote:
> > On 04/03/2019 10:46 AM, Jiri Olsa wrote:
> > > On Tue, Apr 02, 2019 at 09:49:50AM -0700, andrii.nakry...@gmail.com wrote:
> > >> From: Andrii Nakryiko
> > >>
> > >>
Hi,
I'm exercising a bit of paranoia trying to find the canonical source for
iputils.
Our internal build system is currently been pointing to skbuff.net[1].
This appears to now be out of date there hasn't been a new tarball since
December 2015.
It looks like the tarballs have moved to github[
Update BPF_CGROUP_RUN_PROG_INET_EGRESS() callers to support returning
congestion notifications from the BPF programs.
Signed-off-by: Lawrence Brakmo
Signed-off-by: Alexei Starovoitov
---
net/ipv4/ip_output.c | 34 +++---
net/ipv6/ip6_output.c | 26 +-
When a packet is dropped when calling queue_xmit in __tcp_transmit_skb
and packets_out is 0, it is beneficial to set a small probe timer.
Otherwise, the throughput for the flow can suffer because it may need to
depend on the probe timer to start sending again. The default value for
the probe timer
On Wed, Apr 03 2019, David Laight wrote:
> From: NeilBrown
>> Sent: 02 April 2019 22:11
>>
>> On Tue, Apr 02 2019, David Laight wrote:
>>
>> > From: NeilBrown
>> >> Sent: 02 April 2019 00:08
>> >>
>> >> This patch changes rhashtables to use a bit_spin_lock on BIT(1) of the
>> >> bucket pointer t
Adds more stats to HBM, including average cwnd and rtt of all TCP
flows, percents of packets that are ecn ce marked and distribution
of return values.
Signed-off-by: Lawrence Brakmo
---
samples/bpf/hbm.c | 33 +++
samples/bpf/hbm.h | 6
samples/bpf/hbm_ker
[ +Jeff ]
Given these two are contained to ixgbe, I presume Jeff wants to pick
these up instead via his tree?
On 04/03/2019 11:57 PM, William Tu wrote:
> The tx bytecount is done twice. When running
> './xdpsock -t -N -i eth3' and 'ip -s link show dev eth3'
> The avg packet size is 120 instead o
For egress packets, __cgroup_bpf_fun_filter_skb() will now call
BPF_PROG_CGROUP_INET_EGRESS_RUN_ARRAY() instead of PROG_CGROUP_RUN_ARRAY()
in order to propagate congestion notifications (cn) requests to TCP
callers.
For egress packets, this function can return:
NET_XMIT_SUCCESS(0)- cont
Create new macro BPF_PROG_CGROUP_INET_EGRESS_RUN_ARRAY() to be used by
__cgroup_bpf_run_filter_skb for EGRESS BPF progs so BPF programs can
request cwr for TCP packets.
Current cgroup skb programs can only return 0 or 1 (0 to drop the
packet. This macro changes the behavior so the low order bit
in
Update hbm_out_kern.c to support returning cn notifications.
Also updates relevant files to allow disabling cn notifications.
Signed-off-by: Lawrence Brakmo
---
samples/bpf/do_hbm_test.sh | 10 +++---
samples/bpf/hbm.c | 18 +++---
samples/bpf/hbm.h | 3 ++-
sa
Allows cgroup inet skb programs to return values in the range [0, 3].
The second bit is used to deterine if congestion occurred and higher
level protocol should decrease rate. E.g. TCP would call tcp_enter_cwr()
The bpf_prog must set expected_attach_type to BPF_CGROUP_INET_EGRESS
at load time if i
This patchset adds support for propagating congestion notifications (cn)
to TCP from cgroup inet skb egress BPF programs.
Current cgroup skb BPF programs cannot trigger TCP congestion window
reductions, even when they drop a packet. This patch-set adds support
for cgroup skb BPF programs to send c
On 04/02/2019 06:27 AM, Alexei Starovoitov wrote:
> v1->v2:
> - fixed typo in patch 1
> - added a patch to convert kcalloc to kvcalloc
> - added a patch to verbose 16-bit jump offset check
> - added a test with 1m insns
>
> This patch set is the first step to be able to accept large programs.
> Th
On 04/03/2019 11:57 PM, Andrey Ignatov wrote:
> Daniel Borkmann [Wed, 2019-04-03 09:46 -0700]:
>> On 04/03/2019 06:21 PM, Daniel Borkmann wrote:
>>> On 04/02/2019 10:19 PM, Andrey Ignatov wrote:
It's hard to guarantee that whole memory is marked as initialized on
helper return if uniniti
hci_event_packet() blindly assumes all packets are sane, at least
for packets allocated via vhci_get_user() path this is not true.
We have to check if we access skb data out-of-bound with
pskb_may_pull() before each skb->data dereference on RX path.
Reported-and-tested-by: syzbot+cec7a50c412a2c03f
Similarly, we need to check skb->data boundary for
HCI_EV_CMD_COMPLETE event too.
Cc: Marcel Holtmann
Cc: Johan Hedberg
Cc: Dan Carpenter
Reviewed-by: Tomas Bortoli
Signed-off-by: Cong Wang
---
net/bluetooth/hci_event.c | 258 +++---
1 file changed, 215 insert
Similarly, we need to check skb->data boundary for
HCI_EV_LE_META event too.
Note, hci_le_adv_report_evt() and hci_le_ext_adv_report_evt()
are slightly complicated, as they read the length of the field
from the packet as well.
Cc: Marcel Holtmann
Cc: Johan Hedberg
Cc: Dan Carpenter
Reviewed-by
This patchset fixes the out-of-bound access in bluetooth stack.
Although it is large, all of them follow the same pattern, so
it should not be hard to review. I try to group them as much as
I can. This patchset should cover Dan's patch too.
Please check each patch for details.
(Resending v2 as it
On 04/03/2019 07:30 PM, Alexei Starovoitov wrote:
> On Wed, Apr 03, 2019 at 04:52:40PM +0100, Edward Cree wrote:
>> On 02/04/2019 15:37, Daniel Borkmann wrote:
>>> If we really want to have a kernel warn, then lets add a
>>> helper macro verbose_and_warn(...) which will trigger a one-time warning,
On 04/03/2019 11:02 PM, Andrey Ignatov wrote:
> Daniel Borkmann [Wed, 2019-04-03 09:22 -0700]:
>> On 04/02/2019 10:19 PM, Andrey Ignatov wrote:
>>> It's hard to guarantee that whole memory is marked as initialized on
>>> helper return if uninitialized stack is accessed with variable offset
>>> sin
Since, ksym_search added with verification logic for symbols existence,
it could return NULL when the kernel symbols are not loaded.
This commit will add NULL check logic after ksym_search.
Signed-off-by: Daniel T. Lee
---
Changes in v3:
- Added NULL check for samples/spintest_user.c
Change
Currently, ksym_search located at trace_helpers won't check symbols are
existing or not.
In ksym_search, when symbol is not found, it will return &syms[0](_stext).
But when the kernel symbols are not loaded, it will return NULL, which is
not a desired action.
This commit will add verification log
Test that verifier rejects indirect stack access with variable offset in
unprivileged mode and accepts same code in privileged mode.
Since pointer arithmetics is prohibited in unprivileged mode verifier
should reject the program even before it gets to helper call that uses
variable offset, at the
check_stack_access() that prints verbose log is used in
adjust_ptr_min_max_vals() that prints its own verbose log and now they
stick together, e.g.:
variable stack access var_off=(0xfff0; 0x4) off=-16
size=1R2 stack pointer arithmetic goes out of range, prohibited for
!root
Add
Proper support of indirect stack access with variable offset in
unprivileged mode (!root) requires corresponding support in Spectre
masking for stack ALU in retrieve_ptr_limit().
There are no use-case for variable offset in unprivileged mode though so
make verifier reject such accesses for simplic
v1->v2:
- rely on meta = NULL to reject var_off stack access to uninit buffer.
This patch set is a follow-up for discussion [1].
It fixes variable offset stack access handling for raw and unprivileged
mode, rejecting both of them.
Patch 1 handles raw (uninitialized) mode.
Patch 2 adds test for r
Test that verifier rejects indirect access to uninitialized stack with
variable offset.
Example of output:
# ./test_verifier
...
#859/p indirect variable-offset stack access, uninitialized OK
Signed-off-by: Andrey Ignatov
---
.../testing/selftests/bpf/verifier/var_off.c | 27
It's hard to guarantee that whole memory is marked as initialized on
helper return if uninitialized stack is accessed with variable offset
since specific bounds are unknown to verifier. This may cause
uninitialized stack leaking.
Reject such an access in check_stack_boundary to prevent possible
le
On Wed, Apr 03, 2019 at 11:14:33PM +0200, Heiner Kallweit wrote:
> Meanwhile we have generic functions for reading the abilities of
> Clause 22 / 45 PHY's. This allows to use them as fallback in case
> callback get_features isn't set. Benefit is the reduction of
> boilerplate code in PHY drivers.
>
On Wed, Apr 03, 2019 at 11:15:17PM +0200, Heiner Kallweit wrote:
> Now that phylib uses genphy_read_abilities() as fallback, we don't have
> to set callback get_features any longer.
>
> Signed-off-by: Heiner Kallweit
Reviewed-by: Andrew Lunn
Andrew
The total_packets count at ixgbe_clean_xdp_tx_irq is
always zero when testing with xdpsock -t -N. Set the gso_segs
to 1 to make the tx packet count correct.
Signed-off-by: William Tu
---
drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/
The tx bytecount is done twice. When running
'./xdpsock -t -N -i eth3' and 'ip -s link show dev eth3'
The avg packet size is 120 instead of 60. So remove the
extra one.
Signed-off-by: William Tu
---
drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/
Daniel Borkmann [Wed, 2019-04-03 09:46 -0700]:
> On 04/03/2019 06:21 PM, Daniel Borkmann wrote:
> > On 04/02/2019 10:19 PM, Andrey Ignatov wrote:
> >> It's hard to guarantee that whole memory is marked as initialized on
> >> helper return if uninitialized stack is accessed with variable offset
> >
Hi all,
I've been looking at modem drivers, to see what the APIs are to interact
with them, and while I originally thought I had the story sorted out ...
not at all.
Here's the current things we seem to be doing:
(1) Channels are created/encoded as VLANs (cdc_mbim)
This is ... strange a
Meanwhile we have generic functions for reading the abilities of
Clause 22 / 45 PHY's. This allows to use them as fallback in case
callback get_features isn't set. Benefit is the reduction of
boilerplate code in PHY drivers.
v2:
- adjust the comment in phy_driver_register to match the code
Signed
Now that phylib uses genphy_read_abilities() as fallback, we don't have
to set callback get_features any longer.
Signed-off-by: Heiner Kallweit
---
drivers/net/phy/realtek.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index
Meanwhile we have generic functions for reading the abilities of
Clause 22 / 45 PHY's. This allows to use them as fallback in case
callback get_features isn't set. Benefit is the reduction of
boilerplate code in PHY drivers.
v2:
- adjust a comment in patch 1 to match the code
Heiner Kallweit (2):
On 03.04.2019 22:55, Andrew Lunn wrote:
> On Wed, Apr 03, 2019 at 08:20:09PM +0200, Heiner Kallweit wrote:
>> Now that phylib uses genphy_read_abilities() as fallback, we don't have
>> to set callback get_features any longer.
>
> Hi Heiner
>
> I wonder how many PHY drivers we will break if we jus
On 03.04.2019 22:46, Andrew Lunn wrote:
>> @@ -2218,9 +2223,9 @@ int phy_driver_register(struct phy_driver *new_driver,
>> struct module *owner)
>> /* Either the features are hard coded, or dynamically
>> * determine. It cannot be both or neither
>> */
>
> Hi Heiner
>
> The comm
Daniel Borkmann [Wed, 2019-04-03 09:22 -0700]:
> On 04/02/2019 10:19 PM, Andrey Ignatov wrote:
> > It's hard to guarantee that whole memory is marked as initialized on
> > helper return if uninitialized stack is accessed with variable offset
> > since specific bounds are unknown to verifier. This
On Wed, Apr 03, 2019 at 08:20:09PM +0200, Heiner Kallweit wrote:
> Now that phylib uses genphy_read_abilities() as fallback, we don't have
> to set callback get_features any longer.
Hi Heiner
I wonder how many PHY drivers we will break if we just remove
.features everywhere?
Maybe we should crea
Rename bpf_flow_dissector.txt to bpf_flow_dissector.rst and fix
formatting. Also, link it from the Documentation/networking/index.rst.
Tested with 'make htmldocs' to make sure it looks reasonable.
Fixes: ae82899bbe92 ("flow_dissector: document BPF flow dissector environment")
Signed-off-by: Stani
> @@ -2218,9 +2223,9 @@ int phy_driver_register(struct phy_driver *new_driver,
> struct module *owner)
> /* Either the features are hard coded, or dynamically
>* determine. It cannot be both or neither
>*/
Hi Heiner
The comment needs updating to match the code.
> - if
On 03/04/2019 18:30, Alexei Starovoitov wrote:
> verbose_and_warn() doesn't fit these two practical cases of warn + verbose.
> Hence I see no reason to combine warn and verbose into single helper.
> They're perfectly fine being separate.
Makes sense.
So presumably the right patch would be to add m
On 03.04.2019 21:18, Frederick Lawler wrote:
> Heiner Kallweit wrote on 4/3/19 12:45 PM:
>> On 03.04.2019 15:14, Bjorn Helgaas wrote:
>>> [+cc Frederick]
>>>
>>> On Wed, Apr 03, 2019 at 07:53:40AM +0200, Heiner Kallweit wrote:
On 02.04.2019 23:57, Bjorn Helgaas wrote:
> On Tue, Apr 02, 201
On 03/04/2019 21:53, Stephen Hemminger wrote:
>
>
> Begin forwarded message:
>
> Date: Wed, 03 Apr 2019 04:49:49 +
> From: bugzilla-dae...@bugzilla.kernel.org
> To: step...@networkplumber.org
> Subject: [Bug 203137] New: Bridge does not forward multicast if
> multicast_querier is enabled
>
Heiner Kallweit wrote on 4/3/19 12:45 PM:
On 03.04.2019 15:14, Bjorn Helgaas wrote:
[+cc Frederick]
On Wed, Apr 03, 2019 at 07:53:40AM +0200, Heiner Kallweit wrote:
On 02.04.2019 23:57, Bjorn Helgaas wrote:
On Tue, Apr 02, 2019 at 10:41:20PM +0200, Heiner Kallweit wrote:
On 02.04.2019 22:16,
On 4/3/19 11:10 AM, Steve Wise wrote:
> This series adds rdmatool support for creating/deleting rdma links.
> This will be used, mainly, by soft rdma drivers to allow adding/deleting
> rdma links over netdev interfaces. It provides the user side for
> the following kernel changes merged in linux-5
On 4/2/19 11:27 PM, Martin Lau wrote:
> On Tue, Apr 02, 2019 at 02:11:53PM -0700, David Ahern wrote:
>> From: David Ahern
>>
>> Second set of three with the end goal of enabling IPv6 gateways with IPv4
>> routes.
> I am still not completely convinced on the new "*nhc" in patch 2 without
> seeing a
Begin forwarded message:
Date: Wed, 03 Apr 2019 04:49:49 +
From: bugzilla-dae...@bugzilla.kernel.org
To: step...@networkplumber.org
Subject: [Bug 203137] New: Bridge does not forward multicast if
multicast_querier is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=203137
On 04/03, Jesper Dangaard Brouer wrote:
> On Mon, 1 Apr 2019 13:57:34 -0700
> Stanislav Fomichev wrote:
>
> > diff --git a/Documentation/networking/bpf_flow_dissector.txt
> > b/Documentation/networking/bpf_flow_dissector.txt
> > new file mode 100644
> > index ..513be8e20afb
> > ---
On Mon, 1 Apr 2019 13:57:34 -0700
Stanislav Fomichev wrote:
> diff --git a/Documentation/networking/bpf_flow_dissector.txt
> b/Documentation/networking/bpf_flow_dissector.txt
> new file mode 100644
> index ..513be8e20afb
> --- /dev/null
> +++ b/Documentation/networking/bpf_flow_diss
On 03/04/2019 21:17, Nikolay Aleksandrov wrote:
> On 03/04/2019 20:53, Nikolay Aleksandrov wrote:
>> On 03/04/2019 20:43, Mike Manning wrote:
>>> On 02/04/2019 20:22, Nikolay Aleksandrov wrote:
On 02/04/2019 18:35, Mike Manning wrote:
> In the case of vlan filtering on bridges, the bridge
Now that phylib uses genphy_read_abilities() as fallback, we don't have
to set callback get_features any longer.
Signed-off-by: Heiner Kallweit
---
drivers/net/phy/realtek.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index
Meanwhile we have generic functions for reading the abilities of
Clause 22 / 45 PHY's. This allows to use them as fallback in case
callback get_features isn't set. Benefit is the reduction of
boilerplate code in PHY drivers.
Signed-off-by: Heiner Kallweit
---
drivers/net/phy/phy_device.c | 17 ++
Meanwhile we have generic functions for reading the abilities of
Clause 22 / 45 PHY's. This allows to use them as fallback in case
callback get_features isn't set. Benefit is the reduction of
boilerplate code in PHY drivers.
Heiner Kallweit (2):
net: phy: allow a PHY driver to define neither fea
On 03/04/2019 20:53, Nikolay Aleksandrov wrote:
> On 03/04/2019 20:43, Mike Manning wrote:
>> On 02/04/2019 20:22, Nikolay Aleksandrov wrote:
>>> On 02/04/2019 18:35, Mike Manning wrote:
In the case of vlan filtering on bridges, the bridge may also have the
corresponding vlan devices as u
On 4/2/19, 4:26 PM, "David Miller" wrote:
> From: Michael Zhivich
> Date: Mon, 1 Apr 2019 13:14:28 -0400
>
>> When building C++ userspace code that includes ethtool.h
>> with "-Werror -Wall", g++ complains about signed-unsigned comparison in
>> ethtool_validate_speed() due to definition of SPEE
This reverts commit 6578229d4efb7ea6287861bfc2bd306140458e07.
netif_receive_skb_list() doesn't support GRO, therefore we may have
scenarios with decreased performance. See discussion here [0].
[0] https://marc.info/?t=15540384741&r=1&w=2
Signed-off-by: Heiner Kallweit
---
drivers/net/ethern
On 03/04/2019 20:43, Mike Manning wrote:
> On 02/04/2019 20:22, Nikolay Aleksandrov wrote:
>> On 02/04/2019 18:35, Mike Manning wrote:
>>> In the case of vlan filtering on bridges, the bridge may also have the
>>> corresponding vlan devices as upper devices. A vlan bridge binding mode
>>> is added
On 02/04/2019 21:15, Nikolay Aleksandrov wrote:
> On 02/04/2019 18:35, Mike Manning wrote:
>> In vlan bridge binding mode, the link state is no longer transferred
>> from the lower device. Instead it is set by the bridge module according
>> to the state of bridge ports that are members of the vlan.
On 02/04/2019 20:22, Nikolay Aleksandrov wrote:
> On 02/04/2019 18:35, Mike Manning wrote:
>> In the case of vlan filtering on bridges, the bridge may also have the
>> corresponding vlan devices as upper devices. A vlan bridge binding mode
>> is added to allow the link state of the vlan device to t
On 03.04.2019 15:14, Bjorn Helgaas wrote:
> [+cc Frederick]
>
> On Wed, Apr 03, 2019 at 07:53:40AM +0200, Heiner Kallweit wrote:
>> On 02.04.2019 23:57, Bjorn Helgaas wrote:
>>> On Tue, Apr 02, 2019 at 10:41:20PM +0200, Heiner Kallweit wrote:
On 02.04.2019 22:16, Florian Fainelli wrote:
>
On Tue, Apr 02, 2019 at 12:56:09PM +, Rundong Ge wrote:
> Problem:
> When bridge-nf-call-iptables is enabled, skb_dst(skb) of packets that
> in the nfqueue may be a dangling pointer if user delete the bridge.
> Because packets go through the br_nf_pre_routing_finish will set the dst
> pointer t
On 02/04/2019 21:10, Nikolay Aleksandrov wrote:
> On 02/04/2019 18:35, Mike Manning wrote:
>> If vlan bridge binding is enabled, then the link state of a vlan device
>> that is an upper device of the bridge should track the state of bridge
>> ports that are members of that vlan. So if a bridge port
On Wed, Apr 03, 2019 at 12:10:28PM -0500, Steve Wise wrote:
> This series adds rdmatool support for creating/deleting rdma links.
> This will be used, mainly, by soft rdma drivers to allow adding/deleting
> rdma links over netdev interfaces. It provides the user side for
> the following kernel cha
On Wed, Apr 03, 2019 at 12:10:32PM -0500, Steve Wise wrote:
> Update the 'rdma link' man page with 'link add/delete' info.
>
> Signed-off-by: Steve Wise
> ---
> man/man8/rdma-link.8 | 47
> 1 file changed, 47 insertions(+)
>
Thanks,
Reviewed-by: Leon
On Wed, Apr 03, 2019 at 04:52:40PM +0100, Edward Cree wrote:
> On 02/04/2019 15:37, Daniel Borkmann wrote:
> > If we really want to have a kernel warn, then lets add a
> > helper macro verbose_and_warn(...) which will trigger a one-time warning,
> > but keeps
> > the verbose log intact as well.
>
This function sends the constructed netlink message and then
receives the response.
Change rd_recv_msg() to display any error messages.
Change 'rdma dev set' to use rd_sendrecv_msg().
Signed-off-by: Steve Wise
Reviewed-by: Leon Romanovsky
---
rdma/dev.c | 2 +-
rdma/rdma.h | 2 ++
rdma/r
.mailmap allows tracking multiple email addresses to the proper user name.
Signed-off-by: Steve Wise
Reviewed-by: Leon Romanovsky
---
.mailmap | 8
1 file changed, 8 insertions(+)
create mode 100644 .mailmap
diff --git a/.mailmap b/.mailmap
new file mode 100644
index ..c012d3
This series adds rdmatool support for creating/deleting rdma links.
This will be used, mainly, by soft rdma drivers to allow adding/deleting
rdma links over netdev interfaces. It provides the user side for
the following kernel changes merged in linux-5.1.
Changes since v2:
- move checks for requ
Add new 'link' subcommand 'add' and 'delete' to allow binding a soft-rdma
device to a netdev interface.
EG:
rdma link add rxe_eth0 type rxe netdev eth0
rdma link delete rxe_eth0
Signed-off-by: Steve Wise
Reviewed-by: Leon Romanovsky
---
rdma/link.c | 78 +++
Update the 'rdma link' man page with 'link add/delete' info.
Signed-off-by: Steve Wise
---
man/man8/rdma-link.8 | 47
1 file changed, 47 insertions(+)
diff --git a/man/man8/rdma-link.8 b/man/man8/rdma-link.8
index bddf3474..b3b40de7 100644
--- a/man/
On 04/03/2019 06:21 PM, Daniel Borkmann wrote:
> On 04/02/2019 10:19 PM, Andrey Ignatov wrote:
>> It's hard to guarantee that whole memory is marked as initialized on
>> helper return if uninitialized stack is accessed with variable offset
>> since specific bounds are unknown to verifier. This may
On Wed 03 Apr 2019 at 15:37, John Hurley wrote:
> Recent refactoring of fl_change aims to use the classifier spinlock to
> avoid the need for rtnl lock. In doing so, the fl_hw_replace_filer()
> function was moved to before the lock is taken. This can create problems
> for drivers if duplicate fi
On 04/02/2019 10:19 PM, Andrey Ignatov wrote:
> It's hard to guarantee that whole memory is marked as initialized on
> helper return if uninitialized stack is accessed with variable offset
> since specific bounds are unknown to verifier. This may cause
> uninitialized stack leaking.
>
> Reject suc
On Wed 03 Apr 2019 at 01:53, John Hurley wrote:
> Recent changes to TC flower remove the requirement for rtnl lock when
> accessing and modifying filters. Refcounts now ensure access and deletion
> do not happen concurrently. However, the reoffload function which cycles
> through all filters and r
On 02/04/2019 15:37, Daniel Borkmann wrote:
> If we really want to have a kernel warn, then lets add a
> helper macro verbose_and_warn(...) which will trigger a one-time warning, but
> keeps
> the verbose log intact as well.
+1
Any time the verifier detects that its internal invariants have been
This patch adds tests validating that VRF and BPF-LWT
encap work together well, as requested by David Ahern.
Signed-off-by: Peter Oskolkov
---
.../selftests/bpf/test_lwt_ip_encap.sh| 134 +++---
1 file changed, 86 insertions(+), 48 deletions(-)
diff --git a/tools/testing/sel
Hi,
We just had this happen on 5.0.2
It looks like the interface went down, ended up in a broken state and
a ip li set down/up dev enp2s0f0 made it work again
It looks really weird and I haven't really seen anything like it,
anyone with a clue?
dmesg:
[1310361.808694] bnx2x :02:00.0 en
On 04/01/2019 10:57 PM, Stanislav Fomichev wrote:
> This patch series fixes the existing BPF flow dissector API to
> support calling BPF progs from the eth_get_headlen context (the support
> itself will be added in bpf-next tree).
>
> The summary of the changes:
> * fix VLAN handling in bpf_flow
On Tue, Apr 02, 2019 at 10:39:29AM -0700, Alexei Starovoitov wrote:
> On Tue, Apr 02, 2019 at 04:37:19PM +0200, Daniel Borkmann wrote:
> > On 04/02/2019 01:58 PM, Paul Chaignon wrote:
> > > Three checks for verifier bugs were introduced in commit f4d7e40 ("bpf:
> > > introduce function calls (verif
1 - 100 of 132 matches
Mail list logo
