* [PATCH AUTOSEL 5.2 051/123] isdn: mISDN: hfcsusb: Fix possible null-pointer dereferences in start_isoc_chain()
From: Sasha Levin @ 2019-08-14 2:09 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Jia-Ju Bai, David S . Miller, Sasha Levin, netdev
In-Reply-To: <20190814021047.14828-1-sashal@kernel.org>
From: Jia-Ju Bai <baijiaju1990@gmail.com>
[ Upstream commit a0d57a552b836206ad7705a1060e6e1ce5a38203 ]
In start_isoc_chain(), usb_alloc_urb() on line 1392 may fail
and return NULL. At this time, fifo->iso[i].urb is assigned to NULL.
Then, fifo->iso[i].urb is used at some places, such as:
LINE 1405: fill_isoc_urb(fifo->iso[i].urb, ...)
urb->number_of_packets = num_packets;
urb->transfer_flags = URB_ISO_ASAP;
urb->actual_length = 0;
urb->interval = interval;
LINE 1416: fifo->iso[i].urb->...
LINE 1419: fifo->iso[i].urb->...
Thus, possible null-pointer dereferences may occur.
To fix these bugs, "continue" is added to avoid using fifo->iso[i].urb
when it is NULL.
These bugs are found by a static analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/isdn/hardware/mISDN/hfcsusb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/isdn/hardware/mISDN/hfcsusb.c b/drivers/isdn/hardware/mISDN/hfcsusb.c
index 0e224232f7464..8fb7c5dea07fc 100644
--- a/drivers/isdn/hardware/mISDN/hfcsusb.c
+++ b/drivers/isdn/hardware/mISDN/hfcsusb.c
@@ -1394,6 +1394,7 @@ start_isoc_chain(struct usb_fifo *fifo, int num_packets_per_urb,
printk(KERN_DEBUG
"%s: %s: alloc urb for fifo %i failed",
hw->name, __func__, fifo->fifonum);
+ continue;
}
fifo->iso[i].owner_fifo = (struct usb_fifo *) fifo;
fifo->iso[i].indx = i;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 039/123] can: gw: Fix error path of cgw_module_init
From: Sasha Levin @ 2019-08-14 2:09 UTC (permalink / raw)
To: linux-kernel, stable
Cc: YueHaibing, Oliver Hartkopp, Marc Kleine-Budde, Sasha Levin,
linux-can, netdev
In-Reply-To: <20190814021047.14828-1-sashal@kernel.org>
From: YueHaibing <yuehaibing@huawei.com>
[ Upstream commit b7a14297f102b6e2ce6f16feffebbb9bde1e9b55 ]
This patch add error path for cgw_module_init to avoid possible crash if
some error occurs.
Fixes: c1aabdf379bc ("can-gw: add netlink based CAN routing")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/can/gw.c | 48 +++++++++++++++++++++++++++++++++---------------
1 file changed, 33 insertions(+), 15 deletions(-)
diff --git a/net/can/gw.c b/net/can/gw.c
index 5275ddf580bc7..72711053ebe66 100644
--- a/net/can/gw.c
+++ b/net/can/gw.c
@@ -1046,32 +1046,50 @@ static __init int cgw_module_init(void)
pr_info("can: netlink gateway (rev " CAN_GW_VERSION ") max_hops=%d\n",
max_hops);
- register_pernet_subsys(&cangw_pernet_ops);
+ ret = register_pernet_subsys(&cangw_pernet_ops);
+ if (ret)
+ return ret;
+
+ ret = -ENOMEM;
cgw_cache = kmem_cache_create("can_gw", sizeof(struct cgw_job),
0, 0, NULL);
-
if (!cgw_cache)
- return -ENOMEM;
+ goto out_cache_create;
/* set notifier */
notifier.notifier_call = cgw_notifier;
- register_netdevice_notifier(¬ifier);
+ ret = register_netdevice_notifier(¬ifier);
+ if (ret)
+ goto out_register_notifier;
ret = rtnl_register_module(THIS_MODULE, PF_CAN, RTM_GETROUTE,
NULL, cgw_dump_jobs, 0);
- if (ret) {
- unregister_netdevice_notifier(¬ifier);
- kmem_cache_destroy(cgw_cache);
- return -ENOBUFS;
- }
-
- /* Only the first call to rtnl_register_module can fail */
- rtnl_register_module(THIS_MODULE, PF_CAN, RTM_NEWROUTE,
- cgw_create_job, NULL, 0);
- rtnl_register_module(THIS_MODULE, PF_CAN, RTM_DELROUTE,
- cgw_remove_job, NULL, 0);
+ if (ret)
+ goto out_rtnl_register1;
+
+ ret = rtnl_register_module(THIS_MODULE, PF_CAN, RTM_NEWROUTE,
+ cgw_create_job, NULL, 0);
+ if (ret)
+ goto out_rtnl_register2;
+ ret = rtnl_register_module(THIS_MODULE, PF_CAN, RTM_DELROUTE,
+ cgw_remove_job, NULL, 0);
+ if (ret)
+ goto out_rtnl_register3;
return 0;
+
+out_rtnl_register3:
+ rtnl_unregister(PF_CAN, RTM_NEWROUTE);
+out_rtnl_register2:
+ rtnl_unregister(PF_CAN, RTM_GETROUTE);
+out_rtnl_register1:
+ unregister_netdevice_notifier(¬ifier);
+out_register_notifier:
+ kmem_cache_destroy(cgw_cache);
+out_cache_create:
+ unregister_pernet_subsys(&cangw_pernet_ops);
+
+ return ret;
}
static __exit void cgw_module_exit(void)
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 037/123] can: dev: call netif_carrier_off() in register_candev()
From: Sasha Levin @ 2019-08-14 2:09 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Rasmus Villemoes, Willem de Bruijn, Marc Kleine-Budde,
Sasha Levin, linux-can, netdev
In-Reply-To: <20190814021047.14828-1-sashal@kernel.org>
From: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
[ Upstream commit c63845609c4700488e5eacd6ab4d06d5d420e5ef ]
CONFIG_CAN_LEDS is deprecated. When trying to use the generic netdev
trigger as suggested, there's a small inconsistency with the link
property: The LED is on initially, stays on when the device is brought
up, and then turns off (as expected) when the device is brought down.
Make sure the LED always reflects the state of the CAN device.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Acked-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/can/dev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index b6b93a2d93a59..483d270664cc8 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -1249,6 +1249,8 @@ int register_candev(struct net_device *dev)
return -EINVAL;
dev->rtnl_link_ops = &can_link_ops;
+ netif_carrier_off(dev);
+
return register_netdev(dev);
}
EXPORT_SYMBOL_GPL(register_candev);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 038/123] can: mcp251x: add error check when wq alloc failed
From: Sasha Levin @ 2019-08-14 2:09 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Weitao Hou, Willem de Bruijn, Sean Nyekjaer, Marc Kleine-Budde,
Sasha Levin, linux-can, netdev
In-Reply-To: <20190814021047.14828-1-sashal@kernel.org>
From: Weitao Hou <houweitaoo@gmail.com>
[ Upstream commit 375f755899b8fc21196197e02aab26257df26e85 ]
add error check when workqueue alloc failed, and remove redundant code
to make it clear.
Fixes: e0000163e30e ("can: Driver for the Microchip MCP251x SPI CAN controllers")
Signed-off-by: Weitao Hou <houweitaoo@gmail.com>
Acked-by: Willem de Bruijn <willemb@google.com>
Tested-by: Sean Nyekjaer <sean@geanix.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/can/spi/mcp251x.c | 49 ++++++++++++++++-------------------
1 file changed, 22 insertions(+), 27 deletions(-)
diff --git a/drivers/net/can/spi/mcp251x.c b/drivers/net/can/spi/mcp251x.c
index 44e99e3d71348..2aec934fab0cd 100644
--- a/drivers/net/can/spi/mcp251x.c
+++ b/drivers/net/can/spi/mcp251x.c
@@ -664,17 +664,6 @@ static int mcp251x_power_enable(struct regulator *reg, int enable)
return regulator_disable(reg);
}
-static void mcp251x_open_clean(struct net_device *net)
-{
- struct mcp251x_priv *priv = netdev_priv(net);
- struct spi_device *spi = priv->spi;
-
- free_irq(spi->irq, priv);
- mcp251x_hw_sleep(spi);
- mcp251x_power_enable(priv->transceiver, 0);
- close_candev(net);
-}
-
static int mcp251x_stop(struct net_device *net)
{
struct mcp251x_priv *priv = netdev_priv(net);
@@ -940,37 +929,43 @@ static int mcp251x_open(struct net_device *net)
flags | IRQF_ONESHOT, DEVICE_NAME, priv);
if (ret) {
dev_err(&spi->dev, "failed to acquire irq %d\n", spi->irq);
- mcp251x_power_enable(priv->transceiver, 0);
- close_candev(net);
- goto open_unlock;
+ goto out_close;
}
priv->wq = alloc_workqueue("mcp251x_wq", WQ_FREEZABLE | WQ_MEM_RECLAIM,
0);
+ if (!priv->wq) {
+ ret = -ENOMEM;
+ goto out_clean;
+ }
INIT_WORK(&priv->tx_work, mcp251x_tx_work_handler);
INIT_WORK(&priv->restart_work, mcp251x_restart_work_handler);
ret = mcp251x_hw_reset(spi);
- if (ret) {
- mcp251x_open_clean(net);
- goto open_unlock;
- }
+ if (ret)
+ goto out_free_wq;
ret = mcp251x_setup(net, spi);
- if (ret) {
- mcp251x_open_clean(net);
- goto open_unlock;
- }
+ if (ret)
+ goto out_free_wq;
ret = mcp251x_set_normal_mode(spi);
- if (ret) {
- mcp251x_open_clean(net);
- goto open_unlock;
- }
+ if (ret)
+ goto out_free_wq;
can_led_event(net, CAN_LED_EVENT_OPEN);
netif_wake_queue(net);
+ mutex_unlock(&priv->mcp_lock);
-open_unlock:
+ return 0;
+
+out_free_wq:
+ destroy_workqueue(priv->wq);
+out_clean:
+ free_irq(spi->irq, priv);
+ mcp251x_hw_sleep(spi);
+out_close:
+ mcp251x_power_enable(priv->transceiver, 0);
+ close_candev(net);
mutex_unlock(&priv->mcp_lock);
return ret;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 036/123] libbpf: fix using uninitialized ioctl results
From: Sasha Levin @ 2019-08-14 2:09 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Ilya Maximets, Magnus Karlsson, Andrii Nakryiko,
Alexei Starovoitov, Sasha Levin, netdev, bpf
In-Reply-To: <20190814021047.14828-1-sashal@kernel.org>
From: Ilya Maximets <i.maximets@samsung.com>
[ Upstream commit decb705e01a5d325c9876b9674043cde4b54f0db ]
'channels.max_combined' initialized only on ioctl success and
errno is only valid on ioctl failure.
The code doesn't produce any runtime issues, but makes memory
sanitizers angry:
Conditional jump or move depends on uninitialised value(s)
at 0x55C056F: xsk_get_max_queues (xsk.c:336)
by 0x55C05B2: xsk_create_bpf_maps (xsk.c:354)
by 0x55C089F: xsk_setup_xdp_prog (xsk.c:447)
by 0x55C0E57: xsk_socket__create (xsk.c:601)
Uninitialised value was created by a stack allocation
at 0x55C04CD: xsk_get_max_queues (xsk.c:318)
Additionally fixed warning on uninitialized bytes in ioctl arguments:
Syscall param ioctl(SIOCETHTOOL) points to uninitialised byte(s)
at 0x648D45B: ioctl (in /usr/lib64/libc-2.28.so)
by 0x55C0546: xsk_get_max_queues (xsk.c:330)
by 0x55C05B2: xsk_create_bpf_maps (xsk.c:354)
by 0x55C089F: xsk_setup_xdp_prog (xsk.c:447)
by 0x55C0E57: xsk_socket__create (xsk.c:601)
Address 0x1ffefff378 is on thread 1's stack
in frame #1, created by xsk_get_max_queues (xsk.c:318)
Uninitialised value was created by a stack allocation
at 0x55C04CD: xsk_get_max_queues (xsk.c:318)
CC: Magnus Karlsson <magnus.karlsson@intel.com>
Fixes: 1cad07884239 ("libbpf: add support for using AF_XDP sockets")
Signed-off-by: Ilya Maximets <i.maximets@samsung.com>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/lib/bpf/xsk.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/tools/lib/bpf/xsk.c b/tools/lib/bpf/xsk.c
index ca272c5b67f47..8e03b65830da0 100644
--- a/tools/lib/bpf/xsk.c
+++ b/tools/lib/bpf/xsk.c
@@ -327,15 +327,14 @@ static int xsk_load_xdp_prog(struct xsk_socket *xsk)
static int xsk_get_max_queues(struct xsk_socket *xsk)
{
- struct ethtool_channels channels;
- struct ifreq ifr;
+ struct ethtool_channels channels = { .cmd = ETHTOOL_GCHANNELS };
+ struct ifreq ifr = {};
int fd, err, ret;
fd = socket(AF_INET, SOCK_DGRAM, 0);
if (fd < 0)
return -errno;
- channels.cmd = ETHTOOL_GCHANNELS;
ifr.ifr_data = (void *)&channels;
strncpy(ifr.ifr_name, xsk->ifname, IFNAMSIZ - 1);
ifr.ifr_name[IFNAMSIZ - 1] = '\0';
@@ -345,7 +344,7 @@ static int xsk_get_max_queues(struct xsk_socket *xsk)
goto out;
}
- if (channels.max_combined == 0 || errno == EOPNOTSUPP)
+ if (err || channels.max_combined == 0)
/* If the device says it has no channels, then all traffic
* is sent to a single stream, so max queues = 1.
*/
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 034/123] bpf: fix access to skb_shared_info->gso_segs
From: Sasha Levin @ 2019-08-14 2:09 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Eric Dumazet, syzbot, Alexei Starovoitov, Sasha Levin, netdev,
bpf
In-Reply-To: <20190814021047.14828-1-sashal@kernel.org>
From: Eric Dumazet <edumazet@google.com>
[ Upstream commit 06a22d897d82f12776d44dbf0850f5895469cb2a ]
It is possible we reach bpf_convert_ctx_access() with
si->dst_reg == si->src_reg
Therefore, we need to load BPF_REG_AX before eventually
mangling si->src_reg.
syzbot generated this x86 code :
3: 55 push %rbp
4: 48 89 e5 mov %rsp,%rbp
7: 48 81 ec 00 00 00 00 sub $0x0,%rsp // Might be avoided ?
e: 53 push %rbx
f: 41 55 push %r13
11: 41 56 push %r14
13: 41 57 push %r15
15: 6a 00 pushq $0x0
17: 31 c0 xor %eax,%eax
19: 48 8b bf c0 00 00 00 mov 0xc0(%rdi),%rdi
20: 44 8b 97 bc 00 00 00 mov 0xbc(%rdi),%r10d
27: 4c 01 d7 add %r10,%rdi
2a: 48 0f b7 7f 06 movzwq 0x6(%rdi),%rdi // Crash
2f: 5b pop %rbx
30: 41 5f pop %r15
32: 41 5e pop %r14
34: 41 5d pop %r13
36: 5b pop %rbx
37: c9 leaveq
38: c3 retq
Fixes: d9ff286a0f59 ("bpf: allow BPF programs access skb_shared_info->gso_segs field")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/core/filter.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/core/filter.c b/net/core/filter.c
index f681fb772940c..534c310bb0893 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -7325,12 +7325,12 @@ static u32 bpf_convert_ctx_access(enum bpf_access_type type,
case offsetof(struct __sk_buff, gso_segs):
/* si->dst_reg = skb_shinfo(SKB); */
#ifdef NET_SKBUFF_DATA_USES_OFFSET
- *insn++ = BPF_LDX_MEM(BPF_FIELD_SIZEOF(struct sk_buff, head),
- si->dst_reg, si->src_reg,
- offsetof(struct sk_buff, head));
*insn++ = BPF_LDX_MEM(BPF_FIELD_SIZEOF(struct sk_buff, end),
BPF_REG_AX, si->src_reg,
offsetof(struct sk_buff, end));
+ *insn++ = BPF_LDX_MEM(BPF_FIELD_SIZEOF(struct sk_buff, head),
+ si->dst_reg, si->src_reg,
+ offsetof(struct sk_buff, head));
*insn++ = BPF_ALU64_REG(BPF_ADD, si->dst_reg, BPF_REG_AX);
#else
*insn++ = BPF_LDX_MEM(BPF_FIELD_SIZEOF(struct sk_buff, end),
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 032/123] selftests: forwarding: gre_multipath: Enable IPv4 forwarding
From: Sasha Levin @ 2019-08-14 2:09 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Ido Schimmel, Stephen Suryaputra, David S . Miller, Sasha Levin,
netdev, linux-kselftest
In-Reply-To: <20190814021047.14828-1-sashal@kernel.org>
From: Ido Schimmel <idosch@mellanox.com>
[ Upstream commit efa7b79f675da0efafe3f32ba0d6efe916cf4867 ]
The test did not enable IPv4 forwarding during its setup phase, which
causes the test to fail on machines where IPv4 forwarding is disabled.
Fixes: 54818c4c4b93 ("selftests: forwarding: Test multipath tunneling")
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reported-by: Stephen Suryaputra <ssuryaextr@gmail.com>
Tested-by: Stephen Suryaputra <ssuryaextr@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/testing/selftests/net/forwarding/gre_multipath.sh | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/tools/testing/selftests/net/forwarding/gre_multipath.sh b/tools/testing/selftests/net/forwarding/gre_multipath.sh
index cca2baa03fb81..37d7297e1cf8a 100755
--- a/tools/testing/selftests/net/forwarding/gre_multipath.sh
+++ b/tools/testing/selftests/net/forwarding/gre_multipath.sh
@@ -187,12 +187,16 @@ setup_prepare()
sw1_create
sw2_create
h2_create
+
+ forwarding_enable
}
cleanup()
{
pre_cleanup
+ forwarding_restore
+
h2_destroy
sw2_destroy
sw1_destroy
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 030/123] bonding: Force slave speed check after link state recovery for 802.3ad
From: Sasha Levin @ 2019-08-14 2:09 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Thomas Falcon, Jarod Wilson, Jay Vosburgh, Veaceslav Falico,
Andy Gospodarek, David S . Miller, Sasha Levin, netdev
In-Reply-To: <20190814021047.14828-1-sashal@kernel.org>
From: Thomas Falcon <tlfalcon@linux.ibm.com>
[ Upstream commit 12185dfe44360f814ac4ead9d22ad2af7511b2e9 ]
The following scenario was encountered during testing of logical
partition mobility on pseries partitions with bonded ibmvnic
adapters in LACP mode.
1. Driver receives a signal that the device has been
swapped, and it needs to reset to initialize the new
device.
2. Driver reports loss of carrier and begins initialization.
3. Bonding driver receives NETDEV_CHANGE notifier and checks
the slave's current speed and duplex settings. Because these
are unknown at the time, the bond sets its link state to
BOND_LINK_FAIL and handles the speed update, clearing
AD_PORT_LACP_ENABLE.
4. Driver finishes recovery and reports that the carrier is on.
5. Bond receives a new notification and checks the speed again.
The speeds are valid but miimon has not altered the link
state yet. AD_PORT_LACP_ENABLE remains off.
Because the slave's link state is still BOND_LINK_FAIL,
no further port checks are made when it recovers. Though
the slave devices are operational and have valid speed
and duplex settings, the bond will not send LACPDU's. The
simplest fix I can see is to force another speed check
in bond_miimon_commit. This way the bond will update
AD_PORT_LACP_ENABLE if needed when transitioning from
BOND_LINK_FAIL to BOND_LINK_UP.
CC: Jarod Wilson <jarod@redhat.com>
CC: Jay Vosburgh <j.vosburgh@gmail.com>
CC: Veaceslav Falico <vfalico@gmail.com>
CC: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/bonding/bond_main.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index b0aab3a0a1bfa..41f6da5b4bab8 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -2203,6 +2203,15 @@ static void bond_miimon_commit(struct bonding *bond)
bond_for_each_slave(bond, slave, iter) {
switch (slave->new_link) {
case BOND_LINK_NOCHANGE:
+ /* For 802.3ad mode, check current slave speed and
+ * duplex again in case its port was disabled after
+ * invalid speed/duplex reporting but recovered before
+ * link monitoring could make a decision on the actual
+ * link status
+ */
+ if (BOND_MODE(bond) == BOND_MODE_8023AD &&
+ slave->link == BOND_LINK_UP)
+ bond_3ad_adapter_speed_duplex_changed(slave);
continue;
case BOND_LINK_UP:
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 020/123] libbpf: sanitize VAR to conservative 1-byte INT
From: Sasha Levin @ 2019-08-14 2:09 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Andrii Nakryiko, Alexei Starovoitov, Sasha Levin, netdev, bpf
In-Reply-To: <20190814021047.14828-1-sashal@kernel.org>
From: Andrii Nakryiko <andriin@fb.com>
[ Upstream commit 1d4126c4e1190d2f7d3f388552f9bd17ae0c64fc ]
If VAR in non-sanitized BTF was size less than 4, converting such VAR
into an INT with size=4 will cause BTF validation failure due to
violationg of STRUCT (into which DATASEC was converted) member size.
Fix by conservatively using size=1.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/lib/bpf/libbpf.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 3865a5d272514..77e14d9954796 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -1044,8 +1044,13 @@ static void bpf_object__sanitize_btf(struct bpf_object *obj)
if (!has_datasec && kind == BTF_KIND_VAR) {
/* replace VAR with INT */
t->info = BTF_INFO_ENC(BTF_KIND_INT, 0, 0);
- t->size = sizeof(int);
- *(int *)(t+1) = BTF_INT_ENC(0, 0, 32);
+ /*
+ * using size = 1 is the safest choice, 4 will be too
+ * big and cause kernel BTF validation failure if
+ * original variable took less than 4 bytes
+ */
+ t->size = 1;
+ *(int *)(t+1) = BTF_INT_ENC(0, 0, 8);
} else if (!has_datasec && kind == BTF_KIND_DATASEC) {
/* replace DATASEC with STRUCT */
struct btf_var_secinfo *v = (void *)(t + 1);
--
2.20.1
^ permalink raw reply related
* Re: [RFC bpf-next 0/3] tools: bpftool: add subcommand to count map entries
From: Alexei Starovoitov @ 2019-08-14 1:51 UTC (permalink / raw)
To: Quentin Monnet
Cc: Alexei Starovoitov, Daniel Borkmann, bpf, netdev, oss-drivers
In-Reply-To: <20190813130921.10704-1-quentin.monnet@netronome.com>
On Tue, Aug 13, 2019 at 02:09:18PM +0100, Quentin Monnet wrote:
> This series adds a "bpftool map count" subcommand to count the number of
> entries present in a BPF map. This results from a customer request for a
> tool to count the number of entries in BPF maps used in production (for
> example, to know how many free entries are left in a given map).
>
> The first two commits actually contain some clean-up in preparation for the
> new subcommand.
>
> The third commit adds the new subcommand. Because what data should count as
> an entry is not entirely clear for all map types, we actually dump several
> counters, and leave it to the users to interpret the values.
>
> Sending as a RFC because I'm looking for feedback on the approach. Is
> printing several values the good thing to do? Also, note that some map
> types such as queue/stack maps do not support any type of counting, this
> would need to be implemented in the kernel I believe.
>
> More generally, we have a use case where (hash) maps are under pressure
> (many additions/deletions from the BPF program), and counting the entries
> by iterating other the different keys is not at all reliable. Would that
> make sense to add a new bpf() subcommand to count the entries on the kernel
> side instead of cycling over the entries in bpftool? If so, we would need
> to agree on what makes an entry for each kind of map.
I don't mind new bpftool sub-command, but against adding kernel interface.
Can you elaborate what is the actual use case?
The same can be achieved by 'bpftool map dump|grep key|wc -l', no?
> Note that we are also facing similar issues for purging map from their
> entries (deleting all entries at once). We can iterate on the keys and
> delete elements one by one, but this is very inefficient when entries are
> being added/removed in parallel from the BPF program, and having another
> dedicated command accessible from the bpf() system call might help here as
> well.
I think that fits into the batch processing of map commands discussion.
^ permalink raw reply
* Re: [PATCH 00/17] Netfilter/IPVS updates for net-next
From: Jakub Kicinski @ 2019-08-14 1:44 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netfilter-devel, davem, netdev
In-Reply-To: <20190813183701.4002-1-pablo@netfilter.org>
On Tue, 13 Aug 2019 20:36:44 +0200, Pablo Neira Ayuso wrote:
> Hi,
>
> The following patchset contains Netfilter/IPVS updates for net-next:
>
> 1) Rename mss field to mss_option field in synproxy, from Fernando Mancera.
>
> 2) Use SYSCTL_{ZERO,ONE} definitions in conntrack, from Matteo Croce.
>
> 3) More strict validation of IPVS sysctl values, from Junwei Hu.
>
> 4) Remove unnecessary spaces after on the right hand side of assignments,
> from yangxingwu.
>
> 5) Add offload support for bitwise operation.
>
> 6) Extend the nft_offload_reg structure to store immediate date.
>
> 7) Collapse several ip_set header files into ip_set.h, from
> Jeremy Sowden.
>
> 8) Make netfilter headers compile with CONFIG_KERNEL_HEADER_TEST=y,
> from Jeremy Sowden.
>
> 9) Fix several sparse warnings due to missing prototypes, from
> Valdis Kletnieks.
>
> 10) Use static lock initialiser to ensure connlabel spinlock is
> initialized on boot time to fix sched/act_ct.c, patch
> from Florian Westphal.
Pulled, thanks.
^ permalink raw reply
* Re: [RFC PATCH bpf-next 00/14] xdp_flow: Flow offload to XDP
From: Alexei Starovoitov @ 2019-08-14 1:44 UTC (permalink / raw)
To: Toshiaki Makita
Cc: Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Song Liu,
Yonghong Song, David S. Miller, Jakub Kicinski,
Jesper Dangaard Brouer, John Fastabend, Jamal Hadi Salim,
Cong Wang, Jiri Pirko, netdev, bpf, William Tu
In-Reply-To: <20190813120558.6151-1-toshiaki.makita1@gmail.com>
On Tue, Aug 13, 2019 at 09:05:44PM +0900, Toshiaki Makita wrote:
> This is a rough PoC for an idea to offload TC flower to XDP.
...
> xdp_flow TC ovs kmod
> -------- -------- --------
> 4.0 Mpps 1.1 Mpps 1.1 Mpps
Is xdp_flow limited to 4 Mpps due to veth or something else?
>
> So xdp_flow drop rate is roughly 4x faster than software TC or ovs kmod.
>
> OTOH the time to add a flow increases with xdp_flow.
>
> ping latency of first packet when veth1 does XDP_PASS instead of DROP:
>
> xdp_flow TC ovs kmod
> -------- -------- --------
> 25ms 12ms 0.6ms
>
> xdp_flow does a lot of work to emulate TC behavior including UMH
> transaction and multiple bpf map update from UMH which I think increases
> the latency.
make sense, but why vanilla TC is so slow ?
> * Implementation
>
> xdp_flow makes use of UMH to load an eBPF program for XDP, similar to
> bpfilter. The difference is that xdp_flow does not generate the eBPF
> program dynamically but a prebuilt program is embedded in UMH. This is
> mainly because flow insertion is considerably frequent. If we generate
> and load an eBPF program on each insertion of a flow, the latency of the
> first packet of ping in above test will incease, which I want to avoid.
I think UMH approach is a good fit for this.
Clearly the same algorithm can be done as kernel code or kernel module, but
bpfilter-like UMH is a safer approach.
> - patch 9
> Add tc-offload-xdp netdev feature and hooks to call xdp_flow kmod in
> TC flower offload code.
The hook into UMH from TC looks simple. Do you expect the same interface to be
reused from OVS ?
> * About alternative userland (ovs-vswitchd etc.) implementation
>
> Maybe a similar logic can be implemented in ovs-vswitchd offload
> mechanism, instead of adding code to kernel. I just thought offloading
> TC is more generic and allows wider usage with direct TC command.
>
> For example, considering that OVS inserts a flow to kernel only when
> flow miss happens in kernel, we can in advance add offloaded flows via
> tc filter to avoid flow insertion latency for certain sensitive flows.
> TC flower usage without using OVS is also possible.
>
> Also as written above nftables can be offloaded to XDP with this
> mechanism as well.
Makes sense to me.
> bpf, hashtab: Compare keys in long
3Mpps vs 4Mpps just from this patch ?
or combined with i40 prefech patch ?
> drivers/net/ethernet/intel/i40e/i40e_txrx.c | 1 +
Could you share "perf report" for just hash tab optimization
and for i40 ?
I haven't seen memcmp to be bottle neck in hash tab.
What is the the of the key?
^ permalink raw reply
* [PATCH] net: pch_gbe: Fix memory leaks
From: Wenwen Wang @ 2019-08-14 1:33 UTC (permalink / raw)
To: Wenwen Wang
Cc: David S. Miller, Richard Fontana, Allison Randal, Alexios Zavras,
Greg Kroah-Hartman, Thomas Gleixner, open list:NETWORKING DRIVERS,
open list
In pch_gbe_set_ringparam(), if netif_running() returns false, 'tx_old' and
'rx_old' are not deallocated, leading to memory leaks. To fix this issue,
move the free statements after the if branch.
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
---
drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_ethtool.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_ethtool.c b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_ethtool.c
index 1a3008e..ef6311cd 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_ethtool.c
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_ethtool.c
@@ -340,12 +340,12 @@ static int pch_gbe_set_ringparam(struct net_device *netdev,
goto err_setup_tx;
pch_gbe_free_rx_resources(adapter, rx_old);
pch_gbe_free_tx_resources(adapter, tx_old);
- kfree(tx_old);
- kfree(rx_old);
adapter->rx_ring = rxdr;
adapter->tx_ring = txdr;
err = pch_gbe_up(adapter);
}
+ kfree(tx_old);
+ kfree(rx_old);
return err;
err_setup_tx:
--
2.7.4
^ permalink raw reply related
* [PATCH] net/ncsi: Ensure 32-bit boundary for data cksum
From: Terry S. Duncan @ 2019-08-14 1:18 UTC (permalink / raw)
To: Samuel Mendoza-Jonas, David S . Miller, netdev, linux-kernel,
openbmc, William Kennington, Joel Stanley
Cc: Terry S. Duncan
The NCSI spec indicates that if the data does not end on a 32 bit
boundary, one to three padding bytes equal to 0x00 shall be present to
align the checksum field to a 32-bit boundary.
Signed-off-by: Terry S. Duncan <terry.s.duncan@linux.intel.com>
---
net/ncsi/internal.h | 1 +
net/ncsi/ncsi-cmd.c | 2 +-
net/ncsi/ncsi-rsp.c | 12 ++++++++----
3 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/net/ncsi/internal.h b/net/ncsi/internal.h
index 0b3f0673e1a2..468a19fdfd88 100644
--- a/net/ncsi/internal.h
+++ b/net/ncsi/internal.h
@@ -185,6 +185,7 @@ struct ncsi_package;
#define NCSI_TO_CHANNEL(p, c) (((p) << NCSI_PACKAGE_SHIFT) | (c))
#define NCSI_MAX_PACKAGE 8
#define NCSI_MAX_CHANNEL 32
+#define NCSI_ROUND32(x) (((x) + 3) & ~3) /* Round to 32 bit boundary */
struct ncsi_channel {
unsigned char id;
diff --git a/net/ncsi/ncsi-cmd.c b/net/ncsi/ncsi-cmd.c
index 5c3fad8cba57..c12f2183b460 100644
--- a/net/ncsi/ncsi-cmd.c
+++ b/net/ncsi/ncsi-cmd.c
@@ -54,7 +54,7 @@ static void ncsi_cmd_build_header(struct ncsi_pkt_hdr *h,
checksum = ncsi_calculate_checksum((unsigned char *)h,
sizeof(*h) + nca->payload);
pchecksum = (__be32 *)((void *)h + sizeof(struct ncsi_pkt_hdr) +
- nca->payload);
+ NCSI_ROUND32(nca->payload));
*pchecksum = htonl(checksum);
}
diff --git a/net/ncsi/ncsi-rsp.c b/net/ncsi/ncsi-rsp.c
index 7581bf919885..10a142d0422f 100644
--- a/net/ncsi/ncsi-rsp.c
+++ b/net/ncsi/ncsi-rsp.c
@@ -47,7 +47,8 @@ static int ncsi_validate_rsp_pkt(struct ncsi_request *nr,
if (ntohs(h->code) != NCSI_PKT_RSP_C_COMPLETED ||
ntohs(h->reason) != NCSI_PKT_RSP_R_NO_ERROR) {
netdev_dbg(nr->ndp->ndev.dev,
- "NCSI: non zero response/reason code\n");
+ "NCSI: non zero response/reason code %04xh, %04xh\n",
+ ntohs(h->code), ntohs(h->reason));
return -EPERM;
}
@@ -55,15 +56,18 @@ static int ncsi_validate_rsp_pkt(struct ncsi_request *nr,
* sender doesn't support checksum according to NCSI
* specification.
*/
- pchecksum = (__be32 *)((void *)(h + 1) + payload - 4);
+ pchecksum = (__be32 *)((void *)(h + 1) + NCSI_ROUND32(payload) - 4);
if (ntohl(*pchecksum) == 0)
return 0;
checksum = ncsi_calculate_checksum((unsigned char *)h,
- sizeof(*h) + payload - 4);
+ sizeof(*h) +
+ NCSI_ROUND32(payload) - 4);
if (*pchecksum != htonl(checksum)) {
- netdev_dbg(nr->ndp->ndev.dev, "NCSI: checksum mismatched\n");
+ netdev_dbg(nr->ndp->ndev.dev,
+ "NCSI: checksum mismatched; recd: %08x calc: %08x\n",
+ *pchecksum, htonl(checksum));
return -EINVAL;
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next v2 0/5] r8152: RX improve
From: Jakub Kicinski @ 2019-08-14 1:15 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1394712342-15778-295-albertk@realtek.com>
On Tue, 13 Aug 2019 11:42:04 +0800, Hayes Wang wrote:
> v2:
> For patch #2, replace list_for_each_safe with list_for_each_entry_safe.
> Remove unlikely in WARN_ON. Adjust the coding style.
>
> For patch #4, replace list_for_each_safe with list_for_each_entry_safe.
> Remove "else" after "continue".
>
> For patch #5. replace sysfs with ethtool to modify rx_copybreak and
> rx_pending.
>
> v1:
> The different chips use different rx buffer size.
>
> Use skb_add_rx_frag() to reduce memory copy for RX.
Applied, thank you.
^ permalink raw reply
* Re: [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf
From: Alexei Starovoitov @ 2019-08-14 0:57 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Song Liu, Kees Cook, Networking, bpf, Alexei Starovoitov,
Daniel Borkmann, Kernel Team, Lorenz Bauer, Jann Horn, Greg KH,
Linux API, LSM List
In-Reply-To: <CALCETrVT-dDXQGukGs5S1DkzvQv9_e=axzr_GyEd2c4T4z8Qng@mail.gmail.com>
On Tue, Aug 13, 2019 at 04:06:00PM -0700, Andy Lutomirski wrote:
> On Tue, Aug 13, 2019 at 2:58 PM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> >
> > On Tue, Aug 06, 2019 at 10:24:25PM -0700, Andy Lutomirski wrote:
> > > >
> > > > Inside containers and inside nested containers we need to start processes
> > > > that will use bpf. All of the processes are trusted.
> > >
> > > Trusted by whom? In a non-nested container, the container manager
> > > *might* be trusted by the outside world. In a *nested* container,
> > > unless the inner container management is controlled from outside the
> > > outer container, it's not trusted. I don't know much about how
> > > Facebook's containers work, but the LXC/LXD/Podman world is moving
> > > very strongly toward user namespaces and maximally-untrusted
> > > containers, and I think bpf() should work in that context.
> >
> > agree that containers (namespaces) reduce amount of trust necessary
> > for apps to run, but the end goal is not security though.
> > Linux has become a single user system.
> > If user can ssh into the host they can become root.
> > If arbitrary code can run on the host it will be break out of any sandbox.
>
> I would argue that this is a reasonable assumption to make if you're
> designing a system using Linux, but it's not a valid assumption to
> make as kernel developers. Otherwise we should just give everyone
> CAP_SYS_ADMIN and call it a day. There really is a difference between
> root and non-root.
hmm. No. Kernel developers should not make any assumptions.
They should guide their design by real use cases instead. That includes studing
what people do now and hacks they use to workaround lack of interfaces.
Effecitvely bpf is root only. There are no unpriv users.
This root applications go out of their way to reduce privileges
while they still want to use bpf. That is the need that /dev/bpf is solving.
>
> > Containers are not providing the level of security that is enough
> > to run arbitrary code. VMs can do it better, but cpu bugs don't make it easy.
> > Containers are used to make production systems safer.
> > Some people call it more 'secure', but it's clearly not secure for
> > arbitrary code and that is what kernel.unprivileged_bpf_disabled allows.
> > When we say 'unprivileged bpf' we really mean arbitrary malicious bpf program.
> > It's been a constant source of pain. The constant blinding, randomization,
> > verifier speculative analysis, all spectre v1, v2, v4 mitigations
> > are simply not worth it. It's a lot of complex kernel code without users.
>
> Seccomp really will want eBPF some day, and it should work without
> privilege. Maybe it should be a restricted subset of eBPF, and
> Spectre will always be an issue until dramatically better hardware
> shows up, but I think people will want the ability for regular
> programs to load eBPF seccomp programs.
I'm absolutely against using eBPF in seccomp.
Precisely due to discussions like the current one.
>
> > Hence I prefer this /dev/bpf mechanism to be as simple a possible.
> > The applications that will use it are going to be just as trusted as systemd.
>
> I still don't understand your systemd example. systemd --users is not
> trusted systemwide in any respect. The main PID 1 systemd is root.
> No matter how you dice it, granting a user systemd instance extra bpf
> access is tantamount to granting the user extra bpf access in general.
People use systemd --user while their kernel have 'undef CONFIG_USER_NS'.
> It sounds to me like you're thinking of eBPF as a feature a bit like
> unprivileged user namespaces: *in principle*, it's supposed to be safe
> to give any unprivileged process the ability to use it, and you
> consider security flaws in it to be bugs worth fixing. But you think
> it's a large attack surface and that most unprivileged programs
> shouldn't be allowed to use it. Is that reasonable?
I think there should be no unprivileged bpf at all,
because over all these years we've seen zero use cases.
Hence all new features are root only.
LPM map is a prime example. There was not a single security bug in there.
There were few functional bugs, but not security issues.
These bugs didn't crash the kernel and didn't expose any data.
Yet we still keep LPM as root only.
Can we flip the switch and make it non-root? It's trivial single line patch ?
and security risk is very low?
Nope, since it will not address the underlying issue.
^ permalink raw reply
* Re: [PATCH bpf-next V9 1/3] bpf: new helper to obtain namespace data from current task
From: Carlos Antonio Neira Bustos @ 2019-08-14 0:56 UTC (permalink / raw)
To: Yonghong Song
Cc: netdev@vger.kernel.org, ebiederm@xmission.com, brouer@redhat.com,
bpf@vger.kernel.org
In-Reply-To: <13b7f81f-83b6-07c9-4864-b49749cbf7d9@fb.com>
On Tue, Aug 13, 2019 at 11:11:14PM +0000, Yonghong Song wrote:
>
>
> On 8/13/19 11:47 AM, Carlos Neira wrote:
> > From: Carlos <cneirabustos@gmail.com>
> >
> > New bpf helper bpf_get_current_pidns_info.
> > This helper obtains the active namespace from current and returns
> > pid, tgid, device and namespace id as seen from that namespace,
> > allowing to instrument a process inside a container.
> >
> > Signed-off-by: Carlos Neira <cneirabustos@gmail.com>
> > ---
> > fs/internal.h | 2 --
> > fs/namei.c | 1 -
> > include/linux/bpf.h | 1 +
> > include/linux/namei.h | 4 +++
> > include/uapi/linux/bpf.h | 31 ++++++++++++++++++++++-
> > kernel/bpf/core.c | 1 +
> > kernel/bpf/helpers.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++
> > kernel/trace/bpf_trace.c | 2 ++
> > 8 files changed, 102 insertions(+), 4 deletions(-)
> >
> > diff --git a/fs/internal.h b/fs/internal.h
> > index 315fcd8d237c..6647e15dd419 100644
> > --- a/fs/internal.h
> > +++ b/fs/internal.h
> > @@ -59,8 +59,6 @@ extern int finish_clean_context(struct fs_context *fc);
> > /*
> > * namei.c
> > */
> > -extern int filename_lookup(int dfd, struct filename *name, unsigned flags,
> > - struct path *path, struct path *root);
> > extern int user_path_mountpoint_at(int, const char __user *, unsigned int, struct path *);
> > extern int vfs_path_lookup(struct dentry *, struct vfsmount *,
> > const char *, unsigned int, struct path *);
> > diff --git a/fs/namei.c b/fs/namei.c
> > index 209c51a5226c..a89fc72a4a10 100644
> > --- a/fs/namei.c
> > +++ b/fs/namei.c
> > @@ -19,7 +19,6 @@
> > #include <linux/export.h>
> > #include <linux/kernel.h>
> > #include <linux/slab.h>
> > -#include <linux/fs.h>
> > #include <linux/namei.h>
> > #include <linux/pagemap.h>
> > #include <linux/fsnotify.h>
> > diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> > index f9a506147c8a..e4adf5e05afd 100644
> > --- a/include/linux/bpf.h
> > +++ b/include/linux/bpf.h
> > @@ -1050,6 +1050,7 @@ extern const struct bpf_func_proto bpf_get_local_storage_proto;
> > extern const struct bpf_func_proto bpf_strtol_proto;
> > extern const struct bpf_func_proto bpf_strtoul_proto;
> > extern const struct bpf_func_proto bpf_tcp_sock_proto;
> > +extern const struct bpf_func_proto bpf_get_current_pidns_info_proto;
> >
> > /* Shared helpers among cBPF and eBPF. */
> > void bpf_user_rnd_init_once(void);
> > diff --git a/include/linux/namei.h b/include/linux/namei.h
> > index 9138b4471dbf..b45c8b6f7cb4 100644
> > --- a/include/linux/namei.h
> > +++ b/include/linux/namei.h
> > @@ -6,6 +6,7 @@
> > #include <linux/path.h>
> > #include <linux/fcntl.h>
> > #include <linux/errno.h>
> > +#include <linux/fs.h>
> >
> > enum { MAX_NESTED_LINKS = 8 };
> >
> > @@ -97,6 +98,9 @@ extern void unlock_rename(struct dentry *, struct dentry *);
> >
> > extern void nd_jump_link(struct path *path);
> >
> > +extern int filename_lookup(int dfd, struct filename *name, unsigned flags,
> > + struct path *path, struct path *root);
> > +
> > static inline void nd_terminate_link(void *name, size_t len, size_t maxlen)
> > {
> > ((char *) name)[min(len, maxlen)] = '\0';
> > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > index 4393bd4b2419..db241857ec15 100644
> > --- a/include/uapi/linux/bpf.h
> > +++ b/include/uapi/linux/bpf.h
> > @@ -2741,6 +2741,28 @@ union bpf_attr {
> > * **-EOPNOTSUPP** kernel configuration does not enable SYN cookies
> > *
> > * **-EPROTONOSUPPORT** IP packet version is not 4 or 6
> > + *
> > + * int bpf_get_current_pidns_info(struct bpf_pidns_info *pidns, u32 size_of_pidns)
> > + * Description
> > + * Copies into *pidns* pid, namespace id and tgid as seen by the
> > + * current namespace and also device from /proc/self/ns/pid.
> > + * *size_of_pidns* must be the size of *pidns*
> > + *
> > + * This helper is used when pid filtering is needed inside a
> > + * container as bpf_get_current_tgid() helper returns always the
> > + * pid id as seen by the root namespace.
> > + * Return
> > + * 0 on success
> > + *
> > + * **-EINVAL** if *size_of_pidns* is not valid or unable to get ns, pid
> > + * or tgid of the current task.
> > + *
> > + * **-ECHILD** if /proc/self/ns/pid does not exists.
> > + *
> > + * **-ENOTDIR** if /proc/self/ns does not exists.
> > + *
> > + * **-ENOMEM** if allocation fails.
> > + *
> > */
> > #define __BPF_FUNC_MAPPER(FN) \
> > FN(unspec), \
> > @@ -2853,7 +2875,8 @@ union bpf_attr {
> > FN(sk_storage_get), \
> > FN(sk_storage_delete), \
> > FN(send_signal), \
> > - FN(tcp_gen_syncookie),
> > + FN(tcp_gen_syncookie), \
> > + FN(get_current_pidns_info),
> >
> > /* integer value in 'imm' field of BPF_CALL instruction selects which helper
> > * function eBPF program intends to call
> > @@ -3604,4 +3627,10 @@ struct bpf_sockopt {
> > __s32 retval;
> > };
> >
> > +struct bpf_pidns_info {
> > + __u32 dev;
> > + __u32 nsid;
> > + __u32 tgid;
> > + __u32 pid;
> > +};
> > #endif /* _UAPI__LINUX_BPF_H__ */
> > diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> > index 8191a7db2777..3159f2a0188c 100644
> > --- a/kernel/bpf/core.c
> > +++ b/kernel/bpf/core.c
> > @@ -2038,6 +2038,7 @@ const struct bpf_func_proto bpf_get_current_uid_gid_proto __weak;
> > const struct bpf_func_proto bpf_get_current_comm_proto __weak;
> > const struct bpf_func_proto bpf_get_current_cgroup_id_proto __weak;
> > const struct bpf_func_proto bpf_get_local_storage_proto __weak;
> > +const struct bpf_func_proto bpf_get_current_pidns_info __weak;
> >
> > const struct bpf_func_proto * __weak bpf_get_trace_printk_proto(void)
> > {
> > diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> > index 5e28718928ca..41fbf1f28a48 100644
> > --- a/kernel/bpf/helpers.c
> > +++ b/kernel/bpf/helpers.c
> > @@ -11,6 +11,12 @@
> > #include <linux/uidgid.h>
> > #include <linux/filter.h>
> > #include <linux/ctype.h>
> > +#include <linux/pid_namespace.h>
> > +#include <linux/major.h>
> > +#include <linux/stat.h>
> > +#include <linux/namei.h>
> > +#include <linux/version.h>
> > +
> >
> > #include "../../lib/kstrtox.h"
> >
> > @@ -312,6 +318,64 @@ void copy_map_value_locked(struct bpf_map *map, void *dst, void *src,
> > preempt_enable();
> > }
> >
> > +BPF_CALL_2(bpf_get_current_pidns_info, struct bpf_pidns_info *, pidns_info, u32,
> > + size)
> > +{
> > + const char *pidns_path = "/proc/self/ns/pid";
> > + struct pid_namespace *pidns = NULL;
> > + struct filename *tmp = NULL;
> > + struct inode *inode;
> > + struct path kp;
> > + pid_t tgid = 0;
> > + pid_t pid = 0;
> > + int ret;
> > + int len;
>
Thank you very much for catching this!.
Could you share how to replicate this bug?.
> I am running your sample program and get the following kernel bug:
>
> ...
> [ 26.414825] BUG: sleeping function called from invalid context at
> /data/users/yhs/work/net-next/fs
> /dcache.c:843
> [ 26.416314] in_atomic(): 1, irqs_disabled(): 0, pid: 1911, name: ping
> [ 26.417189] CPU: 0 PID: 1911 Comm: ping Tainted: G W
> 5.3.0-rc1+ #280
> [ 26.418182] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS 1.9.3-1.el7.centos 04/01/2
> 014
> [ 26.419393] Call Trace:
> [ 26.419697] <IRQ>
> [ 26.419960] dump_stack+0x46/0x5b
> [ 26.420434] ___might_sleep+0xe4/0x110
> [ 26.420894] dput+0x2a/0x200
> [ 26.421265] walk_component+0x10c/0x280
> [ 26.421773] link_path_walk+0x327/0x560
> [ 26.422280] ? proc_ns_dir_readdir+0x1a0/0x1a0
> [ 26.422848] ? path_init+0x232/0x330
> [ 26.423364] path_lookupat+0x88/0x200
> [ 26.423808] ? selinux_parse_skb.constprop.69+0x124/0x430
> [ 26.424521] filename_lookup+0xaf/0x190
> [ 26.425031] ? simple_attr_release+0x20/0x20
> [ 26.425560] bpf_get_current_pidns_info+0xfa/0x190
> [ 26.426168] bpf_prog_83627154cefed596+0xe66/0x1000
> [ 26.426779] trace_call_bpf+0xb5/0x160
> [ 26.427317] ? __netif_receive_skb_core+0x1/0xbb0
> [ 26.427929] ? __netif_receive_skb_core+0x1/0xbb0
> [ 26.428496] kprobe_perf_func+0x4d/0x280
> [ 26.428986] ? tracing_record_taskinfo_skip+0x1a/0x30
> [ 26.429584] ? tracing_record_taskinfo+0xe/0x80
> [ 26.430152] ? ttwu_do_wakeup.isra.114+0xcf/0xf0
> [ 26.430737] ? __netif_receive_skb_core+0x1/0xbb0
> [ 26.431334] ? __netif_receive_skb_core+0x5/0xbb0
> [ 26.431930] kprobe_ftrace_handler+0x90/0xf0
> [ 26.432495] ftrace_ops_assist_func+0x63/0x100
> [ 26.433060] 0xffffffffc03180bf
> [ 26.433471] ? __netif_receive_skb_core+0x1/0xbb0
> ...
>
> To prevent we are running in arbitrary task (e.g., idle task)
> context which may introduce sleeping issues, the following
> probably appropriate:
>
> if (in_nmi() || in_softirq())
> return -EPERM;
>
> Anyway, if in nmi or softirq, the namespace and pid/tgid
> we get may be just accidentally associated with the bpf running
> context, but it could be in a different context. So such info
> is not reliable any way.
>
> > +
> > + if (unlikely(size != sizeof(struct bpf_pidns_info)))
> > + return -EINVAL;
> > + pidns = task_active_pid_ns(current);
> > + if (unlikely(!pidns))
> > + goto clear;
> > + pidns_info->nsid = pidns->ns.inum;
> > + pid = task_pid_nr_ns(current, pidns);
> > + if (unlikely(!pid))
> > + goto clear;
> > + tgid = task_tgid_nr_ns(current, pidns);
> > + if (unlikely(!tgid))
> > + goto clear;
> > + pidns_info->tgid = (u32) tgid;
> > + pidns_info->pid = (u32) pid;
> > + tmp = kmem_cache_alloc(names_cachep, GFP_ATOMIC);
> > + if (unlikely(!tmp)) {
> > + memset((void *)pidns_info, 0, (size_t) size);
> > + return -ENOMEM;
> > + }
> > + len = strlen(pidns_path) + 1;
> > + memcpy((char *)tmp->name, pidns_path, len);
> > + tmp->uptr = NULL;
> > + tmp->aname = NULL;
> > + tmp->refcnt = 1;
> > + ret = filename_lookup(AT_FDCWD, tmp, 0, &kp, NULL);
> > + if (ret) {
> > + memset((void *)pidns_info, 0, (size_t) size);
> > + return ret;
> > + }
> > + inode = d_backing_inode(kp.dentry);
> > + pidns_info->dev = inode->i_sb->s_dev;
> > + return 0;
> > +clear:
> > + memset((void *)pidns_info, 0, (size_t) size);
> > + return -EINVAL;
> > +}
> > +
> > +const struct bpf_func_proto bpf_get_current_pidns_info_proto = {
> > + .func = bpf_get_current_pidns_info,
> > + .gpl_only = false,
> > + .ret_type = RET_INTEGER,
> > + .arg1_type = ARG_PTR_TO_UNINIT_MEM,
> > + .arg2_type = ARG_CONST_SIZE,
> > +};
> > +
> > #ifdef CONFIG_CGROUPS
> > BPF_CALL_0(bpf_get_current_cgroup_id)
> > {
> > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> > index ca1255d14576..5e1dc22765a5 100644
> > --- a/kernel/trace/bpf_trace.c
> > +++ b/kernel/trace/bpf_trace.c
> > @@ -709,6 +709,8 @@ tracing_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
> > #endif
> > case BPF_FUNC_send_signal:
> > return &bpf_send_signal_proto;
> > + case BPF_FUNC_get_current_pidns_info:
> > + return &bpf_get_current_pidns_info_proto;
> > default:
> > return NULL;
> > }
> >
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: PHY LIBRARY: Remove sysfs-bus-mdio record
From: Florian Fainelli @ 2019-08-14 0:55 UTC (permalink / raw)
To: Denis Efremov, linux-kernel
Cc: joe, David S . Miller, Andrew Lunn, Heiner Kallweit, netdev
In-Reply-To: <20190813061439.17529-1-efremov@linux.com>
Le 8/12/19 à 11:14 PM, Denis Efremov a écrit :
> Update MAINTAINERS to reflect that sysfs-bus-mdio documentation
> was removed.
>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Heiner Kallweit <hkallweit1@gmail.com>
> Cc: netdev@vger.kernel.org
> Fixes: a6cd0d2d493a ("Documentation: net-sysfs: Remove duplicate PHY device documentation")
> Signed-off-by: Denis Efremov <efremov@linux.com>
Not sure if this really deserves a Fixes tag; but thanks for catching
that, a maybe more appropriate change would be to list
Documentation/ABI/testing/sysfs-class-net-phydev instead.
--
Florian
^ permalink raw reply
* Re: [PATCH bpf-next] libbpf: make libbpf.map source of truth for libbpf version
From: Jakub Kicinski @ 2019-08-14 0:51 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: bpf, netdev, ast, daniel, andrii.nakryiko, kernel-team,
Andrey Ignatov
In-Reply-To: <20190813232408.1246694-1-andriin@fb.com>
On Tue, 13 Aug 2019 16:24:08 -0700, Andrii Nakryiko wrote:
> diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
> index 9312066a1ae3..d9afc8509725 100644
> --- a/tools/lib/bpf/Makefile
> +++ b/tools/lib/bpf/Makefile
> @@ -1,9 +1,10 @@
> # SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause)
> # Most of this file is copied from tools/lib/traceevent/Makefile
>
> -BPF_VERSION = 0
> -BPF_PATCHLEVEL = 0
> -BPF_EXTRAVERSION = 4
> +BPF_FULL_VERSION = $(shell \
> + grep -E 'LIBBPF_([0-9]+)\.([0-9]+)\.([0-9]+) \{' libbpf.map | \
> + tail -n1 | cut -d'_' -f2 | cut -d' ' -f1)
> +BPF_VERSION = $(firstword $(subst ., ,$(BPF_FULL_VERSION)))
>
> MAKEFLAGS += --no-print-directory
>
> @@ -79,15 +80,12 @@ export prefix libdir src obj
> libdir_SQ = $(subst ','\'',$(libdir))
> libdir_relative_SQ = $(subst ','\'',$(libdir_relative))
>
> +LIBBPF_VERSION = $(BPF_FULL_VERSION)
Perhaps better use immediate set here ':='?
I'm not sure how many times this gets evaluated, but it shouldn't
really change either..
> VERSION = $(BPF_VERSION)
> -PATCHLEVEL = $(BPF_PATCHLEVEL)
> -EXTRAVERSION = $(BPF_EXTRAVERSION)
>
> OBJ = $@
> N =
>
> -LIBBPF_VERSION = $(BPF_VERSION).$(BPF_PATCHLEVEL).$(BPF_EXTRAVERSION)
> -
> LIB_TARGET = libbpf.a libbpf.so.$(LIBBPF_VERSION)
> LIB_FILE = libbpf.a libbpf.so*
> PC_FILE = libbpf.pc
^ permalink raw reply
* Re: [PATCH bpf-next 1/3] libbpf: add asm/unistd.h to xsk to get __NR_mmap2
From: Yonghong Song @ 2019-08-14 0:32 UTC (permalink / raw)
To: Ivan Khoronzhuk, magnus.karlsson@intel.com, bjorn.topel@intel.com
Cc: davem@davemloft.net, hawk@kernel.org, john.fastabend@gmail.com,
jakub.kicinski@netronome.com, daniel@iogearbox.net,
netdev@vger.kernel.org, bpf@vger.kernel.org,
xdp-newbies@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20190813102318.5521-2-ivan.khoronzhuk@linaro.org>
On 8/13/19 3:23 AM, Ivan Khoronzhuk wrote:
> That's needed to get __NR_mmap2 when mmap2 syscall is used.
It seems I did not have this issue on x64 machine e.g., Fedora 29.
My glibc version is 2.28. gcc 8.2.1.
What is your particular system glibc version?
So needing kernel asm/unistd.h is because of older glibc on your
system, or something else? Could you clarify?
>
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
> ---
> tools/lib/bpf/xsk.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tools/lib/bpf/xsk.c b/tools/lib/bpf/xsk.c
> index 5007b5d4fd2c..f2fc40f9804c 100644
> --- a/tools/lib/bpf/xsk.c
> +++ b/tools/lib/bpf/xsk.c
> @@ -12,6 +12,7 @@
> #include <stdlib.h>
> #include <string.h>
> #include <unistd.h>
> +#include <asm/unistd.h>
> #include <arpa/inet.h>
> #include <asm/barrier.h>
> #include <linux/compiler.h>
>
^ permalink raw reply
* Re: [PATCH bpf-next] libbpf: make libbpf.map source of truth for libbpf version
From: Andrey Ignatov @ 2019-08-14 0:28 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org, Alexei Starovoitov,
daniel@iogearbox.net, andrii.nakryiko@gmail.com, Kernel Team
In-Reply-To: <20190813232408.1246694-1-andriin@fb.com>
Andrii Nakryiko <andriin@fb.com> [Tue, 2019-08-13 16:24 -0700]:
> Currently libbpf version is specified in 2 places: libbpf.map and
> Makefile. They easily get out of sync and it's very easy to update one,
> but forget to update another one. In addition, Github projection of
> libbpf has to maintain its own version which has to be remembered to be
> kept in sync manually, which is very error-prone approach.
>
> This patch makes libbpf.map a source of truth for libbpf version and
> uses shell invocation to parse out correct full and major libbpf version
> to use during build. Now we need to make sure that once new release
> cycle starts, we need to add (initially) empty section to libbpf.map
> with correct latest version.
>
> This also will make it possible to keep Github projection consistent
> with kernel sources version of libbpf by adopting similar parsing of
> version from libbpf.map.
Thanks for taking care of this!
> Cc: Andrey Ignatov <rdna@fb.com>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> ---
> tools/lib/bpf/Makefile | 12 +++++-------
> tools/lib/bpf/libbpf.map | 3 +++
> 2 files changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
> index 9312066a1ae3..d9afc8509725 100644
> --- a/tools/lib/bpf/Makefile
> +++ b/tools/lib/bpf/Makefile
> @@ -1,9 +1,10 @@
> # SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause)
> # Most of this file is copied from tools/lib/traceevent/Makefile
>
> -BPF_VERSION = 0
> -BPF_PATCHLEVEL = 0
> -BPF_EXTRAVERSION = 4
> +BPF_FULL_VERSION = $(shell \
Nit: Should it be LIBBPF_VERSION? IMO it's more descriptive name.
> + grep -E 'LIBBPF_([0-9]+)\.([0-9]+)\.([0-9]+) \{' libbpf.map | \
> + tail -n1 | cut -d'_' -f2 | cut -d' ' -f1)
It can be done simpler and IMO versions should be sorted before taking
the last one (just in case), something like:
grep -oE '^LIBBPF_[0-9.]+' libbpf.map | cut -d_ -f 2 | sort -nr | head -n 1
> +BPF_VERSION = $(firstword $(subst ., ,$(BPF_FULL_VERSION)))
>
> MAKEFLAGS += --no-print-directory
>
> @@ -79,15 +80,12 @@ export prefix libdir src obj
> libdir_SQ = $(subst ','\'',$(libdir))
> libdir_relative_SQ = $(subst ','\'',$(libdir_relative))
>
> +LIBBPF_VERSION = $(BPF_FULL_VERSION)
> VERSION = $(BPF_VERSION)
> -PATCHLEVEL = $(BPF_PATCHLEVEL)
> -EXTRAVERSION = $(BPF_EXTRAVERSION)
>
> OBJ = $@
> N =
>
> -LIBBPF_VERSION = $(BPF_VERSION).$(BPF_PATCHLEVEL).$(BPF_EXTRAVERSION)
> -
> LIB_TARGET = libbpf.a libbpf.so.$(LIBBPF_VERSION)
> LIB_FILE = libbpf.a libbpf.so*
> PC_FILE = libbpf.pc
> diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
> index f9d316e873d8..4e72df8e98ba 100644
> --- a/tools/lib/bpf/libbpf.map
> +++ b/tools/lib/bpf/libbpf.map
> @@ -184,3 +184,6 @@ LIBBPF_0.0.4 {
> perf_buffer__new_raw;
> perf_buffer__poll;
> } LIBBPF_0.0.3;
> +
> +LIBBPF_0.0.5 {
> +} LIBBPF_0.0.4;
I'm not sure version should be bumped in this patch since this patch is
about keeping the version in one place, not about bumping it, right?
> --
> 2.17.1
>
--
Andrey Ignatov
^ permalink raw reply
* Re: [PATCH net-next] net/ncsi: allow to customize BMC MAC Address offset
From: Terry Duncan @ 2019-08-14 0:22 UTC (permalink / raw)
To: Tao Ren
Cc: Andrew Lunn, Jakub Kicinski, netdev@vger.kernel.org,
openbmc@lists.ozlabs.org, Ben Wei, linux-kernel@vger.kernel.org,
Samuel Mendoza-Jonas, David S.Miller, William Kennington
In-Reply-To: <33e3e783-fb93-e628-8baa-a8374540ea25@linux.intel.com>
On 8/13/19 1:54 PM, Terry Duncan wrote:
>
> On 8/13/19 11:28 AM, Tao Ren wrote:
>> On 8/13/19 9:31 AM, Terry Duncan wrote:
>>> Tao, in your new patch will it be possible to disable the setting of
>>> the BMC MAC? I would like to be able to send NCSI_OEM_GET_MAC
>>> perhaps with netlink (TBD) to get the system address without it
>>> affecting the BMC address.
>>>
>>> I was about to send patches to add support for the Intel adapters
>>> when I saw this thread.
>>>
>>> Thanks,
>>>
>>> Terry
>>
>> Hi Terry,
>>
>> Sounds like you are planning to configure BMC MAC address from user
>> space via netlink? Ben Wei <benwei@fb.com> started a thread
>> "Out-of-band NIC management" in openbmc community for NCSI management
>> using netlink, and you may follow up with him for details.
>>
>> I haven't decided what to do in my v2 patch: maybe using device tree,
>> maybe moving the logic to uboot, and I'm also evaluating the netlink
>> option. But it shouldn't impact your patch, because you can disable
>> NCSI_OEM_GET_MAC option from your config file.
>
> Thanks Tao. I see now that disabling the NCSI_OEM_GET_MAC option will do
> what I want.
>
> Best,
> Terry
Hi Tao,
After a second look, it appears that the OEM handlers for Broadcom and
Melanox in ncsi-rsp.c will set the MAC regardless of the origin of the
request. Even with NCSI_OEM_GET_MAC disabled, sending an OEM command
with netlink would result in setting the BMC MAC.
Thanks,
Terry
^ permalink raw reply
* Re: [PATCH net-next v2 0/3] net: phy: let phy_speed_down/up support speeds >1Gbps
From: Jakub Kicinski @ 2019-08-14 0:21 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Andrew Lunn, Florian Fainelli, David Miller,
netdev@vger.kernel.org
In-Reply-To: <dca82a0e-e936-b60a-3a1c-9fdb1714d1d3@gmail.com>
On Mon, 12 Aug 2019 23:47:45 +0200, Heiner Kallweit wrote:
> So far phy_speed_down/up can be used up to 1Gbps only. Remove this
> restriction and add needed helpers to phy-core.c
>
> v2:
> - remove unused parameter in patch 1
> - rename __phy_speed_down to phy_speed_down_core in patch 2
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] sctp: fix memleak in sctp_send_reset_streams
From: Neil Horman @ 2019-08-14 0:10 UTC (permalink / raw)
To: zhengbin; +Cc: vyasevich, marcelo.leitner, davem, linux-sctp, netdev, yi.zhang
In-Reply-To: <1565705150-17242-1-git-send-email-zhengbin13@huawei.com>
On Tue, Aug 13, 2019 at 10:05:50PM +0800, zhengbin wrote:
> If the stream outq is not empty, need to kfree nstr_list.
>
> Fixes: d570a59c5b5f ("sctp: only allow the out stream reset when the stream outq is empty")
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: zhengbin <zhengbin13@huawei.com>
> ---
> net/sctp/stream.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/sctp/stream.c b/net/sctp/stream.c
> index 2594660..e83cdaa 100644
> --- a/net/sctp/stream.c
> +++ b/net/sctp/stream.c
> @@ -316,6 +316,7 @@ int sctp_send_reset_streams(struct sctp_association *asoc,
> nstr_list[i] = htons(str_list[i]);
>
> if (out && !sctp_stream_outq_is_empty(stream, str_nums, nstr_list)) {
> + kfree(nstr_list);
> retval = -EAGAIN;
> goto out;
> }
> --
> 2.7.4
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [PATCH net-next] net: devlink: remove redundant rtnl lock assert
From: Jakub Kicinski @ 2019-08-14 0:01 UTC (permalink / raw)
To: Vlad Buslov; +Cc: netdev, jhs, xiyou.wangcong, jiri, davem, Jiri Pirko
In-Reply-To: <20190812170202.32314-1-vladbu@mellanox.com>
On Mon, 12 Aug 2019 20:02:02 +0300, Vlad Buslov wrote:
> It is enough for caller of devlink_compat_switch_id_get() to hold the net
> device to guarantee that devlink port is not destroyed concurrently. Remove
> rtnl lock assertion and modify comment to warn user that they must hold
> either rtnl lock or reference to net device. This is necessary to
> accommodate future implementation of rtnl-unlocked TC offloads driver
> callbacks.
>
> Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
> Acked-by: Jiri Pirko <jiri@mellanox.com>
Looks good, applied.
^ 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