1. 05 Jul, 2019 1 commit
  2. 04 Jul, 2019 5 commits
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next · c4cde580
      David S. Miller authored
      Daniel Borkmann says:
      
      ====================
      pull-request: bpf-next 2019-07-03
      
      The following pull-request contains BPF updates for your *net-next* tree.
      
      There is a minor merge conflict in mlx5 due to 8960b389 ("linux/dim:
      Rename externally used net_dim members") which has been pulled into your
      tree in the meantime, but resolution seems not that bad ... getting current
      bpf-next out now before there's coming more on mlx5. ;) I'm Cc'ing Saeed
      just so he's aware of the resolution below:
      
      ** First conflict in drivers/net/ethernet/mellanox/mlx5/core/en_main.c:
      
        <<<<<<< HEAD
        static int mlx5e_open_cq(struct mlx5e_channel *c,
                                 struct dim_cq_moder moder,
                                 struct mlx5e_cq_param *param,
                                 struct mlx5e_cq *cq)
        =======
        int mlx5e_open_cq(struct mlx5e_channel *c, struct net_dim_cq_moder moder,
                          struct mlx5e_cq_param *param, struct mlx5e_cq *cq)
        >>>>>>> e5a3e259
      
      Resolution is to take the second chunk and rename net_dim_cq_moder into
      dim_cq_moder. Also the signature for mlx5e_open_cq() in ...
      
        drivers/net/ethernet/mellanox/mlx5/core/en.h +977
      
      ... and in mlx5e_open_xsk() ...
      
        drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c +64
      
      ... needs the same rename from net_dim_cq_moder into dim_cq_moder.
      
      ** Second conflict in drivers/net/ethernet/mellanox/mlx5/core/en_main.c:
      
        <<<<<<< HEAD
                int cpu = cpumask_first(mlx5_comp_irq_get_affinity_mask(priv->mdev, ix));
                struct dim_cq_moder icocq_moder = {0, 0};
                struct net_device *netdev = priv->netdev;
                struct mlx5e_channel *c;
                unsigned int irq;
        =======
                struct net_dim_cq_moder icocq_moder = {0, 0};
        >>>>>>> e5a3e259
      
      Take the second chunk and rename net_dim_cq_moder into dim_cq_moder
      as well.
      
      Let me know if you run into any issues. Anyway, the main changes are:
      
      1) Long-awaited AF_XDP support for mlx5e driver, from Maxim.
      
      2) Addition of two new per-cgroup BPF hooks for getsockopt and
         setsockopt along with a new sockopt program type which allows more
         fine-grained pass/reject settings for containers. Also add a sock_ops
         callback that can be selectively enabled on a per-socket basis and is
         executed for every RTT to help tracking TCP statistics, both features
         from Stanislav.
      
      3) Follow-up fix from loops in precision tracking which was not propagating
         precision marks and as a result verifier assumed that some branches were
         not taken and therefore wrongly removed as dead code, from Alexei.
      
      4) Fix BPF cgroup release synchronization race which could lead to a
         double-free if a leaf's cgroup_bpf object is released and a new BPF
         program is attached to the one of ancestor cgroups in parallel, from Roman.
      
      5) Support for bulking XDP_TX on veth devices which improves performance
         in some cases by around 9%, from Toshiaki.
      
      6) Allow for lookups into BPF devmap and improve feedback when calling into
         bpf_redirect_map() as lookup is now performed right away in the helper
         itself, from Toke.
      
      7) Add support for fq's Earliest Departure Time to the Host Bandwidth
         Manager (HBM) sample BPF program, from Lawrence.
      
      8) Various cleanups and minor fixes all over the place from many others.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c4cde580
    • René van Dorst's avatar
      net: ethernet: mediatek: Fix overlapping capability bits. · e2c74694
      René van Dorst authored
      Both MTK_TRGMII_MT7621_CLK and MTK_PATH_BIT are defined as bit 10.
      
      This can causes issues on non-MT7621 devices which has the
      MTK_PATH_BIT(MTK_ETH_PATH_GMAC1_RGMII) and MTK_TRGMII capability set.
      The wrong TRGMII setup code can be executed. The current wrongly executed
      code doesn’t do any harm on MT7623 and the TRGMII setup for the MT7623
      SOC side is done in MT7530 driver So it wasn’t noticed in the test.
      
      Move all capability bits in one enum so that they are all unique and easy
      to expand in the future.
      
      Because mtk_eth_path enum is merged in to mkt_eth_capabilities, the
      variable path value is no longer between 0 to number of paths,
      mtk_eth_path_name can’t be used anymore in this form. Convert the
      mtk_eth_path_name array to a function to lookup the pathname.
      
      The old code walked thru the mtk_eth_path enum, which is also merged
      with mkt_eth_capabilities. Expand array mtk_eth_muxc so it can store the
      name and capability bit of the mux. Convert the code so it can walk thru
      the mtk_eth_muxc array.
      
      Fixes: 8efaa653 ("net: ethernet: mediatek: Add MT7621 TRGMII mode support")
      Signed-off-by: default avatarRené van Dorst <opensource@vdorst.com>
      
      v1->v2:
      - Move all capability bits in one enum, suggested by Willem de Bruijn
      - Convert the mtk_eth_path_name array to a function to lookup the pathname
      - Expand array mtk_eth_muxc so it can also store the name and capability
        bit of the mux
      - Updated commit message
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e2c74694
    • Weifeng Voon's avatar
      net: stmmac: Enable dwmac4 jumbo frame more than 8KiB · c3efed5a
      Weifeng Voon authored
      Enable GMAC v4.xx and beyond to support 16KiB buffer.
      Signed-off-by: default avatarWeifeng Voon <weifeng.voon@intel.com>
      Signed-off-by: default avatarOng Boon Leong <boon.leong.ong@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c3efed5a
    • Vincent Bernat's avatar
      bonding: add an option to specify a delay between peer notifications · 07a4ddec
      Vincent Bernat authored
      Currently, gratuitous ARP/ND packets are sent every `miimon'
      milliseconds. This commit allows a user to specify a custom delay
      through a new option, `peer_notif_delay'.
      
      Like for `updelay' and `downdelay', this delay should be a multiple of
      `miimon' to avoid managing an additional work queue. The configuration
      logic is copied from `updelay' and `downdelay'. However, the default
      value cannot be set using a module parameter: Netlink or sysfs should
      be used to configure this feature.
      
      When setting `miimon' to 100 and `peer_notif_delay' to 500, we can
      observe the 500 ms delay is respected:
      
          20:30:19.354693 ARP, Request who-has 203.0.113.10 tell 203.0.113.10, length 28
          20:30:19.874892 ARP, Request who-has 203.0.113.10 tell 203.0.113.10, length 28
          20:30:20.394919 ARP, Request who-has 203.0.113.10 tell 203.0.113.10, length 28
          20:30:20.914963 ARP, Request who-has 203.0.113.10 tell 203.0.113.10, length 28
      
      In bond_mii_monitor(), I have tried to keep the lock logic readable.
      The change is due to the fact we cannot rely on a notification to
      lower the value of `bond->send_peer_notif' as `NETDEV_NOTIFY_PEERS' is
      only triggered once every N times, while we need to decrement the
      counter each time.
      
      iproute2 also needs to be updated to be able to specify this new
      attribute through `ip link'.
      Signed-off-by: default avatarVincent Bernat <vincent@bernat.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      07a4ddec
    • Colin Ian King's avatar
      net: ethernet: sun: remove redundant assignment to variable err · 2368a870
      Colin Ian King authored
      The variable err is being assigned with a value that is never
      read and it is being updated in the next statement with a new value.
      The assignment is redundant and can be removed.
      
      Addresses-Coverity: ("Unused value")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2368a870
  3. 03 Jul, 2019 26 commits
  4. 02 Jul, 2019 8 commits
    • Petr Machata's avatar
      mlxsw: spectrum_ptp: Fix validation in mlxsw_sp1_ptp_packet_finish() · dbcdb61a
      Petr Machata authored
      Before mlxsw_sp1_ptp_packet_finish() sends the packet back, it validates
      whether the corresponding port is still valid. However the condition is
      incorrect: when mlxsw_sp_port == NULL, the code dereferences the port to
      compare it to skb->dev.
      
      The condition needs to check whether the port is present and skb->dev still
      refers to that port (or else is NULL). If that does not hold, bail out.
      Add a pair of parentheses to fix the condition.
      
      Fixes: d92e4e6e ("mlxsw: spectrum: PTP: Support timestamping on Spectrum-1")
      Reported-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarPetr Machata <petrm@mellanox.com>
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dbcdb61a
    • Heiner Kallweit's avatar
      r8169: add random MAC address fallback · c782e204
      Heiner Kallweit authored
      It was reported that the GPD MicroPC is broken in a way that no valid
      MAC address can be read from the network chip. The vendor driver deals
      with this by assigning a random MAC address as fallback. So let's do
      the same.
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c782e204
    • Heiner Kallweit's avatar
      Revert "r8169: improve handling VLAN tag" · 7424edbb
      Heiner Kallweit authored
      This reverts commit 759d0957.
      
      The patch was based on a misunderstanding. As Al Viro pointed out [0]
      it's simply wrong on big endian. So let's revert it.
      
      [0] https://marc.info/?t=156200975600004&r=1&w=2Reported-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7424edbb
    • Martin Blumenstingl's avatar
      net: stmmac: make "snps,reset-delays-us" optional again · cc5e92c2
      Martin Blumenstingl authored
      Commit 760f1dc2 ("net: stmmac: add sanity check to
      device_property_read_u32_array call") introduced error checking of the
      device_property_read_u32_array() call in stmmac_mdio_reset().
      This results in the following error when the "snps,reset-delays-us"
      property is not defined in devicetree:
        invalid property snps,reset-delays-us
      
      This sanity check made sense until commit 84ce4d0f ("net: stmmac:
      initialize the reset delay array") ensured that there are fallback
      values for the reset delay if the "snps,reset-delays-us" property is
      absent. That was at the cost of making that property mandatory though.
      
      Drop the sanity check for device_property_read_u32_array() and thus make
      the "snps,reset-delays-us" property optional again (avoiding the error
      message while loading the stmmac driver with a .dtb where the property
      is absent).
      
      Fixes: 760f1dc2 ("net: stmmac: add sanity check to device_property_read_u32_array call")
      Signed-off-by: default avatarMartin Blumenstingl <martin.blumenstingl@googlemail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cc5e92c2
    • Eric Dumazet's avatar
      bonding/main: fix NULL dereference in bond_select_active_slave() · b8bd72d3
      Eric Dumazet authored
      A bonding master can be up while best_slave is NULL.
      
      [12105.636318] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
      [12105.638204] mlx4_en: eth1: Linkstate event 1 -> 1
      [12105.648984] IP: bond_select_active_slave+0x125/0x250
      [12105.653977] PGD 0 P4D 0
      [12105.656572] Oops: 0000 [#1] SMP PTI
      [12105.660487] gsmi: Log Shutdown Reason 0x03
      [12105.664620] Modules linked in: kvm_intel loop act_mirred uhaul vfat fat stg_standard_ftl stg_megablocks stg_idt stg_hdi stg elephant_dev_num stg_idt_eeprom w1_therm wire i2c_mux_pca954x i2c_mux mlx4_i2c i2c_usb cdc_acm ehci_pci ehci_hcd i2c_iimc mlx4_en mlx4_ib ib_uverbs ib_core mlx4_core [last unloaded: kvm_intel]
      [12105.685686] mlx4_core 0000:03:00.0: dispatching link up event for port 2
      [12105.685700] mlx4_en: eth2: Linkstate event 2 -> 1
      [12105.685700] mlx4_en: eth2: Link Up (linkstate)
      [12105.724452] Workqueue: bond0 bond_mii_monitor
      [12105.728854] RIP: 0010:bond_select_active_slave+0x125/0x250
      [12105.734355] RSP: 0018:ffffaf146a81fd88 EFLAGS: 00010246
      [12105.739637] RAX: 0000000000000003 RBX: ffff8c62b03c6900 RCX: 0000000000000000
      [12105.746838] RDX: 0000000000000000 RSI: ffffaf146a81fd08 RDI: ffff8c62b03c6000
      [12105.754054] RBP: ffffaf146a81fdb8 R08: 0000000000000001 R09: ffff8c517d387600
      [12105.761299] R10: 00000000001075d9 R11: ffffffffaceba92f R12: 0000000000000000
      [12105.768553] R13: ffff8c8240ae4800 R14: 0000000000000000 R15: 0000000000000000
      [12105.775748] FS:  0000000000000000(0000) GS:ffff8c62bfa40000(0000) knlGS:0000000000000000
      [12105.783892] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [12105.789716] CR2: 0000000000000000 CR3: 0000000d0520e001 CR4: 00000000001626f0
      [12105.796976] Call Trace:
      [12105.799446]  [<ffffffffac31d387>] bond_mii_monitor+0x497/0x6f0
      [12105.805317]  [<ffffffffabd42643>] process_one_work+0x143/0x370
      [12105.811225]  [<ffffffffabd42c7a>] worker_thread+0x4a/0x360
      [12105.816761]  [<ffffffffabd48bc5>] kthread+0x105/0x140
      [12105.821865]  [<ffffffffabd42c30>] ? rescuer_thread+0x380/0x380
      [12105.827757]  [<ffffffffabd48ac0>] ? kthread_associate_blkcg+0xc0/0xc0
      [12105.834266]  [<ffffffffac600241>] ret_from_fork+0x51/0x60
      
      Fixes: e2a7420d ("bonding/main: convert to using slave printk macros")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarJohn Sperbeck <jsperbeck@google.com>
      Cc: Jarod Wilson <jarod@redhat.com>
      CC: Jay Vosburgh <j.vosburgh@gmail.com>
      CC: Veaceslav Falico <vfalico@gmail.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b8bd72d3
    • Xin Long's avatar
      tipc: remove ub->ubsock checks · d2c3a4ba
      Xin Long authored
      Both tipc_udp_enable and tipc_udp_disable are called under rtnl_lock,
      ub->ubsock could never be NULL in tipc_udp_disable and cleanup_bearer,
      so remove the check.
      
      Also remove the one in tipc_udp_enable by adding "free" label.
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d2c3a4ba
    • Stefano Brivio's avatar
      ipv4: Fix off-by-one in route dump counter without netlink strict checking · 885b8b4d
      Stefano Brivio authored
      In commit ee28906f ("ipv4: Dump route exceptions if requested") I
      added a counter of per-node dumped routes (including actual routes and
      exceptions), analogous to the existing counter for dumped nodes. Dumping
      exceptions means we need to also keep track of how many routes are dumped
      for each node: this would be just one route per node, without exceptions.
      
      When netlink strict checking is not enabled, we dump both routes and
      exceptions at the same time: the RTM_F_CLONED flag is not used as a
      filter. In this case, the per-node counter 'i_fa' is incremented by one
      to track the single dumped route, then also incremented by one for each
      exception dumped, and then stored as netlink callback argument as skip
      counter, 's_fa', to be used when a partial dump operation restarts.
      
      The per-node counter needs to be increased by one also when we skip a
      route (exception) due to a previous non-zero skip counter, because it
      needs to match the existing skip counter, if we are dumping both routes
      and exceptions. I missed this, and only incremented the counter, for
      regular routes, if the previous skip counter was zero. This means that,
      in case of a mixed dump, partial dump operations after the first one
      will start with a mismatching skip counter value, one less than expected.
      
      This means in turn that the first exception for a given node is skipped
      every time a partial dump operation restarts, if netlink strict checking
      is not enabled (iproute < 5.0).
      
      It turns out I didn't repeat the test in its final version, commit
      de755a85 ("selftests: pmtu: Introduce list_flush_ipv4_exception test
      case"), which also counts the number of route exceptions returned, with
      iproute2 versions < 5.0 -- I was instead using the equivalent of the IPv6
      test as it was before commit b964641e ("selftests: pmtu: Make
      list_flush_ipv6_exception test more demanding").
      
      Always increment the per-node counter by one if we previously dumped
      a regular route, so that it matches the current skip counter.
      
      Fixes: ee28906f ("ipv4: Dump route exceptions if requested")
      Signed-off-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      885b8b4d
    • René van Dorst's avatar
      net: ethernet: mediatek: Allow non TRGMII mode with MT7621 DDR2 devices · cce581a0
      René van Dorst authored
      No reason to error out on a MT7621 device with DDR2 memory when non
      TRGMII mode is selected.
      Only MT7621 DDR2 clock setup is not supported for TRGMII mode.
      But non TRGMII mode doesn't need any special clock setup.
      Signed-off-by: default avatarRené van Dorst <opensource@vdorst.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cce581a0