1. 20 May, 2020 2 commits
    • David Howells's avatar
      rxrpc: Fix ack discard · 441fdee1
      David Howells authored
      The Rx protocol has a "previousPacket" field in it that is not handled in
      the same way by all protocol implementations.  Sometimes it contains the
      serial number of the last DATA packet received, sometimes the sequence
      number of the last DATA packet received and sometimes the highest sequence
      number so far received.
      
      AF_RXRPC is using this to weed out ACKs that are out of date (it's possible
      for ACK packets to get reordered on the wire), but this does not work with
      OpenAFS which will just stick the sequence number of the last packet seen
      into previousPacket.
      
      The issue being seen is that big AFS FS.StoreData RPC (eg. of ~256MiB) are
      timing out when partly sent.  A trace was captured, with an additional
      tracepoint to show ACKs being discarded in rxrpc_input_ack().  Here's an
      excerpt showing the problem.
      
       52873.203230: rxrpc_tx_data: c=000004ae DATA ed1a3584:00000002 0002449c q=00024499 fl=09
      
      A DATA packet with sequence number 00024499 has been transmitted (the "q="
      field).
      
       ...
       52873.243296: rxrpc_rx_ack: c=000004ae 00012a2b DLY r=00024499 f=00024497 p=00024496 n=0
       52873.243376: rxrpc_rx_ack: c=000004ae 00012a2c IDL r=0002449b f=00024499 p=00024498 n=0
       52873.243383: rxrpc_rx_ack: c=000004ae 00012a2d OOS r=0002449d f=00024499 p=0002449a n=2
      
      The Out-Of-Sequence ACK indicates that the server didn't see DATA sequence
      number 00024499, but did see seq 0002449a (previousPacket, shown as "p=",
      skipped the number, but firstPacket, "f=", which shows the bottom of the
      window is set at that point).
      
       52873.252663: rxrpc_retransmit: c=000004ae q=24499 a=02 xp=14581537
       52873.252664: rxrpc_tx_data: c=000004ae DATA ed1a3584:00000002 000244bc q=00024499 fl=0b *RETRANS*
      
      The packet has been retransmitted.  Retransmission recurs until the peer
      says it got the packet.
      
       52873.271013: rxrpc_rx_ack: c=000004ae 00012a31 OOS r=000244a1 f=00024499 p=0002449e n=6
      
      More OOS ACKs indicate that the other packets that are already in the
      transmission pipeline are being received.  The specific-ACK list is up to 6
      ACKs and NAKs.
      
       ...
       52873.284792: rxrpc_rx_ack: c=000004ae 00012a49 OOS r=000244b9 f=00024499 p=000244b6 n=30
       52873.284802: rxrpc_retransmit: c=000004ae q=24499 a=0a xp=63505500
       52873.284804: rxrpc_tx_data: c=000004ae DATA ed1a3584:00000002 000244c2 q=00024499 fl=0b *RETRANS*
       52873.287468: rxrpc_rx_ack: c=000004ae 00012a4a OOS r=000244ba f=00024499 p=000244b7 n=31
       52873.287478: rxrpc_rx_ack: c=000004ae 00012a4b OOS r=000244bb f=00024499 p=000244b8 n=32
      
      At this point, the server's receive window is full (n=32) with presumably 1
      NAK'd packet and 31 ACK'd packets.  We can't transmit any more packets.
      
       52873.287488: rxrpc_retransmit: c=000004ae q=24499 a=0a xp=61327980
       52873.287489: rxrpc_tx_data: c=000004ae DATA ed1a3584:00000002 000244c3 q=00024499 fl=0b *RETRANS*
       52873.293850: rxrpc_rx_ack: c=000004ae 00012a4c DLY r=000244bc f=000244a0 p=00024499 n=25
      
      And now we've received an ACK indicating that a DATA retransmission was
      received.  7 packets have been processed (the occupied part of the window
      moved, as indicated by f= and n=).
      
       52873.293853: rxrpc_rx_discard_ack: c=000004ae r=00012a4c 000244a0<00024499 00024499<000244b8
      
      However, the DLY ACK gets discarded because its previousPacket has gone
      backwards (from p=000244b8, in the ACK at 52873.287478 to p=00024499 in the
      ACK at 52873.293850).
      
      We then end up in a continuous cycle of retransmit/discard.  kafs fails to
      update its window because it's discarding the ACKs and can't transmit an
      extra packet that would clear the issue because the window is full.
      OpenAFS doesn't change the previousPacket value in the ACKs because no new
      DATA packets are received with a different previousPacket number.
      
      Fix this by altering the discard check to only discard an ACK based on
      previousPacket if there was no advance in the firstPacket.  This allows us
      to transmit a new packet which will cause previousPacket to advance in the
      next ACK.
      
      The check, however, needs to allow for the possibility that previousPacket
      may actually have had the serial number placed in it instead - in which
      case it will go outside the window and we should ignore it.
      
      Fixes: 1a2391c3 ("rxrpc: Fix detection of out of order acks")
      Reported-by: default avatarDave Botsch <botsch@cnf.cornell.edu>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      441fdee1
    • David Howells's avatar
      rxrpc: Trace discarded ACKs · d1f12947
      David Howells authored
      Add a tracepoint to track received ACKs that are discarded due to being
      outside of the Tx window.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      d1f12947
  2. 11 May, 2020 1 commit
    • David Howells's avatar
      rxrpc: Fix the excessive initial retransmission timeout · c410bf01
      David Howells authored
      rxrpc currently uses a fixed 4s retransmission timeout until the RTT is
      sufficiently sampled.  This can cause problems with some fileservers with
      calls to the cache manager in the afs filesystem being dropped from the
      fileserver because a packet goes missing and the retransmission timeout is
      greater than the call expiry timeout.
      
      Fix this by:
      
       (1) Copying the RTT/RTO calculation code from Linux's TCP implementation
           and altering it to fit rxrpc.
      
       (2) Altering the various users of the RTT to make use of the new SRTT
           value.
      
       (3) Replacing the use of rxrpc_resend_timeout to use the calculated RTO
           value instead (which is needed in jiffies), along with a backoff.
      
      Notes:
      
       (1) rxrpc provides RTT samples by matching the serial numbers on outgoing
           DATA packets that have the RXRPC_REQUEST_ACK set and PING ACK packets
           against the reference serial number in incoming REQUESTED ACK and
           PING-RESPONSE ACK packets.
      
       (2) Each packet that is transmitted on an rxrpc connection gets a new
           per-connection serial number, even for retransmissions, so an ACK can
           be cross-referenced to a specific trigger packet.  This allows RTT
           information to be drawn from retransmitted DATA packets also.
      
       (3) rxrpc maintains the RTT/RTO state on the rxrpc_peer record rather than
           on an rxrpc_call because many RPC calls won't live long enough to
           generate more than one sample.
      
       (4) The calculated SRTT value is in units of 8ths of a microsecond rather
           than nanoseconds.
      
      The (S)RTT and RTO values are displayed in /proc/net/rxrpc/peers.
      
      Fixes: 17926a79 ([AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both"")
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      c410bf01
  3. 29 Apr, 2020 2 commits
    • Florian Westphal's avatar
      mptcp: replace mptcp_disconnect with a stub · 42c556fe
      Florian Westphal authored
      Paolo points out that mptcp_disconnect is bogus:
      "lock_sock(sk);
      looks suspicious (lock should be already held by the caller)
      And call to: tcp_disconnect(sk, flags); too, sk is not a tcp
      socket".
      
      ->disconnect() gets called from e.g. inet_stream_connect when
      one tries to disassociate a connected socket again (to re-connect
      without closing the socket first).
      MPTCP however uses mptcp_stream_connect, not inet_stream_connect,
      for the mptcp-socket connect call.
      
      inet_stream_connect only gets called indirectly, for the tcp socket,
      so any ->disconnect() calls end up calling tcp_disconnect for that
      tcp subflow sk.
      
      This also explains why syzkaller has not yet reported a problem
      here.  So for now replace this with a stub that doesn't do anything.
      
      Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/14Acked-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      42c556fe
    • Jason Yan's avatar
      net: dsa: mv88e6xxx: remove duplicate assignment of struct members · 98123074
      Jason Yan authored
      These struct members named 'phylink_validate' was assigned twice:
      
      static const struct mv88e6xxx_ops mv88e6190_ops = {
      	......
      	.phylink_validate = mv88e6390_phylink_validate,
      	......
      	.phylink_validate = mv88e6390_phylink_validate,
      };
      
      static const struct mv88e6xxx_ops mv88e6190x_ops = {
      	......
      	.phylink_validate = mv88e6390_phylink_validate,
      	......
      	.phylink_validate = mv88e6390x_phylink_validate,
      };
      
      static const struct mv88e6xxx_ops mv88e6191_ops = {
      	......
      	.phylink_validate = mv88e6390_phylink_validate,
      	......
      	.phylink_validate = mv88e6390_phylink_validate,
      };
      
      static const struct mv88e6xxx_ops mv88e6290_ops = {
      	......
      	.phylink_validate = mv88e6390_phylink_validate,
      	......
      	.phylink_validate = mv88e6390_phylink_validate,
      };
      
      Remove all the first one and leave the second one which are been used in
      fact. Be aware that for 'mv88e6190x_ops' the assignment functions is
      different while the others are all the same. This fixes the following
      coccicheck warning:
      
      drivers/net/dsa/mv88e6xxx/chip.c:3911:48-49: phylink_validate: first
      occurrence line 3965, second occurrence line 3967
      drivers/net/dsa/mv88e6xxx/chip.c:3970:49-50: phylink_validate: first
      occurrence line 4024, second occurrence line 4026
      drivers/net/dsa/mv88e6xxx/chip.c:4029:48-49: phylink_validate: first
      occurrence line 4082, second occurrence line 4085
      drivers/net/dsa/mv88e6xxx/chip.c:4184:48-49: phylink_validate: first
      occurrence line 4238, second occurrence line 4242
      
      Fixes: 4262c38d ("net: dsa: mv88e6xxx: Add SERDES stats counters to all 6390 family members")
      Signed-off-by: default avatarJason Yan <yanaijie@huawei.com>
      Reviewed-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      98123074
  4. 28 Apr, 2020 2 commits
    • YueHaibing's avatar
      net/x25: Fix null-ptr-deref in x25_disconnect · 8999dc89
      YueHaibing authored
      We should check null before do x25_neigh_put in x25_disconnect,
      otherwise may cause null-ptr-deref like this:
      
       #include <sys/socket.h>
       #include <linux/x25.h>
      
       int main() {
          int sck_x25;
          sck_x25 = socket(AF_X25, SOCK_SEQPACKET, 0);
          close(sck_x25);
          return 0;
       }
      
      BUG: kernel NULL pointer dereference, address: 00000000000000d8
      CPU: 0 PID: 4817 Comm: t2 Not tainted 5.7.0-rc3+ #159
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-
      RIP: 0010:x25_disconnect+0x91/0xe0
      Call Trace:
       x25_release+0x18a/0x1b0
       __sock_release+0x3d/0xc0
       sock_close+0x13/0x20
       __fput+0x107/0x270
       ____fput+0x9/0x10
       task_work_run+0x6d/0xb0
       exit_to_usermode_loop+0x102/0x110
       do_syscall_64+0x23c/0x260
       entry_SYSCALL_64_after_hwframe+0x49/0xb3
      
      Reported-by: syzbot+6db548b615e5aeefdce2@syzkaller.appspotmail.com
      Fixes: 4becb7ee ("net/x25: Fix x25_neigh refcnt leak when x25 disconnect")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8999dc89
    • Gavin Shan's avatar
      net/ena: Fix build warning in ena_xdp_set() · caec6619
      Gavin Shan authored
      This fixes the following build warning in ena_xdp_set(), which is
      observed on aarch64 with 64KB page size.
      
         In file included from ./include/net/inet_sock.h:19,
            from ./include/net/ip.h:27,
            from drivers/net/ethernet/amazon/ena/ena_netdev.c:46:
         drivers/net/ethernet/amazon/ena/ena_netdev.c: In function         \
         ‘ena_xdp_set’:                                                    \
         drivers/net/ethernet/amazon/ena/ena_netdev.c:557:6: warning:      \
         format ‘%lu’                                                      \
         expects argument of type ‘long unsigned int’, but argument 4      \
         has type ‘int’                                                    \
         [-Wformat=] "Failed to set xdp program, the current MTU (%d) is   \
         larger than the maximum allowed MTU (%lu) while xdp is on",
      Signed-off-by: default avatarGavin Shan <gshan@redhat.com>
      Acked-by: default avatarShay Agroskin <shayagr@amazon.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      caec6619
  5. 27 Apr, 2020 20 commits
  6. 26 Apr, 2020 2 commits
  7. 25 Apr, 2020 11 commits
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace · b2768df2
      Linus Torvalds authored
      Pull pid leak fix from Eric Biederman:
       "Oleg noticed that put_pid(thread_pid) was not getting called when proc
        was not compiled in.
      
        Let's get that fixed before 5.7 is released and causes problems for
        anyone"
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace:
        proc: Put thread_pid in release_task not proc_flush_pid
      b2768df2
    • Linus Torvalds's avatar
      Merge tag 'timers-urgent-2020-04-25' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · acd62944
      Linus Torvalds authored
      Pull timer fixlet from Ingo Molnar:
       "A single fix for a comment that may show up in DocBook output"
      
      * tag 'timers-urgent-2020-04-25' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        vdso/datapage: Use correct clock mode name in comment
      acd62944
    • Linus Torvalds's avatar
      Merge tag 'sched-urgent-2020-04-25' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 05db498a
      Linus Torvalds authored
      Pull scheduler fixes from Ingo Molnar:
       "Misc fixes:
      
         - an uclamp accounting fix
      
         - three frequency invariance fixes and a readability improvement"
      
      * tag 'sched-urgent-2020-04-25' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        sched/core: Fix reset-on-fork from RT with uclamp
        x86, sched: Move check for CPU type to caller function
        x86, sched: Don't enable static key when starting secondary CPUs
        x86, sched: Account for CPUs with less than 4 cores in freq. invariance
        x86, sched: Bail out of frequency invariance if base frequency is unknown
      05db498a
    • Linus Torvalds's avatar
      Merge tag 'perf-urgent-2020-04-25' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · e1858800
      Linus Torvalds authored
      Pull perf fixes from Ingo Molnar:
       "Two changes:
      
         - fix exit event records
      
         - extend x86 PMU driver enumeration to add Intel Jasper Lake CPU
           support"
      
      * tag 'perf-urgent-2020-04-25' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        perf/core: fix parent pid/tid in task exit events
        perf/x86/cstate: Add Jasper Lake CPU support
      e1858800
    • Linus Torvalds's avatar
      Merge tag 'objtool-urgent-2020-04-25' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 9b3e59e3
      Linus Torvalds authored
      Pull objtool fixes from Ingo Molnar:
       "Two fixes: fix an off-by-one bug, and fix 32-bit builds on 64-bit
        systems"
      
      * tag 'objtool-urgent-2020-04-25' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        objtool: Fix off-by-one in symbol_by_offset()
        objtool: Fix 32bit cross builds
      9b3e59e3
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net · ab51cac0
      Linus Torvalds authored
      Pull networking fixes from David Miller:
      
       1) Fix memory leak in netfilter flowtable, from Roi Dayan.
      
       2) Ref-count leaks in netrom and tipc, from Xiyu Yang.
      
       3) Fix warning when mptcp socket is never accepted before close, from
          Florian Westphal.
      
       4) Missed locking in ovs_ct_exit(), from Tonghao Zhang.
      
       5) Fix large delays during PTP synchornization in cxgb4, from Rahul
          Lakkireddy.
      
       6) team_mode_get() can hang, from Taehee Yoo.
      
       7) Need to use kvzalloc() when allocating fw tracer in mlx5 driver,
          from Niklas Schnelle.
      
       8) Fix handling of bpf XADD on BTF memory, from Jann Horn.
      
       9) Fix BPF_STX/BPF_B encoding in x86 bpf jit, from Luke Nelson.
      
      10) Missing queue memory release in iwlwifi pcie code, from Johannes
          Berg.
      
      11) Fix NULL deref in macvlan device event, from Taehee Yoo.
      
      12) Initialize lan87xx phy correctly, from Yuiko Oshino.
      
      13) Fix looping between VRF and XFRM lookups, from David Ahern.
      
      14) etf packet scheduler assumes all sockets are full sockets, which is
          not necessarily true. From Eric Dumazet.
      
      15) Fix mptcp data_fin handling in RX path, from Paolo Abeni.
      
      16) fib_select_default() needs to handle nexthop objects, from David
          Ahern.
      
      17) Use GFP_ATOMIC under spinlock in mac80211_hwsim, from Wei Yongjun.
      
      18) vxlan and geneve use wrong nlattr array, from Sabrina Dubroca.
      
      19) Correct rx/tx stats in bcmgenet driver, from Doug Berger.
      
      20) BPF_LDX zero-extension is encoded improperly in x86_32 bpf jit, fix
          from Luke Nelson.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (100 commits)
        selftests/bpf: Fix a couple of broken test_btf cases
        tools/runqslower: Ensure own vmlinux.h is picked up first
        bpf: Make bpf_link_fops static
        bpftool: Respect the -d option in struct_ops cmd
        selftests/bpf: Add test for freplace program with expected_attach_type
        bpf: Propagate expected_attach_type when verifying freplace programs
        bpf: Fix leak in LINK_UPDATE and enforce empty old_prog_fd
        bpf, x86_32: Fix logic error in BPF_LDX zero-extension
        bpf, x86_32: Fix clobbering of dst for BPF_JSET
        bpf, x86_32: Fix incorrect encoding in BPF_LDX zero-extension
        bpf: Fix reStructuredText markup
        net: systemport: suppress warnings on failed Rx SKB allocations
        net: bcmgenet: suppress warnings on failed Rx SKB allocations
        macsec: avoid to set wrong mtu
        mac80211: sta_info: Add lockdep condition for RCU list usage
        mac80211: populate debugfs only after cfg80211 init
        net: bcmgenet: correct per TX/RX ring statistics
        net: meth: remove spurious copyright text
        net: phy: bcm84881: clear settings on link down
        chcr: Fix CPU hard lockup
        ...
      ab51cac0
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf · 167ff131
      David S. Miller authored
      Alexei Starovoitov says:
      
      ====================
      pull-request: bpf 2020-04-24
      
      The following pull-request contains BPF updates for your *net* tree.
      
      We've added 17 non-merge commits during the last 5 day(s) which contain
      a total of 19 files changed, 203 insertions(+), 85 deletions(-).
      
      The main changes are:
      
      1) link_update fix, from Andrii.
      
      2) libbpf get_xdp_id fix, from David.
      
      3) xadd verifier fix, from Jann.
      
      4) x86-32 JIT fixes, from Luke and Wang.
      
      5) test_btf fix, from Stanislav.
      
      6) freplace verifier fix, from Toke.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      167ff131
    • Stanislav Fomichev's avatar
      selftests/bpf: Fix a couple of broken test_btf cases · e1cebd84
      Stanislav Fomichev authored
      Commit 51c39bb1 ("bpf: Introduce function-by-function verification")
      introduced function linkage flag and changed the error message from
      "vlen != 0" to "Invalid func linkage" and broke some fake BPF programs.
      
      Adjust the test accordingly.
      
      AFACT, the programs don't really need any arguments and only look
      at BTF for maps, so let's drop the args altogether.
      
      Before:
      BTF raw test[103] (func (Non zero vlen)): do_test_raw:3703:FAIL expected
      err_str:vlen != 0
      magic: 0xeb9f
      version: 1
      flags: 0x0
      hdr_len: 24
      type_off: 0
      type_len: 72
      str_off: 72
      str_len: 10
      btf_total_size: 106
      [1] INT (anon) size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
      [2] INT (anon) size=4 bits_offset=0 nr_bits=32 encoding=(none)
      [3] FUNC_PROTO (anon) return=0 args=(1 a, 2 b)
      [4] FUNC func type_id=3 Invalid func linkage
      
      BTF libbpf test[1] (test_btf_haskv.o): libbpf: load bpf program failed:
      Invalid argument
      libbpf: -- BEGIN DUMP LOG ---
      libbpf:
      Validating test_long_fname_2() func#1...
      Arg#0 type PTR in test_long_fname_2() is not supported yet.
      processed 0 insns (limit 1000000) max_states_per_insn 0 total_states 0
      peak_states 0 mark_read 0
      
      libbpf: -- END LOG --
      libbpf: failed to load program 'dummy_tracepoint'
      libbpf: failed to load object 'test_btf_haskv.o'
      do_test_file:4201:FAIL bpf_object__load: -4007
      BTF libbpf test[2] (test_btf_newkv.o): libbpf: load bpf program failed:
      Invalid argument
      libbpf: -- BEGIN DUMP LOG ---
      libbpf:
      Validating test_long_fname_2() func#1...
      Arg#0 type PTR in test_long_fname_2() is not supported yet.
      processed 0 insns (limit 1000000) max_states_per_insn 0 total_states 0
      peak_states 0 mark_read 0
      
      libbpf: -- END LOG --
      libbpf: failed to load program 'dummy_tracepoint'
      libbpf: failed to load object 'test_btf_newkv.o'
      do_test_file:4201:FAIL bpf_object__load: -4007
      BTF libbpf test[3] (test_btf_nokv.o): libbpf: load bpf program failed:
      Invalid argument
      libbpf: -- BEGIN DUMP LOG ---
      libbpf:
      Validating test_long_fname_2() func#1...
      Arg#0 type PTR in test_long_fname_2() is not supported yet.
      processed 0 insns (limit 1000000) max_states_per_insn 0 total_states 0
      peak_states 0 mark_read 0
      
      libbpf: -- END LOG --
      libbpf: failed to load program 'dummy_tracepoint'
      libbpf: failed to load object 'test_btf_nokv.o'
      do_test_file:4201:FAIL bpf_object__load: -4007
      
      Fixes: 51c39bb1 ("bpf: Introduce function-by-function verification")
      Signed-off-by: default avatarStanislav Fomichev <sdf@google.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20200422003753.124921-1-sdf@google.com
      e1cebd84
    • Andrii Nakryiko's avatar
      tools/runqslower: Ensure own vmlinux.h is picked up first · dfc55ace
      Andrii Nakryiko authored
      Reorder include paths to ensure that runqslower sources are picking up
      vmlinux.h, generated by runqslower's own Makefile. When runqslower is built
      from selftests/bpf, due to current -I$(BPF_INCLUDE) -I$(OUTPUT) ordering, it
      might pick up not-yet-complete vmlinux.h, generated by selftests Makefile,
      which could lead to compilation errors like [0]. So ensure that -I$(OUTPUT)
      goes first and rely on runqslower's Makefile own dependency chain to ensure
      vmlinux.h is properly completed before source code relying on it is compiled.
      
        [0] https://travis-ci.org/github/libbpf/libbpf/jobs/677905925Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20200422012407.176303-1-andriin@fb.com
      dfc55ace
    • Zou Wei's avatar
      bpf: Make bpf_link_fops static · 6f302bfb
      Zou Wei authored
      Fix the following sparse warning:
      
      kernel/bpf/syscall.c:2289:30: warning: symbol 'bpf_link_fops' was not declared. Should it be static?
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarZou Wei <zou_wei@huawei.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Link: https://lore.kernel.org/bpf/1587609160-117806-1-git-send-email-zou_wei@huawei.com
      6f302bfb
    • Martin KaFai Lau's avatar
      bpftool: Respect the -d option in struct_ops cmd · 32e4c6f4
      Martin KaFai Lau authored
      In the prog cmd, the "-d" option turns on the verifier log.
      This is missed in the "struct_ops" cmd and this patch fixes it.
      
      Fixes: 65c93628 ("bpftool: Add struct_ops support")
      Signed-off-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Reviewed-by: default avatarQuentin Monnet <quentin@isovalent.com>
      Link: https://lore.kernel.org/bpf/20200424182911.1259355-1-kafai@fb.com
      32e4c6f4