On 2018-12-04 19:58, Marcelo Ricardo Leitner wrote:
> On Tue, Dec 04, 2018 at 07:51:54PM +0100, Jakub Audykowicz wrote:
> ...
>> Thanks, I've taken your remarks into account and ended up with this
>> simple solution:
> LGTM! Thanks
>
>> diff --git a/include/net/sctp/sctp.h
On Tue, Dec 04, 2018 at 08:43:11AM -0800, David Miller wrote:
> From: Jiong Wang
> Date: Tue, 4 Dec 2018 04:56:29 -0500
>
> > This patch implements interpreting BPF_ALU | BPF_ARSH. Do arithmetic right
> > shift on low 32-bit sub-register, and zero the high 32 bits.
> >
> > Reviewed-by: Jakub
On Mon, Dec 3, 2018 at 10:39 AM Cong Wang wrote:
>
> On Sat, Dec 1, 2018 at 12:38 PM Cong Wang wrote:
> >
> > is_last_ethertype_ip() is used to check IP/IPv6 protocol before
> > parsing IP/IPv6 headers.
>
> One thing I noticed while reviewing the assembly code is that
> is_last_ethertype_ip() is
If for some reason an association's fragmentation point is zero,
sctp_datamsg_from_user will try to endlessly try to divide a message
into zero-sized chunks. This eventually causes kernel panic due to
running out of memory.
Although this situation is quite unlikely, it has occurred before as
On Mon, Dec 3, 2018 at 3:17 PM David Miller wrote:
>
> From: Cong Wang
> Date: Tue, 27 Nov 2018 22:10:13 -0800
>
> > When an ethernet frame is padded to meet the minimum ethernet frame
> > size, the padding octets are not covered by the hardware checksum.
> > Fortunately the padding octets are
On Mon, Dec 3, 2018 at 11:52 PM Eric Dumazet wrote:
>
> On Mon, Dec 3, 2018 at 11:30 PM Cong Wang wrote:
> >
> > On Mon, Dec 3, 2018 at 11:08 PM Eric Dumazet wrote:
> > >
> > > The hardware has probably validated the L3 & L4 checksum just fine.
> > >
> > > Note that if ip_summed is
On Tue, Dec 4, 2018 at 12:02 PM Doug Ledford wrote:
>
> On Mon, 2018-11-26 at 08:28 +0200, Leon Romanovsky wrote:
> > From: Leon Romanovsky
> >
> > From Yishai,
> > ---
> > This series enriches DEVX support in few aspects: it enables
> > interoperability
> >
Thanks, Stephen!
I don't care much about braces either. David, do you want me to send a
new patch with braces moved around?
On Tue, Dec 4, 2018 at 9:56 AM Stephen Hemminger
wrote:
>
> I like this, it makes a lot of sense since packets are almost
> always queued in order.
>
> Minor style stuff
On Mon, Dec 3, 2018 at 10:14 PM Cong Wang wrote:
>
> When an ethernet frame is padded to meet the minimum ethernet frame
> size, the padding octets are not covered by the hardware checksum.
> Fortunately the padding octets are ususally zero's, which don't affect
> checksum. However, we have a
On Mon, 2018-11-26 at 08:28 +0200, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> From Yishai,
> ---
> This series enriches DEVX support in few aspects: it enables interoperability
> between DEVX and verbs and improves mechanism for controlling privileged DEVX
On Tue, Dec 04, 2018 at 07:51:54PM +0100, Jakub Audykowicz wrote:
...
> Thanks, I've taken your remarks into account and ended up with this
> simple solution:
LGTM! Thanks
>
> diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
> index ab9242e51d9e..3487686f2cf5 100644
> ---
On 2018-12-04 18:45, Marcelo Ricardo Leitner wrote:
> On Tue, Dec 04, 2018 at 06:00:51PM +0100, Jakub Audykowicz wrote:
> ...
>> OK, let's forget about that "if" :)
>> Coming back to the sanity check, I came up with something like below,
>> based on the code from sctp_setsockopt_maxseg, like you
> -Original Message-
> From: Stefan Assmann [mailto:sassm...@kpanic.de]
> Sent: Tuesday, December 04, 2018 6:19 AM
> To: intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; da...@davemloft.net; Kirsher, Jeffrey T
> ; Keller, Jacob E ;
> sassm...@kpanic.de
> Subject: [PATCH]
On 04/12/18 17:44, Paolo Abeni wrote:
> On Tue, 2018-12-04 at 17:13 +, Edward Cree wrote:
>> On 03/12/18 11:40, Paolo Abeni wrote:
>>> This header define a bunch of helpers that allow avoiding the
>>> retpoline overhead when calling builtin functions via function pointers.
>>> It boils down to
On Tue, Dec 04, 2018 at 10:29:04AM +0100, Jesper Dangaard Brouer wrote:
> On Mon, 3 Dec 2018 23:24:18 -0800
> Jakub Kicinski wrote:
>
> > On Tue, 04 Dec 2018 09:03:52 +0200, Toke Høiland-Jørgensen wrote:
> > > David Miller writes:
> > >
> > > > From: David Ahern
> > > > Date: Mon, 3 Dec
On Tue, 4 Dec 2018 10:29:04 +0100, Jesper Dangaard Brouer wrote:
> On Mon, 3 Dec 2018 23:24:18 -0800
> Jakub Kicinski wrote:
>
> > On Tue, 04 Dec 2018 09:03:52 +0200, Toke Høiland-Jørgensen wrote:
> > > David Miller writes:
> > >
> > > > From: David Ahern
> > > > Date: Mon, 3 Dec 2018
I like this, it makes a lot of sense since packets are almost
always queued in order.
Minor style stuff you might want to fix (but don't have to).
> + if (!last ||
> + t_last->time_to_send > last->time_to_send) {
> +
On Tue, Dec 04, 2018 at 09:40:35AM -0800, Eric Dumazet wrote:
> kmsan was able to trigger a kernel-infoleak using a gre device [1]
>
> nlmsg_populate_fdb_fill() has a hard coded assumption
> that dev->addr_len is ETH_ALEN, as normally guaranteed
> for ARPHRD_ETHER devices.
>
> A similar issue
On Tue, Dec 04, 2018 at 06:00:51PM +0100, Jakub Audykowicz wrote:
...
> OK, let's forget about that "if" :)
> Coming back to the sanity check, I came up with something like below,
> based on the code from sctp_setsockopt_maxseg, like you mentioned.
> I may have overcomplicated things since I
On Tue, 2018-12-04 at 17:13 +, Edward Cree wrote:
> On 03/12/18 11:40, Paolo Abeni wrote:
> > This header define a bunch of helpers that allow avoiding the
> > retpoline overhead when calling builtin functions via function pointers.
> > It boils down to explicitly comparing the function
kmsan was able to trigger a kernel-infoleak using a gre device [1]
nlmsg_populate_fdb_fill() has a hard coded assumption
that dev->addr_len is ETH_ALEN, as normally guaranteed
for ARPHRD_ETHER devices.
A similar issue was fixed recently in commit da71577545a5
("rtnetlink: Disallow FDB
list_del() leaves the skb->next pointer poisoned, which can then lead to
a crash in e.g. OVS forwarding. For example, setting up an OVS VXLAN
forwarding bridge on sfc as per:
$ ovs-vsctl show
5dfd9c47-f04b-4aaa-aa96-4fbb0a522a30
Bridge "br0"
Port "br0"
Interface
This fixes two bugs in hardware VLAN offload:
1. VLAN.TCI == 0 was being dropped
2. there was a race between disabling of VLAN RX feature in hardware
and processing RX queue, where packets processed in this window
could have their VLAN information dropped
Fix moves the VLAN handling
Move rx_ptype extracting to i40e_process_skb_fields() to avoid
duplicating the code.
Signed-off-by: Michał Mirosław
Signed-off-by: Michał Mirosław
---
v3:
* no changes
v2:
* fix prototype in i40e_txrx_common.h
---
drivers/net/ethernet/intel/i40e/i40e_txrx.c| 12
From: Eric Dumazet
> Sent: 04 December 2018 17:04
> On 12/04/2018 08:59 AM, David Laight wrote:
> > From: Tariq Toukan
> >> Sent: 02 December 2018 12:35
> >> From: Eran Ben Elisha
> >>
> >> NIC driver minimal MTU size shall be set to ETH_MIN_MTU, as defined in
> >> the RFC791 and in the network
From: Eric Dumazet
> Sent: 04 December 2018 17:04
>
> On 12/04/2018 08:59 AM, David Laight wrote:
> > From: Tariq Toukan
> >> Sent: 02 December 2018 12:35
> >> From: Eran Ben Elisha
> >>
> >> NIC driver minimal MTU size shall be set to ETH_MIN_MTU, as defined in
> >> the RFC791 and in the
On 03/12/18 11:40, Paolo Abeni wrote:
> This header define a bunch of helpers that allow avoiding the
> retpoline overhead when calling builtin functions via function pointers.
> It boils down to explicitly comparing the function pointers to
> known builtin functions and eventually invoke directly
Following commit 59f997b088d2 ("macvlan: return correct error value"),
there is a duplicate check for mac addresses both in macvlan_sync_address()
and macvlan_set_mac_address().
As the former calls the latter, remove the one in macvlan_set_mac_address()
and move the one in macvlan_sync_address()
On 12/04/2018 08:59 AM, David Laight wrote:
> From: Tariq Toukan
>> Sent: 02 December 2018 12:35
>> From: Eran Ben Elisha
>>
>> NIC driver minimal MTU size shall be set to ETH_MIN_MTU, as defined in
>> the RFC791 and in the network stack. Remove old mlx4_en only define for
>> it, which was set
> -Original Message-
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Yang Xiao
> Sent: Wednesday, November 28, 2018 5:54 PM
> To: Kirsher, Jeffrey T ; da...@davemloft.net
> Cc: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org; Yang Xiao
>
>
On 2018-11-28 12:26, Marcelo Ricardo Leitner wrote:
> On Wed, Nov 28, 2018 at 12:08:38AM -0200, Marcelo Ricardo Leitner wrote:
>> On Tue, Nov 27, 2018 at 11:18:02PM +0100, Jakub Audykowicz wrote:
>>> On 2018-11-19 08:20, Xin Long wrote:
>>>
On Mon, Nov 19, 2018 at 5:49 AM Jakub Audykowicz
> -Original Message-
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Steve Douthit
> Sent: Monday, December 3, 2018 12:15 PM
> To: Kirsher, Jeffrey T
> Cc: Andrew Lunn ; Florian Fainelli ;
> netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org; David
> -Original Message-
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Steve Douthit
> Sent: Monday, December 3, 2018 12:15 PM
> To: Kirsher, Jeffrey T
> Cc: Andrew Lunn ; Florian Fainelli ;
> netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org; David
From: Tariq Toukan
> Sent: 02 December 2018 12:35
> From: Eran Ben Elisha
>
> NIC driver minimal MTU size shall be set to ETH_MIN_MTU, as defined in
> the RFC791 and in the network stack. Remove old mlx4_en only define for
> it, which was set to wrong value.
...
>
> - /* MTU range: 46 -
> -Original Message-
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Stefan Assmann
> Sent: Tuesday, December 4, 2018 6:19 AM
> To: intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; da...@davemloft.net; sassm...@kpanic.de
> Subject:
From: Paolo Abeni
Date: Tue, 04 Dec 2018 12:27:51 +0100
> On Mon, 2018-12-03 at 10:04 -0800, Eric Dumazet wrote:
>> On 12/03/2018 03:40 AM, Paolo Abeni wrote:
>> > This header define a bunch of helpers that allow avoiding the
>> > retpoline overhead when calling builtin functions via function
From: Jiong Wang
Date: Tue, 4 Dec 2018 04:56:29 -0500
> This patch implements interpreting BPF_ALU | BPF_ARSH. Do arithmetic right
> shift on low 32-bit sub-register, and zero the high 32 bits.
>
> Reviewed-by: Jakub Kicinski
> Signed-off-by: Jiong Wang
I just want to say that this behavior
From: Ido Schimmel
Date: Tue, 4 Dec 2018 08:15:09 +
> Up until now, when a packet was routed by the ASIC through the same
> router interface (RIF) from which it ingressed from, the ASIC passed the
> sole copy of the packet to the kernel. This allowed the kernel to route
> the packet and also
On 12/04/2018 07:46 AM, Alexei Starovoitov wrote:
> Three patches to improve verifier ability to handle pathological bpf programs
> with a lot of branches:
> - make sure prog_load syscall can be aborted
> - improve branch taken analysis
> - introduce per-insn complexity limit for unprivileged
On Mon, Dec 03, 2018 at 11:31:22AM +, Lorenz Bauer wrote:
> Right now, there is no safe way to use BPF_PROG_TEST_RUN with data_out.
> This is because bpf_test_finish copies the output buffer to user space
> without checking its size. This can lead to the kernel overwriting
> data in user space
Test that when a second or following command in a batch fails, tc
reports it correctly. This is a test for the previous patch.
Signed-off-by: Petr Machata
---
testsuite/tests/tc/batch.t | 23 +++
1 file changed, 23 insertions(+)
create mode 100755 testsuite/tests/tc/batch.t
When no error is reported in the first iov, do not prematurely return,
but process further iovs. This fixes batch processing.
Fixes: c60389e4f9ea ("libnetlink: fix leak and using unused memory on error")
Signed-off-by: Petr Machata
---
lib/libnetlink.c | 3 +++
1 file changed, 3 insertions(+)
On 12/3/18 6:46 PM, Florian Fainelli wrote:
> Yes, we have been discussing that topic with Andrew and have a few ideas
> on how that could be achieved, but not code to use that at the moment.
> One of the idea was to finally allow enslaving the DSA master network
> device, that way you could
TCP_NOTSENT_LOWAT socket option or sysctl was added in linux-3.12
as a step to enable bigger tcp sndbuf limits.
It works reasonably well, but the following happens :
Once the limit is reached, TCP stack generates
an [E]POLLOUT event for every incoming ACK packet.
This causes a high number of
On 12/03/2018 03:52 PM, David Miller wrote:
> From: Ido Schimmel
> Date: Fri, 30 Nov 2018 19:00:24 +0200
>
>> Yes, agree. Patch is good. I'll tag your v2.
>
> This means, I assume, that a new version of this fix is coming.
>
> Eric, is this correct?
>
This is absolutely correct David, I
On 12/03/2018 05:07 PM, Peter Oskolkov wrote:
> When testing high-bandwidth TCP streams with large windows,
> high latency, and low jitter, netem consumes a lot of CPU cycles
> doing rbtree rebalancing.
>
> This patch uses a linear list/queue in addition to the rbtree:
> if an incoming packet
The bridge multicast code currently uses a custom resizable hashtable
which predates the generic rhashtable interface. It has many
shortcomings compared and duplicates functionality that is presently
available via the generic rhashtable, so this patch removes the custom
rhashtable implementation
bridge's default hash_max was 512 which is rather conservative, now that
we're using the generic rhashtable API which autoshrinks let's increase
it to 4096 and move it to a define in br_private.h.
Signed-off-by: Nikolay Aleksandrov
---
v2: no change
net/bridge/br_multicast.c | 2 +-
Now that the bridge multicast uses the generic rhashtable interface we
can drop the hash_elasticity option as that is already done for us and
it's hardcoded to a maximum of RHT_ELASTICITY (16 currently). Add a
warning about the obsolete option when the hash_elasticity is set.
Signed-off-by:
Hi,
The current bridge multicast code uses a custom rhashtable
implementation which predates the generic rhashtable API. Patch 01
converts it to use the generic kernel rhashtable which simplifies the
code a lot and removes duplicated functionality. The convert also makes
hash_elasticity obsolete
On 04/12/2018 16:44, Nikolay Aleksandrov wrote:
> Hi,
> The current bridge multicast code uses a custom rhashtable
> implementation which predates the generic rhashtable API. Patch 01
> converts it to use the generic kernel rhashtable which simplifies the
> code a lot and removes duplicated
Now that the bridge multicast uses the generic rhashtable interface we
can drop the hash_elasticity option as that is already done for us and
it's hardcoded to a maximum of RHT_ELASTICITY (16 currently). Add a
warning about the obsolete option when the hash_elasticity is set.
Signed-off-by:
bridge's default hash_max was 512 which is rather conservative, now that
we're using the generic rhashtable API which autoshrinks let's increase
it to 4096 and move it to a define in br_private.h.
Signed-off-by: Nikolay Aleksandrov
---
net/bridge/br_multicast.c | 2 +-
net/bridge/br_private.h
Hi,
The current bridge multicast code uses a custom rhashtable
implementation which predates the generic rhashtable API. Patch 01
converts it to use the generic kernel rhashtable which simplifies the
code a lot and removes duplicated functionality. The convert also makes
hash_elasticity obsolete
The bridge multicast code currently uses a custom resizable hashtable
which predates the generic rhashtable interface. It has many
shortcomings compared and duplicates functionality that is presently
available via the generic rhashtable, so this patch removes the custom
rhashtable implementation
A previous commit moved the ether_addr_copy() in i40e_set_mac() before
the mac filter del/add to avoid a race. However it wasn't taken into
account that this alters the mac address being handed to
i40e_del_mac_filter().
Also changed i40e_add_mac_filter() to operate on netdev->dev_addr,
hopefully
The mvpp2_phylink_validate() relies on the interface field of
phylink_link_state to determine valid link modes. However, when called
from phylink_sfp_module_insert() this field in not initialized. The
default switch case then excludes 10G link modes. This allows 10G SFP
modules that are detected
The .validate phylink callback should empty the supported bitmap when
the interface mode is invalid.
Cc: Maxime Chevallier
Cc: Antoine Tenart
Reported-by: Russell King
Signed-off-by: Baruch Siach
---
v2:
New patch in this series
---
.../net/ethernet/marvell/mvpp2/mvpp2_main.c | 33
On 3.12.2018 23:41, Heiner Kallweit wrote:
> On 03.12.2018 11:43, Anssi Hannula wrote:
>> On 1.12.2018 0:16, Heiner Kallweit wrote:
>>> On 30.11.2018 19:45, Anssi Hannula wrote:
When a PHY_HALTED phydev is resumed by phy_start(), it is set to
PHY_RESUMING to wait for the link to come up.
Copy Joakim.
> > From: Wei Yongjun [mailto:weiyongj...@huawei.com]
[...]
> > Subject: [PATCH net-next] can: flexcan: flexcan_chip_start(): fix the
> > error return code in flexcan_setup_stop_mode()
> >
> > The error return code PTR_ERR(gpr_np) is always 0 since gpr_np is
> > equal to NULL in this
> -Original Message-
> From: Wei Yongjun [mailto:weiyongj...@huawei.com]
> Sent: Tuesday, December 4, 2018 2:26 PM
> To: Wolfgang Grandegger ; Marc Kleine-Budde
> ; Aisheng DONG
> Cc: Wei Yongjun ; linux-...@vger.kernel.org;
> netdev@vger.kernel.org; kernel-janit...@vger.kernel.org
>
Hi Russell,
On Tue, Dec 04, 2018 at 10:27:01AM +, Russell King - ARM Linux wrote:
> On Tue, Dec 04, 2018 at 12:19:54PM +0200, Baruch Siach wrote:
> > On Thu, Nov 29, 2018 at 10:00:43PM +, Russell King - ARM Linux wrote:
> > > On Thu, Nov 29, 2018 at 11:31:23AM -0800, Florian Fainelli
On Mon, 2018-12-03 at 10:04 -0800, Eric Dumazet wrote:
> On 12/03/2018 03:40 AM, Paolo Abeni wrote:
> > This header define a bunch of helpers that allow avoiding the
> > retpoline overhead when calling builtin functions via function pointers.
> > It boils down to explicitly comparing the function
On 03/12 07:59, Eric Dumazet wrote:
>
>
> On 12/03/2018 07:20 AM, Nicolas Belouin wrote:
> > Hi,
> > I ran into a panic while adding an interface to a bridge with a vxlan
> > interface already attached to it, as it seems related mtu=9000.
> >
> > I get the following panic info :
> >
> > [
> Yes the current solution whereby we need to get a hold on the network
> device's struct device reference is not quite ideal, AFAIR, Andrew has
> had the same problem.
Yes, it is not nice, and there is a race with systemd renaming the
interfaces using its naming rules. We need a way to lookup an
On Tue, Dec 04, 2018 at 12:19:54PM +0200, Baruch Siach wrote:
> Hi Russell,
>
> On Thu, Nov 29, 2018 at 10:00:43PM +, Russell King - ARM Linux wrote:
> > On Thu, Nov 29, 2018 at 11:31:23AM -0800, Florian Fainelli wrote:
> > > On 11/29/2018 4:49 AM, Baruch Siach wrote:
> > > > The
Hi Russell,
On Thu, Nov 29, 2018 at 10:00:43PM +, Russell King - ARM Linux wrote:
> On Thu, Nov 29, 2018 at 11:31:23AM -0800, Florian Fainelli wrote:
> > On 11/29/2018 4:49 AM, Baruch Siach wrote:
> > > The mvpp2_phylink_validate() relies on the interface field of
> > > phylink_link_state to
Allow setting u{8,16,32} generic parameters as a well defined strings in
devlink user space tool.
Signed-off-by: Shalom Toledo
Reviewed-by: Jiri Pirko
---
devlink/devlink.c | 145 ++
1 file changed, 135 insertions(+), 10 deletions(-)
diff --git
Add string to uint conversion for 'fw_load_policy' generic parameter.
Signed-off-by: Shalom Toledo
Reviewed-by: Jiri Pirko
---
devlink/devlink.c| 13 -
include/uapi/linux/devlink.h | 5 +
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git
Patch #1 add string to uint conversion support for generic parameters.
Patch #2 add string to uint support for 'fw_load_policy' generic parameter
Shalom Toledo (2):
devlink: Add string to uint{8,16,32} conversion for generic parameters
devlink: Add support for 'fw_load_policy' generic
This patch remove the rejection on BPF_ALU | BPF_ARSH as we have supported
them on interpreter and all JIT back-ends
Reviewed-by: Jakub Kicinski
Signed-off-by: Jiong Wang
---
kernel/bpf/verifier.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/kernel/bpf/verifier.c
This patch implements code-gen for BPF_ALU | BPF_ARSH | BPF_*.
Cc: Naveen N. Rao
Cc: Sandipan Das
Signed-off-by: Jiong Wang
---
arch/powerpc/include/asm/ppc-opcode.h | 2 ++
arch/powerpc/net/bpf_jit.h| 4
arch/powerpc/net/bpf_jit_comp64.c | 6 ++
3 files changed, 12
Jitting of BPF_K is supported already, but not BPF_X. This patch complete
the support for the latter on both MIPS and microMIPS.
Cc: Paul Burton
Cc: linux-m...@vger.kernel.org
Signed-off-by: Jiong Wang
---
arch/mips/include/asm/uasm.h | 1 +
arch/mips/include/uapi/asm/inst.h | 1 +
BPF_X support needs indirect shift mode, please see code comments for
details.
Reviewed-by: Jakub Kicinski
Signed-off-by: Jiong Wang
---
drivers/net/ethernet/netronome/nfp/bpf/jit.c | 45
1 file changed, 45 insertions(+)
diff --git
This patch implements interpreting BPF_ALU | BPF_ARSH. Do arithmetic right
shift on low 32-bit sub-register, and zero the high 32 bits.
Reviewed-by: Jakub Kicinski
Signed-off-by: Jiong Wang
---
kernel/bpf/core.c | 52 ++--
1 file changed, 30
"arsh32 on imm" and "arsh32 on reg" now are accepted. Also added two new
testcases to make sure arsh32 won't be treated as arsh64 during
interpretation or JIT code-gen for which case the high bits will be moved
into low halve that the testcases could catch them.
Reviewed-by: Jakub Kicinski
This patch implements code-gen for BPF_ALU | BPF_ARSH | BPF_*.
Cc: Martin Schwidefsky
Cc: Heiko Carstens
Signed-off-by: Jiong Wang
---
arch/s390/net/bpf_jit_comp.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/s390/net/bpf_jit_comp.c b/arch/s390/net/bpf_jit_comp.c
BPF_ALU | BPF_ARSH | BPF_* were rejected by commit: 7891a87efc71
("bpf: arsh is not supported in 32 bit alu thus reject it"). As explained
in the commit message, this is due to there is no complete support for them
on interpreter and various JIT compilation back-ends.
This patch set is a
On Mon, 3 Dec 2018 23:24:18 -0800
Jakub Kicinski wrote:
> On Tue, 04 Dec 2018 09:03:52 +0200, Toke Høiland-Jørgensen wrote:
> > David Miller writes:
> >
> > > From: David Ahern
> > > Date: Mon, 3 Dec 2018 17:15:03 -0700
> > >
> > >> So, instead of a program tag which the program writer
Up until now, when a packet was routed by the ASIC through the same
router interface (RIF) from which it ingressed from, the ASIC passed the
sole copy of the packet to the kernel. This allowed the kernel to route
the packet and also potentially generate an ICMP redirect.
There are scenarios
When the ASIC detects that a unicast packet is routed through the same
router interface (RIF) from which it ingressed (iRIF == eRIF), it raises
a trap called loopback error (LBERROR).
Thus far, this trap was configured to send a sole copy of the packet to
the CPU so that ICMP redirect packets
Packets marked with 'offload_l3_fwd_mark' were already forwarded by a
capable device and should not be forwarded again by the kernel.
Therefore, have the kernel consume them.
The check is performed in ip{,6}_forward_finish() in order to allow the
kernel to process such packets in ip{,6}_forward()
Commit abf4bb6b63d0 ("skbuff: Add the offload_mr_fwd_mark field") added
the 'offload_mr_fwd_mark' field to indicate that a packet has already
undergone L3 multicast routing by a capable device. The field is used to
prevent the kernel from forwarding a packet through a netdev through
which the
Construct a "one-armed router" topology and test that packets are
forwarded by the ASIC and that a copy of the packet is sent to the
kernel, which does not forward the packet again.
Signed-off-by: Ido Schimmel
---
.../drivers/net/mlxsw/one_armed_router.sh | 259 ++
1 file
101 - 184 of 184 matches
Mail list logo
