* [PATCH v3] net: fix skb use after free in netpoll
From: Feng Sun @ 2019-08-26 6:46 UTC (permalink / raw)
To: davem
Cc: edumazet, dsterba, dbanerje, fw, davej, tglx, matwey,
sakari.ailus, netdev, linux-kernel, Feng Sun, Xiaojun Zhao
In-Reply-To: <20190825.232003.1145950065287854577.davem@davemloft.net>
After commit baeababb5b85d5c4e6c917efe2a1504179438d3b
("tun: return NET_XMIT_DROP for dropped packets"),
when tun_net_xmit drop packets, it will free skb and return NET_XMIT_DROP,
netpoll_send_skb_on_dev will run into following use after free cases:
1. retry netpoll_start_xmit with freed skb;
2. queue freed skb in npinfo->txq.
queue_process will also run into use after free case.
hit netpoll_send_skb_on_dev first case with following kernel log:
[ 117.864773] kernel BUG at mm/slub.c:306!
[ 117.864773] invalid opcode: 0000 [#1] SMP PTI
[ 117.864774] CPU: 3 PID: 2627 Comm: loop_printmsg Kdump: loaded Tainted: P OE 5.3.0-050300rc5-generic #201908182231
[ 117.864775] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
[ 117.864775] RIP: 0010:kmem_cache_free+0x28d/0x2b0
[ 117.864781] Call Trace:
[ 117.864781] ? tun_net_xmit+0x21c/0x460
[ 117.864781] kfree_skbmem+0x4e/0x60
[ 117.864782] kfree_skb+0x3a/0xa0
[ 117.864782] tun_net_xmit+0x21c/0x460
[ 117.864782] netpoll_start_xmit+0x11d/0x1b0
[ 117.864788] netpoll_send_skb_on_dev+0x1b8/0x200
[ 117.864789] __br_forward+0x1b9/0x1e0 [bridge]
[ 117.864789] ? skb_clone+0x53/0xd0
[ 117.864790] ? __skb_clone+0x2e/0x120
[ 117.864790] deliver_clone+0x37/0x50 [bridge]
[ 117.864790] maybe_deliver+0x89/0xc0 [bridge]
[ 117.864791] br_flood+0x6c/0x130 [bridge]
[ 117.864791] br_dev_xmit+0x315/0x3c0 [bridge]
[ 117.864792] netpoll_start_xmit+0x11d/0x1b0
[ 117.864792] netpoll_send_skb_on_dev+0x1b8/0x200
[ 117.864792] netpoll_send_udp+0x2c6/0x3e8
[ 117.864793] write_msg+0xd9/0xf0 [netconsole]
[ 117.864793] console_unlock+0x386/0x4e0
[ 117.864793] vprintk_emit+0x17e/0x280
[ 117.864794] vprintk_default+0x29/0x50
[ 117.864794] vprintk_func+0x4c/0xbc
[ 117.864794] printk+0x58/0x6f
[ 117.864795] loop_fun+0x24/0x41 [printmsg_loop]
[ 117.864795] kthread+0x104/0x140
[ 117.864795] ? 0xffffffffc05b1000
[ 117.864796] ? kthread_park+0x80/0x80
[ 117.864796] ret_from_fork+0x35/0x40
Signed-off-by: Feng Sun <loyou85@gmail.com>
Signed-off-by: Xiaojun Zhao <xiaojunzhao141@gmail.com>
---
Changes in v3:
- use dev_xmit_complete directly
Changes in v2:
- change commit and title
- add netpoll_xmit_complete helper
- add one more return value check of netpoll_start_xmit
---
net/core/netpoll.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 2cf27da..849380a6 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -122,7 +122,7 @@ static void queue_process(struct work_struct *work)
txq = netdev_get_tx_queue(dev, q_index);
HARD_TX_LOCK(dev, txq, smp_processor_id());
if (netif_xmit_frozen_or_stopped(txq) ||
- netpoll_start_xmit(skb, dev, txq) != NETDEV_TX_OK) {
+ !dev_xmit_complete(netpoll_start_xmit(skb, dev, txq))) {
skb_queue_head(&npinfo->txq, skb);
HARD_TX_UNLOCK(dev, txq);
local_irq_restore(flags);
@@ -335,7 +335,7 @@ void netpoll_send_skb_on_dev(struct netpoll *np, struct sk_buff *skb,
HARD_TX_UNLOCK(dev, txq);
- if (status == NETDEV_TX_OK)
+ if (dev_xmit_complete(status))
break;
}
@@ -352,7 +352,7 @@ void netpoll_send_skb_on_dev(struct netpoll *np, struct sk_buff *skb,
}
- if (status != NETDEV_TX_OK) {
+ if (!dev_xmit_complete(status)) {
skb_queue_tail(&npinfo->txq, skb);
schedule_delayed_work(&npinfo->tx_work,0);
}
--
2.7.4
^ permalink raw reply related
* Re: libbpf distro packaging
From: Jiri Olsa @ 2019-08-26 6:42 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Julia Kartseva, Andrii Nakryiko, labbott@redhat.com,
acme@kernel.org, debian-kernel@lists.debian.org,
netdev@vger.kernel.org, Andrey Ignatov, Yonghong Song,
jolsa@kernel.org, Daniel Borkmann
In-Reply-To: <a00bab9b-dae8-23d8-8de0-3751a1d1b023@fb.com>
On Fri, Aug 23, 2019 at 04:00:01PM +0000, Alexei Starovoitov wrote:
> On 8/23/19 2:22 AM, Jiri Olsa wrote:
> > btw, the libbpf GH repo tag v0.0.4 has 0.0.3 version set in Makefile:
> >
> > VERSION = 0
> > PATCHLEVEL = 0
> > EXTRAVERSION = 3
> >
> > current code takes version from libbpf.map so it's fine,
> > but would be great to start from 0.0.5 so we don't need to
> > bother with rpm patches.. is 0.0.5 planned soon?
>
> Technically we can bump it at any time.
> The goal was to bump it only when new kernel is released
> to capture a collection of new APIs in a given 0.0.X release.
> So that libbpf versions are synchronized with kernel versions
> in some what loose way.
> In this case we can make an exception and bump it now.
I see, I dont think it's worth of the exception now,
the patch is simple or we'll start with 0.0.3
jirka
^ permalink raw reply
* Re: Unable to create htb tc classes more than 64K
From: Eric Dumazet @ 2019-08-26 6:32 UTC (permalink / raw)
To: Cong Wang, Akshat Kakkar; +Cc: Anton Danilov, NetFilter, lartc, netdev
In-Reply-To: <CAM_iQpVtGUH6CAAegRtTgyemLtHsO+RFP8f6LH2WtiYu9-srfw@mail.gmail.com>
On 8/25/19 7:52 PM, Cong Wang wrote:
> On Wed, Aug 21, 2019 at 11:00 PM Akshat Kakkar <akshat.1984@gmail.com> wrote:
>>
>> On Thu, Aug 22, 2019 at 3:37 AM Cong Wang <xiyou.wangcong@gmail.com> wrote:
>>>> I am using ipset + iptables to classify and not filters. Besides, if
>>>> tc is allowing me to define qdisc -> classes -> qdsic -> classes
>>>> (1,2,3 ...) sort of structure (ie like the one shown in ascii tree)
>>>> then how can those lowest child classes be actually used or consumed?
>>>
>>> Just install tc filters on the lower level too.
>>
>> If I understand correctly, you are saying,
>> instead of :
>> tc filter add dev eno2 parent 100: protocol ip prio 1 handle
>> 0x00000001 fw flowid 1:10
>> tc filter add dev eno2 parent 100: protocol ip prio 1 handle
>> 0x00000002 fw flowid 1:20
>> tc filter add dev eno2 parent 100: protocol ip prio 1 handle
>> 0x00000003 fw flowid 2:10
>> tc filter add dev eno2 parent 100: protocol ip prio 1 handle
>> 0x00000004 fw flowid 2:20
>>
>>
>> I should do this: (i.e. changing parent to just immediate qdisc)
>> tc filter add dev eno2 parent 1: protocol ip prio 1 handle 0x00000001
>> fw flowid 1:10
>> tc filter add dev eno2 parent 1: protocol ip prio 1 handle 0x00000002
>> fw flowid 1:20
>> tc filter add dev eno2 parent 2: protocol ip prio 1 handle 0x00000003
>> fw flowid 2:10
>> tc filter add dev eno2 parent 2: protocol ip prio 1 handle 0x00000004
>> fw flowid 2:20
>
>
> Yes, this is what I meant.
>
>
>>
>> I tried this previously. But there is not change in the result.
>> Behaviour is exactly same, i.e. I am still getting 100Mbps and not
>> 100kbps or 300kbps
>>
>> Besides, as I mentioned previously I am using ipset + skbprio and not
>> filters stuff. Filters I used just to test.
>>
>> ipset -N foo hash:ip,mark skbinfo
>>
>> ipset -A foo 10.10.10.10, 0x0x00000001 skbprio 1:10
>> ipset -A foo 10.10.10.20, 0x0x00000002 skbprio 1:20
>> ipset -A foo 10.10.10.30, 0x0x00000003 skbprio 2:10
>> ipset -A foo 10.10.10.40, 0x0x00000004 skbprio 2:20
>>
>> iptables -A POSTROUTING -j SET --map-set foo dst,dst --map-prio
>
> Hmm..
>
> I am not familiar with ipset, but it seems to save the skbprio into
> skb->priority, so it doesn't need TC filter to classify it again.
>
> I guess your packets might go to the direct queue of HTB, which
> bypasses the token bucket. Can you dump the stats and check?
With more than 64K 'classes' I suggest to use a single FQ qdisc [1], and
an eBPF program using EDT model (Earliest Departure Time)
The BPF program would perform the classification, then find a data structure
based on the 'class', and then update/maintain class virtual times and skb->tstamp
TBF = bpf_map_lookup_elem(&map, &classid);
uint64_t now = bpf_ktime_get_ns();
uint64_t time_to_send = max(TBF->time_to_send, now);
time_to_send += (u64)qdisc_pkt_len(skb) * NSEC_PER_SEC / TBF->rate;
if (time_to_send > TBF->max_horizon) {
return TC_ACT_SHOT;
}
TBF->time_to_send = time_to_send;
skb->tstamp = max(time_to_send, skb->tstamp);
if (time_to_send - now > TBF->ecn_horizon)
bpf_skb_ecn_set_ce(skb);
return TC_ACT_OK;
tools/testing/selftests/bpf/progs/test_tc_edt.c shows something similar.
[1] MQ + FQ if the device is multi-queues.
Note that this setup scales very well on SMP, since we no longer are forced
to use a single HTB hierarchy (protected by a single spinlock)
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2019-08-26 6:29 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Use 32-bit index for tails calls in s390 bpf JIT, from Ilya Leoshkevich.
2) Fix missed EPOLLOUT events in TCP, from Eric Dumazet. Same fix for SMC
from Jason Baron.
3) ipv6_mc_may_pull() should return 0 for malformed packets, not -EINVAL.
From Stefano Brivio.
4) Don't forget to unpin umem xdp pages in error path of
xdp_umem_reg(). From Ivan Khoronzhuk.
5) Fix sta object leak in mac80211, from Johannes Berg.
6) Fix regression by not configuring PHYLINK on CPU port of bcm_sf2
switches. From Florian Fainelli.
7) Revert DMA sync removal from r8169 which was causing regressions on some
MIPS Loongson platforms. From Heiner Kallweit.
8) Use after free in flow dissector, from Jakub Sitnicki.
9) Fix NULL derefs of net devices during ICMP processing across collect_md
tunnels, from Hangbin Liu.
10) proto_register() memory leaks, from Zhang Lin.
11) Set NLM_F_MULTI flag in multipart netlink messages consistently, from
John Fastabend.
Please pull, thanks a lot!
The following changes since commit 06821504fd47a5e5b641aeeb638a0ae10a216ef8:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net (2019-08-19 10:00:01 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
for you to fetch changes up to f53a7ad189594a112167efaf17ea8d0242b5ac00:
r8152: Set memory to all 0xFFs on failed reg reads (2019-08-25 19:52:59 -0700)
----------------------------------------------------------------
Alexander Wetzel (1):
cfg80211: Fix Extended Key ID key install checks
Alexei Starovoitov (1):
bpf: fix precision tracking in presence of bpf2bpf calls
Alexey Kodanev (1):
ipv4: mpls: fix mpls_xmit for iptunnel
Anders Roxell (2):
selftests/bpf: add config fragment BPF_JIT
selftests/bpf: install files test_xdp_vlan.sh
Andrew Lunn (1):
MAINTAINERS: Add phylink keyword to SFF/SFP/SFP+ MODULE SUPPORT
Antoine Tenart (1):
net: cpsw: fix NULL pointer exception in the probe error path
Christophe JAILLET (1):
Kconfig: Fix the reference to the IDT77105 Phy driver in the description of ATM_NICSTAR_USE_IDT77105
Colin Ian King (1):
net: ieee802154: remove redundant assignment to rc
Dan Carpenter (1):
gve: Copy and paste bug in gve_get_stats()
Daniel Borkmann (1):
bpf: fix use after free in prog symbol exposure
David Ahern (1):
nexthop: Fix nexthop_num_path for blackhole nexthops
David S. Miller (8):
Merge git://git.kernel.org/.../pablo/nf
Merge tag 'mac80211-for-davem-2019-08-21' of git://git.kernel.org/.../jberg/mac80211
Merge tag 'batadv-net-for-davem-20190821' of git://git.open-mesh.org/linux-merge
Merge tag 'wireless-drivers-for-davem-2019-08-21' of git://git.kernel.org/.../kvalo/wireless-drivers
Merge git://git.kernel.org/.../bpf/bpf
Merge branch 'ieee802154-for-davem-2019-08-24' of git://git.kernel.org/.../sschmidt/wpan
Merge branch 'collect_md-mode-dev-null'
Merge tag 'mlx5-fixes-2019-08-22' of git://git.kernel.org/.../saeed/linux
Denis Efremov (2):
MAINTAINERS: Remove IP MASQUERADING record
MAINTAINERS: net_failover: Fix typo in a filepath
Emmanuel Grumbach (1):
iwlwifi: pcie: fix the byte count table format for 22560 devices
Eran Ben Elisha (2):
net/mlx5e: Add num bytes metadata to WQE info
net/mlx5e: Remove ethernet segment from dump WQE
Eric Dumazet (2):
batman-adv: fix uninit-value in batadv_netlink_get_ifindex()
tcp: make sure EPOLLOUT wont be missed
Florian Fainelli (1):
net: dsa: bcm_sf2: Do not configure PHYLINK on CPU port
Hangbin Liu (3):
ipv6/addrconf: allow adding multicast addr if IFA_F_MCAUTOJOIN is set
ipv4/icmp: fix rt dst dev null pointer dereference
xfrm/xfrm_policy: fix dst dev null pointer dereference in collect_md mode
Heiner Kallweit (1):
Revert "r8169: remove not needed call to dma_sync_single_for_device"
Hodaszi, Robert (1):
Revert "cfg80211: fix processing world regdomain when non modular"
Ilan Peer (1):
iwlwifi: mvm: Allow multicast data frames only when associated
Ilya Leoshkevich (6):
s390/bpf: fix lcgr instruction encoding
s390/bpf: use 32-bit index for tail calls
selftests/bpf: fix "bind{4, 6} deny specific IP & port" on s390
selftests/bpf: fix test_cgroup_storage on s390
selftests/bpf: fix test_btf_dump with O=
bpf: allow narrow loads of some sk_reuseport_md fields with offset > 0
Ivan Khoronzhuk (1):
xdp: unpin xdp umem pages in error path
Jakub Sitnicki (1):
flow_dissector: Fix potential use-after-free on BPF_PROG_DETACH
Jason Baron (1):
net/smc: make sure EPOLLOUT is raised
Johannes Berg (1):
mac80211: fix possible sta leak
John Fastabend (1):
net: route dump netlink NLM_F_MULTI flag missing
Julian Wiedmann (1):
s390/qeth: reject oversized SNMP requests
Juliana Rodrigueiro (1):
netfilter: xt_nfacct: Fix alignment mismatch in xt_nfacct_match_info
Justin.Lee1@Dell.com (1):
net/ncsi: Fix the payload copying for the request coming from Netlink
Li RongQing (2):
net: fix __ip_mc_inc_group usage
net: fix icmp_socket_deliver argument 2 input
Luca Coelho (2):
iwlwifi: pcie: don't switch FW to qnj when ax201 is detected
iwlwifi: pcie: fix recognition of QuZ devices
Masahiro Yamada (1):
netfilter: add include guard to nf_conntrack_h323_types.h
Mike Rapoport (1):
trivial: netns: fix typo in 'struct net.passive' description
Moshe Shemesh (2):
net/mlx5: Fix crdump chunks print
net/mlx5: Fix delay in fw fatal report handling due to fw report
Pablo Neira Ayuso (1):
netfilter: nft_flow_offload: missing netlink attribute policy
Prashant Malani (1):
r8152: Set memory to all 0xFFs on failed reg reads
Quentin Monnet (1):
tools: bpftool: close prog FD before exit on showing a single program
Sabrina Dubroca (1):
ipv6: propagate ipv6_add_dev's error returns out of ipv6_find_idev
Stanislaw Gruszka (2):
mt76: mt76x0u: do not reset radio on resume
rt2x00: clear IV's on start to fix AP mode regression
Stefano Brivio (1):
ipv6: Fix return value of ipv6_mc_may_pull() for malformed packets
Terry S. Duncan (1):
net/ncsi: Ensure 32-bit boundary for data cksum
Todd Seidelmann (1):
netfilter: ebtables: Fix argument order to ADD_COUNTER
Vlad Buslov (1):
nfp: flower: verify that block cb is not busy before binding
Wenwen Wang (1):
qed: Add cleanup in qed_slowpath_start()
Yangbo Lu (1):
ocelot_ace: fix action of trap
Yi-Hung Wei (2):
openvswitch: Fix log message in ovs conntrack
openvswitch: Fix conntrack cache with timeout
YueHaibing (2):
ieee802154: hwsim: Fix error handle path in hwsim_init_module
ieee802154: hwsim: unregister hw while hwsim_subscribe_all_others fails
Zhu Yanjun (1):
net: rds: add service level support in rds-info
zhanglin (1):
sock: fix potential memory leak in proto_register()
MAINTAINERS | 8 ++------
arch/s390/net/bpf_jit_comp.c | 12 +++++++-----
drivers/atm/Kconfig | 2 +-
drivers/net/dsa/bcm_sf2.c | 10 ++++++++--
drivers/net/ethernet/google/gve/gve_main.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_tx.c | 38 +++++++++++++++++---------------------
drivers/net/ethernet/mellanox/mlx5/core/health.c | 22 ++++++++++++----------
drivers/net/ethernet/mscc/ocelot_ace.c | 2 +-
drivers/net/ethernet/netronome/nfp/flower/offload.c | 7 +++++++
drivers/net/ethernet/qlogic/qed/qed_main.c | 4 +++-
drivers/net/ethernet/realtek/r8169_main.c | 1 +
drivers/net/ethernet/ti/cpsw.c | 2 +-
drivers/net/ieee802154/mac802154_hwsim.c | 8 +++++---
drivers/net/usb/r8152.c | 5 ++++-
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 33 ++++++++++++++++++++++++++++++---
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 10 ++++++++++
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 17 +++++++++++++++++
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 1 +
drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c | 20 +++++++++++++-------
drivers/net/wireless/mediatek/mt76/mt76x0/usb.c | 8 ++++----
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 9 +++++++++
drivers/net/wireless/ralink/rt2x00/rt2x00.h | 1 +
drivers/net/wireless/ralink/rt2x00/rt2x00dev.c | 13 ++++++++-----
drivers/s390/net/qeth_core_main.c | 4 ++++
include/linux/netfilter/nf_conntrack_h323_types.h | 5 +++++
include/net/addrconf.h | 2 +-
include/net/net_namespace.h | 2 +-
include/net/nexthop.h | 6 ------
include/net/route.h | 2 +-
include/uapi/linux/netfilter/xt_nfacct.h | 5 +++++
include/uapi/linux/rds.h | 2 ++
kernel/bpf/syscall.c | 30 ++++++++++++++++++------------
kernel/bpf/verifier.c | 9 +++++----
net/batman-adv/netlink.c | 2 +-
net/bridge/netfilter/ebtables.c | 8 ++++----
net/core/filter.c | 8 ++++----
net/core/flow_dissector.c | 2 +-
net/core/sock.c | 31 +++++++++++++++++++++----------
net/core/stream.c | 16 +++++++++-------
net/ieee802154/socket.c | 2 +-
net/ipv4/fib_trie.c | 2 +-
net/ipv4/icmp.c | 10 ++++++++--
net/ipv4/igmp.c | 4 ++--
net/ipv4/route.c | 17 ++++++++++-------
net/ipv6/addrconf.c | 19 ++++++++++---------
net/mac80211/cfg.c | 9 +++++----
net/mpls/mpls_iptunnel.c | 8 ++++----
net/ncsi/ncsi-cmd.c | 13 ++++++++++---
net/ncsi/ncsi-rsp.c | 9 ++++++---
net/netfilter/nft_flow_offload.c | 6 ++++++
net/netfilter/xt_nfacct.c | 36 +++++++++++++++++++++++++-----------
net/openvswitch/conntrack.c | 15 ++++++++++++++-
net/rds/ib.c | 16 ++++++++++------
net/rds/ib.h | 1 +
net/rds/ib_cm.c | 3 +++
net/rds/rdma_transport.c | 10 ++++++++--
net/smc/smc_tx.c | 6 ++----
net/wireless/reg.c | 2 +-
net/wireless/util.c | 23 ++++++++++++++---------
net/xdp/xdp_umem.c | 4 +++-
net/xfrm/xfrm_policy.c | 4 ++--
tools/bpf/bpftool/prog.c | 4 +++-
tools/testing/selftests/bpf/Makefile | 6 +++++-
tools/testing/selftests/bpf/config | 1 +
tools/testing/selftests/bpf/test_btf_dump.c | 7 +++++++
tools/testing/selftests/bpf/test_cgroup_storage.c | 6 +++---
tools/testing/selftests/bpf/test_sock.c | 7 +++++--
67 files changed, 415 insertions(+), 204 deletions(-)
^ permalink raw reply
* Re: [PATCH net-next 05/14] bnxt_en: Discover firmware error recovery capabilities.
From: Michael Chan @ 2019-08-26 6:23 UTC (permalink / raw)
To: David Miller; +Cc: Netdev, Vasundhara Volam, Jiri Pirko, Ray Jui
In-Reply-To: <20190825.224913.1760774642952210371.davem@davemloft.net>
On Sun, Aug 25, 2019 at 10:49 PM David Miller <davem@davemloft.net> wrote:
>
> From: Michael Chan <michael.chan@broadcom.com>
> Date: Sun, 25 Aug 2019 23:54:56 -0400
>
> > +static int bnxt_hwrm_error_recovery_qcfg(struct bnxt *bp)
> > +{
> > + struct hwrm_error_recovery_qcfg_output *resp = bp->hwrm_cmd_resp_addr;
> > + struct bnxt_fw_health *fw_health = bp->fw_health;
> > + struct hwrm_error_recovery_qcfg_input req = {0};
> > + int rc, i;
> > +
> > + if (!(bp->fw_cap & BNXT_FW_CAP_ERROR_RECOVERY))
> > + return 0;
> > +
> > + bnxt_hwrm_cmd_hdr_init(bp, &req, HWRM_ERROR_RECOVERY_QCFG, -1, -1);
> > + mutex_lock(&bp->hwrm_cmd_lock);
> > + rc = _hwrm_send_message(bp, &req, sizeof(req), HWRM_CMD_TIMEOUT);
> > + if (rc) {
> > + rc = -EOPNOTSUPP;
> > + goto err_recovery_out;
> > + }
>
> How is this logically an unsupported operation if you're guarding it's use
> with an appropriate capability check?
The BNXT_FW_CAP_ERROR_RECOVERY flag says that error recovery should be
supported, but if the firmware call to get the recovery parameters
fails, we return -EOPNOTSUPP to let the caller know that error
recovery cannot be supported. Again, I will try to clean up the error
codes in v2.
^ permalink raw reply
* Re: [PATCH v2] net: fix skb use after free in netpoll
From: David Miller @ 2019-08-26 6:20 UTC (permalink / raw)
To: loyou85
Cc: edumazet, dsterba, dbanerje, fw, davej, tglx, matwey,
sakari.ailus, netdev, linux-kernel, xiaojunzhao141
In-Reply-To: <1566800020-10007-1-git-send-email-loyou85@gmail.com>
From: Feng Sun <loyou85@gmail.com>
Date: Mon, 26 Aug 2019 14:13:40 +0800
> +static inline bool netpoll_xmit_complete(int rc)
> +{
> + return dev_xmit_complete(rc);
> +}
There is no need for this useless indirection, just call dev_xmit_complete()
staright.
Also, even if it was suitable, never use the inline keyword in foo.c files.
^ permalink raw reply
* Re: [PATCH net-next 01/14] bnxt_en: Suppress all error messages in hwrm_do_send_msg() in silent mode.
From: Michael Chan @ 2019-08-26 6:17 UTC (permalink / raw)
To: David Miller; +Cc: Netdev, Vasundhara Volam, Jiri Pirko, Ray Jui
In-Reply-To: <20190825.221507.1465677703637201643.davem@davemloft.net>
On Sun, Aug 25, 2019 at 10:15 PM David Miller <davem@davemloft.net> wrote:
>
> From: Michael Chan <michael.chan@broadcom.com>
> Date: Sun, 25 Aug 2019 23:54:52 -0400
>
> > If the silent parameter is set, suppress all messages when there is
> > no response from firmware. When polling for firmware to come out of
> > reset, no response may be normal and we want to suppress the error
> > messages. Also, don't poll for the firmware DMA response if Bus Master
> > is disabled. This is in preparation for error recovery when firmware
> > may be in error or reset state or Bus Master is disabled.
> >
> > Signed-off-by: Michael Chan <michael.chan@broadcom.com>
>
> The function bnxt_hwrm_do_send_msg() seems to be an interesting mix of return
> values, what are the semantics?
>
> It seems to use 0 for success, some error codes, and -1. Does -1 have special
> meaning?
>
> Just curious, and really this unorthodox return value semantic should
> be documented into a comment above the function.
Sadly, it was coded initially to return firmware defined error codes.
But in some cases, the return code gets propagated all the way back to
userspace. The long term goal is to convert to standard error codes
and so we try to use standard error codes whenever we add new patches
related to this function. I will see what I can do to make this
better in v2. Thanks.
^ permalink raw reply
* [PATCH v2] net: fix skb use after free in netpoll
From: Feng Sun @ 2019-08-26 6:13 UTC (permalink / raw)
To: davem
Cc: edumazet, dsterba, dbanerje, fw, davej, tglx, matwey,
sakari.ailus, netdev, linux-kernel, Feng Sun, Xiaojun Zhao
In-Reply-To: <1566577920-20956-1-git-send-email-loyou85@gmail.com>
After commit baeababb5b85d5c4e6c917efe2a1504179438d3b
("tun: return NET_XMIT_DROP for dropped packets"),
when tun_net_xmit drop packets, it will free skb and return NET_XMIT_DROP,
netpoll_send_skb_on_dev will run into following use after free cases:
1. retry netpoll_start_xmit with freed skb;
2. queue freed skb in npinfo->txq.
queue_process will also run into use after free case.
hit netpoll_send_skb_on_dev first case with following kernel log:
[ 117.864773] kernel BUG at mm/slub.c:306!
[ 117.864773] invalid opcode: 0000 [#1] SMP PTI
[ 117.864774] CPU: 3 PID: 2627 Comm: loop_printmsg Kdump: loaded Tainted: P OE 5.3.0-050300rc5-generic #201908182231
[ 117.864775] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
[ 117.864775] RIP: 0010:kmem_cache_free+0x28d/0x2b0
[ 117.864781] Call Trace:
[ 117.864781] ? tun_net_xmit+0x21c/0x460
[ 117.864781] kfree_skbmem+0x4e/0x60
[ 117.864782] kfree_skb+0x3a/0xa0
[ 117.864782] tun_net_xmit+0x21c/0x460
[ 117.864782] netpoll_start_xmit+0x11d/0x1b0
[ 117.864788] netpoll_send_skb_on_dev+0x1b8/0x200
[ 117.864789] __br_forward+0x1b9/0x1e0 [bridge]
[ 117.864789] ? skb_clone+0x53/0xd0
[ 117.864790] ? __skb_clone+0x2e/0x120
[ 117.864790] deliver_clone+0x37/0x50 [bridge]
[ 117.864790] maybe_deliver+0x89/0xc0 [bridge]
[ 117.864791] br_flood+0x6c/0x130 [bridge]
[ 117.864791] br_dev_xmit+0x315/0x3c0 [bridge]
[ 117.864792] netpoll_start_xmit+0x11d/0x1b0
[ 117.864792] netpoll_send_skb_on_dev+0x1b8/0x200
[ 117.864792] netpoll_send_udp+0x2c6/0x3e8
[ 117.864793] write_msg+0xd9/0xf0 [netconsole]
[ 117.864793] console_unlock+0x386/0x4e0
[ 117.864793] vprintk_emit+0x17e/0x280
[ 117.864794] vprintk_default+0x29/0x50
[ 117.864794] vprintk_func+0x4c/0xbc
[ 117.864794] printk+0x58/0x6f
[ 117.864795] loop_fun+0x24/0x41 [printmsg_loop]
[ 117.864795] kthread+0x104/0x140
[ 117.864795] ? 0xffffffffc05b1000
[ 117.864796] ? kthread_park+0x80/0x80
[ 117.864796] ret_from_fork+0x35/0x40
Signed-off-by: Feng Sun <loyou85@gmail.com>
Signed-off-by: Xiaojun Zhao <xiaojunzhao141@gmail.com>
---
Changes in v2:
- change commit and title
- add netpoll_xmit_complete helper
- add one more return value check of netpoll_start_xmit
---
net/core/netpoll.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 2cf27da..a3f20e9 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -95,6 +95,11 @@ static int netpoll_start_xmit(struct sk_buff *skb, struct net_device *dev,
return status;
}
+static inline bool netpoll_xmit_complete(int rc)
+{
+ return dev_xmit_complete(rc);
+}
+
static void queue_process(struct work_struct *work)
{
struct netpoll_info *npinfo =
@@ -122,7 +127,7 @@ static void queue_process(struct work_struct *work)
txq = netdev_get_tx_queue(dev, q_index);
HARD_TX_LOCK(dev, txq, smp_processor_id());
if (netif_xmit_frozen_or_stopped(txq) ||
- netpoll_start_xmit(skb, dev, txq) != NETDEV_TX_OK) {
+ !netpoll_xmit_complete(netpoll_start_xmit(skb, dev, txq))) {
skb_queue_head(&npinfo->txq, skb);
HARD_TX_UNLOCK(dev, txq);
local_irq_restore(flags);
@@ -335,7 +340,7 @@ void netpoll_send_skb_on_dev(struct netpoll *np, struct sk_buff *skb,
HARD_TX_UNLOCK(dev, txq);
- if (status == NETDEV_TX_OK)
+ if (netpoll_xmit_complete(status))
break;
}
@@ -352,7 +357,7 @@ void netpoll_send_skb_on_dev(struct netpoll *np, struct sk_buff *skb,
}
- if (status != NETDEV_TX_OK) {
+ if (!netpoll_xmit_complete(status)) {
skb_queue_tail(&npinfo->txq, skb);
schedule_delayed_work(&npinfo->tx_work,0);
}
--
2.7.4
^ permalink raw reply related
* [PATCH bpf-next v2 4/4] xsk: lock the control mutex in sock_diag interface
From: Björn Töpel @ 2019-08-26 6:10 UTC (permalink / raw)
To: ast, daniel, netdev
Cc: Björn Töpel, magnus.karlsson, magnus.karlsson, bpf,
jonathan.lemon, syzbot+c82697e3043781e08802, hdanton, i.maximets
In-Reply-To: <20190826061053.15996-1-bjorn.topel@gmail.com>
From: Björn Töpel <bjorn.topel@intel.com>
When accessing the members of an XDP socket, the control mutex should
be held. This commit fixes that.
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Fixes: a36b38aa2af6 ("xsk: add sock_diag interface for AF_XDP")
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
---
net/xdp/xsk_diag.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/xdp/xsk_diag.c b/net/xdp/xsk_diag.c
index d5e06c8e0cbf..c8f4f11edbbc 100644
--- a/net/xdp/xsk_diag.c
+++ b/net/xdp/xsk_diag.c
@@ -97,6 +97,7 @@ static int xsk_diag_fill(struct sock *sk, struct sk_buff *nlskb,
msg->xdiag_ino = sk_ino;
sock_diag_save_cookie(sk, msg->xdiag_cookie);
+ mutex_lock(&xs->mutex);
if ((req->xdiag_show & XDP_SHOW_INFO) && xsk_diag_put_info(xs, nlskb))
goto out_nlmsg_trim;
@@ -117,10 +118,12 @@ static int xsk_diag_fill(struct sock *sk, struct sk_buff *nlskb,
sock_diag_put_meminfo(sk, nlskb, XDP_DIAG_MEMINFO))
goto out_nlmsg_trim;
+ mutex_unlock(&xs->mutex);
nlmsg_end(nlskb, nlh);
return 0;
out_nlmsg_trim:
+ mutex_unlock(&xs->mutex);
nlmsg_cancel(nlskb, nlh);
return -EMSGSIZE;
}
--
2.20.1
^ permalink raw reply related
* [PATCH bpf-next v2 3/4] xsk: avoid store-tearing when assigning umem
From: Björn Töpel @ 2019-08-26 6:10 UTC (permalink / raw)
To: ast, daniel, netdev
Cc: Björn Töpel, magnus.karlsson, magnus.karlsson, bpf,
jonathan.lemon, syzbot+c82697e3043781e08802, hdanton, i.maximets
In-Reply-To: <20190826061053.15996-1-bjorn.topel@gmail.com>
From: Björn Töpel <bjorn.topel@intel.com>
The umem member of struct xdp_sock is read outside of the control
mutex, in the mmap implementation, and needs a WRITE_ONCE to avoid
potentional store-tearing.
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Fixes: 423f38329d26 ("xsk: add umem fill queue support and mmap")
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
---
net/xdp/xsk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
index 8fafa3ce3ae6..e3e99ee5631b 100644
--- a/net/xdp/xsk.c
+++ b/net/xdp/xsk.c
@@ -716,7 +716,7 @@ static int xsk_setsockopt(struct socket *sock, int level, int optname,
/* Make sure umem is ready before it can be seen by others */
smp_wmb();
- xs->umem = umem;
+ WRITE_ONCE(xs->umem, umem);
mutex_unlock(&xs->mutex);
return 0;
}
--
2.20.1
^ permalink raw reply related
* [PATCH bpf-next v2 2/4] xsk: add proper barriers and {READ, WRITE}_ONCE-correctness for state
From: Björn Töpel @ 2019-08-26 6:10 UTC (permalink / raw)
To: ast, daniel, netdev
Cc: Björn Töpel, magnus.karlsson, magnus.karlsson, bpf,
jonathan.lemon, syzbot+c82697e3043781e08802, hdanton, i.maximets
In-Reply-To: <20190826061053.15996-1-bjorn.topel@gmail.com>
From: Björn Töpel <bjorn.topel@intel.com>
The state variable was read, and written outside the control mutex
(struct xdp_sock, mutex), without proper barriers and {READ,
WRITE}_ONCE correctness.
In this commit this issue is addressed, and the state member is now
used a point of synchronization whether the socket is setup correctly
or not.
This also fixes a race, found by syzcaller, in xsk_poll() where umem
could be accessed when stale.
Suggested-by: Hillf Danton <hdanton@sina.com>
Reported-by: syzbot+c82697e3043781e08802@syzkaller.appspotmail.com
Fixes: 77cd0d7b3f25 ("xsk: add support for need_wakeup flag in AF_XDP rings")
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
---
net/xdp/xsk.c | 57 ++++++++++++++++++++++++++++++++++++---------------
1 file changed, 40 insertions(+), 17 deletions(-)
diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
index f3351013c2a5..8fafa3ce3ae6 100644
--- a/net/xdp/xsk.c
+++ b/net/xdp/xsk.c
@@ -162,10 +162,23 @@ static int __xsk_rcv_zc(struct xdp_sock *xs, struct xdp_buff *xdp, u32 len)
return err;
}
+static bool xsk_is_bound(struct xdp_sock *xs)
+{
+ if (READ_ONCE(xs->state) == XSK_BOUND) {
+ /* Matches smp_wmb() in bind(). */
+ smp_rmb();
+ return true;
+ }
+ return false;
+}
+
int xsk_rcv(struct xdp_sock *xs, struct xdp_buff *xdp)
{
u32 len;
+ if (!xsk_is_bound(xs))
+ return -EINVAL;
+
if (xs->dev != xdp->rxq->dev || xs->queue_id != xdp->rxq->queue_index)
return -EINVAL;
@@ -362,7 +375,7 @@ static int xsk_sendmsg(struct socket *sock, struct msghdr *m, size_t total_len)
struct sock *sk = sock->sk;
struct xdp_sock *xs = xdp_sk(sk);
- if (unlikely(!xs->dev))
+ if (unlikely(!xsk_is_bound(xs)))
return -ENXIO;
if (unlikely(!(xs->dev->flags & IFF_UP)))
return -ENETDOWN;
@@ -378,10 +391,15 @@ static unsigned int xsk_poll(struct file *file, struct socket *sock,
struct poll_table_struct *wait)
{
unsigned int mask = datagram_poll(file, sock, wait);
- struct sock *sk = sock->sk;
- struct xdp_sock *xs = xdp_sk(sk);
- struct net_device *dev = xs->dev;
- struct xdp_umem *umem = xs->umem;
+ struct xdp_sock *xs = xdp_sk(sock->sk);
+ struct net_device *dev;
+ struct xdp_umem *umem;
+
+ if (unlikely(!xsk_is_bound(xs)))
+ return mask;
+
+ dev = xs->dev;
+ umem = xs->umem;
if (umem->need_wakeup)
dev->netdev_ops->ndo_xsk_wakeup(dev, xs->queue_id,
@@ -417,10 +435,9 @@ static void xsk_unbind_dev(struct xdp_sock *xs)
{
struct net_device *dev = xs->dev;
- if (!dev || xs->state != XSK_BOUND)
+ if (xs->state != XSK_BOUND)
return;
-
- xs->state = XSK_UNBOUND;
+ WRITE_ONCE(xs->state, XSK_UNBOUND);
/* Wait for driver to stop using the xdp socket. */
xdp_del_sk_umem(xs->umem, xs);
@@ -495,7 +512,9 @@ static int xsk_release(struct socket *sock)
local_bh_enable();
xsk_delete_from_maps(xs);
+ mutex_lock(&xs->mutex);
xsk_unbind_dev(xs);
+ mutex_unlock(&xs->mutex);
xskq_destroy(xs->rx);
xskq_destroy(xs->tx);
@@ -589,19 +608,18 @@ static int xsk_bind(struct socket *sock, struct sockaddr *addr, int addr_len)
}
umem_xs = xdp_sk(sock->sk);
- if (!umem_xs->umem) {
- /* No umem to inherit. */
+ if (!xsk_is_bound(umem_xs)) {
err = -EBADF;
sockfd_put(sock);
goto out_unlock;
- } else if (umem_xs->dev != dev || umem_xs->queue_id != qid) {
+ }
+ if (umem_xs->dev != dev || umem_xs->queue_id != qid) {
err = -EINVAL;
sockfd_put(sock);
goto out_unlock;
}
-
xdp_get_umem(umem_xs->umem);
- xs->umem = umem_xs->umem;
+ WRITE_ONCE(xs->umem, umem_xs->umem);
sockfd_put(sock);
} else if (!xs->umem || !xdp_umem_validate_queues(xs->umem)) {
err = -EINVAL;
@@ -626,10 +644,15 @@ static int xsk_bind(struct socket *sock, struct sockaddr *addr, int addr_len)
xdp_add_sk_umem(xs->umem, xs);
out_unlock:
- if (err)
+ if (err) {
dev_put(dev);
- else
- xs->state = XSK_BOUND;
+ } else {
+ /* Matches smp_rmb() in bind() for shared umem
+ * sockets, and xsk_is_bound().
+ */
+ smp_wmb();
+ WRITE_ONCE(xs->state, XSK_BOUND);
+ }
out_release:
mutex_unlock(&xs->mutex);
rtnl_unlock();
@@ -869,7 +892,7 @@ static int xsk_mmap(struct file *file, struct socket *sock,
unsigned long pfn;
struct page *qpg;
- if (xs->state != XSK_READY)
+ if (READ_ONCE(xs->state) != XSK_READY)
return -EBUSY;
if (offset == XDP_PGOFF_RX_RING) {
--
2.20.1
^ permalink raw reply related
* [PATCH bpf-next v2 1/4] xsk: avoid store-tearing when assigning queues
From: Björn Töpel @ 2019-08-26 6:10 UTC (permalink / raw)
To: ast, daniel, netdev
Cc: Björn Töpel, magnus.karlsson, magnus.karlsson, bpf,
jonathan.lemon, syzbot+c82697e3043781e08802, hdanton, i.maximets
In-Reply-To: <20190826061053.15996-1-bjorn.topel@gmail.com>
From: Björn Töpel <bjorn.topel@intel.com>
Use WRITE_ONCE when doing the store of tx, rx, fq, and cq, to avoid
potential store-tearing. These members are read outside of the control
mutex in the mmap implementation.
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Fixes: 37b076933a8e ("xsk: add missing write- and data-dependency barrier")
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
---
net/xdp/xsk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
index ee4428a892fa..f3351013c2a5 100644
--- a/net/xdp/xsk.c
+++ b/net/xdp/xsk.c
@@ -409,7 +409,7 @@ static int xsk_init_queue(u32 entries, struct xsk_queue **queue,
/* Make sure queue is ready before it can be seen by others */
smp_wmb();
- *queue = q;
+ WRITE_ONCE(*queue, q);
return 0;
}
--
2.20.1
^ permalink raw reply related
* [PATCH bpf-next v2 0/4] xsk: various CPU barrier and {READ, WRITE}_ONCE fixes
From: Björn Töpel @ 2019-08-26 6:10 UTC (permalink / raw)
To: ast, daniel, netdev
Cc: Björn Töpel, magnus.karlsson, magnus.karlsson, bpf,
bjorn.topel, jonathan.lemon, syzbot+c82697e3043781e08802, hdanton,
i.maximets
This is a four patch series of various barrier, {READ, WRITE}_ONCE
cleanups in the AF_XDP socket code. More details can be found in the
corresponding commit message.
For an AF_XDP socket, most control plane operations are done under the
control mutex (struct xdp_sock, mutex), but there are some places
where members of the struct is read outside the control mutex. This,
as pointed out by Daniel in [1], requires proper {READ,
WRITE}_ONCE-correctness [2] [3]. To address this, and to simplify the
code, the state variable (introduced by Ilya), is now used a point of
synchronization ("is the socket in a valid state, or not").
Thanks,
Björn
[1] https://lore.kernel.org/bpf/beef16bb-a09b-40f1-7dd0-c323b4b89b17@iogearbox.net/
[2] https://lwn.net/Articles/793253/
[3] https://github.com/google/ktsan/wiki/READ_ONCE-and-WRITE_ONCE
v1->v2:
Removed redundant dev check. (Jonathan)
Björn Töpel (4):
xsk: avoid store-tearing when assigning queues
xsk: add proper barriers and {READ, WRITE}_ONCE-correctness for state
xsk: avoid store-tearing when assigning umem
xsk: lock the control mutex in sock_diag interface
net/xdp/xsk.c | 61 +++++++++++++++++++++++++++++++---------------
net/xdp/xsk_diag.c | 3 +++
2 files changed, 45 insertions(+), 19 deletions(-)
--
2.20.1
^ permalink raw reply
* Re: [PATCH net-next 03/14] bnxt_en: Refactor bnxt_sriov_enable().
From: Michael Chan @ 2019-08-26 6:06 UTC (permalink / raw)
To: David Miller; +Cc: Netdev, Vasundhara Volam, Jiri Pirko, Ray Jui
In-Reply-To: <20190825.223603.2113058192469260500.davem@davemloft.net>
On Sun, Aug 25, 2019 at 10:36 PM David Miller <davem@davemloft.net> wrote:
>
> From: Michael Chan <michael.chan@broadcom.com>
> Date: Sun, 25 Aug 2019 23:54:54 -0400
>
> > @@ -687,6 +687,32 @@ static int bnxt_func_cfg(struct bnxt *bp, int num_vfs)
> > return bnxt_hwrm_func_cfg(bp, num_vfs);
> > }
> >
> > +int bnxt_cfg_hw_sriov(struct bnxt *bp, int *num_vfs)
> > +{
> > + int rc;
> > +
> > + /* Register buffers for VFs */
> > + rc = bnxt_hwrm_func_buf_rgtr(bp);
> > + if (rc)
> > + return rc;
> > +
> > + /* Reserve resources for VFs */
> > + rc = bnxt_func_cfg(bp, *num_vfs);
> > + if (rc != *num_vfs) {
>
> I notice that these two operations are reversed here from where they were in the
> bnxt_sriov_enable() function. Does the BUF_RGTR operation have to be undone if
> the bnxt_func_cfg() fails?
>
> When it's not a straight extraction of code into a helper function one really
> should do one of two things in my opinion:
>
> 1) Explain the differences in the commit message.
>
> 2) Do a straight extration in one commit, change the ordering in another.
OK. Will break it up into 2 commits with explanations. The reason is
that during normal init, the PF is always initialized first and the
exact bring-up sequence does not matter too much. During error
recovery, the PF and VFs can be all trying to recover at about the
same time and the sequence matters more. Will explain all of this
again in v2. Thanks.
^ permalink raw reply
* Re: [PATCH net-next 03/14] bnxt_en: Refactor bnxt_sriov_enable().
From: Leon Romanovsky @ 2019-08-26 6:00 UTC (permalink / raw)
To: Michael Chan; +Cc: davem, netdev, vasundhara-v.volam, jiri, ray.jui
In-Reply-To: <1566791705-20473-4-git-send-email-michael.chan@broadcom.com>
On Sun, Aug 25, 2019 at 11:54:54PM -0400, Michael Chan wrote:
> Refactor the hardware/firmware configuration portion in
> bnxt_sriov_enable() into a new function bnxt_cfg_hw_sriov(). This
> new function can be called after a firmware reset to reconfigure the
> VFs previously enabled.
I wonder what does it mean for already bound VFs to vfio driver?
Will you rebind them as well? Can I assume that FW error in one VF
will trigger "restart" of other VFs too?
Thanks
^ permalink raw reply
* Re: [PATCH net-next 08/14] bnxt_en: Add BNXT_STATE_IN_FW_RESET state and pf->registered_vfs.
From: David Miller @ 2019-08-26 5:59 UTC (permalink / raw)
To: michael.chan; +Cc: netdev, vasundhara-v.volam, jiri, ray.jui
In-Reply-To: <1566791705-20473-9-git-send-email-michael.chan@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
Date: Sun, 25 Aug 2019 23:54:59 -0400
> @@ -9234,6 +9243,13 @@ int bnxt_close_nic(struct bnxt *bp, bool irq_re_init, bool link_re_init)
> {
> int rc = 0;
>
> + while (test_bit(BNXT_STATE_IN_FW_RESET, &bp->state)) {
> + netdev_info(bp->dev, "FW reset in progress, delaying close");
> + rtnl_unlock();
> + msleep(250);
> + rtnl_lock();
> + }
Dropping the RTNL here is extremely dangerous.
Operations other than actual device close can get into the
bnxt_close_nic() code paths (changing features, ethtool ops, etc.)
So we can thus re-enter this function once you drop the RTNL mutex.
Furthermore, and I understand what pains you go into in patch #9 to
avoid this, but it's an endless loop. If there are bugs there, we
will get stuck in this close path forever.
^ permalink raw reply
* Re: [PATCH net-next 05/14] bnxt_en: Discover firmware error recovery capabilities.
From: David Miller @ 2019-08-26 5:49 UTC (permalink / raw)
To: michael.chan; +Cc: netdev, vasundhara-v.volam, jiri, ray.jui
In-Reply-To: <1566791705-20473-6-git-send-email-michael.chan@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
Date: Sun, 25 Aug 2019 23:54:56 -0400
> +static int bnxt_hwrm_error_recovery_qcfg(struct bnxt *bp)
> +{
> + struct hwrm_error_recovery_qcfg_output *resp = bp->hwrm_cmd_resp_addr;
> + struct bnxt_fw_health *fw_health = bp->fw_health;
> + struct hwrm_error_recovery_qcfg_input req = {0};
> + int rc, i;
> +
> + if (!(bp->fw_cap & BNXT_FW_CAP_ERROR_RECOVERY))
> + return 0;
> +
> + bnxt_hwrm_cmd_hdr_init(bp, &req, HWRM_ERROR_RECOVERY_QCFG, -1, -1);
> + mutex_lock(&bp->hwrm_cmd_lock);
> + rc = _hwrm_send_message(bp, &req, sizeof(req), HWRM_CMD_TIMEOUT);
> + if (rc) {
> + rc = -EOPNOTSUPP;
> + goto err_recovery_out;
> + }
How is this logically an unsupported operation if you're guarding it's use
with an appropriate capability check?
^ permalink raw reply
* Re: [PATCH net-next 04/14] bnxt_en: Handle firmware reset status during IF_UP.
From: David Miller @ 2019-08-26 5:47 UTC (permalink / raw)
To: michael.chan; +Cc: netdev, vasundhara-v.volam, jiri, ray.jui
In-Reply-To: <1566791705-20473-5-git-send-email-michael.chan@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
Date: Sun, 25 Aug 2019 23:54:55 -0400
> @@ -7005,7 +7005,9 @@ static int __bnxt_hwrm_ver_get(struct bnxt *bp, bool silent)
>
> rc = bnxt_hwrm_do_send_msg(bp, &req, sizeof(req), HWRM_CMD_TIMEOUT,
> silent);
> - return rc;
> + if (rc)
> + return -ENODEV;
> + return 0;
> }
>
> static int bnxt_hwrm_ver_get(struct bnxt *bp)
...
> @@ -8528,26 +8533,53 @@ static int bnxt_hwrm_if_change(struct bnxt *bp, bool up)
> req.flags = cpu_to_le32(FUNC_DRV_IF_CHANGE_REQ_FLAGS_UP);
> mutex_lock(&bp->hwrm_cmd_lock);
> rc = _hwrm_send_message(bp, &req, sizeof(req), HWRM_CMD_TIMEOUT);
> - if (!rc && (resp->flags &
> - cpu_to_le32(FUNC_DRV_IF_CHANGE_RESP_FLAGS_RESC_CHANGE)))
> - resc_reinit = true;
> + if (!rc)
> + flags = le32_to_cpu(resp->flags);
> mutex_unlock(&bp->hwrm_cmd_lock);
> + if (rc)
> + return -EIO;
Following up to my other review comments, if _hwrm_send_message() et
al. returned consistently proper error codes instead of sometimes -1,
couldn't you avoid at least some of these 'rc' remappings?
^ permalink raw reply
* Re: [PATCH bpf] nfp: bpf: fix latency bug when updating stack index register
From: Song Liu @ 2019-08-26 5:36 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Alexei Starovoitov, Daniel Borkmann, bpf, Networking, oss-drivers,
Jiong Wang
In-Reply-To: <20190824020028.6242-1-jakub.kicinski@netronome.com>
On Fri, Aug 23, 2019 at 7:04 PM Jakub Kicinski
<jakub.kicinski@netronome.com> wrote:
>
> From: Jiong Wang <jiong.wang@netronome.com>
>
> NFP is using Local Memory to model stack. LM_addr could be used as base of
> a 16 32-bit word region of Local Memory. Then, if the stack offset is
> beyond the current region, the local index needs to be updated. The update
> needs at least three cycles to take effect, therefore the sequence normally
> looks like:
>
> local_csr_wr[ActLMAddr3, gprB_5]
> nop
> nop
> nop
>
> If the local index switch happens on a narrow loads, then the instruction
> preparing value to zero high 32-bit of the destination register could be
> counted as one cycle, the sequence then could be something like:
>
> local_csr_wr[ActLMAddr3, gprB_5]
> nop
> nop
> immed[gprB_5, 0]
>
> However, we have zero extension optimization that zeroing high 32-bit could
> be eliminated, therefore above IMMED insn won't be available for which case
> the first sequence needs to be generated.
>
> Fixes: 0b4de1ff19bf ("nfp: bpf: eliminate zero extension code-gen")
> Signed-off-by: Jiong Wang <jiong.wang@netronome.com>
> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
I haven't looked into the code yet. But ^^^ should be
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
right?
^ permalink raw reply
* Re: [PATCH net-next 03/14] bnxt_en: Refactor bnxt_sriov_enable().
From: David Miller @ 2019-08-26 5:36 UTC (permalink / raw)
To: michael.chan; +Cc: netdev, vasundhara-v.volam, jiri, ray.jui
In-Reply-To: <1566791705-20473-4-git-send-email-michael.chan@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
Date: Sun, 25 Aug 2019 23:54:54 -0400
> @@ -687,6 +687,32 @@ static int bnxt_func_cfg(struct bnxt *bp, int num_vfs)
> return bnxt_hwrm_func_cfg(bp, num_vfs);
> }
>
> +int bnxt_cfg_hw_sriov(struct bnxt *bp, int *num_vfs)
> +{
> + int rc;
> +
> + /* Register buffers for VFs */
> + rc = bnxt_hwrm_func_buf_rgtr(bp);
> + if (rc)
> + return rc;
> +
> + /* Reserve resources for VFs */
> + rc = bnxt_func_cfg(bp, *num_vfs);
> + if (rc != *num_vfs) {
I notice that these two operations are reversed here from where they were in the
bnxt_sriov_enable() function. Does the BUF_RGTR operation have to be undone if
the bnxt_func_cfg() fails?
When it's not a straight extraction of code into a helper function one really
should do one of two things in my opinion:
1) Explain the differences in the commit message.
2) Do a straight extration in one commit, change the ordering in another.
^ permalink raw reply
* Re: [PATCH bpf-next 4/4] selftests/bpf: add precision tracking test
From: Song Liu @ 2019-08-26 5:33 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S . Miller, Daniel Borkmann, Networking, bpf, Kernel Team
In-Reply-To: <20190823055215.2658669-5-ast@kernel.org>
On Fri, Aug 23, 2019 at 3:00 AM Alexei Starovoitov <ast@kernel.org> wrote:
>
> Copy-paste of existing test
> "calls: cross frame pruning - liveness propagation"
> but ran with different parentage chain heuristic
> which stresses different path in precision tracking logic.
>
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Song Liu <songliubraving@fb.com>
>
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the net tree
From: Heiner Kallweit @ 2019-08-26 5:27 UTC (permalink / raw)
To: Stephen Rothwell, David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <20190826122726.145f538d@canb.auug.org.au>
On 26.08.2019 04:27, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> drivers/net/ethernet/realtek/r8169_main.c
>
> between commit:
>
> 345b93265b3a ("Revert "r8169: remove not needed call to dma_sync_single_for_device"")
>
> from the net tree and commit:
>
> fcd4e60885af ("r8169: improve rtl_rx")
> d4ed7463d02a ("r8169: fix DMA issue on MIPS platform")
>
> from the net-next tree.
>
> I fixed it up (the latter seems to do the same as the net tree patch) and
> can carry the fix as necessary. This is now fixed as far as linux-next
> is concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
>
Due to other changes there have been two versions of the fix, one for net
and one for net-next. Therefore ignoring the one from net when merging into
net-next was correct. Thanks!
^ permalink raw reply
* Re: [PATCH bpf-next 3/4] selftests/bpf: verifier precise tests
From: Song Liu @ 2019-08-26 5:22 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S . Miller, Daniel Borkmann, Networking, bpf, Kernel Team
In-Reply-To: <20190823055215.2658669-4-ast@kernel.org>
On Fri, Aug 23, 2019 at 2:59 AM Alexei Starovoitov <ast@kernel.org> wrote:
>
> Use BPF_F_TEST_STATE_FREQ flag to check that precision
> tracking works as expected by comparing every step it takes.
>
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
> ---
> tools/testing/selftests/bpf/test_verifier.c | 68 ++++++++--
> .../testing/selftests/bpf/verifier/precise.c | 117 ++++++++++++++++++
> 2 files changed, 174 insertions(+), 11 deletions(-)
> create mode 100644 tools/testing/selftests/bpf/verifier/precise.c
>
> diff --git a/tools/testing/selftests/bpf/test_verifier.c b/tools/testing/selftests/bpf/test_verifier.c
> index 44e2d640b088..d27fd929abb9 100644
> --- a/tools/testing/selftests/bpf/test_verifier.c
> +++ b/tools/testing/selftests/bpf/test_verifier.c
> @@ -61,6 +61,7 @@
> #define UNPRIV_SYSCTL "kernel/unprivileged_bpf_disabled"
> static bool unpriv_disabled = false;
> static int skips;
> +static bool verbose = false;
>
> struct bpf_test {
> const char *descr;
> @@ -92,7 +93,8 @@ struct bpf_test {
> enum {
> UNDEF,
> ACCEPT,
> - REJECT
> + REJECT,
> + VERBOSE_ACCEPT,
> } result, result_unpriv;
> enum bpf_prog_type prog_type;
> uint8_t flags;
> @@ -859,6 +861,36 @@ static int do_prog_test_run(int fd_prog, bool unpriv, uint32_t expected_val,
> return 0;
> }
>
> +static bool cmp_str_seq(const char *log, const char *exp)
Maybe call it str_str_seq()?
> +{
> + char needle[80];
> + const char *p, *q;
> + int len;
> +
> + do {
> + p = strchr(exp, '\t');
> + if (!p)
> + p = exp + strlen(exp);
> +
> + len = p - exp;
> + if (len >= sizeof(needle) || !len) {
> + printf("FAIL\nTestcase bug\n");
> + return false;
> + }
> + strncpy(needle, exp, len);
> + needle[len] = 0;
> + q = strstr(log, needle);
> + if (!q) {
> + printf("FAIL\nUnexpected verifier log in successful load!\n"
> + "EXP: %s\nRES:\n", needle);
> + return false;
> + }
> + log = q + len;
> + exp = p + 1;
> + } while (*p);
> + return true;
> +}
> +
> static void do_test_single(struct bpf_test *test, bool unpriv,
> int *passes, int *errors)
> {
> @@ -897,14 +929,20 @@ static void do_test_single(struct bpf_test *test, bool unpriv,
> pflags |= BPF_F_STRICT_ALIGNMENT;
> if (test->flags & F_NEEDS_EFFICIENT_UNALIGNED_ACCESS)
> pflags |= BPF_F_ANY_ALIGNMENT;
> + if (test->flags & ~3)
> + pflags |= test->flags;
^^^^^^ why do we need these two lines?
>
> + expected_ret = unpriv && test->result_unpriv != UNDEF ?
> + test->result_unpriv : test->result;
> + expected_err = unpriv && test->errstr_unpriv ?
> + test->errstr_unpriv : test->errstr;
> memset(&attr, 0, sizeof(attr));
> attr.prog_type = prog_type;
> attr.expected_attach_type = test->expected_attach_type;
> attr.insns = prog;
> attr.insns_cnt = prog_len;
> attr.license = "GPL";
> - attr.log_level = 4;
> + attr.log_level = verbose || expected_ret == VERBOSE_ACCEPT ? 1 : 4;
> attr.prog_flags = pflags;
>
> fd_prog = bpf_load_program_xattr(&attr, bpf_vlog, sizeof(bpf_vlog));
> @@ -914,14 +952,9 @@ static void do_test_single(struct bpf_test *test, bool unpriv,
> goto close_fds;
> }
>
> - expected_ret = unpriv && test->result_unpriv != UNDEF ?
> - test->result_unpriv : test->result;
> - expected_err = unpriv && test->errstr_unpriv ?
> - test->errstr_unpriv : test->errstr;
> -
> alignment_prevented_execution = 0;
>
> - if (expected_ret == ACCEPT) {
> + if (expected_ret == ACCEPT || expected_ret == VERBOSE_ACCEPT) {
> if (fd_prog < 0) {
> printf("FAIL\nFailed to load prog '%s'!\n",
> strerror(errno));
> @@ -932,6 +965,9 @@ static void do_test_single(struct bpf_test *test, bool unpriv,
> (test->flags & F_NEEDS_EFFICIENT_UNALIGNED_ACCESS))
> alignment_prevented_execution = 1;
> #endif
> + if (expected_ret == VERBOSE_ACCEPT && !cmp_str_seq(bpf_vlog, expected_err)) {
> + goto fail_log;
> + }
> } else {
> if (fd_prog >= 0) {
> printf("FAIL\nUnexpected success to load!\n");
> @@ -957,6 +993,9 @@ static void do_test_single(struct bpf_test *test, bool unpriv,
> }
> }
>
> + if (verbose)
> + printf(", verifier log:\n%s", bpf_vlog);
> +
> run_errs = 0;
> run_successes = 0;
> if (!alignment_prevented_execution && fd_prog >= 0) {
> @@ -1097,17 +1136,24 @@ int main(int argc, char **argv)
> {
> unsigned int from = 0, to = ARRAY_SIZE(tests);
> bool unpriv = !is_admin();
> + int arg = 1;
> +
> + if (argc > 1 && strcmp(argv[1], "-v") == 0) {
> + arg++;
> + verbose = true;
> + argc--;
> + }
>
> if (argc == 3) {
> - unsigned int l = atoi(argv[argc - 2]);
> - unsigned int u = atoi(argv[argc - 1]);
> + unsigned int l = atoi(argv[arg]);
> + unsigned int u = atoi(argv[arg + 1]);
>
> if (l < to && u < to) {
> from = l;
> to = u + 1;
> }
> } else if (argc == 2) {
> - unsigned int t = atoi(argv[argc - 1]);
> + unsigned int t = atoi(argv[arg]);
>
> if (t < to) {
> from = t;
> diff --git a/tools/testing/selftests/bpf/verifier/precise.c b/tools/testing/selftests/bpf/verifier/precise.c
> new file mode 100644
> index 000000000000..a20953c23721
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/verifier/precise.c
> @@ -0,0 +1,117 @@
> +{
> + "precise: test 1",
> + .insns = {
> + BPF_MOV64_IMM(BPF_REG_0, 1),
> + BPF_LD_MAP_FD(BPF_REG_6, 0),
> + BPF_MOV64_REG(BPF_REG_1, BPF_REG_6),
> + BPF_MOV64_REG(BPF_REG_2, BPF_REG_FP),
> + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
> + BPF_ST_MEM(BPF_DW, BPF_REG_FP, -8, 0),
> + BPF_EMIT_CALL(BPF_FUNC_map_lookup_elem),
> + BPF_JMP_IMM(BPF_JNE, BPF_REG_0, 0, 1),
> + BPF_EXIT_INSN(),
> +
> + BPF_MOV64_REG(BPF_REG_9, BPF_REG_0),
> +
> + BPF_MOV64_REG(BPF_REG_1, BPF_REG_6),
> + BPF_MOV64_REG(BPF_REG_2, BPF_REG_FP),
> + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
> + BPF_EMIT_CALL(BPF_FUNC_map_lookup_elem),
> + BPF_JMP_IMM(BPF_JNE, BPF_REG_0, 0, 1),
> + BPF_EXIT_INSN(),
> +
> + BPF_MOV64_REG(BPF_REG_8, BPF_REG_0),
> +
> + BPF_ALU64_REG(BPF_SUB, BPF_REG_9, BPF_REG_8), /* map_value_ptr -= map_value_ptr */
> + BPF_MOV64_REG(BPF_REG_2, BPF_REG_9),
> + BPF_JMP_IMM(BPF_JLT, BPF_REG_2, 8, 1),
> + BPF_EXIT_INSN(),
> +
> + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, 1), /* R2=inv(umin=1, umax=8) */
> + BPF_MOV64_REG(BPF_REG_1, BPF_REG_FP),
> + BPF_ALU64_IMM(BPF_ADD, BPF_REG_1, -8),
> + BPF_MOV64_IMM(BPF_REG_3, 0),
> + BPF_EMIT_CALL(BPF_FUNC_probe_read),
> + BPF_EXIT_INSN(),
> + },
> + .prog_type = BPF_PROG_TYPE_TRACEPOINT,
> + .fixup_map_array_48b = { 1 },
> + .result = VERBOSE_ACCEPT,
> + .errstr =
> + "26: (85) call bpf_probe_read#4\
> + last_idx 26 first_idx 20\
> + regs=4 stack=0 before 25\
> + regs=4 stack=0 before 24\
> + regs=4 stack=0 before 23\
> + regs=4 stack=0 before 22\
> + regs=4 stack=0 before 20\
> + parent didn't have regs=4 stack=0 marks\
> + last_idx 19 first_idx 10\
> + regs=4 stack=0 before 19\
> + regs=200 stack=0 before 18\
> + regs=300 stack=0 before 17\
> + regs=201 stack=0 before 15\
> + regs=201 stack=0 before 14\
> + regs=200 stack=0 before 13\
> + regs=200 stack=0 before 12\
> + regs=200 stack=0 before 11\
> + regs=200 stack=0 before 10\
> + parent already had regs=0 stack=0 marks",
> +},
> +{
> + "precise: test 2",
> + .insns = {
> + BPF_MOV64_IMM(BPF_REG_0, 1),
> + BPF_LD_MAP_FD(BPF_REG_6, 0),
> + BPF_MOV64_REG(BPF_REG_1, BPF_REG_6),
> + BPF_MOV64_REG(BPF_REG_2, BPF_REG_FP),
> + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
> + BPF_ST_MEM(BPF_DW, BPF_REG_FP, -8, 0),
> + BPF_EMIT_CALL(BPF_FUNC_map_lookup_elem),
> + BPF_JMP_IMM(BPF_JNE, BPF_REG_0, 0, 1),
> + BPF_EXIT_INSN(),
> +
> + BPF_MOV64_REG(BPF_REG_9, BPF_REG_0),
> +
> + BPF_MOV64_REG(BPF_REG_1, BPF_REG_6),
> + BPF_MOV64_REG(BPF_REG_2, BPF_REG_FP),
> + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
> + BPF_EMIT_CALL(BPF_FUNC_map_lookup_elem),
> + BPF_JMP_IMM(BPF_JNE, BPF_REG_0, 0, 1),
> + BPF_EXIT_INSN(),
> +
> + BPF_MOV64_REG(BPF_REG_8, BPF_REG_0),
> +
> + BPF_ALU64_REG(BPF_SUB, BPF_REG_9, BPF_REG_8), /* map_value_ptr -= map_value_ptr */
> + BPF_MOV64_REG(BPF_REG_2, BPF_REG_9),
> + BPF_JMP_IMM(BPF_JLT, BPF_REG_2, 8, 1),
> + BPF_EXIT_INSN(),
> +
> + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, 1), /* R2=inv(umin=1, umax=8) */
> + BPF_MOV64_REG(BPF_REG_1, BPF_REG_FP),
> + BPF_ALU64_IMM(BPF_ADD, BPF_REG_1, -8),
> + BPF_MOV64_IMM(BPF_REG_3, 0),
> + BPF_EMIT_CALL(BPF_FUNC_probe_read),
> + BPF_EXIT_INSN(),
> + },
> + .prog_type = BPF_PROG_TYPE_TRACEPOINT,
> + .fixup_map_array_48b = { 1 },
> + .result = VERBOSE_ACCEPT,
> + .flags = BPF_F_TEST_STATE_FREQ,
> + .errstr =
> + "26: (85) call bpf_probe_read#4\
> + last_idx 26 first_idx 22\
> + regs=4 stack=0 before 25\
> + regs=4 stack=0 before 24\
> + regs=4 stack=0 before 23\
> + regs=4 stack=0 before 22\
> + parent didn't have regs=4 stack=0 marks\
> + last_idx 20 first_idx 20\
> + regs=4 stack=0 before 20\
> + parent didn't have regs=4 stack=0 marks\
> + last_idx 19 first_idx 17\
> + regs=4 stack=0 before 19\
> + regs=200 stack=0 before 18\
> + regs=300 stack=0 before 17\
> + parent already had regs=0 stack=0 marks",
> +},
> --
> 2.20.0
>
^ permalink raw reply
* Re: [PATCH net-next 01/14] bnxt_en: Suppress all error messages in hwrm_do_send_msg() in silent mode.
From: David Miller @ 2019-08-26 5:15 UTC (permalink / raw)
To: michael.chan; +Cc: netdev, vasundhara-v.volam, jiri, ray.jui
In-Reply-To: <1566791705-20473-2-git-send-email-michael.chan@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
Date: Sun, 25 Aug 2019 23:54:52 -0400
> If the silent parameter is set, suppress all messages when there is
> no response from firmware. When polling for firmware to come out of
> reset, no response may be normal and we want to suppress the error
> messages. Also, don't poll for the firmware DMA response if Bus Master
> is disabled. This is in preparation for error recovery when firmware
> may be in error or reset state or Bus Master is disabled.
>
> Signed-off-by: Michael Chan <michael.chan@broadcom.com>
The function bnxt_hwrm_do_send_msg() seems to be an interesting mix of return
values, what are the semantics?
It seems to use 0 for success, some error codes, and -1. Does -1 have special
meaning?
Just curious, and really this unorthodox return value semantic should
be documented into a comment above the function.
^ permalink raw reply
* Re: [PATCH bpf-next 2/4] tools/bpf: sync bpf.h
From: Song Liu @ 2019-08-26 5:10 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S . Miller, Daniel Borkmann, Networking, bpf, Kernel Team
In-Reply-To: <20190823055215.2658669-3-ast@kernel.org>
On Fri, Aug 23, 2019 at 2:59 AM Alexei Starovoitov <ast@kernel.org> wrote:
>
> sync bpf.h from kernel/ to tools/
>
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Song Liu <songliubraving@fb.com>
^ 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