1. 31 7月, 2018 4 次提交
  2. 30 7月, 2018 4 次提交
  3. 29 7月, 2018 13 次提交
    • N
      tcp_bbr: fix bw probing to raise in-flight data for very small BDPs · 383d4709
      Neal Cardwell 提交于
      For some very small BDPs (with just a few packets) there was a
      quantization effect where the target number of packets in flight
      during the super-unity-gain (1.25x) phase of gain cycling was
      implicitly truncated to a number of packets no larger than the normal
      unity-gain (1.0x) phase of gain cycling. This meant that in multi-flow
      scenarios some flows could get stuck with a lower bandwidth, because
      they did not push enough packets inflight to discover that there was
      more bandwidth available. This was really only an issue in multi-flow
      LAN scenarios, where RTTs and BDPs are low enough for this to be an
      issue.
      
      This fix ensures that gain cycling can raise inflight for small BDPs
      by ensuring that in PROBE_BW mode target inflight values with a
      super-unity gain are always greater than inflight values with a gain
      <= 1. Importantly, this applies whether the inflight value is
      calculated for use as a cwnd value, or as a target inflight value for
      the end of the super-unity phase in bbr_is_next_cycle_phase() (both
      need to be bigger to ensure we can probe with more packets in flight
      reliably).
      
      This is a candidate fix for stable releases.
      
      Fixes: 0f8782ea ("tcp_bbr: add BBR congestion control")
      Signed-off-by: NNeal Cardwell <ncardwell@google.com>
      Acked-by: NYuchung Cheng <ycheng@google.com>
      Acked-by: NSoheil Hassas Yeganeh <soheil@google.com>
      Acked-by: NPriyaranjan Jha <priyarjha@google.com>
      Reviewed-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      383d4709
    • D
      Merge branch 'net-socket-Fix-potential-spectre-v1-gadgets' · 6d27c6dd
      David S. Miller 提交于
      Jeremy Cline says:
      
      ====================
      net: socket: Fix potential spectre v1 gadgets
      
      This fixes a pair of potential spectre v1 gadgets.
      
      Note that because the speculation window is large, the policy is to stop
      the speculative out-of-bounds load and not worry if the attack can be
      completed with a dependent load or store[0].
      
      [0] https://marc.info/?l=linux-kernel&m=152449131114778
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6d27c6dd
    • J
      net: socket: Fix potential spectre v1 gadget in sock_is_registered · e978de7a
      Jeremy Cline 提交于
      'family' can be a user-controlled value, so sanitize it after the bounds
      check to avoid speculative out-of-bounds access.
      
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJeremy Cline <jcline@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e978de7a
    • J
      net: socket: fix potential spectre v1 gadget in socketcall · c8e8cd57
      Jeremy Cline 提交于
      'call' is a user-controlled value, so sanitize the array index after the
      bounds check to avoid speculating past the bounds of the 'nargs' array.
      
      Found with the help of Smatch:
      
      net/socket.c:2508 __do_sys_socketcall() warn: potential spectre issue
      'nargs' [r] (local cap)
      
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJeremy Cline <jcline@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c8e8cd57
    • D
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf · 958b4cd8
      David S. Miller 提交于
      Daniel Borkmann says:
      
      ====================
      pull-request: bpf 2018-07-28
      
      The following pull-request contains BPF updates for your *net* tree.
      
      The main changes are:
      
      1) API fixes for libbpf's BTF mapping of map key/value types in order
         to make them compatible with iproute2's BPF_ANNOTATE_KV_PAIR()
         markings, from Martin.
      
      2) Fix AF_XDP to not report POLLIN prematurely by using the non-cached
         consumer pointer of the RX queue, from Björn.
      
      3) Fix __xdp_return() to check for NULL pointer after the rhashtable
         lookup that retrieves the allocator object, from Taehee.
      
      4) Fix x86-32 JIT to adjust ebp register in prologue and epilogue
         by 4 bytes which got removed from overall stack usage, from Wang.
      
      5) Fix bpf_skb_load_bytes_relative() length check to use actual
         packet length, from Daniel.
      
      6) Fix uninitialized return code in libbpf bpf_perf_event_read_simple()
         handler, from Thomas.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      958b4cd8
    • A
      net: mdio-mux: bcm-iproc: fix wrong getter and setter pair · b0753408
      Anton Vasilyev 提交于
      mdio_mux_iproc_probe() uses platform_set_drvdata() to store md pointer
      in device, whereas mdio_mux_iproc_remove() restores md pointer by
      dev_get_platdata(&pdev->dev). This leads to wrong resources release.
      
      The patch replaces getter to platform_get_drvdata.
      
      Fixes: 98bc865a ("net: mdio-mux: Add MDIO mux driver for iProc SoCs")
      Signed-off-by: NAnton Vasilyev <vasilyev@ispras.ru>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b0753408
    • L
      ipv4: remove BUG_ON() from fib_compute_spec_dst · 9fc12023
      Lorenzo Bianconi 提交于
      Remove BUG_ON() from fib_compute_spec_dst routine and check
      in_dev pointer during flowi4 data structure initialization.
      fib_compute_spec_dst routine can be run concurrently with device removal
      where ip_ptr net_device pointer is set to NULL. This can happen
      if userspace enables pkt info on UDP rx socket and the device
      is removed while traffic is flowing
      
      Fixes: 35ebf65e ("ipv4: Create and use fib_compute_spec_dst() helper")
      Signed-off-by: NLorenzo Bianconi <lorenzo.bianconi@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9fc12023
    • G
      enic: handle mtu change for vf properly · ab123fe0
      Govindarajulu Varadarajan 提交于
      When driver gets notification for mtu change, driver does not handle it for
      all RQs. It handles only RQ[0].
      
      Fix is to use enic_change_mtu() interface to change mtu for vf.
      Signed-off-by: NGovindarajulu Varadarajan <gvaradar@cisco.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ab123fe0
    • S
      net: lan78xx: fix rx handling before first packet is send · 136f55f6
      Stefan Wahren 提交于
      As long the bh tasklet isn't scheduled once, no packet from the rx path
      will be handled. Since the tx path also schedule the same tasklet
      this situation only persits until the first packet transmission.
      So fix this issue by scheduling the tasklet after link reset.
      
      Link: https://github.com/raspberrypi/linux/issues/2617
      Fixes: 55d7de9d ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet")
      Suggested-by: NFloris Bos <bos@je-eigen-domein.nl>
      Signed-off-by: NStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      136f55f6
    • J
      nfp: flower: fix port metadata conversion bug · ee614c87
      John Hurley 提交于
      Function nfp_flower_repr_get_type_and_port expects an enum nfp_repr_type
      return value but, if the repr type is unknown, returns a value of type
      enum nfp_flower_cmsg_port_type.  This means that if FW encodes the port
      ID in a way the driver does not understand instead of dropping the frame
      driver may attribute it to a physical port (uplink) provided the port
      number is less than physical port count.
      
      Fix this and ensure a net_device of NULL is returned if the repr can not
      be determined.
      
      Fixes: 1025351a ("nfp: add flower app")
      Signed-off-by: NJohn Hurley <john.hurley@netronome.com>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ee614c87
    • T
      bpf: use GFP_ATOMIC instead of GFP_KERNEL in bpf_parse_prog() · 71eb5255
      Taehee Yoo 提交于
      bpf_parse_prog() is protected by rcu_read_lock().
      so that GFP_KERNEL is not allowed in the bpf_parse_prog().
      
      [51015.579396] =============================
      [51015.579418] WARNING: suspicious RCU usage
      [51015.579444] 4.18.0-rc6+ #208 Not tainted
      [51015.579464] -----------------------------
      [51015.579488] ./include/linux/rcupdate.h:303 Illegal context switch in RCU read-side critical section!
      [51015.579510] other info that might help us debug this:
      [51015.579532] rcu_scheduler_active = 2, debug_locks = 1
      [51015.579556] 2 locks held by ip/1861:
      [51015.579577]  #0: 00000000a8c12fd1 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x2e0/0x910
      [51015.579711]  #1: 00000000bf815f8e (rcu_read_lock){....}, at: lwtunnel_build_state+0x96/0x390
      [51015.579842] stack backtrace:
      [51015.579869] CPU: 0 PID: 1861 Comm: ip Not tainted 4.18.0-rc6+ #208
      [51015.579891] Hardware name: To be filled by O.E.M. To be filled by O.E.M./Aptio CRB, BIOS 5.6.5 07/08/2015
      [51015.579911] Call Trace:
      [51015.579950]  dump_stack+0x74/0xbb
      [51015.580000]  ___might_sleep+0x16b/0x3a0
      [51015.580047]  __kmalloc_track_caller+0x220/0x380
      [51015.580077]  kmemdup+0x1c/0x40
      [51015.580077]  bpf_parse_prog+0x10e/0x230
      [51015.580164]  ? kasan_kmalloc+0xa0/0xd0
      [51015.580164]  ? bpf_destroy_state+0x30/0x30
      [51015.580164]  ? bpf_build_state+0xe2/0x3e0
      [51015.580164]  bpf_build_state+0x1bb/0x3e0
      [51015.580164]  ? bpf_parse_prog+0x230/0x230
      [51015.580164]  ? lock_is_held_type+0x123/0x1a0
      [51015.580164]  lwtunnel_build_state+0x1aa/0x390
      [51015.580164]  fib_create_info+0x1579/0x33d0
      [51015.580164]  ? sched_clock_local+0xe2/0x150
      [51015.580164]  ? fib_info_update_nh_saddr+0x1f0/0x1f0
      [51015.580164]  ? sched_clock_local+0xe2/0x150
      [51015.580164]  fib_table_insert+0x201/0x1990
      [51015.580164]  ? lock_downgrade+0x610/0x610
      [51015.580164]  ? fib_table_lookup+0x1920/0x1920
      [51015.580164]  ? lwtunnel_valid_encap_type.part.6+0xcb/0x3a0
      [51015.580164]  ? rtm_to_fib_config+0x637/0xbd0
      [51015.580164]  inet_rtm_newroute+0xed/0x1b0
      [51015.580164]  ? rtm_to_fib_config+0xbd0/0xbd0
      [51015.580164]  rtnetlink_rcv_msg+0x331/0x910
      [ ... ]
      
      Fixes: 3a0af8fd ("bpf: BPF for lightweight tunnel infrastructure")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      71eb5255
    • D
      bpf: fix bpf_skb_load_bytes_relative pkt length check · 3eee1f75
      Daniel Borkmann 提交于
      The len > skb_headlen(skb) cannot be used as a maximum upper bound
      for the packet length since it does not have any relation to the full
      linear packet length when filtering is used from upper layers (e.g.
      in case of reuseport BPF programs) as by then skb->data, skb->len
      already got mangled through __skb_pull() and others.
      
      Fixes: 4e1ec56c ("bpf: add skb_load_bytes_relative helper")
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NMartin KaFai Lau <kafai@fb.com>
      3eee1f75
    • T
      perf build: Build error in libbpf missing initialization · b611da43
      Thomas Richter 提交于
      In linux-next tree compiling the perf tool with additional make flags
      EXTRA_CFLAGS="-Wp,-D_FORTIFY_SOURCE=2 -O2" causes a compiler error.
      It is the warning 'variable may be used uninitialized' which is treated
      as error: I compile it using a FEDORA 28 installation, my gcc compiler
      version: gcc (GCC) 8.0.1 20180324 (Red Hat 8.0.1-0.20). The file that
      causes the error is tools/lib/bpf/libbpf.c.
      
        [root@p23lp27] # make V=1 EXTRA_CFLAGS="-Wp,-D_FORTIFY_SOURCE=2 -O2"
        [...]
        Makefile.config:849: No openjdk development package found, please
           install JDK package, e.g. openjdk-8-jdk, java-1.8.0-openjdk-devel
        Warning: Kernel ABI header at 'tools/include/uapi/linux/if_link.h'
                differs from latest version at 'include/uapi/linux/if_link.h'
          CC       libbpf.o
        libbpf.c: In function ‘bpf_perf_event_read_simple’:
        libbpf.c:2342:6: error: ‘ret’ may be used uninitialized in this
        			function [-Werror=maybe-uninitialized]
          int ret;
              ^
        cc1: all warnings being treated as errors
        mv: cannot stat './.libbpf.o.tmp': No such file or directory
        /home6/tmricht/linux-next/tools/build/Makefile.build:96: recipe for target 'libbpf.o' failed
      Suggested-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NThomas Richter <tmricht@linux.ibm.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      b611da43
  4. 28 7月, 2018 1 次提交
    • D
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec · d0fdb366
      David S. Miller 提交于
      Steffen Klassert says:
      
      ====================
      pull request (net): ipsec 2018-07-27
      
      1) Fix PMTU handling of vti6. We update the PMTU on
         the xfrm dst_entry which is not cached anymore
         after the flowchache removal. So update the
         PMTU of the original dst_entry instead.
         From Eyal Birger.
      
      2) Fix a leak of kernel memory to userspace.
         From Eric Dumazet.
      
      3) Fix a possible dst_entry memleak in xfrm_lookup_route.
         From Tommi Rantala.
      
      4) Fix a skb leak in case we can't call nlmsg_multicast
         from xfrm_nlmsg_multicast. From Florian Westphal.
      
      5) Fix a leak of a temporary buffer in the error path of
         esp6_input. From Zhen Lei.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d0fdb366
  5. 27 7月, 2018 6 次提交
    • G
      net: ena: Fix use of uninitialized DMA address bits field · 101f0cd4
      Gal Pressman 提交于
      UBSAN triggers the following undefined behaviour warnings:
      [...]
      [   13.236124] UBSAN: Undefined behaviour in drivers/net/ethernet/amazon/ena/ena_eth_com.c:468:22
      [   13.240043] shift exponent 64 is too large for 64-bit type 'long long unsigned int'
      [...]
      [   13.744769] UBSAN: Undefined behaviour in drivers/net/ethernet/amazon/ena/ena_eth_com.c:373:4
      [   13.748694] shift exponent 64 is too large for 64-bit type 'long long unsigned int'
      [...]
      
      When splitting the address to high and low, GENMASK_ULL is used to generate
      a bitmask with dma_addr_bits field from io_sq (in ena_com_prepare_tx and
      ena_com_add_single_rx_desc).
      The problem is that dma_addr_bits is not initialized with a proper value
      (besides being cleared in ena_com_create_io_queue).
      Assign dma_addr_bits the correct value that is stored in ena_dev when
      initializing the SQ.
      
      Fixes: 1738cd3e ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)")
      Signed-off-by: NGal Pressman <pressmangal@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      101f0cd4
    • M
      bpf: btf: Use exact btf value_size match in map_check_btf() · 5f300e80
      Martin KaFai Lau 提交于
      The current map_check_btf() in BPF_MAP_TYPE_ARRAY rejects
      '> map->value_size' to ensure map_seq_show_elem() will not
      access things beyond an array element.
      
      Yonghong suggested that using '!=' is a more correct
      check.  The 8 bytes round_up on value_size is stored
      in array->elem_size.  Hence, using '!=' on map->value_size
      is a proper check.
      
      This patch also adds new tests to check the btf array
      key type and value type.  Two of these new tests verify
      the btf's value_size (the change in this patch).
      
      It also fixes two existing tests that wrongly encoded
      a btf's type size (pprint_test) and the value_type_id (in one
      of the raw_tests[]).  However, that do not affect these two
      BTF verification tests before or after this test changes.
      These two tests mainly failed at array creation time after
      this patch.
      
      Fixes: a26ca7c9 ("bpf: btf: Add pretty print support to the basic arraymap")
      Suggested-by: NYonghong Song <yhs@fb.com>
      Acked-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      5f300e80
    • T
      xdp: add NULL pointer check in __xdp_return() · 36e0f12b
      Taehee Yoo 提交于
      rhashtable_lookup() can return NULL. so that NULL pointer
      check routine should be added.
      
      Fixes: 02b55e56 ("xdp: add MEM_TYPE_ZERO_COPY")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Acked-by: NMartin KaFai Lau <kafai@fb.com>
      Acked-by: NBjörn Töpel <bjorn.topel@intel.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      36e0f12b
    • A
      RDS: RDMA: Fix the NULL-ptr deref in rds_ib_get_mr · 9e630bcb
      Avinash Repaka 提交于
      Registration of a memory region(MR) through FRMR/fastreg(unlike FMR)
      needs a connection/qp. With a proxy qp, this dependency on connection
      will be removed, but that needs more infrastructure patches, which is a
      work in progress.
      
      As an intermediate fix, the get_mr returns EOPNOTSUPP when connection
      details are not populated. The MR registration through sendmsg() will
      continue to work even with fast registration, since connection in this
      case is formed upfront.
      
      This patch fixes the following crash:
      kasan: GPF could be caused by NULL-ptr deref or user memory access
      general protection fault: 0000 [#1] SMP KASAN
      Modules linked in:
      CPU: 1 PID: 4244 Comm: syzkaller468044 Not tainted 4.16.0-rc6+ #361
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
      Google 01/01/2011
      RIP: 0010:rds_ib_get_mr+0x5c/0x230 net/rds/ib_rdma.c:544
      RSP: 0018:ffff8801b059f890 EFLAGS: 00010202
      RAX: dffffc0000000000 RBX: ffff8801b07e1300 RCX: ffffffff8562d96e
      RDX: 000000000000000d RSI: 0000000000000001 RDI: 0000000000000068
      RBP: ffff8801b059f8b8 R08: ffffed0036274244 R09: ffff8801b13a1200
      R10: 0000000000000004 R11: ffffed0036274243 R12: ffff8801b13a1200
      R13: 0000000000000001 R14: ffff8801ca09fa9c R15: 0000000000000000
      FS:  00007f4d050af700(0000) GS:ffff8801db300000(0000)
      knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007f4d050aee78 CR3: 00000001b0d9b006 CR4: 00000000001606e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       __rds_rdma_map+0x710/0x1050 net/rds/rdma.c:271
       rds_get_mr_for_dest+0x1d4/0x2c0 net/rds/rdma.c:357
       rds_setsockopt+0x6cc/0x980 net/rds/af_rds.c:347
       SYSC_setsockopt net/socket.c:1849 [inline]
       SyS_setsockopt+0x189/0x360 net/socket.c:1828
       do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x42/0xb7
      RIP: 0033:0x4456d9
      RSP: 002b:00007f4d050aedb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
      RAX: ffffffffffffffda RBX: 00000000006dac3c RCX: 00000000004456d9
      RDX: 0000000000000007 RSI: 0000000000000114 RDI: 0000000000000004
      RBP: 00000000006dac38 R08: 00000000000000a0 R09: 0000000000000000
      R10: 0000000020000380 R11: 0000000000000246 R12: 0000000000000000
      R13: 00007fffbfb36d6f R14: 00007f4d050af9c0 R15: 0000000000000005
      Code: fa 48 c1 ea 03 80 3c 02 00 0f 85 cc 01 00 00 4c 8b bb 80 04 00 00
      48
      b8 00 00 00 00 00 fc ff df 49 8d 7f 68 48 89 fa 48 c1 ea 03 <80> 3c 02
      00 0f
      85 9c 01 00 00 4d 8b 7f 68 48 b8 00 00 00 00 00
      RIP: rds_ib_get_mr+0x5c/0x230 net/rds/ib_rdma.c:544 RSP:
      ffff8801b059f890
      ---[ end trace 7e1cea13b85473b0 ]---
      
      Reported-by: syzbot+b51c77ef956678a65834@syzkaller.appspotmail.com
      Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@oracle.com>
      Signed-off-by: NAvinash Repaka <avinash.repaka@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9e630bcb
    • T
      net: rollback orig value on failure of dev_qdisc_change_tx_queue_len · 7effaf06
      Tariq Toukan 提交于
      Fix dev_change_tx_queue_len so it rolls back original value
      upon a failure in dev_qdisc_change_tx_queue_len.
      This is already done for notifirers' failures, share the code.
      
      In case of failure in dev_qdisc_change_tx_queue_len, some tx queues
      would still be of the new length, while they should be reverted.
      Currently, the revert is not done, and is marked with a TODO label
      in dev_qdisc_change_tx_queue_len, and should find some nice solution
      to do it.
      Yet it is still better to not apply the newly requested value.
      
      Fixes: 48bfd55e ("net_sched: plug in qdisc ops change_tx_queue_len")
      Signed-off-by: NTariq Toukan <tariqt@mellanox.com>
      Reviewed-by: NEran Ben Elisha <eranbe@mellanox.com>
      Reported-by: NRan Rozenstein <ranro@mellanox.com>
      Cc: Cong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7effaf06
    • T
      net: fix amd-xgbe flow-control issue · 7f3fc7dd
      tangpengpeng 提交于
      If we enable or disable xgbe flow-control by ethtool ,
      it does't work.Because the parameter is not properly
      assigned,so we need to adjust the assignment order
      of the parameters.
      
      Fixes: c1ce2f77 ("amd-xgbe: Fix flow control setting logic")
      Signed-off-by: Ntangpengpeng <tangpengpeng@higon.com>
      Acked-by: NTom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7f3fc7dd
  6. 26 7月, 2018 8 次提交
  7. 25 7月, 2018 4 次提交