* Re: pull request (net): ipsec 2017-04-19
From: David Miller @ 2017-04-20 20:20 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <1492578636-621-1-git-send-email-steffen.klassert@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Wed, 19 Apr 2017 07:10:34 +0200
> Two fixes for af_key:
>
> 1) Add a lock to key dump to prevent a NULL pointer dereference.
> From Yuejie Shi.
>
> 2) Fix slab-out-of-bounds in parse_ipsecrequests.
> From Herbert Xu.
>
> Please pull or let me know if there are problems.
Pulled, thanks Steffen.
^ permalink raw reply
* Re: [PATCH net-next] tcp_cubic: fix typo in module param description
From: David Miller @ 2017-04-20 20:18 UTC (permalink / raw)
To: chema; +Cc: edumazet, netdev, chemag
In-Reply-To: <20170419022223.28318-1-chema@google.com>
From: Chema Gonzalez <chema@google.com>
Date: Tue, 18 Apr 2017 19:22:23 -0700
> From: Chema Gonzalez <chemag@gmail.com>
>
> Signed-off-by: Chema Gonzalez <chemag@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 2/2] Add Jiri Pirko as TC subsystem co-maintainer
From: David Miller @ 2017-04-20 20:15 UTC (permalink / raw)
To: jhs; +Cc: netdev, eric.dumazet, jiri, xiyou.wangcong
In-Reply-To: <1492565040-29102-2-git-send-email-jhs@emojatatu.com>
From: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Tue, 18 Apr 2017 21:24:00 -0400
> From: Jamal Hadi Salim <jhs@mojatatu.com>
>
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 1/2] Add Cong Wang as TC subsystem co-maintainer
From: David Miller @ 2017-04-20 20:15 UTC (permalink / raw)
To: jhs; +Cc: netdev, eric.dumazet, jiri, xiyou.wangcong
In-Reply-To: <1492565040-29102-1-git-send-email-jhs@emojatatu.com>
From: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Tue, 18 Apr 2017 21:23:59 -0400
> From: Jamal Hadi Salim <jhs@mojatatu.com>
>
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 0/3] uapi glibc compat: fix musl libc compatibility
From: David Woodhouse @ 2017-04-20 20:14 UTC (permalink / raw)
To: David Miller, hauke
Cc: netdev, linux-kernel, jarod, jogo, david.heidelberger,
maillist-linux, mikko.rapeli
In-Reply-To: <20170420.160739.1263793303398330801.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 911 bytes --]
On Thu, 2017-04-20 at 16:07 -0400, David Miller wrote:
>
> I think I have to put the brakes on this patch series, after much
> consideration.
>
> It does not scale if we continually add a hodge-podge of different
> ifdef tests to the UAPI headers in order to prevent mutliple
> definitions.
>
> We will add that IFF_ECHO ifdef for MUSL libc today, and for another
> libc we will add another such hack. And so on and so forth...
>
> Instead, LIBC implementation must adopt the ifdef protections which
> have standard names and are being adopted by GLIBC and hopefully
> others.
I agree, except I don't think you're going far enough. Those "standard
names" you mention... some of this stuff actually depends on __GLIBC__,
and *that* isn't right either.
I tried to kill that off completely and make the kernel entirely
agnostic, in https://marc.info/?l=linux-api&m=148898383805658&w=2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4938 bytes --]
^ permalink raw reply
* RE: [net-next 04/14] i40e: dump VF information in debugfs
From: Mintz, Yuval @ 2017-04-20 20:12 UTC (permalink / raw)
To: David Miller
Cc: jiri@resnulli.us, gerlitz.or@gmail.com,
jeffrey.t.kirsher@intel.com, mitch.a.williams@intel.com,
netdev@vger.kernel.org, nhorman@redhat.com, sassmann@redhat.com,
jogreene@redhat.com, Dupuis, Chad, Rangankar, Manish
In-Reply-To: <20170420.125841.799913763607507081.davem@davemloft.net>
> > the HW pipeline itself can't be abstracted in this case.
>
> I've heard that argument before, and I'm glad Jiri didn't drink the koolaide
> and instead wrote dpipe.
Perhaps "can't" was the wrong term to use, but I still believe there's an
inherent problem with applying the dpipe approach here.
dpipe abstraction is meant [And I admit that I'm not that familiar with its
fine-grain details, so feel free to correct me] to give an abstract
representation of functional things, I.e., bits in the HW pipeline the user
might care about and can gain something from sharing information
about it - decision-based statistics [such as in Jiri's initial submission] being
an immediate candidate for benefiting from such.
For the case of debugging you *could* do the same, but at a huge
implementation and code-bloat costs -
Let's assume user doesn't use 'magic values' for debug gathering,
Instead having some HW abstraction it can manipulate intelligibly.
What it means is that level of configurability is limited by the complexity
of the abstraction, and you have to recall the vast majority of the
abstraction would be in-depth about HW-specific bridges and signals
the user cares nothing about [with the exception of debug-data collection].
I surely wouldn't want to write a million lines of code just to provide such
a detailed abstraction.
.
^ permalink raw reply
* Re: [net-next 00/15][pull request] 10GbE Intel Wired LAN Driver Updates 2017-04-18
From: David Miller @ 2017-04-20 20:11 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <20170418230205.37223-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 18 Apr 2017 16:01:50 -0700
> This series contains updates to mainly ixgbe with only one ixgbevf
> change.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH net-next v3] bindings: net: stmmac: add missing note about LPI interrupt
From: Rob Herring @ 2017-04-20 20:10 UTC (permalink / raw)
To: Niklas Cassel
Cc: Mark Rutland, David S. Miller, Joao Pinto, Niklas Cassel,
Alexandre TORGUE, Giuseppe CAVALLARO, Thierry Reding,
Eric Engestrom, netdev, devicetree, linux-kernel
In-Reply-To: <20170418123955.21335-1-niklass@axis.com>
On Tue, Apr 18, 2017 at 02:39:53PM +0200, Niklas Cassel wrote:
> From: Niklas Cassel <niklas.cassel@axis.com>
>
> The hardware has a LPI interrupt.
> There is already code in the stmmac driver to parse and handle the
> interrupt. However, this information was missing from the DT binding.
>
> At the same time, improve the description of the existing interrupts.
>
> Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
> ---
> Documentation/devicetree/bindings/net/stmmac.txt | 13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 0/3] uapi glibc compat: fix musl libc compatibility
From: David Miller @ 2017-04-20 20:07 UTC (permalink / raw)
To: hauke
Cc: netdev, linux-kernel, jarod, jogo, david.heidelberger,
maillist-linux, mikko.rapeli, dwmw2
In-Reply-To: <20170418210036.26039-1-hauke@hauke-m.de>
From: Hauke Mehrtens <hauke@hauke-m.de>
Date: Tue, 18 Apr 2017 23:00:33 +0200
> The code from libc-compat.h depends on some glibc specific defines and
> causes compile problems with the musl libc. These patches remove some
> of the glibc dependencies. With these patches the LEDE (OpenWrt) base
> user space applications can be build with unmodified kernel headers and
> musl libc.
>
> This was compile tested with the user space from LEDE (OpenWrt) with
> musl 1.1.16, glibc 2.25 and uClibc-ng 1.0.22.
>
> Changes since v1:
> - fix typo in commit message
> - combine two changes
I think I have to put the brakes on this patch series, after much
consideration.
It does not scale if we continually add a hodge-podge of different
ifdef tests to the UAPI headers in order to prevent mutliple
definitions.
We will add that IFF_ECHO ifdef for MUSL libc today, and for another
libc we will add another such hack. And so on and so forth...
Instead, LIBC implementation must adopt the ifdef protections which
have standard names and are being adopted by GLIBC and hopefully
others.
So please instead adjust the musl headers so that they interact
properly with the framework we've designed specifically for this
purpose.
Thank you.
^ permalink raw reply
* mlx5en not able to communicate between VF and PF
From: Robert LeBlanc @ 2017-04-20 20:06 UTC (permalink / raw)
To: netdev
After figuring out that CentOS requires a newer version of iproute to
enable trust mode on VFs, I'm now having a problem getting a VM on a
bridge on a VF to communicate with the host on the PF or a different
VF.
The set-up:
Host1 Host2
/--------------------------------------------\
| |
PF - 192.168.13.13/24 PF - 192.168.13.14/24
+-- VF1 - (Move the address
| from PF for testing)
\-- VF2 - br0
+-- VM1 - 192.168.13.101/24
+-- VM2 - 192.168.13.102/24
\-- VM3 - 192.168.13.103/24
Host1 and Host2 have a Mellanox ConnectX-4 100Gb single port adapter
and are connected back-to-back with no switch between them. Host1 VF2
has trust mode set to on. From Host2, I can ping any address on Host1
(PF, VM1, VM2, VM3). From VM3, I can ping VM1, VM2 and Host2 PF. From
Host1 PF, I can ping Host2 PF.
The problem is that none of the VMs can ping Host1 PF nor can the
Host1 PF ping any of the VMs.
While doing tcpdump on the interfaces and a ping from VM3, I can see
the ARP request go through VF2, I can see the request and the response
on PF, but the response never makes it back to VF2.
When I ping from Host1 PF to VM3, I see the ARP request and response
on both the PF and VF2, however the ICMP request is sent on the PF,
but the VF2 never sees it.
If I move the Host1 PF address to a VF, the same problem happens.
It seems to me that some rule in the eswitch is getting in the way,
but I don't know how to view/modify the rules in the eswitch.
Any help getting this working is appreciated.
Thank you,
----------------
Robert LeBlanc
PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1
^ permalink raw reply
* Re: [PATCH] dp83640: don't recieve time stamps twice
From: David Miller @ 2017-04-20 20:02 UTC (permalink / raw)
To: richardcochran
Cc: Stefan.Sorensen, dan.carpenter, netdev, f.fainelli, andrew,
kernel-janitors
In-Reply-To: <20170419103135.GA1670@localhost.localdomain>
From: Richard Cochran <richardcochran@gmail.com>
Date: Wed, 19 Apr 2017 12:31:35 +0200
> On Wed, Apr 19, 2017 at 09:16:56AM +0000, Sørensen, Stefan wrote:
>> You are correct that these lines was added accidentally.
>
> Can we please fix this in another way? There is no need to hold the
> spin lock during the callback into the networking stack. Instead, how
> about the following diff, which also fixes the other call site...
Oops, I read this too late.
I already applied and pushed out Dan's fix.
^ permalink raw reply
* Re: stmmac still supporting spear600 ?
From: Thomas Petazzoni @ 2017-04-20 20:01 UTC (permalink / raw)
To: Giuseppe CAVALLARO, Shiraz Hashim, Viresh Kumar
Cc: netdev, Alexandre Torgue, linux-arm-kernel
In-Reply-To: <20170412150558.57c865e5@free-electrons.com>
Viresh, Shiraz,
As the SPEAr600 platform maintainers, have you tested Ethernet in
recent times, especially with a MII PHY ? I'm still struggling to get
it working. Quick summary:
- The same kernel works fine on another SPEAr600 platform that has a
GMII PHY
- The SPEAr600 platform with a MII PHY has Ethernet working fine under
U-Boot (TFTP works), so the HW is known to be working.
- I've compared the values of the MAC registers between U-Boot and
Linux, and traced all the PHY registers read/write over the MDIO
bus, and compared the traces between U-Boot and Linux. Found a few
differences, but solving them didn't change the problem.
I'm suspecting the problem is not directly in the MAC/PHY
configuration. Would you have some hints like clock configuration, or
other system-level configuration that could affect this? Especially the
TXCLK from the PHY is not coming in through the same pin when in GMII
and MII mode it seems. Does this needs some special configuration?
Any hint/idea would definitely be welcome.
Thanks a lot!
Thomas
On Wed, 12 Apr 2017 15:05:58 +0200, Thomas Petazzoni wrote:
> Hello,
>
> Thanks again for your answer, sorry for the delay, I was away from the
> spear600 board for a while.
>
> On Mon, 3 Apr 2017 08:16:50 +0200, Giuseppe CAVALLARO wrote:
>
> > I tested the SMSC on other platform (+ stmmac), not on SPEAr.
>
> OK. But I believe there might be a SPEAr specific issue here, which
> might explain why you don't reproduce the problem.
>
> > ok for reset, keep the radar on clock. Hmm, can you attach a piece of
> > log file to see the failure?
>
> During the boot, nothing bad:
>
> libphy: Fixed MDIO Bus: probed
> stmmaceth e0800000.ethernet: no reset control found
> stmmac - user ID: 0x10, Synopsys ID: 0x32
> Ring mode enabled
> DMA HW capability register supported Normal descriptors
> libphy: stmmac: probed
> eth0: PHY ID 0007c0c4 at 31 IRQ POLL (stmmac-0:1f) active
>
> Then, when upping the interface:
>
> # ifconfig eth0 up
> eth0: device MAC address 00:30:d3:21:22:60
> stmmaceth e0800000.ethernet: Failed to reset the dma
> stmmac_hw_setup: DMA engine initialization failed
> stmmac_open: Hw setup failed
> SIOCSIFFLAGS: Device or resource busy
>
> As I said earlier, the "Failed to reset the dma" is because
> dwmac_dma_reset() returns -EBUSY because the DMA reset bit never
> clears. Again, we see the same behavior in U-Boot (DMA reset bit never
> clears), but Ethernet does work in U-Boot.
>
> Best regards,
>
> Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH] net/packet: initialize val in packet_getsockopt()
From: David Miller @ 2017-04-20 19:56 UTC (permalink / raw)
To: glider; +Cc: dvyukov, kcc, edumazet, kuznet, linux-kernel, netdev
In-Reply-To: <20170418174708.26341-1-glider@google.com>
From: Alexander Potapenko <glider@google.com>
Date: Tue, 18 Apr 2017 19:47:08 +0200
> In the case getsockopt() is called with PACKET_HDRLEN and zero length,
> |val| remains uninitialized and the syscall may behave differently
> depending on its value. This doesn't have security consequences (as the
> uninit bytes aren't copied back), but it's still cleaner to initialize
> |val|.
>
> This bug has been detected with KMSAN.
>
> Signed-off-by: Alexander Potapenko <glider@google.com>
Copying into an 'int' only 1, 2, or 3 bytes is not going to work
properly.
Either enforce that it must be 4 bytes long, or handle the smaller
sizes properly such that it will work regardless of endianness.
Thanks.
^ permalink raw reply
* [PATCHv2 next] bonding: fix wq initialization for links created via netlink
From: Mahesh Bandewar @ 2017-04-20 19:49 UTC (permalink / raw)
To: Jay Vosburgh, Andy Gospodarek, Veaceslav Falico,
Nikolay Aleksandrov, David Miller, Eric Dumazet, Joe Stringer
Cc: netdev, Mahesh Bandewar, Mahesh Bandewar
From: Mahesh Bandewar <maheshb@google.com>
Earlier patch 4493b81bea ("bonding: initialize work-queues during
creation of bond") moved the work-queue initialization from bond_open()
to bond_create(). However this caused the link those are created using
netlink 'create bond option' (ip link add bondX type bond); create the
new trunk without initializing work-queues. Prior to the above mentioned
change, ndo_open was in both paths and things worked correctly. The
consequence is visible in the report shared by Joe Stringer -
I've noticed that this patch breaks bonding within namespaces if
you're not careful to perform device cleanup correctly.
Here's my repro script, you can run on any net-next with this patch
and you'll start seeing some weird behaviour:
ip netns add foo
ip li add veth0 type veth peer name veth0+ netns foo
ip li add veth1 type veth peer name veth1+ netns foo
ip netns exec foo ip li add bond0 type bond
ip netns exec foo ip li set dev veth0+ master bond0
ip netns exec foo ip li set dev veth1+ master bond0
ip netns exec foo ip addr add dev bond0 192.168.0.1/24
ip netns exec foo ip li set dev bond0 up
ip li del dev veth0
ip li del dev veth1
The second to last command segfaults, last command hangs. rtnl is now
permanently locked. It's not a problem if you take bond0 down before
deleting veths, or delete bond0 before deleting veths. If you delete
either end of the veth pair as per above, either inside or outside the
namespace, it hits this problem.
Here's some kernel logs:
[ 1221.801610] bond0: Enslaving veth0+ as an active interface with an up link
[ 1224.449581] bond0: Enslaving veth1+ as an active interface with an up link
[ 1281.193863] bond0: Releasing backup interface veth0+
[ 1281.193866] bond0: the permanent HWaddr of veth0+ -
16:bf:fb:e0:b8:43 - is still in use by bond0 - set the HWaddr of
veth0+ to a different address to avoid conflicts
[ 1281.193867] ------------[ cut here ]------------
[ 1281.193873] WARNING: CPU: 0 PID: 2024 at kernel/workqueue.c:1511
__queue_delayed_work+0x13f/0x150
[ 1281.193873] Modules linked in: bonding veth openvswitch nf_nat_ipv6
nf_nat_ipv4 nf_nat autofs4 nfsd auth_rpcgss nfs_acl binfmt_misc nfs
lockd grace sunrpc fscache ppdev vmw_balloon coretemp psmouse
serio_raw vmwgfx ttm drm_kms_helper vmw_vmci netconsole parport_pc
configfs drm i2c_piix4 fb_sys_fops syscopyarea sysfillrect sysimgblt
shpchp mac_hid nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4
nf_defrag_ipv4 nf_conntrack libcrc32c lp parport hid_generic usbhid
hid mptspi mptscsih e1000 mptbase ahci libahci
[ 1281.193905] CPU: 0 PID: 2024 Comm: ip Tainted: G W
4.10.0-bisect-bond-v0.14 #37
[ 1281.193906] Hardware name: VMware, Inc. VMware Virtual
Platform/440BX Desktop Reference Platform, BIOS 6.00 09/30/2014
[ 1281.193906] Call Trace:
[ 1281.193912] dump_stack+0x63/0x89
[ 1281.193915] __warn+0xd1/0xf0
[ 1281.193917] warn_slowpath_null+0x1d/0x20
[ 1281.193918] __queue_delayed_work+0x13f/0x150
[ 1281.193920] queue_delayed_work_on+0x27/0x40
[ 1281.193929] bond_change_active_slave+0x25b/0x670 [bonding]
[ 1281.193932] ? synchronize_rcu_expedited+0x27/0x30
[ 1281.193935] __bond_release_one+0x489/0x510 [bonding]
[ 1281.193939] ? addrconf_notify+0x1b7/0xab0
[ 1281.193942] bond_netdev_event+0x2c5/0x2e0 [bonding]
[ 1281.193944] ? netconsole_netdev_event+0x124/0x190 [netconsole]
[ 1281.193947] notifier_call_chain+0x49/0x70
[ 1281.193948] raw_notifier_call_chain+0x16/0x20
[ 1281.193950] call_netdevice_notifiers_info+0x35/0x60
[ 1281.193951] rollback_registered_many+0x23b/0x3e0
[ 1281.193953] unregister_netdevice_many+0x24/0xd0
[ 1281.193955] rtnl_delete_link+0x3c/0x50
[ 1281.193956] rtnl_dellink+0x8d/0x1b0
[ 1281.193960] rtnetlink_rcv_msg+0x95/0x220
[ 1281.193962] ? __kmalloc_node_track_caller+0x35/0x280
[ 1281.193964] ? __netlink_lookup+0xf1/0x110
[ 1281.193966] ? rtnl_newlink+0x830/0x830
[ 1281.193967] netlink_rcv_skb+0xa7/0xc0
[ 1281.193969] rtnetlink_rcv+0x28/0x30
[ 1281.193970] netlink_unicast+0x15b/0x210
[ 1281.193971] netlink_sendmsg+0x319/0x390
[ 1281.193974] sock_sendmsg+0x38/0x50
[ 1281.193975] ___sys_sendmsg+0x25c/0x270
[ 1281.193978] ? mem_cgroup_commit_charge+0x76/0xf0
[ 1281.193981] ? page_add_new_anon_rmap+0x89/0xc0
[ 1281.193984] ? lru_cache_add_active_or_unevictable+0x35/0xb0
[ 1281.193985] ? __handle_mm_fault+0x4e9/0x1170
[ 1281.193987] __sys_sendmsg+0x45/0x80
[ 1281.193989] SyS_sendmsg+0x12/0x20
[ 1281.193991] do_syscall_64+0x6e/0x180
[ 1281.193993] entry_SYSCALL64_slow_path+0x25/0x25
[ 1281.193995] RIP: 0033:0x7f6ec122f5a0
[ 1281.193995] RSP: 002b:00007ffe69e89c48 EFLAGS: 00000246 ORIG_RAX:
000000000000002e
[ 1281.193997] RAX: ffffffffffffffda RBX: 00007ffe69e8dd60 RCX: 00007f6ec122f5a0
[ 1281.193997] RDX: 0000000000000000 RSI: 00007ffe69e89c90 RDI: 0000000000000003
[ 1281.193998] RBP: 00007ffe69e89c90 R08: 0000000000000000 R09: 0000000000000003
[ 1281.193999] R10: 00007ffe69e89a10 R11: 0000000000000246 R12: 0000000058f14b9f
[ 1281.193999] R13: 0000000000000000 R14: 00000000006473a0 R15: 00007ffe69e8e450
[ 1281.194001] ---[ end trace 713a77486cbfbfa3 ]---
Fixes: 4493b81bea ("bonding: initialize work-queues during creation of bond")
Reported-by: Joe Stringer <joe@ovn.org>
Tested-by: Joe Stringer <joe@ovn.org>
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
---
v1 -> v2 : fixed 'if' condition
drivers/net/bonding/bond_main.c | 2 +-
drivers/net/bonding/bond_netlink.c | 5 +++++
include/net/bonding.h | 1 +
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 6bd3b50faf48..e549bf6f5cac 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3243,7 +3243,7 @@ u32 bond_xmit_hash(struct bonding *bond, struct sk_buff *skb)
/*-------------------------- Device entry points ----------------------------*/
-static void bond_work_init_all(struct bonding *bond)
+void bond_work_init_all(struct bonding *bond)
{
INIT_DELAYED_WORK(&bond->mcast_work,
bond_resend_igmp_join_requests_delayed);
diff --git a/drivers/net/bonding/bond_netlink.c b/drivers/net/bonding/bond_netlink.c
index b8df0f5e8c25..c502c139d3bc 100644
--- a/drivers/net/bonding/bond_netlink.c
+++ b/drivers/net/bonding/bond_netlink.c
@@ -449,6 +449,11 @@ static int bond_newlink(struct net *src_net, struct net_device *bond_dev,
err = register_netdevice(bond_dev);
netif_carrier_off(bond_dev);
+ if (!err) {
+ struct bonding *bond = netdev_priv(bond_dev);
+
+ bond_work_init_all(bond);
+ }
return err;
}
diff --git a/include/net/bonding.h b/include/net/bonding.h
index 04a21e8048be..b00508d22e0a 100644
--- a/include/net/bonding.h
+++ b/include/net/bonding.h
@@ -614,6 +614,7 @@ struct bond_vlan_tag *bond_verify_device_path(struct net_device *start_dev,
int level);
int bond_update_slave_arr(struct bonding *bond, struct slave *skipslave);
void bond_slave_arr_work_rearm(struct bonding *bond, unsigned long delay);
+void bond_work_init_all(struct bonding *bond);
#ifdef CONFIG_PROC_FS
void bond_create_proc_entry(struct bonding *bond);
--
2.12.2.816.g2cccc81164-goog
^ permalink raw reply related
* Re: [PATCH] brcm80211: brcmfmac: Ensure that incoming skb's are writable
From: Arend van Spriel @ 2017-04-20 19:48 UTC (permalink / raw)
To: James Hughes, netdev, Franky Lin, Hante Meuleman, Kalle Valo
Cc: linux-wireless
In-Reply-To: <20170420111651.10213-1-james.hughes@raspberrypi.org>
+ linux-wireless
On 4/20/2017 1:16 PM, James Hughes wrote:
> The driver was adding header information to incoming skb
> without ensuring the head was uncloned and hence writable.
>
> skb_cow_head has been used to ensure they are writable, however,
> this required some changes to error handling to ensure that
> if skb_cow_head failed it was not ignored.
>
> This really needs to be reviewed by someone who is more familiar
> with this code base to ensure any deallocation of skb's is
> still correct.
>
> Signed-off-by: James Hughes <james.hughes@raspberrypi.org>
> ---
> .../wireless/broadcom/brcm80211/brcmfmac/bcdc.c | 15 ++++++++--
> .../wireless/broadcom/brcm80211/brcmfmac/core.c | 23 +++++-----------
> .../broadcom/brcm80211/brcmfmac/fwsignal.c | 32 +++++++++++++++++-----
> .../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 7 ++++-
> 4 files changed, 51 insertions(+), 26 deletions(-)
>
[...]
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> index 5eaac13..08272e8 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> @@ -198,7 +198,7 @@ static netdev_tx_t brcmf_netdev_start_xmit(struct sk_buff *skb,
> int ret;
> struct brcmf_if *ifp = netdev_priv(ndev);
> struct brcmf_pub *drvr = ifp->drvr;
> - struct ethhdr *eh = (struct ethhdr *)(skb->data);
> + struct ethhdr *eh;
>
> brcmf_dbg(DATA, "Enter, bsscfgidx=%d\n", ifp->bsscfgidx);
>
> @@ -212,23 +212,14 @@ static netdev_tx_t brcmf_netdev_start_xmit(struct sk_buff *skb,
> }
>
> /* Make sure there's enough room for any header */
> - if (skb_headroom(skb) < drvr->hdrlen) {
> - struct sk_buff *skb2;
> -
> - brcmf_dbg(INFO, "%s: insufficient headroom\n",
> - brcmf_ifname(ifp));
> - drvr->bus_if->tx_realloc++;
> - skb2 = skb_realloc_headroom(skb, drvr->hdrlen);
> - dev_kfree_skb(skb);
> - skb = skb2;
> - if (skb == NULL) {
> - brcmf_err("%s: skb_realloc_headroom failed\n",
> - brcmf_ifname(ifp));
> - ret = -ENOMEM;
> - goto done;
> - }
What you are throwing away here is code that assures there is sufficient
headroom for protocol and bus layer in the tx path, because that is
determined by drvr->hdrlen. This is where the skb is handed to the
driver so if you could leave the functionality above *and* assure it is
writeable that would be the best solution as there is no need for all
the other changes down the tx path.
> + ret = skb_cow_head(skb, drvr->hdrlen);
> + if (ret) {
So move the realloc code above here instead of simply freeing the skb.
> + dev_kfree_skb_any(skb);
> + goto done;
> }
>
> + eh = (struct ethhdr *)(skb->data);
Now this is actually a separate fix so I would like a separate patch for it.
I have a RPi3 sitting on my desk so how can I replicate the issue. It
was something about broadcast/multicast traffic when using AP mode and a
bridge, right?
Regards,
Arend
^ permalink raw reply
* Re: [PATCH net-next 0/2] tcp: address two poll() flakes
From: David Miller @ 2017-04-20 19:42 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet
In-Reply-To: <20170418164552.29261-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Tue, 18 Apr 2017 09:45:50 -0700
> Some packetdrill tests are failing when host kernel is using ASAN
> or other debugging infrastructure.
>
> I was able to fix the flakes by making sure we were not
> sending wakeup events too soon.
Series applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net] ipv6: sr: fix out-of-bounds access in SRH validation
From: David Miller @ 2017-04-20 19:41 UTC (permalink / raw)
To: david.lebrun; +Cc: netdev, andreyknvl
In-Reply-To: <20170418155949.1028-1-david.lebrun@uclouvain.be>
From: David Lebrun <david.lebrun@uclouvain.be>
Date: Tue, 18 Apr 2017 17:59:49 +0200
> This patch fixes an out-of-bounds access in seg6_validate_srh() when the
> trailing data is less than sizeof(struct sr6_tlv).
>
> Reported-by: Andrey Konovalov <andreyknvl@google.com>
> Cc: Andrey Konovalov <andreyknvl@google.com>
> Signed-off-by: David Lebrun <david.lebrun@uclouvain.be>
Applied, but please provide a proper Fixes: tag next time.
^ permalink raw reply
* Re: [PATCH net] selftests/net: Fixes psock_fanout CBPF test case
From: David Miller @ 2017-04-20 19:39 UTC (permalink / raw)
To: maloneykernel; +Cc: netdev, sowmini.varadhan, maloney
In-Reply-To: <20170418151416.17858-1-maloneykernel@gmail.com>
From: Mike Maloney <maloneykernel@gmail.com>
Date: Tue, 18 Apr 2017 11:14:16 -0400
> From: Mike Maloney <maloney@google.com>
>
> 'psock_fanout' has been failing since commit 4d7b9dc1f36a9 ("tools:
> psock_lib: harden socket filter used by psock tests"). That commit
> changed the CBPF filter to examine the full ethernet frame, and was
> tested on 'psock_tpacket' which uses SOCK_RAW. But 'psock_fanout' was
> also using this same CBPF in two places, for filtering and fanout, on a
> SOCK_DGRAM socket.
>
> Change 'psock_fanout' to use SOCK_RAW so that the CBPF program used with
> SO_ATTACH_FILTER can examine the entire frame. Create a new CBPF
> program for use with PACKET_FANOUT_DATA which ignores the header, as it
> cannot see the ethernet header.
>
> Tested: Ran tools/testing/selftests/net/psock_{fanout,tpacket} 10 times,
> and they all passed.
>
> Fixes: 4d7b9dc1f36a9 ("tools: psock_lib: harden socket filter used by psock tests")
> Signed-off-by: 'Mike Maloney <maloneykernel@gmail.com>'
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] mac80211: reject ToDS broadcast data frames
From: David Miller @ 2017-04-20 19:38 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless, johannes.berg
In-Reply-To: <20170420193216.17087-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Thu, 20 Apr 2017 21:32:16 +0200
> From: Johannes Berg <johannes.berg@intel.com>
>
> AP/AP_VLAN modes don't accept any real 802.11 multicast data
> frames, but since they do need to accept broadcast management
> frames the same is currently permitted for data frames. This
> opens a security problem because such frames would be decrypted
> with the GTK, and could even contain unicast L3 frames.
>
> Since the spec says that ToDS frames must always have the BSSID
> as the RA (addr1), reject any other data frames.
>
> The problem was originally reported in "Predicting, Decrypting,
> and Abusing WPA2/802.11 Group Keys" at usenix
> https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/vanhoef
> and brought to my attention by Jouni.
>
> Cc: stable@vger.kernel.org
> Reported-by: Jouni Malinen <j@w1.fi>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> --
> Dave, I didn't want to send you a new pull request for a single
> commit yet again - can you apply this one patch as is?
Sure, done.
^ permalink raw reply
* [PATCH stable 4.4] tipc: fix crash during node removal
From: Jon Maloy @ 2017-04-20 19:33 UTC (permalink / raw)
To: davem, netdev; +Cc: parthasarathy.bhuvaragan, ying.xue, tipc-discussion
From: Jon Paul Maloy <jon.maloy@ericsson.com>
commit d25a01257e422a4bdeb426f69529d57c73b235fe upstream
When the TIPC module is unloaded, we have identified a race condition
that allows a node reference counter to go to zero and the node instance
being freed before the node timer is finished with accessing it. This
leads to occasional crashes, especially in multi-namespace environments.
The scenario goes as follows:
CPU0:(node_stop) CPU1:(node_timeout) // ref == 2
1: if(!mod_timer())
2: if (del_timer())
3: tipc_node_put() // ref -> 1
4: tipc_node_put() // ref -> 0
5: kfree_rcu(node);
6: tipc_node_get(node)
7: // BOOM!
We now clean up this functionality as follows:
1) We remove the node pointer from the node lookup table before we
attempt deactivating the timer. This way, we reduce the risk that
tipc_node_find() may obtain a valid pointer to an instance marked
for deletion; a harmless but undesirable situation.
2) We use del_timer_sync() instead of del_timer() to safely deactivate
the node timer without any risk that it might be reactivated by the
timeout handler. There is no risk of deadlock here, since the two
functions never touch the same spinlocks.
3: We remove a pointless tipc_node_get() + tipc_node_put() from the
timeout handler.
Reported-by: Zhijiang Hu <huzhijiang@gmail.com>
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/tipc/node.c | 24 +++++++++++-------------
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/net/tipc/node.c b/net/tipc/node.c
index 3926b56..d468aad 100644
--- a/net/tipc/node.c
+++ b/net/tipc/node.c
@@ -102,9 +102,10 @@ static unsigned int tipc_hashfn(u32 addr)
static void tipc_node_kref_release(struct kref *kref)
{
- struct tipc_node *node = container_of(kref, struct tipc_node, kref);
+ struct tipc_node *n = container_of(kref, struct tipc_node, kref);
- tipc_node_delete(node);
+ kfree(n->bc_entry.link);
+ kfree_rcu(n, rcu);
}
void tipc_node_put(struct tipc_node *node)
@@ -216,21 +217,20 @@ static void tipc_node_delete(struct tipc_node *node)
{
list_del_rcu(&node->list);
hlist_del_rcu(&node->hash);
- kfree(node->bc_entry.link);
- kfree_rcu(node, rcu);
+ tipc_node_put(node);
+
+ del_timer_sync(&node->timer);
+ tipc_node_put(node);
}
void tipc_node_stop(struct net *net)
{
- struct tipc_net *tn = net_generic(net, tipc_net_id);
+ struct tipc_net *tn = tipc_net(net);
struct tipc_node *node, *t_node;
spin_lock_bh(&tn->node_list_lock);
- list_for_each_entry_safe(node, t_node, &tn->node_list, list) {
- if (del_timer(&node->timer))
- tipc_node_put(node);
- tipc_node_put(node);
- }
+ list_for_each_entry_safe(node, t_node, &tn->node_list, list)
+ tipc_node_delete(node);
spin_unlock_bh(&tn->node_list_lock);
}
@@ -313,9 +313,7 @@ static void tipc_node_timeout(unsigned long data)
if (rc & TIPC_LINK_DOWN_EVT)
tipc_node_link_down(n, bearer_id, false);
}
- if (!mod_timer(&n->timer, jiffies + n->keepalive_intv))
- tipc_node_get(n);
- tipc_node_put(n);
+ mod_timer(&n->timer, jiffies + n->keepalive_intv);
}
/**
--
2.1.4
^ permalink raw reply related
* Re: [patch net-next 0/8] mlxsw: Allow flow based forwarding in OVS
From: David Miller @ 2017-04-20 19:32 UTC (permalink / raw)
To: jiri; +Cc: netdev, idosch, mlxsw
In-Reply-To: <1492527338-13298-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Tue, 18 Apr 2017 16:55:30 +0200
> This patchset does some fixes so the HW is setup correctly to do
> flow-based (ACL based) forwarding for OVS-enslaved port.
>
> The first patch is just trivial fix spotted on the way.
>
> Patches 2-4 take care of proper FID setup which HW needs in order to
> for ACL based forwarding.
>
> The 7th patch (with dependency of patch 5 and 6) takes care of proper setup
> of ports that are enslaved in OVS.
>
> The last patch implements new FID miss trap that is used to push
> packets belonging to unknown flows to kernel and userspace.
Series applied, thanks Jiri.
^ permalink raw reply
* [PATCH net] mac80211: reject ToDS broadcast data frames
From: Johannes Berg @ 2017-04-20 19:32 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Johannes Berg
From: Johannes Berg <johannes.berg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
AP/AP_VLAN modes don't accept any real 802.11 multicast data
frames, but since they do need to accept broadcast management
frames the same is currently permitted for data frames. This
opens a security problem because such frames would be decrypted
with the GTK, and could even contain unicast L3 frames.
Since the spec says that ToDS frames must always have the BSSID
as the RA (addr1), reject any other data frames.
The problem was originally reported in "Predicting, Decrypting,
and Abusing WPA2/802.11 Group Keys" at usenix
https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/vanhoef
and brought to my attention by Jouni.
Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Reported-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
--
Dave, I didn't want to send you a new pull request for a single
commit yet again - can you apply this one patch as is?
---
net/mac80211/rx.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 4b12c70c85f0..4d7543d1a62c 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -3639,6 +3639,27 @@ static bool ieee80211_accept_frame(struct ieee80211_rx_data *rx)
!ether_addr_equal(bssid, hdr->addr1))
return false;
}
+
+ /*
+ * 802.11-2016 Table 9-26 says that for data frames, A1 must be
+ * the BSSID - we've checked that already but may have accepted
+ * the wildcard (ff:ff:ff:ff:ff:ff).
+ *
+ * It also says:
+ * The BSSID of the Data frame is determined as follows:
+ * a) If the STA is contained within an AP or is associated
+ * with an AP, the BSSID is the address currently in use
+ * by the STA contained in the AP.
+ *
+ * So we should not accept data frames with an address that's
+ * multicast.
+ *
+ * Accepting it also opens a security problem because stations
+ * could encrypt it with the GTK and inject traffic that way.
+ */
+ if (ieee80211_is_data(hdr->frame_control) && multicast)
+ return false;
+
return true;
case NL80211_IFTYPE_WDS:
if (bssid || !ieee80211_is_data(hdr->frame_control))
--
2.11.0
^ permalink raw reply related
* Re: [PATCH net-next] bpf: remove reference to sock_filter_ext from kerneldoc comment
From: David Miller @ 2017-04-20 19:27 UTC (permalink / raw)
To: tklauser; +Cc: netdev, daniel, ast
In-Reply-To: <20170418092700.9157-1-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Tue, 18 Apr 2017 11:27:00 +0200
> struct sock_filter_ext didn't make it into the tree and is now called
> struct bpf_insn. Reword the kerneldoc comment for bpf_convert_filter()
> accordingly.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied, thank you.
^ permalink raw reply
* [PATCH netnext 3/3] selftests/net: add tests for PACKET_FANOUT_FLAG_UNIQUEID
From: Mike Maloney @ 2017-04-20 19:25 UTC (permalink / raw)
To: netdev, davem; +Cc: Mike Maloney
In-Reply-To: <20170420192546.5567-1-maloneykernel@gmail.com>
From: Mike Maloney <maloney@google.com>
Create two groups with PACKET_FANOUT_FLAG_UNIQUEID, add a socket to one.
Ensure that the groups can only be joined if all options are consistent
with the original except for this flag.
Tested:
ran tools/testing/selftests/net/psock_fanout 10 times, all pass.
Signed-off-by: Mike Maloney <maloney@google.com>
Acked-by: Willem de Bruijn <willemb@google.com>
---
tools/testing/selftests/net/psock_fanout.c | 95 ++++++++++++++++++++++++++----
1 file changed, 84 insertions(+), 11 deletions(-)
diff --git a/tools/testing/selftests/net/psock_fanout.c b/tools/testing/selftests/net/psock_fanout.c
index b475d87d3aa3..1c46a21a9b5e 100644
--- a/tools/testing/selftests/net/psock_fanout.c
+++ b/tools/testing/selftests/net/psock_fanout.c
@@ -71,7 +71,7 @@
/* Open a socket in a given fanout mode.
* @return -1 if mode is bad, a valid socket otherwise */
-static int sock_fanout_open(uint16_t typeflags)
+static int sock_fanout_open(uint16_t typeflags, uint16_t group_id)
{
int fd, val;
@@ -81,8 +81,7 @@ static int sock_fanout_open(uint16_t typeflags)
exit(1);
}
- /* fanout group ID is always 0: tests whether old groups are deleted */
- val = ((int) typeflags) << 16;
+ val = (((int) typeflags) << 16) | group_id;
if (setsockopt(fd, SOL_PACKET, PACKET_FANOUT, &val, sizeof(val))) {
if (close(fd)) {
perror("close packet");
@@ -95,6 +94,20 @@ static int sock_fanout_open(uint16_t typeflags)
return fd;
}
+static void sock_fanout_getopts(int fd, uint16_t *typeflags, uint16_t *group_id)
+{
+ int sockopt;
+ socklen_t sockopt_len = sizeof(sockopt);
+
+ if (getsockopt(fd, SOL_PACKET, PACKET_FANOUT,
+ &sockopt, &sockopt_len)) {
+ perror("failed to getsockopt");
+ exit(1);
+ }
+ *typeflags = sockopt >> 16;
+ *group_id = sockopt & 0xfffff;
+}
+
static void sock_fanout_set_ebpf(int fd)
{
const int len_off = __builtin_offsetof(struct __sk_buff, len);
@@ -210,7 +223,7 @@ static void test_control_single(void)
fprintf(stderr, "test: control single socket\n");
if (sock_fanout_open(PACKET_FANOUT_ROLLOVER |
- PACKET_FANOUT_FLAG_ROLLOVER) != -1) {
+ PACKET_FANOUT_FLAG_ROLLOVER, 0) != -1) {
fprintf(stderr, "ERROR: opened socket with dual rollover\n");
exit(1);
}
@@ -223,26 +236,26 @@ static void test_control_group(void)
fprintf(stderr, "test: control multiple sockets\n");
- fds[0] = sock_fanout_open(PACKET_FANOUT_HASH);
+ fds[0] = sock_fanout_open(PACKET_FANOUT_HASH, 0);
if (fds[0] == -1) {
fprintf(stderr, "ERROR: failed to open HASH socket\n");
exit(1);
}
if (sock_fanout_open(PACKET_FANOUT_HASH |
- PACKET_FANOUT_FLAG_DEFRAG) != -1) {
+ PACKET_FANOUT_FLAG_DEFRAG, 0) != -1) {
fprintf(stderr, "ERROR: joined group with wrong flag defrag\n");
exit(1);
}
if (sock_fanout_open(PACKET_FANOUT_HASH |
- PACKET_FANOUT_FLAG_ROLLOVER) != -1) {
+ PACKET_FANOUT_FLAG_ROLLOVER, 0) != -1) {
fprintf(stderr, "ERROR: joined group with wrong flag ro\n");
exit(1);
}
- if (sock_fanout_open(PACKET_FANOUT_CPU) != -1) {
+ if (sock_fanout_open(PACKET_FANOUT_CPU, 0) != -1) {
fprintf(stderr, "ERROR: joined group with wrong mode\n");
exit(1);
}
- fds[1] = sock_fanout_open(PACKET_FANOUT_HASH);
+ fds[1] = sock_fanout_open(PACKET_FANOUT_HASH, 0);
if (fds[1] == -1) {
fprintf(stderr, "ERROR: failed to join group\n");
exit(1);
@@ -253,6 +266,61 @@ static void test_control_group(void)
}
}
+/* Test creating a unique fanout group ids */
+static void test_unique_fanout_group_ids(void)
+{
+ int fds[3];
+ uint16_t typeflags, first_group_id, second_group_id;
+
+ fprintf(stderr, "test: unique ids\n");
+
+ fds[0] = sock_fanout_open(PACKET_FANOUT_HASH |
+ PACKET_FANOUT_FLAG_UNIQUEID, 0);
+ if (fds[0] == -1) {
+ fprintf(stderr, "ERROR: failed to create a unique id group.\n");
+ exit(1);
+ }
+
+ sock_fanout_getopts(fds[0], &typeflags, &first_group_id);
+ if (typeflags != PACKET_FANOUT_HASH) {
+ fprintf(stderr, "ERROR: unexpected typeflags %x\n", typeflags);
+ exit(1);
+ }
+
+ if (sock_fanout_open(PACKET_FANOUT_CPU, first_group_id)) {
+ fprintf(stderr, "ERROR: joined group with wrong type.\n");
+ exit(1);
+ }
+
+ fds[1] = sock_fanout_open(PACKET_FANOUT_HASH, first_group_id);
+ if (fds[1] == -1) {
+ fprintf(stderr,
+ "ERROR: failed to join previously created group.\n");
+ exit(1);
+ }
+
+ fds[2] = sock_fanout_open(PACKET_FANOUT_HASH |
+ PACKET_FANOUT_FLAG_UNIQUEID, 0);
+ if (fds[2] == -1) {
+ fprintf(stderr,
+ "ERROR: failed to create a second unique id group.\n");
+ exit(1);
+ }
+
+ sock_fanout_getopts(fds[2], &typeflags, &second_group_id);
+ if (sock_fanout_open(PACKET_FANOUT_HASH | PACKET_FANOUT_FLAG_UNIQUEID,
+ second_group_id) != -1) {
+ fprintf(stderr,
+ "ERROR: specified a group id when requesting unique id\n");
+ exit(1);
+ }
+
+ if (close(fds[0]) || close(fds[1]) || close(fds[2])) {
+ fprintf(stderr, "ERROR: closing sockets\n");
+ exit(1);
+ }
+}
+
static int test_datapath(uint16_t typeflags, int port_off,
const int expect1[], const int expect2[])
{
@@ -263,8 +331,8 @@ static int test_datapath(uint16_t typeflags, int port_off,
fprintf(stderr, "test: datapath 0x%hx\n", typeflags);
- fds[0] = sock_fanout_open(typeflags);
- fds[1] = sock_fanout_open(typeflags);
+ fds[0] = sock_fanout_open(typeflags, 0);
+ fds[1] = sock_fanout_open(typeflags, 0);
if (fds[0] == -1 || fds[1] == -1) {
fprintf(stderr, "ERROR: failed open\n");
exit(1);
@@ -331,10 +399,12 @@ int main(int argc, char **argv)
const int expect_cpu0[2][2] = { { 20, 0 }, { 20, 0 } };
const int expect_cpu1[2][2] = { { 0, 20 }, { 0, 20 } };
const int expect_bpf[2][2] = { { 15, 5 }, { 15, 20 } };
+ const int expect_uniqueid[2][2] = { { 20, 20}, { 20, 20 } };
int port_off = 2, tries = 5, ret;
test_control_single();
test_control_group();
+ test_unique_fanout_group_ids();
/* find a set of ports that do not collide onto the same socket */
ret = test_datapath(PACKET_FANOUT_HASH, port_off,
@@ -365,6 +435,9 @@ int main(int argc, char **argv)
ret |= test_datapath(PACKET_FANOUT_CPU, port_off,
expect_cpu1[0], expect_cpu1[1]);
+ ret |= test_datapath(PACKET_FANOUT_FLAG_UNIQUEID, port_off,
+ expect_uniqueid[0], expect_uniqueid[1]);
+
if (ret)
return 1;
--
2.12.2.816.g2cccc81164-goog
^ permalink raw reply related
* [PATCH netnext 0/3] packet: Add option to create new fanout group with unique id.
From: Mike Maloney @ 2017-04-20 19:25 UTC (permalink / raw)
To: netdev, davem; +Cc: Mike Maloney
From: Mike Maloney <maloney@google.com>
Fanout uses a per net global namespace. A process that intends to create a
new fanout group can accidentally join an existing group. It is
not possible to detect this.
Add a socket option to specify on the first call to
setsockopt(..., PACKET_FANOUT, ...) to ensure that a new group is created.
Also add tests.
Mike Maloney (3):
selftests/net: cleanup unused parameter in psock_fanout
packet: add PACKET_FANOUT_FLAG_UNIQUEID to assign new fanout group id.
selftests/net: add tests for PACKET_FANOUT_FLAG_UNIQUEID
include/uapi/linux/if_packet.h | 1 +
net/packet/af_packet.c | 44 ++++++++++++++
tools/testing/selftests/net/psock_fanout.c | 93 ++++++++++++++++++++++++++----
3 files changed, 128 insertions(+), 10 deletions(-)
--
2.12.2.816.g2cccc81164-goog
^ 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