Hi,
(CC: XDP maintainers)
On 2019/04/13 21:16, Yuya Kusakabe wrote:
> skb_reorder_vlan_header() should move XDP meta data with ethernet
> header if XDP meta data exists.
>
> Signed-off-by: Yuya Kusakabe
> Signed-off-by: Takeru Hayasaka
> Co-developed-by: Takeru Hayasaka
Missing fixes tag
Fix
On Fri, Apr 12, 2019 at 6:42 PM Jakub Kicinski
wrote:
>
> On Sat, 13 Apr 2019 03:37:32 +0200, Matteo Croce wrote:
> > Some binaries are generated when building libbpf from tools/lib/bpf/,
> > namely libbpf.so.0.0.2 and libbpf.so.0.
> > Add them to the local .gitignore.
> >
> > Signed-off-by: Matte
On Fri, Apr 12, 2019 at 4:32 PM Alexei Starovoitov
wrote:
>
> On Fri, Apr 12, 2019 at 04:24:51PM -0700, Song Liu wrote:
> > On Fri, Apr 12, 2019 at 2:41 PM Alexei Starovoitov wrote:
> > >
> > > Add two tests to check that sequence of 1024 jumps is verifiable.
> > >
> > > Signed-off-by: Alexei Sta
On Sat, Apr 13, 2019 at 12:01 AM Jiong Wang wrote:
>
>
> Alexei Starovoitov writes:
>
> > On Fri, Apr 12, 2019 at 10:59:37PM +0100, Jiong Wang wrote:
> >> There are a few "regs[regno]" here are there across "check_reg_arg", this
> >> patch factor it out into a simple "reg" pointer. The intention i
Mon, Apr 15, 2019 at 04:24:24AM CEST, dsah...@gmail.com wrote:
>On 4/13/19 10:20 AM, Jiri Pirko wrote:
>> From: Jiri Pirko
>>
>> Currently there is one devlink instance created per network namespace.
>> That is quite odd considering the fact that devlink instance should
>> represent an ASIC. The
Sun, Apr 14, 2019 at 10:27:56PM CEST, da...@davemloft.net wrote:
>From: Jiri Pirko
>Date: Sat, 13 Apr 2019 18:21:01 +0200
>
>> @@ -3,7 +3,7 @@
>> obj-$(CONFIG_NETDEVSIM) += netdevsim.o
>>
>> netdevsim-objs := \
>> -netdev.o dev.o fib.o sdev.o \
>> +netdev.o dev.o fib.o sdev.o bus.o \
>
tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
master
head: e62b2fd5d3b4c5c958cf88b92f31960750d88dc5
commit: 21e043cd812492e0a02fbbd956fbe49e19daeb45 [709/723] net: hns3: fix set
port based VLAN for PF
reproduce:
# apt-get install sparse
git checkout
> It fails to decode the frames, obviously. But so does any other EtherType.
> Florian was hinting
> (https://lwn.net/ml/netdev/b52f4cdf-edcf-0757-1d6e-d4a831ec7...@gmail.com/)
> at the recent pull requests submitted to tcpdump and libpcap that make
> it possible to decode based on the string in
>
On 4/13/19 10:20 AM, Jiri Pirko wrote:
> From: Jiri Pirko
>
> Currently there is one devlink instance created per network namespace.
> That is quite odd considering the fact that devlink instance should
> represent an ASIC. The following patches are going to move the devlink
> instance even more
On 4/14/19 3:21 PM, Jonathan Lemon wrote:
> When __ip6_rt_update_pmtu() is called, rt->from is RCU dereferenced, but is
> never checked for null - rt6_flush_exceptions() may have removed the entry.
>
> [ 1913.989004] RIP: 0010:ip6_rt_cache_alloc+0x13/0x170
> [ 1914.209410] Call Trace:
> [ 1914.214
On 4/14/19 12:57 PM, Ido Schimmel wrote:
> In a similar fashion to routes and FDB entries, the neighbour table is
> reflected to the device.
>
> Set an offload indication on the neighbour in case it was programmed to
> the device.
>
> Signed-off-by: Ido Schimmel
> Acked-by: Jiri Pirko
> ---
>
To make ICMPv6 closer to ICMPv4, add ratemask parameter. Since the ICMP
message types use larger numeric values, a simple bitmask doesn't fit.
I use large bitmap. The input and output are the in form of list of
ranges. Set the default to rate limit all error messages but Packet Too
Big. For Packet
On 2019/04/12 16:53, Jakub Kicinski wrote:
> On Sat, 13 Apr 2019 07:49:24 +0900, Benjamin Poirier wrote:
> > To be honest, I don't think the formatting in those print_entry_*
> > functions should change according to the length in any case. I think the
> > key and value for each entry should always
On 04/14/2019 01:44 PM, David Miller wrote:
> From: Eric Dumazet
> Date: Sat, 13 Apr 2019 17:32:21 -0700
>
>> fib_compute_spec_dst() needs to be called under rcu protection.
>>
>> syzbot reported :
> ...
>> Fixes: ed0de45a1008 ("ipv4: recompile ip options in ipv4_link_failure")
>> Signed-off-
On 04/14/2019 02:21 PM, Jonathan Lemon wrote:
> When __ip6_rt_update_pmtu() is called, rt->from is RCU dereferenced, but is
> never checked for null - rt6_flush_exceptions() may have removed the entry.
>
> [ 1913.989004] RIP: 0010:ip6_rt_cache_alloc+0x13/0x170
> [ 1914.209410] Call Trace:
> [ 1
From: Saeed Mahameed
Date: Tue, 9 Apr 2019 12:36:26 -0700
> This series provides some fixes to mlx5 driver.
>
> I've cc'ed some of the checksum fixes to Eric Dumazet and i would like to get
> his feedback before you pull.
I gave him enough time to provide feedback.
Pulled.
> For -stable v4.1
When __ip6_rt_update_pmtu() is called, rt->from is RCU dereferenced, but is
never checked for null - rt6_flush_exceptions() may have removed the entry.
[ 1913.989004] RIP: 0010:ip6_rt_cache_alloc+0x13/0x170
[ 1914.209410] Call Trace:
[ 1914.214798]
[ 1914.219226] __ip6_rt_update_pmtu+0xb0/0x190
From: Eric Dumazet
Date: Sun, 14 Apr 2019 11:02:05 -0700
> Jakub forgot to either use nlmsg_len() or nlmsg_msg_size(),
> allowing KMSAN to detect a possible uninit-value in rtnl_stats_get
...
> Fixes: 51bc860d4a99 ("rtnetlink: stats: validate attributes in get as well as
> dumps")
> Signed-off-
From: Denis Bolotin
Date: Sun, 14 Apr 2019 17:23:04 +0300
> This patch series fixes and improves the doorbell recovery mechanism.
> The main goals of this series are to fix missing attentions from the
> doorbells block (DORQ) or not handling them properly, and execute the
> recovery from periodic
From: Heiner Kallweit
Date: Sun, 14 Apr 2019 11:48:39 +0200
> This check isn't really needed and we can simplify the code and save
> some CPU cycles by removing it. Only in case of an error none of these
> bits are set, and calling the NAPI callback doesn't hurt in this case.
>
> Signed-off-by:
From: Heiner Kallweit
Date: Sun, 14 Apr 2019 10:29:23 +0200
> Using function pointer arrays makes the code easier to read and better
> maintainable. AFAIK function pointer arrays cause some performance
> drawback due to Spectre mitigation, but we're not in a hot path.
Series applied, thanks.
From: Eric Dumazet
Date: Sat, 13 Apr 2019 17:32:21 -0700
> fib_compute_spec_dst() needs to be called under rcu protection.
>
> syzbot reported :
...
> Fixes: ed0de45a1008 ("ipv4: recompile ip options in ipv4_link_failure")
> Signed-off-by: Eric Dumazet
> Reported-by: syzbot
Applied, thanks E
On 4/13/19 6:56 PM, Andre Tomt wrote:
> On 13.04.2019 17:34, Steinar H. Gunderson wrote:
>> Hi,
>>
>> I've been using kTLS for a while, with my video reflector Cubemap
>> (https://git.sesse.net/?p=cubemap). After I upgraded my server from
>> 4.18.11 to 5.0.6, seemingly I've started seeing corruptio
From: Heiner Kallweit
Date: Sat, 13 Apr 2019 20:47:22 +0200
> The definition of array settings[] is quite lengthy meanwhile. Add a
> macro to shrink the definition.
>
> When doing this I saw that the new 200Gbps modes and few 100Gbps/50Gbps
> modes aren't supported in phylib yet. So add this.
>
On 14.04.2019 22:29, David Miller wrote:
> From: Heiner Kallweit
> Date: Sat, 13 Apr 2019 18:51:16 +0200
>
>> The definition of array settings[] is quite lengthy meanwhile. Add a
>> macro to shrink the definition.
>>
>> When doing this I saw that the new 200Gbps modes aren't supported
>> in phyli
From: Heiner Kallweit
Date: Sat, 13 Apr 2019 18:51:16 +0200
> The definition of array settings[] is quite lengthy meanwhile. Add a
> macro to shrink the definition.
>
> When doing this I saw that the new 200Gbps modes aren't supported
> in phylib yet. So add this. I think we need to document som
From: Jiri Pirko
Date: Sat, 13 Apr 2019 18:21:01 +0200
> @@ -3,7 +3,7 @@
> obj-$(CONFIG_NETDEVSIM) += netdevsim.o
>
> netdevsim-objs := \
> - netdev.o dev.o fib.o sdev.o \
> + netdev.o dev.o fib.o sdev.o bus.o \
>
I know this is unrelated to what you are trying to do, but could you
Currently, iproute2 can be used to add the underlying dev as real_dev
and create rmnet links over it (ip link add link rmnet_ipa0 name
rmnet0 type
rmnet mux_id 1). Would this continue to work if -
1. the rmnet library were to be included directly as part of the
underlying driver itself
2. there
Test that neighbour entries are marked as offloaded.
Signed-off-by: Ido Schimmel
---
.../selftests/drivers/net/mlxsw/rtnetlink.sh | 26 +++
1 file changed, 26 insertions(+)
diff --git a/tools/testing/selftests/drivers/net/mlxsw/rtnetlink.sh
b/tools/testing/selftests/drivers/ne
Next patch will add offload indication to neighbours, but the indication
should only be altered in case the neighbour was successfully added to /
deleted from the device.
Propagate neighbour update errors, so that they could be taken into
account by the next patch.
Signed-off-by: Ido Schimmel
Ac
Neighbour entries are programmed to the device's table so that the
correct destination MAC will be specified in a packet after it was
routed.
Despite being programmed to the device and unlike routes and FDB
entries, neighbour entries are currently not marked as offloaded. This
patchset changes tha
In a similar fashion to routes and FDB entries, the neighbour table is
reflected to the device.
Set an offload indication on the neighbour in case it was programmed to
the device.
Signed-off-by: Ido Schimmel
Acked-by: Jiri Pirko
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 6 +++
Hi All,
I apologize for the delay, my lab was reserved for some other uses.
But we am going to run the full TAHI IPv6 test suite against this patch
on Tue, and I will reply with the results.
Thanks Peter and Google team for the patch!
--John Masinter
On Mon, Apr 8, 2019 at 6:10 PM Peter Oskolko
Jakub forgot to either use nlmsg_len() or nlmsg_msg_size(),
allowing KMSAN to detect a possible uninit-value in rtnl_stats_get
BUG: KMSAN: uninit-value in rtnl_stats_get+0x6d9/0x11d0
net/core/rtnetlink.c:4997
CPU: 0 PID: 10428 Comm: syz-executor034 Not tainted 5.1.0-rc2+ #24
Hardware name: Google
DB_REC_DRY_RUN (running doorbell recovery without sending doorbells) is
never used. DB_REC_ONCE (send a single doorbell from the doorbell recovery)
is not needed anymore because by running the periodic handler we make sure
we check the overflow status later instead.
This patch is needed because in
Separate the overflow handling from the hardware interrupt status analysis.
The interrupt status is a single register and is common for all PFs. The
first PF reading the register is not necessarily the one who overflowed.
All PFs must check their overflow status on every attention.
In this change w
Fix the condition which verifies that doorbell address is inside the
doorbell bar by checking that the end of the address is within range
as well.
Signed-off-by: Denis Bolotin
Signed-off-by: Michal Kalderon
Signed-off-by: Ariel Elior
---
drivers/net/ethernet/qlogic/qed/qed_dev.c | 16 -
When the DORQ (doorbell block) is overflowed, all PFs get attentions at the
same time. If one PF finished handling the attention before another PF even
started, the second PF might miss the DORQ's attention bit and not handle
the attention at all.
If the DORQ attention is missed and the issue is no
Hi Dave,
This patch series fixes and improves the doorbell recovery mechanism.
The main goals of this series are to fix missing attentions from the
doorbells block (DORQ) or not handling them properly, and execute the
recovery from periodic handler instead of the attention handler.
Please conside
This check isn't really needed and we can simplify the code and save
some CPU cycles by removing it. Only in case of an error none of these
bits are set, and calling the NAPI callback doesn't hurt in this case.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169.c | 6 ++
1
Using a function pointer array makes this easier to read and better
maintainable.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169.c | 219 +--
1 file changed, 68 insertions(+), 151 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/dr
Using a function pointer array makes this easier to read and better
maintainable. AFAIK function pointer arrays cause some performance
drawback due to Spectre mitigation, but we're not in a hot path here.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169.c | 182 +
Using function pointer arrays makes the code easier to read and better
maintainable. AFAIK function pointer arrays cause some performance
drawback due to Spectre mitigation, but we're not in a hot path.
Heiner Kallweit (2):
r8169: create function pointer array for PHY init functions
r8169: cre
43 matches
Mail list logo
