* [PATCH] ixgbe: fix broken ipsec Rx with proper cast on spi
From: Shannon Nelson @ 2018-05-31 21:12 UTC (permalink / raw)
To: intel-wired-lan, jeffrey.t.kirsher; +Cc: netdev
Fix up a cast problem introduced by a sparse cleanup patch. This fixes
a problem where the encrypted packets were not recognized on Rx and
subsequently dropped.
Fixes: 9cfbfa701b55 ("ixgbe: cleanup sparse warnings")
Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
index e1c9762..344a1f2 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
@@ -663,7 +663,7 @@ static int ixgbe_ipsec_add_sa(struct xfrm_state *xs)
/* hash the new entry for faster search in Rx path */
hash_add_rcu(ipsec->rx_sa_list, &ipsec->rx_tbl[sa_idx].hlist,
- (__force u64)rsa.xs->id.spi);
+ (__force u32)rsa.xs->id.spi);
} else {
struct tx_sa tsa;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] rtnetlink: Add more well known protocol values
From: Stephen Hemminger @ 2018-05-31 21:13 UTC (permalink / raw)
To: Donald Sharp; +Cc: netdev, dsahern
In-Reply-To: <20180530122732.3688-1-sharpd@cumulusnetworks.com>
On Wed, 30 May 2018 08:27:32 -0400
Donald Sharp <sharpd@cumulusnetworks.com> wrote:
> FRRouting installs routes into the kernel associated with
> the originating protocol. Add these values to the well
> known values in rtnetlink.h.
>
> Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
> ---
> v2: Fixed whitespace issues
> include/uapi/linux/rtnetlink.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
> index cabb210c93af..7d8502313c99 100644
> --- a/include/uapi/linux/rtnetlink.h
> +++ b/include/uapi/linux/rtnetlink.h
> @@ -254,6 +254,11 @@ enum {
> #define RTPROT_DHCP 16 /* DHCP client */
> #define RTPROT_MROUTED 17 /* Multicast daemon */
> #define RTPROT_BABEL 42 /* Babel daemon */
> +#define RTPROT_BGP 186 /* BGP Routes */
> +#define RTPROT_ISIS 187 /* ISIS Routes */
> +#define RTPROT_OSPF 188 /* OSPF Routes */
> +#define RTPROT_RIP 189 /* RIP Routes */
> +#define RTPROT_EIGRP 192 /* EIGRP Routes */
>
> /* rtm_scope
>
There is a matching table in iproute2 which should also be updated.
See etc/iproute/rt_protos
There also seems to be some leftover gated garbage there as well...
^ permalink raw reply
* [PATCH v2 net] ixgbe: fix parsing of TC actions for HW offload
From: Ondřej Hlavatý @ 2018-05-31 21:21 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: netdev, Andrew Bowers, Ondřej Hlavatý
The previous code was optimistic, accepting the offload of whole action
chain when there was a single known action (drop/redirect). This results
in offloading a rule which should not be offloaded, because its behavior
cannot be reproduced in the hardware.
For example:
$ tc filter add dev eno1 parent ffff: protocol ip \
u32 ht 800: order 1 match tcp src 42 FFFF \
action mirred egress mirror dev enp1s16 pipe \
drop
The controller is unable to mirror the packet to a VF, but still
offloads the rule by dropping the packet.
Change the approach of the function to a pessimistic one, rejecting the
chain when an unknown action is found. This is better suited for future
extensions.
Note that both recognized actions always return TC_ACT_SHOT, therefore
it is safe to ignore actions behind them.
Signed-off-by: Ondřej Hlavatý <ohlavaty@redhat.com>
---
Changes from v1: Fix the introduced warning by rejecting hypothetical
empty action chains as well. Removed Cc's from description.
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index afadba99f7b8..2ecd55856c50 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -9054,7 +9054,6 @@ static int parse_tc_actions(struct ixgbe_adapter *adapter,
{
const struct tc_action *a;
LIST_HEAD(actions);
- int err;
if (!tcf_exts_has_actions(exts))
return -EINVAL;
@@ -9075,11 +9074,11 @@ static int parse_tc_actions(struct ixgbe_adapter *adapter,
if (!dev)
return -EINVAL;
- err = handle_redirect_action(adapter, dev->ifindex, queue,
- action);
- if (err == 0)
- return err;
+ return handle_redirect_action(adapter, dev->ifindex,
+ queue, action);
}
+
+ return -EINVAL;
}
return -EINVAL;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v2 net] ixgbe: fix parsing of TC actions for HW offload
From: Jeff Kirsher @ 2018-05-31 21:46 UTC (permalink / raw)
To: Ondřej Hlavatý; +Cc: netdev, Andrew Bowers
In-Reply-To: <20180531212104.23572-1-ohlavaty@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]
On Thu, 2018-05-31 at 23:21 +0200, Ondřej Hlavatý wrote:
> The previous code was optimistic, accepting the offload of whole
> action
> chain when there was a single known action (drop/redirect). This
> results
> in offloading a rule which should not be offloaded, because its
> behavior
> cannot be reproduced in the hardware.
>
> For example:
>
> $ tc filter add dev eno1 parent ffff: protocol ip \
> u32 ht 800: order 1 match tcp src 42 FFFF \
> action mirred egress mirror dev enp1s16 pipe \
> drop
>
> The controller is unable to mirror the packet to a VF, but still
> offloads the rule by dropping the packet.
>
> Change the approach of the function to a pessimistic one, rejecting
> the
> chain when an unknown action is found. This is better suited for
> future
> extensions.
>
> Note that both recognized actions always return TC_ACT_SHOT,
> therefore
> it is safe to ignore actions behind them.
>
> Signed-off-by: Ondřej Hlavatý <ohlavaty@redhat.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Note- I am having our validation move to testing with GCC 8.1.1 or
later so that we can catch warnings like Dave found in the future.
Dave- Please go ahead and pick this up.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH net-next 0/2] selftests: forwarding: mirror_vlan: Fixlets
From: Petr Machata @ 2018-05-31 22:37 UTC (permalink / raw)
To: netdev, linux-kselftest; +Cc: davem, shuah, idosch
This patchset includes two small fixes for the tests that were
introduced in commit 1bb58d2d3cbe ("Merge branch
'Mirroring-tests-involving-VLAN'").
In patch #1, a "tc action trap" is uninstalled after the suite runs,
instead of being installed again.
In patch #2, a test in suite is renamed to differentiate it from another
test of the same name.
Petr Machata (2):
selftests: forwarding: mirror_vlan: Uninstall trap
selftests: forwarding: mirror_vlan: Change test description
tools/testing/selftests/net/forwarding/mirror_vlan.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
2.4.11
^ permalink raw reply
* [PATCH net-next 1/2] selftests: forwarding: mirror_vlan: Uninstall trap
From: Petr Machata @ 2018-05-31 22:37 UTC (permalink / raw)
To: netdev, linux-kselftest; +Cc: davem, shuah, idosch
In-Reply-To: <cover.1527805500.git.petrm@mellanox.com>
Instead of installing a trap before tests run and uninstalling it after
they run, mirror_vlan.sh installs it twice due to a typo. Fix the typo.
Signed-off-by: Petr Machata <petrm@mellanox.com>
---
tools/testing/selftests/net/forwarding/mirror_vlan.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/net/forwarding/mirror_vlan.sh b/tools/testing/selftests/net/forwarding/mirror_vlan.sh
index 1e10520..c22e949 100755
--- a/tools/testing/selftests/net/forwarding/mirror_vlan.sh
+++ b/tools/testing/selftests/net/forwarding/mirror_vlan.sh
@@ -146,7 +146,7 @@ test_all()
tests_run
- trap_install $h3 ingress
+ trap_uninstall $h3 ingress
slow_path_trap_uninstall $swp1 egress
slow_path_trap_uninstall $swp1 ingress
}
--
2.4.11
^ permalink raw reply related
* [PATCH net-next 2/2] selftests: forwarding: mirror_vlan: Change test description
From: Petr Machata @ 2018-05-31 22:37 UTC (permalink / raw)
To: netdev, linux-kselftest; +Cc: davem, shuah, idosch
In-Reply-To: <cover.1527805500.git.petrm@mellanox.com>
The test description is displayed with the PASS/FAIL resolution after
the test is ran. There however already is one other test described
exactly like this, which makes it unclear which of the tests passed or
failed. Make the description unique.
Signed-off-by: Petr Machata <petrm@mellanox.com>
---
tools/testing/selftests/net/forwarding/mirror_vlan.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/net/forwarding/mirror_vlan.sh b/tools/testing/selftests/net/forwarding/mirror_vlan.sh
index c22e949..efade19 100755
--- a/tools/testing/selftests/net/forwarding/mirror_vlan.sh
+++ b/tools/testing/selftests/net/forwarding/mirror_vlan.sh
@@ -129,7 +129,7 @@ test_tagged_vlan_dir()
192.0.2.17 192.0.2.18
mirror_uninstall $swp1 $direction
- log_test "$direction mirror to vlan ($tcflags)"
+ log_test "$direction mirror tagged to vlan ($tcflags)"
}
test_tagged_vlan()
--
2.4.11
^ permalink raw reply related
* Re: [PATCH bpf-next] bpf: prevent non-IPv4 socket to be added into sock hash
From: John Fastabend @ 2018-05-31 23:31 UTC (permalink / raw)
To: Wei Wang, netdev; +Cc: Eric Dumazet, Willem de Bruijn
In-Reply-To: <20180530212928.190650-1-tracywwnj@gmail.com>
On 05/30/2018 02:29 PM, Wei Wang wrote:
> From: Wei Wang <weiwan@google.com>
>
> Sock hash only supports IPv4 socket proto right now.
> If a non-IPv4 socket gets stored in the BPF map, sk->sk_prot gets
> overwritten with the v4 tcp prot.
>
> Syskaller reported the following related issue on an IPv6 socket:
> BUG: KASAN: slab-out-of-bounds in ip6_dst_idev include/net/ip6_fib.h:203 [inline]
> BUG: KASAN: slab-out-of-bounds in ip6_xmit+0x2002/0x23f0 net/ipv6/ip6_output.c:264
> Read of size 8 at addr ffff8801b300edb0 by task syz-executor888/4522
>
> CPU: 0 PID: 4522 Comm: syz-executor888 Not tainted 4.17.0-rc4+ #17
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1b9/0x294 lib/dump_stack.c:113
> print_address_description+0x6c/0x20b mm/kasan/report.c:256
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
> ip6_dst_idev include/net/ip6_fib.h:203 [inline]
> ip6_xmit+0x2002/0x23f0 net/ipv6/ip6_output.c:264
> inet6_csk_xmit+0x377/0x630 net/ipv6/inet6_connection_sock.c:139
> tcp_transmit_skb+0x1be0/0x3e40 net/ipv4/tcp_output.c:1159
> tcp_send_syn_data net/ipv4/tcp_output.c:3441 [inline]
> tcp_connect+0x2207/0x45a0 net/ipv4/tcp_output.c:3480
> tcp_v4_connect+0x1934/0x1d50 net/ipv4/tcp_ipv4.c:272
> __inet_stream_connect+0x943/0x1120 net/ipv4/af_inet.c:655
> tcp_sendmsg_fastopen net/ipv4/tcp.c:1162 [inline]
> tcp_sendmsg_locked+0x2859/0x3ee0 net/ipv4/tcp.c:1209
> tcp_sendmsg+0x2f/0x50 net/ipv4/tcp.c:1447
> inet_sendmsg+0x19f/0x690 net/ipv4/af_inet.c:798
> sock_sendmsg_nosec net/socket.c:629 [inline]
> sock_sendmsg+0xd5/0x120 net/socket.c:639
> ___sys_sendmsg+0x805/0x940 net/socket.c:2117
> __sys_sendmsg+0x115/0x270 net/socket.c:2155
> __do_sys_sendmsg net/socket.c:2164 [inline]
> __se_sys_sendmsg net/socket.c:2162 [inline]
> __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2162
> do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x43ff99
> RSP: 002b:00007ffc00bd1cf8 EFLAGS: 00000217 ORIG_RAX: 000000000000002e
> RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043ff99
> RDX: 0000000020000000 RSI: 0000000020000580 RDI: 0000000000000003
> RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
> R10: 00000000004002c8 R11: 0000000000000217 R12: 00000000004018c0
> R13: 0000000000401950 R14: 0000000000000000 R15: 0000000000000000
>
> Fixes: 81110384441a ("bpf: sockmap, add hash map support")
> Reported-by: syzbot+5c063698bdbfac19f363@syzkaller.appspotmail.com
> Signed-off-by: Wei Wang <weiwan@google.com>
> Acked-by: Eric Dumazet <edumazet@google.com>
> Acked-by: Willem de Bruijn <willemb@google.com>
> ---
Hi Wei,
Thanks for the report and fix. It would be better to fix the
root cause so that IPv6 works as intended.
I'm testing the following now,
Author: John Fastabend <john.fastabend@gmail.com>
Date: Thu May 31 14:38:59 2018 -0700
sockmap: fix crash when ipv6 sock is added by adding support for IPv6
Apparently we had a testing escape and missed IPv6. This fixes a crash
where we assign tcp_prot to IPv6 sockets instead of tcpv6_prot.
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
diff --git a/kernel/bpf/sockmap.c b/kernel/bpf/sockmap.c
index 52a91d8..e191122 100644
--- a/kernel/bpf/sockmap.c
+++ b/kernel/bpf/sockmap.c
@@ -41,6 +41,7 @@
#include <linux/mm.h>
#include <net/strparser.h>
#include <net/tcp.h>
+#include <net/transp_v6.h>
#include <linux/ptr_ring.h>
#include <net/inet_common.h>
#include <linux/sched/signal.h>
@@ -162,6 +163,8 @@ static bool bpf_tcp_stream_read(const struct sock *sk)
}
static struct proto tcp_bpf_proto;
+static struct proto tcpv6_bpf_proto;
+
static int bpf_tcp_init(struct sock *sk)
{
struct smap_psock *psock;
@@ -182,13 +185,21 @@ static int bpf_tcp_init(struct sock *sk)
psock->sk_proto = sk->sk_prot;
if (psock->bpf_tx_msg) {
+ tcpv6_bpf_proto.sendmsg = bpf_tcp_sendmsg;
+ tcpv6_bpf_proto.sendpage = bpf_tcp_sendpage;
+ tcpv6_bpf_proto.recvmsg = bpf_tcp_recvmsg;
+ tcpv6_bpf_proto.stream_memory_read = bpf_tcp_stream_read;
tcp_bpf_proto.sendmsg = bpf_tcp_sendmsg;
tcp_bpf_proto.sendpage = bpf_tcp_sendpage;
tcp_bpf_proto.recvmsg = bpf_tcp_recvmsg;
tcp_bpf_proto.stream_memory_read = bpf_tcp_stream_read;
}
- sk->sk_prot = &tcp_bpf_proto;
+ if (sk->sk_family == AF_INET6)
+ sk->sk_prot = &tcpv6_bpf_proto;
+ else
+ sk->sk_prot = &tcp_bpf_proto;
+
rcu_read_unlock();
return 0;
}
@@ -1113,6 +1124,8 @@ static int bpf_tcp_ulp_register(void)
{
tcp_bpf_proto = tcp_prot;
tcp_bpf_proto.close = bpf_tcp_close;
+ tcpv6_bpf_proto = tcpv6_prot;
+ tcpv6_bpf_proto.close = bpf_tcp_close;
/* Once BPF TX ULP is registered it is never unregistered. It
* will be in the ULP list for the lifetime of the system. Doing
* duplicate registers is not a problem.
^ permalink raw reply related
* Re: suspicius csum initialization in vmxnet3_rx_csum
From: Neil Horman @ 2018-05-31 23:32 UTC (permalink / raw)
To: Ronak Doshi; +Cc: Paolo Abeni, Guolin Yang, Boon Ang, Louis Luo, netdev
In-Reply-To: <alpine.OSX.2.21.1805311048380.47071@doshir-m01.vmware.com>
On Thu, May 31, 2018 at 11:02:34AM -0700, Ronak Doshi wrote:
>
> On Wed, 30 May 2018, Paolo Abeni wrote:
>
> > Hi,
> >
> > On Thu, 2018-05-24 at 21:48 +0000, Guolin Yang wrote:
> > > Yes, that code is not correct, we should fix that code
> >
> > Did you have any chance to address the issue and/or to give a more in-
> > deepth look to the change proposed in my initial email?
> >
> Hi Paolo,
>
> Can you provide the esx build you are using? It can be found using
> "vmware -vl" on ESX host.
>
> Did you try your proposed fix and did it work? Are you sure the packet
> hits the below if block and not the else block? I still don't think the
> ICMP packet will go through the below if block.
>
> if (gdesc->rcd.csum) {
> skb->csum = htons(gdesc->rcd.csum);
> skb->ip_summed = CHECKSUM_PARTIAL;
> } else {
> skb_checksum_none_assert(skb);
> }
>
> The vmxnet3 emulation does not calculate rcd.csum for ICMP packet and
> hence should go through the else block i.e. checksum none.
>
What packet types will rcd.csum be set for?
Neil
> Thanks,
> Ronak
>
^ permalink raw reply
* Re: [PATCH net-next v2 0/2] net: phy: improve PHY suspend/resume
From: Andrew Lunn @ 2018-06-01 0:10 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <f48b0978-7891-487b-d2b1-3f23b269578c@gmail.com>
> Configuring the different WoL options isn't handled by writing to
> the PHY registers but by writing to chip / MAC registers.
> Therefore phy_suspend() isn't able to figure out whether WoL is
> enabled or not. Only the parent has the full picture.
Hi Heiner
I think you need to look at your different runtime PM domains. If i
understand the code right, you runtime suspend if there is no
link. But for this to work correctly, your PHY needs to keep working.
You also cannot assume all accesses to the PHY go via the MAC. Some
calls will go direct to the PHY, and they can trigger MDIO bus
accesses. So i think you need two runtime PM domains. MAC and MDIO
bus. Maybe just the pll? An MDIO bus is a device, so it can have its
on PM callbacks. It is not clear what you need to resume in order to
make MDIO work.
It might also help if you do the phy_connect in .ndo_open and
disconnect in .ndo_stop. This is a common pattern in drivers. But some
also do it is probe and remove.
Andrew
^ permalink raw reply
* Re: [PATCH bpf-next] xsk: temporarily disable AF_XDP
From: Björn Töpel @ 2018-06-01 0:24 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, Netdev
Cc: Björn Töpel, Karlsson, Magnus, Magnus Karlsson
In-Reply-To: <20180531001754.15923-1-bjorn.topel@gmail.com>
Den ons 30 maj 2018 kl 17:22 skrev Björn Töpel <bjorn.topel@gmail.com>:
>
> From: Björn Töpel <bjorn.topel@intel.com>
>
> Temporarily disable AF_XDP sockets, and hide uapi.
>
[...]
Alexei/Daniel,
Ignore this patch, please.
Thanks,
Björn
^ permalink raw reply
* Re: [PATCH net-next] net/ncsi: Avoid GFP_KERNEL in response handler
From: Samuel Mendoza-Jonas @ 2018-06-01 0:33 UTC (permalink / raw)
To: Eric Dumazet, netdev; +Cc: David S . Miller, linux-kernel, openbmc
In-Reply-To: <69fcb143-00a2-2ddf-e2d4-c692b650f292@gmail.com>
On Thu, 2018-05-31 at 04:50 -0400, Eric Dumazet wrote:
>
> On 05/31/2018 03:02 AM, Samuel Mendoza-Jonas wrote:
> > ncsi_rsp_handler_gc() allocates the filter arrays using GFP_KERNEL in
> > softirq context, causing the below backtrace. This allocation is only a
> > few dozen bytes during probing so allocate with GFP_ATOMIC instead.
> >
>
> Hi Samuel
>
> You forgot to add
>
> Fixes: 062b3e1b6d4f ("net/ncsi: Refactor MAC, VLAN filters")
>
> size = (rsp->uc_cnt + rsp->mc_cnt + rsp->mixed_cnt) * ETH_ALEN;
>
> -> seems to be able to reach more than few dozen bytes...
Hi Eric,
The NCSI spec (at least in the v1.1.0 version I'm looking at) sets the
total number of MAC address filters at 8, so we would be looking at a
maximum of 8 * ETH_ALEN = 48 bytes.
That said it shouldn't be too arduous to move the allocation to later in
the probe/configure cycle so if needed we could do that.
>
> Also, what prevents ncsi_rsp_handler_gc() to be called multiples times ?
>
> nc->mac_filter.addrs & nc->vlan_filter.vids would be re-allocated and memory would leak.
>
Good point, we should put a check there just in case to see if it's
allocated. We should be safe though as ncsi_rsp_handler_gc() should only
be called via ncsi_probe_channel() which only happens through
ncsi_start_dev(), and addrs/vids is cleaned up in ncsi_remove_channel().
Rogue packets shouldn't hit the ncsi_rsp_handler_gc() handler without an
outstanding request.. but it probably is safer to check regardless.
Regards,
Sam
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: prevent non-IPv4 socket to be added into sock hash
From: Eric Dumazet @ 2018-06-01 1:00 UTC (permalink / raw)
To: John Fastabend; +Cc: Wei Wang, netdev, Willem de Bruijn
In-Reply-To: <c6aae1fa-3ad1-9192-3e99-e177b1098f06@gmail.com>
On Thu, May 31, 2018 at 7:32 PM John Fastabend <john.fastabend@gmail.com> wrote:
>
>
> Hi Wei,
>
> Thanks for the report and fix. It would be better to fix the
> root cause so that IPv6 works as intended.
>
> I'm testing the following now,
>
> Author: John Fastabend <john.fastabend@gmail.com>
> Date: Thu May 31 14:38:59 2018 -0700
>
> sockmap: fix crash when ipv6 sock is added by adding support for IPv6
>
> Apparently we had a testing escape and missed IPv6. This fixes a crash
> where we assign tcp_prot to IPv6 sockets instead of tcpv6_prot.
>
> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
>
Hi John
In any case, please forward correct attribution for Wei's work, and
syzbot 'Reported-by'
Are you sure you are handling IPv4 mapped in IPv6 sockets as well ?
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: phy: consider PHY_IGNORE_INTERRUPT in state machine PHY_NOLINK handling
From: David Miller @ 2018-06-01 1:26 UTC (permalink / raw)
To: hkallweit1; +Cc: f.fainelli, andrew, netdev
In-Reply-To: <0a4e472d-cb7f-ef1f-420c-1327fa41e8cd@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Wed, 30 May 2018 22:13:20 +0200
> We can bail out immediately also in case of PHY_IGNORE_INTERRUPT because
> phy_mac_interupt() informs us once the link is up.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
When state is PHY_NOLINK, the phy_mac_interrupt() code paths
will change the state to PHY_CHANGELINK before queueing up
the state machine invocation.
So I can't even see how we can enter phy_state_machine with
->state == PHY_NOLINK is the mac interrupt paths are being
used properly.
Therefore it looks like the code as written is harmless.
Did you actually hit a problem with this test or is this
a change based purely upon code inspection?
^ permalink raw reply
* [PATCH net-next v2 0/2] qed: Fix issues in UFP feature commit 'cac6f691'.
From: Sudarsana Reddy Kalluru @ 2018-06-01 1:47 UTC (permalink / raw)
To: davem; +Cc: netdev, Ariel.Elior, Michal.Kalderon, Sudarsana Reddy Kalluru
From: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
This patch series fixes couple of issues in the UFP feature commit,
cac6f691: Add support for Unified Fabric Port.
Changes from previous version:
------------------------------
v2: Added "Fixes:" tag.
Please consider applying it to "net-next".
Sudarsana Reddy Kalluru (2):
qed: Fix shared memory inconsistency between driver and the MFW.
qed: Fix use of incorrect shmem address.
drivers/net/ethernet/qlogic/qed/qed_hsi.h | 1 +
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 5 +++--
2 files changed, 4 insertions(+), 2 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [PATCH net-next v2 1/2] qed: Fix shared memory inconsistency between driver and the MFW.
From: Sudarsana Reddy Kalluru @ 2018-06-01 1:47 UTC (permalink / raw)
To: davem; +Cc: netdev, Ariel.Elior, Michal.Kalderon
In-Reply-To: <20180601014737.6164-1-sudarsana.kalluru@cavium.com>
The structure shared between driver and management firmware (MFW)
differ in sizes. The additional field defined by the MFW is not
relevant to the current driver. Add a dummy field to the structure.
Fixes: cac6f691 ("qed: Add support for Unified Fabric Port")
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Ariel Elior <ariel.elior@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_hsi.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_hsi.h b/drivers/net/ethernet/qlogic/qed/qed_hsi.h
index 8e1e6e1..beba930 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_hsi.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_hsi.h
@@ -11996,6 +11996,7 @@ struct public_port {
#define EEE_REMOTE_TW_RX_MASK 0xffff0000
#define EEE_REMOTE_TW_RX_OFFSET 16
+ u32 reserved1;
u32 oem_cfg_port;
#define OEM_CFG_CHANNEL_TYPE_MASK 0x00000003
#define OEM_CFG_CHANNEL_TYPE_OFFSET 0
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next v2 2/2] qed: Fix use of incorrect shmem address.
From: Sudarsana Reddy Kalluru @ 2018-06-01 1:47 UTC (permalink / raw)
To: davem; +Cc: netdev, Ariel.Elior, Michal.Kalderon
In-Reply-To: <20180601014737.6164-1-sudarsana.kalluru@cavium.com>
Incorrect shared memory address is used while deriving the values
for tc and pri_type. Use shmem address corresponding to 'oem_cfg_func'
where the management firmare saves tc/pri_type values.
Fixes: cac6f691 ("qed: Add support for Unified Fabric Port")
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Ariel Elior <ariel.elior@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_mcp.c b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
index 2612e3e..6f9927d 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_mcp.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
@@ -1514,9 +1514,10 @@ void qed_mcp_read_ufp_config(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt)
}
qed_mcp_get_shmem_func(p_hwfn, p_ptt, &shmem_info, MCP_PF_ID(p_hwfn));
- val = (port_cfg & OEM_CFG_FUNC_TC_MASK) >> OEM_CFG_FUNC_TC_OFFSET;
+ val = (shmem_info.oem_cfg_func & OEM_CFG_FUNC_TC_MASK) >>
+ OEM_CFG_FUNC_TC_OFFSET;
p_hwfn->ufp_info.tc = (u8)val;
- val = (port_cfg & OEM_CFG_FUNC_HOST_PRI_CTRL_MASK) >>
+ val = (shmem_info.oem_cfg_func & OEM_CFG_FUNC_HOST_PRI_CTRL_MASK) >>
OEM_CFG_FUNC_HOST_PRI_CTRL_OFFSET;
if (val == OEM_CFG_FUNC_HOST_PRI_CTRL_VNIC) {
p_hwfn->ufp_info.pri_type = QED_UFP_PRI_VNIC;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v2 net] mlx4_core: restore optimal ICM memory allocation
From: Qing Huang @ 2018-06-01 1:51 UTC (permalink / raw)
To: Eric Dumazet, David S . Miller
Cc: netdev, Eric Dumazet, John Sperbeck, Tarick Bedeir,
Daniel Jurgens, Zhu Yanjun
In-Reply-To: <20180531125224.97098-1-edumazet@google.com>
On 5/31/2018 5:52 AM, Eric Dumazet wrote:
> Commit 1383cb8103bb ("mlx4_core: allocate ICM memory in page size chunks")
> brought two regressions caught in our regression suite.
>
> The big one is an additional cost of 256 bytes of overhead per 4096 bytes,
> or 6.25 % which is unacceptable since ICM can be pretty large.
>
> This comes from having to allocate one struct mlx4_icm_chunk (256 bytes)
> per MLX4_TABLE_CHUNK, which the buggy commit shrank to 4KB
> (instead of prior 256KB)
It would be great if you could share the test case that triggered the
KASAN report in your
environment. Our QA has been running intensive tests using 8KB or 4KB
chunk size configuration
for some time, no one has reported memory corruption issues so far,
given that we are not
running the latest upstream kernel.
IMO, it's worthwhile to find out the root cause and fix the problem.
>
> Note that mlx4_alloc_icm() is already able to try high order allocations
> and fallback to low-order allocations under high memory pressure.
>
> Most of these allocations happen right after boot time, when we get
> plenty of non fragmented memory, there is really no point being so
> pessimistic and break huge pages into order-0 ones just for fun.
>
> We only have to tweak gfp_mask a bit, to help falling back faster,
> without risking OOM killings.
Just FYI, out of memory wasn't our original concern. We didn't encounter
OOM killings.
>
> Second regression is an KASAN fault, that will need further investigations.
>
> Fixes: 1383cb8103bb ("mlx4_core: allocate ICM memory in page size chunks")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Acked-by: Tariq Toukan <tariqt@mellanox.com>
> Cc: John Sperbeck <jsperbeck@google.com>
> Cc: Tarick Bedeir <tarick@google.com>
> Cc: Qing Huang <qing.huang@oracle.com>
> Cc: Daniel Jurgens <danielj@mellanox.com>
> Cc: Zhu Yanjun <yanjun.zhu@oracle.com>
> ---
> drivers/net/ethernet/mellanox/mlx4/icm.c | 18 ++++++++++++------
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/icm.c b/drivers/net/ethernet/mellanox/mlx4/icm.c
> index 685337d58276fc91baeeb64387c52985e1bc6dda..5342bd8a3d0bfaa9e76bb9b6943790606c97b181 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/icm.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/icm.c
> @@ -43,12 +43,13 @@
> #include "fw.h"
>
> /*
> - * We allocate in page size (default 4KB on many archs) chunks to avoid high
> - * order memory allocations in fragmented/high usage memory situation.
> + * We allocate in as big chunks as we can, up to a maximum of 256 KB
> + * per chunk. Note that the chunks are not necessarily in contiguous
> + * physical memory.
> */
> enum {
> - MLX4_ICM_ALLOC_SIZE = PAGE_SIZE,
> - MLX4_TABLE_CHUNK_SIZE = PAGE_SIZE,
> + MLX4_ICM_ALLOC_SIZE = 1 << 18,
> + MLX4_TABLE_CHUNK_SIZE = 1 << 18,
> };
>
> static void mlx4_free_icm_pages(struct mlx4_dev *dev, struct mlx4_icm_chunk *chunk)
> @@ -135,6 +136,7 @@ struct mlx4_icm *mlx4_alloc_icm(struct mlx4_dev *dev, int npages,
> struct mlx4_icm *icm;
> struct mlx4_icm_chunk *chunk = NULL;
> int cur_order;
> + gfp_t mask;
> int ret;
>
> /* We use sg_set_buf for coherent allocs, which assumes low memory */
> @@ -178,13 +180,17 @@ struct mlx4_icm *mlx4_alloc_icm(struct mlx4_dev *dev, int npages,
> while (1 << cur_order > npages)
> --cur_order;
>
> + mask = gfp_mask;
> + if (cur_order)
> + mask &= ~__GFP_DIRECT_RECLAIM;
> +
> if (coherent)
> ret = mlx4_alloc_icm_coherent(&dev->persist->pdev->dev,
> &chunk->mem[chunk->npages],
> - cur_order, gfp_mask);
> + cur_order, mask);
> else
> ret = mlx4_alloc_icm_pages(&chunk->mem[chunk->npages],
> - cur_order, gfp_mask,
> + cur_order, mask,
> dev->numa_node);
>
> if (ret) {
^ permalink raw reply
* [PATCH] net: ethernet: mlx4: Remove unnecessary parentheses
From: Varsha Rao @ 2018-06-01 2:00 UTC (permalink / raw)
To: Tariq Toukan, David S. Miller, Nicholas Mc Guire, Lukas Bulwahn,
netdev, linux-rdma, linux-kernel
Cc: Varsha Rao
This patch fixes the clang warning of extraneous parentheses, with the
following coccinelle script.
@@
identifier i;
expression e;
statement s;
@@
if (
-(i == e)
+i == e
)
s
Suggested-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Varsha Rao <rvarsha016@gmail.com>
---
drivers/net/ethernet/mellanox/mlx4/port.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/port.c b/drivers/net/ethernet/mellanox/mlx4/port.c
index 3ef3406ff4cb..10fcc22f4590 100644
--- a/drivers/net/ethernet/mellanox/mlx4/port.c
+++ b/drivers/net/ethernet/mellanox/mlx4/port.c
@@ -614,9 +614,9 @@ int __mlx4_register_vlan(struct mlx4_dev *dev, u8 port, u16 vlan,
int index_at_dup_port = -1;
for (i = MLX4_VLAN_REGULAR; i < MLX4_MAX_VLAN_NUM; i++) {
- if ((vlan == (MLX4_VLAN_MASK & be32_to_cpu(table->entries[i]))))
+ if (vlan == (MLX4_VLAN_MASK & be32_to_cpu(table->entries[i])))
index_at_port = i;
- if ((vlan == (MLX4_VLAN_MASK & be32_to_cpu(dup_table->entries[i]))))
+ if (vlan == (MLX4_VLAN_MASK & be32_to_cpu(dup_table->entries[i])))
index_at_dup_port = i;
}
/* check that same vlan is not in the tables at different indices */
--
2.17.0
^ permalink raw reply related
* Re: [PATCH V4] mlx4_core: allocate ICM memory in page size chunks
From: Qing Huang @ 2018-06-01 2:04 UTC (permalink / raw)
To: Michal Hocko, Eric Dumazet
Cc: David Miller, tariqt, haakon.bugge, yanjun.zhu, netdev,
linux-rdma, linux-kernel, gi-oh.kim, santosh.shilimkar@oracle.com
In-Reply-To: <20180531091022.GL15278@dhcp22.suse.cz>
On 5/31/2018 2:10 AM, Michal Hocko wrote:
> On Thu 31-05-18 10:55:32, Michal Hocko wrote:
>> On Thu 31-05-18 04:35:31, Eric Dumazet wrote:
> [...]
>>> I merely copied/pasted from alloc_skb_with_frags() :/
>> I will have a look at it. Thanks!
> OK, so this is an example of an incremental development ;).
>
> __GFP_NORETRY was added by ed98df3361f0 ("net: use __GFP_NORETRY for
> high order allocations") to prevent from OOM killer. Yet this was
> not enough because fb05e7a89f50 ("net: don't wait for order-3 page
> allocation") didn't want an excessive reclaim for non-costly orders
> so it made it completely NOWAIT while it preserved __GFP_NORETRY in
> place which is now redundant. Should I send a patch?
>
Just curious, how about GFP_ATOMIC flag? Would it work in a similar
fashion? We experimented
with it a bit in the past but it seemed to cause other issue in our
tests. :-)
By the way, we didn't encounter any OOM killer events. It seemed that
the mlx4_alloc_icm() triggered slowpath.
We still had about 2GB free memory while it was highly fragmented.
#0 [ffff8801f308b380] remove_migration_pte at ffffffff811f0e0b
#1 [ffff8801f308b3e0] rmap_walk_file at ffffffff811cb890
#2 [ffff8801f308b440] rmap_walk at ffffffff811cbaf2
#3 [ffff8801f308b450] remove_migration_ptes at ffffffff811f0db0
#4 [ffff8801f308b490] __unmap_and_move at ffffffff811f2ea6
#5 [ffff8801f308b4e0] unmap_and_move at ffffffff811f2fc5
#6 [ffff8801f308b540] migrate_pages at ffffffff811f3219
#7 [ffff8801f308b5c0] compact_zone at ffffffff811b707e
#8 [ffff8801f308b650] compact_zone_order at ffffffff811b735d
#9 [ffff8801f308b6e0] try_to_compact_pages at ffffffff811b7485
#10 [ffff8801f308b770] __alloc_pages_direct_compact at ffffffff81195f96
#11 [ffff8801f308b7b0] __alloc_pages_slowpath at ffffffff811978a1
#12 [ffff8801f308b890] __alloc_pages_nodemask at ffffffff81197ec1
#13 [ffff8801f308b970] alloc_pages_current at ffffffff811e261f
#14 [ffff8801f308b9e0] mlx4_alloc_icm at ffffffffa01f39b2 [mlx4_core]
Thanks!
^ permalink raw reply
* [PATCH] net: wireless: brcmsmac: Remove unnecessary parentheses
From: Varsha Rao @ 2018-06-01 2:14 UTC (permalink / raw)
To: Nicholas Mc Guire, Lukas Bulwahn, Arend van Spriel, Franky Lin,
Hante Meuleman, Chi-Hsien Lin, Wright Feng, Kalle Valo,
David S. Miller, linux-wireless, brcm80211-dev-list.pdl,
brcm80211-dev-list, netdev, linux-kernel
Cc: Varsha Rao
This patch fixes the clang warning of extraneous parentheses, with the
following coccinelle script.
@@
identifier i;
expression e;
statement s;
@@
if (
-(i == e)
+i == e
)
s
Suggested-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Varsha Rao <rvarsha016@gmail.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_cmn.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_cmn.c b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_cmn.c
index 3a13d176b221..35e3b101e5cf 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_cmn.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_cmn.c
@@ -159,7 +159,7 @@ u16 read_radio_reg(struct brcms_phy *pi, u16 addr)
{
u16 data;
- if ((addr == RADIO_IDCODE))
+ if (addr == RADIO_IDCODE)
return 0xffff;
switch (pi->pubpi.phy_type) {
--
2.17.0
^ permalink raw reply related
* Re: [PATCH] rtnetlink: Remove VLA usage
From: David Miller @ 2018-06-01 2:49 UTC (permalink / raw)
To: keescook; +Cc: fw, dsahern, netdev, linux-kernel
In-Reply-To: <20180530222052.GA30622@beast>
From: Kees Cook <keescook@chromium.org>
Date: Wed, 30 May 2018 15:20:52 -0700
> In the quest to remove all stack VLA usage from the kernel[1], this
> allocates the maximum size expected for all possible types and adds
> sanity-checks at both registration and usage to make sure nothing gets
> out of sync. This matches the proposed VLA solution for nfnetlink[2]. The
> values chosen here were based on finding assignments for .maxtype and
> .slave_maxtype and manually counting the enums:
>
> slave_maxtype (max 33):
...
> maxtype (max 45):
...
>
> This additionally changes maxtype and slave_maxtype fields to unsigned,
> since they're only ever using positive values.
>
> [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com
> [2] https://patchwork.kernel.org/patch/10439647/
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
Looks good, applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] virtio_net: fix error return code in virtnet_probe()
From: David Miller @ 2018-06-01 2:50 UTC (permalink / raw)
To: weiyongjun1
Cc: mst, jasowang, sridhar.samudrala, virtualization, netdev,
kernel-janitors
In-Reply-To: <1527732307-145609-1-git-send-email-weiyongjun1@huawei.com>
From: Wei Yongjun <weiyongjun1@huawei.com>
Date: Thu, 31 May 2018 02:05:07 +0000
> Fix to return a negative error code from the failover create fail error
> handling case instead of 0, as done elsewhere in this function.
>
> Fixes: ba5e4426e80e ("virtio_net: Extend virtio to use VF datapath when available")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 net] ixgbe: fix parsing of TC actions for HW offload
From: David Miller @ 2018-06-01 3:01 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: ohlavaty, netdev, andrewx.bowers
In-Reply-To: <b67b75aeb43afd4812e378673151a629f1681eea.camel@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 31 May 2018 14:46:08 -0700
> On Thu, 2018-05-31 at 23:21 +0200, Ondřej Hlavatý wrote:
>> The previous code was optimistic, accepting the offload of whole
>> action
>> chain when there was a single known action (drop/redirect). This
>> results
>> in offloading a rule which should not be offloaded, because its
>> behavior
>> cannot be reproduced in the hardware.
>>
>> For example:
>>
>> $ tc filter add dev eno1 parent ffff: protocol ip \
>> u32 ht 800: order 1 match tcp src 42 FFFF \
>> action mirred egress mirror dev enp1s16 pipe \
>> drop
>>
>> The controller is unable to mirror the packet to a VF, but still
>> offloads the rule by dropping the packet.
>>
>> Change the approach of the function to a pessimistic one, rejecting
>> the
>> chain when an unknown action is found. This is better suited for
>> future
>> extensions.
>>
>> Note that both recognized actions always return TC_ACT_SHOT,
>> therefore
>> it is safe to ignore actions behind them.
>>
>> Signed-off-by: Ondřej Hlavatý <ohlavaty@redhat.com>
>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>
> Note- I am having our validation move to testing with GCC 8.1.1 or
> later so that we can catch warnings like Dave found in the future.
>
> Dave- Please go ahead and pick this up.
Ok, applied, thanks.
^ permalink raw reply
* Re: [net PATCH] net-sysfs: Fix memory leak in XPS configuration
From: David Miller @ 2018-06-01 3:03 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: netdev
In-Reply-To: <20180531195922.7571.86674.stgit@ahduyck-green-test.jf.intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Thu, 31 May 2018 15:59:46 -0400
> This patch reorders the error cases in showing the XPS configuration so
> that we hold off on memory allocation until after we have verified that we
> can support XPS on a given ring.
>
> Fixes: 184c449f91fe ("net: Add support for XPS with QoS via traffic classes")
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Applied and queued up for -stable.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox