1. 22 Feb, 2022 1 commit
  2. 21 Feb, 2022 15 commits
  3. 20 Feb, 2022 10 commits
  4. 19 Feb, 2022 14 commits
    • Volodymyr Mytnyk's avatar
      net: prestera: acl: fix 'client_map' buff overflow · 48c77bdf
      Volodymyr Mytnyk authored
      smatch warnings:
      drivers/net/ethernet/marvell/prestera/prestera_acl.c:103
      prestera_acl_chain_to_client() error: buffer overflow
      'client_map' 3 <= 3
      
      	prestera_acl_chain_to_client(u32 chain_index, ...)
              ...
      	u32 client_map[] = {
      		PRESTERA_HW_COUNTER_CLIENT_LOOKUP_0,
      		PRESTERA_HW_COUNTER_CLIENT_LOOKUP_1,
      		PRESTERA_HW_COUNTER_CLIENT_LOOKUP_2
      	};
      	if (chain_index > ARRAY_SIZE(client_map))
      	...
      
      Fixes: fa5d824c ("net: prestera: acl: add multi-chain support offload")
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarVolodymyr Mytnyk <vmytnyk@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      48c77bdf
    • Ahmad Fatoum's avatar
      net: dsa: microchip: add ksz8563 to ksz9477 I2C driver · 173a272a
      Ahmad Fatoum authored
      The KSZ9477 SPI driver already has support for the KSZ8563. The same switch
      chip can also be managed via i2c and we have an KSZ9477 I2C driver, but
      that one lacks the relevant compatible entry. Add it.
      
      DT bindings already describe this compatible.
      Signed-off-by: default avatarAhmad Fatoum <a.fatoum@pengutronix.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      173a272a
    • Dan Carpenter's avatar
      net/smc: unlock on error paths in __smc_setsockopt() · 7a11455f
      Dan Carpenter authored
      These two error paths need to release_sock(sk) before returning.
      
      Fixes: a6a6fe27 ("net/smc: Dynamic control handshake limitation by socket options")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: default avatarD. Wythe <alibuda@linux.alibaba.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7a11455f
    • Oleksij Rempel's avatar
      net: dsa: microchip: ksz9477: export HW stats over stats64 interface · a7f4f13a
      Oleksij Rempel authored
      Provide access to HW offloaded packets over stats64 interface.
      The rx/tx_bytes values needed some fixing since HW is accounting size of
      the Ethernet frame together with FCS.
      Signed-off-by: default avatarOleksij Rempel <o.rempel@pengutronix.de>
      Reviewed-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a7f4f13a
    • David S. Miller's avatar
      Merge branch 'phylink-remove-pcs_poll' · 0d0350c4
      David S. Miller authored
      Russell King says:
      
      ====================
      net: phylink: remove pcs_poll
      
      This small series removes the now unused pcs_poll members from DSA and
      phylink. "git grep pcs_poll drivers/net/ net/" on net-next confirms that
      the only places that reference this are in DSA core code and phylink
      code:
      
      drivers/net/phy/phylink.c:              if (pl->config->pcs_poll || pcs->poll)
      drivers/net/phy/phylink.c:              poll |= pl->config->pcs_poll;
      net/dsa/port.c: dp->pl_config.pcs_poll = ds->pcs_poll;
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0d0350c4
    • Russell King (Oracle)'s avatar
      net: phylink: remove phylink_config's pcs_poll · 64b4a0f8
      Russell King (Oracle) authored
      phylink_config's pcs_poll is no longer used, let's get rid of it.
      Signed-off-by: default avatarRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      64b4a0f8
    • Russell King (Oracle)'s avatar
      net: dsa: remove pcs_poll · ccfbf44d
      Russell King (Oracle) authored
      With drivers converted over to using phylink PCS, there is no need for
      the struct dsa_switch member "pcs_poll" to exist anymore - there is a
      flag in the struct phylink_pcs which indicates whether this PCS needs
      to be polled which supersedes this.
      Signed-off-by: default avatarRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ccfbf44d
    • Juhee Kang's avatar
      net: hsr: fix suspicious RCU usage warning in hsr_node_get_first() · e7f27420
      Juhee Kang authored
      When hsr_create_self_node() calls hsr_node_get_first(), the suspicious
      RCU usage warning is occurred. The reason why this warning is raised is
      the callers of hsr_node_get_first() use rcu_read_lock_bh() and
      other different synchronization mechanisms. Thus, this patch solved by
      replacing rcu_dereference() with rcu_dereference_bh_check().
      
      The kernel test robot reports:
          [   50.083470][ T3596] =============================
          [   50.088648][ T3596] WARNING: suspicious RCU usage
          [   50.093785][ T3596] 5.17.0-rc3-next-20220208-syzkaller #0 Not tainted
          [   50.100669][ T3596] -----------------------------
          [   50.105513][ T3596] net/hsr/hsr_framereg.c:34 suspicious rcu_dereference_check() usage!
          [   50.113799][ T3596]
          [   50.113799][ T3596] other info that might help us debug this:
          [   50.113799][ T3596]
          [   50.124257][ T3596]
          [   50.124257][ T3596] rcu_scheduler_active = 2, debug_locks = 1
          [   50.132368][ T3596] 2 locks held by syz-executor.0/3596:
          [   50.137863][ T3596]  #0: ffffffff8d3357e8 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x3be/0xb80
          [   50.147470][ T3596]  #1: ffff88807ec9d5f0 (&hsr->list_lock){+...}-{2:2}, at: hsr_create_self_node+0x225/0x650
          [   50.157623][ T3596]
          [   50.157623][ T3596] stack backtrace:
          [   50.163510][ T3596] CPU: 1 PID: 3596 Comm: syz-executor.0 Not tainted 5.17.0-rc3-next-20220208-syzkaller #0
          [   50.173381][ T3596] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
          [   50.183623][ T3596] Call Trace:
          [   50.186904][ T3596]  <TASK>
          [   50.189844][ T3596]  dump_stack_lvl+0xcd/0x134
          [   50.194640][ T3596]  hsr_node_get_first+0x9b/0xb0
          [   50.199499][ T3596]  hsr_create_self_node+0x22d/0x650
          [   50.204688][ T3596]  hsr_dev_finalize+0x2c1/0x7d0
          [   50.209669][ T3596]  hsr_newlink+0x315/0x730
          [   50.214113][ T3596]  ? hsr_dellink+0x130/0x130
          [   50.218789][ T3596]  ? rtnl_create_link+0x7e8/0xc00
          [   50.223803][ T3596]  ? hsr_dellink+0x130/0x130
          [   50.228397][ T3596]  __rtnl_newlink+0x107c/0x1760
          [   50.233249][ T3596]  ? rtnl_setlink+0x3c0/0x3c0
          [   50.238043][ T3596]  ? is_bpf_text_address+0x77/0x170
          [   50.243362][ T3596]  ? lock_downgrade+0x6e0/0x6e0
          [   50.248219][ T3596]  ? unwind_next_frame+0xee1/0x1ce0
          [   50.253605][ T3596]  ? entry_SYSCALL_64_after_hwframe+0x44/0xae
          [   50.259669][ T3596]  ? __sanitizer_cov_trace_cmp4+0x1c/0x70
          [   50.265423][ T3596]  ? is_bpf_text_address+0x99/0x170
          [   50.270819][ T3596]  ? kernel_text_address+0x39/0x80
          [   50.275950][ T3596]  ? __kernel_text_address+0x9/0x30
          [   50.281336][ T3596]  ? unwind_get_return_address+0x51/0x90
          [   50.286975][ T3596]  ? create_prof_cpu_mask+0x20/0x20
          [   50.292178][ T3596]  ? arch_stack_walk+0x93/0xe0
          [   50.297172][ T3596]  ? kmem_cache_alloc_trace+0x42/0x2c0
          [   50.302637][ T3596]  ? rcu_read_lock_sched_held+0x3a/0x70
          [   50.308194][ T3596]  rtnl_newlink+0x64/0xa0
          [   50.312524][ T3596]  ? __rtnl_newlink+0x1760/0x1760
          [   50.317545][ T3596]  rtnetlink_rcv_msg+0x413/0xb80
          [   50.322631][ T3596]  ? rtnl_newlink+0xa0/0xa0
          [   50.327159][ T3596]  netlink_rcv_skb+0x153/0x420
          [   50.331931][ T3596]  ? rtnl_newlink+0xa0/0xa0
          [   50.336436][ T3596]  ? netlink_ack+0xa80/0xa80
          [   50.341095][ T3596]  ? netlink_deliver_tap+0x1a2/0xc40
          [   50.346532][ T3596]  ? netlink_deliver_tap+0x1b1/0xc40
          [   50.351839][ T3596]  netlink_unicast+0x539/0x7e0
          [   50.356633][ T3596]  ? netlink_attachskb+0x880/0x880
          [   50.361750][ T3596]  ? __sanitizer_cov_trace_const_cmp8+0x1d/0x70
          [   50.368003][ T3596]  ? __sanitizer_cov_trace_const_cmp8+0x1d/0x70
          [   50.374707][ T3596]  ? __phys_addr_symbol+0x2c/0x70
          [   50.379753][ T3596]  ? __sanitizer_cov_trace_cmp8+0x1d/0x70
          [   50.385568][ T3596]  ? __check_object_size+0x16c/0x4f0
          [   50.390859][ T3596]  netlink_sendmsg+0x904/0xe00
          [   50.395715][ T3596]  ? netlink_unicast+0x7e0/0x7e0
          [   50.400722][ T3596]  ? __sanitizer_cov_trace_const_cmp4+0x1c/0x70
          [   50.407003][ T3596]  ? netlink_unicast+0x7e0/0x7e0
          [   50.412119][ T3596]  sock_sendmsg+0xcf/0x120
          [   50.416548][ T3596]  __sys_sendto+0x21c/0x320
          [   50.421052][ T3596]  ? __ia32_sys_getpeername+0xb0/0xb0
          [   50.426427][ T3596]  ? lockdep_hardirqs_on_prepare+0x400/0x400
          [   50.432721][ T3596]  ? __context_tracking_exit+0xb8/0xe0
          [   50.438188][ T3596]  ? lock_downgrade+0x6e0/0x6e0
          [   50.443041][ T3596]  ? lock_downgrade+0x6e0/0x6e0
          [   50.447902][ T3596]  __x64_sys_sendto+0xdd/0x1b0
          [   50.452759][ T3596]  ? lockdep_hardirqs_on+0x79/0x100
          [   50.457964][ T3596]  ? syscall_enter_from_user_mode+0x21/0x70
          [   50.464150][ T3596]  do_syscall_64+0x35/0xb0
          [   50.468565][ T3596]  entry_SYSCALL_64_after_hwframe+0x44/0xae
          [   50.474452][ T3596] RIP: 0033:0x7f3148504e1c
          [   50.479052][ T3596] Code: fa fa ff ff 44 8b 4c 24 2c 4c 8b 44 24 20 89 c5 44 8b 54 24 28 48 8b 54 24 18 b8 2c 00 00 00 48 8b 74 24 10 8b 7c 24 08 0f 05 <48> 3d 00 f0 ff ff 77 34 89 ef 48 89 44 24 08 e8 20 fb ff ff 48 8b
          [   50.498926][ T3596] RSP: 002b:00007ffeab5f2ab0 EFLAGS: 00000293 ORIG_RAX: 000000000000002c
          [   50.507342][ T3596] RAX: ffffffffffffffda RBX: 00007f314959d320 RCX: 00007f3148504e1c
          [   50.515393][ T3596] RDX: 0000000000000048 RSI: 00007f314959d370 RDI: 0000000000000003
          [   50.523444][ T3596] RBP: 0000000000000000 R08: 00007ffeab5f2b04 R09: 000000000000000c
          [   50.531492][ T3596] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000
          [   50.539455][ T3596] R13: 00007f314959d370 R14: 0000000000000003 R15: 0000000000000000
      
      Fixes: 4acc45db ("net: hsr: use hlist_head instead of list_head for mac addresses")
      Reported-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Reported-and-tested-by: syzbot+f0eb4f3876de066b128c@syzkaller.appspotmail.com
      Signed-off-by: default avatarJuhee Kang <claudiajkang@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e7f27420
    • Christophe JAILLET's avatar
      atm: nicstar: Use kcalloc() to simplify code · 92c54a65
      Christophe JAILLET authored
      Use kcalloc() instead of kmalloc_array() and a loop to set all the values
      of the array to NULL.
      
      While at it, remove a duplicated assignment to 'scq->num_entries'.
      Signed-off-by: default avatarChristophe JAILLET <christophe.jaillet@wanadoo.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      92c54a65
    • David S. Miller's avatar
      Merge branch 'dpaa2-eth-one-step-register' · 32d51cef
      David S. Miller authored
      Radu Bulie says:
      
      ====================
      Provide direct access to 1588 one step register
      
      DPAA2 MAC supports 1588 one step timestamping.
      If this option is enabled then for each transmitted PTP event packet,
      the 1588 SINGLE_STEP register is accessed to modify the following fields:
      
      -offset of the correction field inside the PTP packet
      -UDP checksum update bit,  in case the PTP event packet has
       UDP encapsulation
      
      These values can change any time, because there may be multiple
      PTP clients connected, that receive various 1588 frame types:
      - L2 only frame
      - UDP / Ipv4
      - UDP / Ipv6
      - other
      
      The current implementation uses dpni_set_single_step_cfg to update the
      SINLGE_STEP register.
      Using an MC command  on the Tx datapath for each transmitted 1588 message
      introduces high delays, leading to low throughput and consequently to a
      small number of supported PTP clients. Besides these, the nanosecond
      correction field from the PTP packet will contain the high delay from the
      driver which together with the originTimestamp will render timestamp
      values that are unacceptable in a GM clock implementation.
      
      This patch series replaces the dpni_set_single_step_cfg function call from
      the Tx datapath for 1588 messages (when one step timestamping is enabled)
      with a callback that either implements direct access to the SINGLE_STEP
      register, eliminating the overhead caused by the MC command that will need
      to be dispatched by the MC firmware through the MC command portal
      interface or falls back to the dpni_set_single_step_cfg in case the MC
      version does not have support for returning the single step register
      base address.
      
      In other words all the delay introduced by dpni_set_single_step_cfg
      function will be eliminated (if MC version has support for returning the
      base address of the single step register), improving the egress driver
      performance for PTP packets when single step timestamping is enabled.
      
      The first patch adds a new attribute that contains the base address of
      the SINGLE_STEP register. It will be used to directly update the register
      on the Tx datapath.
      
      The second patch updates the driver such that the SINGLE_STEP
      register is either accessed directly if MC version >= 10.32 or is
      accessed through dpni_set_single_step_cfg command when 1588 messages
      are transmitted.
      
      Changes in v2:
       - move global function pointer into the driver's private structure in 2/2
       - move repetitive code outside the body of the callback functions  in 2/2
       - update function dpaa2_ptp_onestep_reg_update_method  and remove goto
         statement from non error path in 2/2
      
      Changes in v3:
       - remove static storage class specifier from within the structure in 2/2
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      32d51cef
    • Radu Bulie's avatar
      dpaa2-eth: Update SINGLE_STEP register access · c4680c97
      Radu Bulie authored
      DPAA2 MAC supports 1588 one step timestamping.
      If this option is enabled then for each transmitted PTP event packet,
      the 1588 SINGLE_STEP register is accessed to modify the following fields:
      
      -offset of the correction field inside the PTP packet
      -UDP checksum update bit,  in case the PTP event packet has
       UDP encapsulation
      
      These values can change any time, because there may be multiple
      PTP clients connected, that receive various 1588 frame types:
      - L2 only frame
      - UDP / Ipv4
      - UDP / Ipv6
      - other
      
      The current implementation uses dpni_set_single_step_cfg to update the
      SINLGE_STEP register.
      Using an MC command  on the Tx datapath for each transmitted 1588 message
      introduces high delays, leading to low throughput and consequently to a
      small number of supported PTP clients. Besides these, the nanosecond
      correction field from the PTP packet will contain the high delay from the
      driver which together with the originTimestamp will render timestamp
      values that are unacceptable in a GM clock implementation.
      
      This patch updates the Tx datapath for 1588 messages when single step
      timestamp is enabled and provides direct access to SINGLE_STEP register,
      eliminating the  overhead caused by the dpni_set_single_step_cfg
      MC command. MC version >= 10.32 implements this functionality.
      If the MC version does not have support for returning the
      single step register base address, the driver will use
      dpni_set_single_step_cfg command for updates operations.
      
      All the delay introduced by dpni_set_single_step_cfg
      function will be eliminated (if MC version has support for returning the
      base address of the single step register), improving the egress driver
      performance for PTP packets when single step timestamping is enabled.
      
      Before these changes the maximum throughput for 1588 messages with
      single step hardware timestamp enabled was around 2000pps.
      After the updates the throughput increased up to 32.82 Mbps / 46631.02 pps.
      Signed-off-by: default avatarRadu Bulie <radu-andrei.bulie@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c4680c97
    • Radu Bulie's avatar
      dpaa2-eth: Update dpni_get_single_step_cfg command · 9572594e
      Radu Bulie authored
      dpni_get_single_step_cfg is an MC firmware command used for
      retrieving the contents of SINGLE_STEP 1588 register available
      in a DPMAC.
      
      This patch adds a new version of this command that returns as an extra
      argument the physical base address of the aforementioned register.
      The address will be used to directly modify the contents of the
      SINGLE_STEP register instead of invoking the MC command
      dpni_set_single_step_cgf. The former approach introduced huge delays on
      the TX datapath when one step PTP events were transmitted. This led to low
      throughput and high latencies observed in the PTP correction field.
      Signed-off-by: default avatarRadu Bulie <radu-andrei.bulie@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9572594e
    • Eric Dumazet's avatar
      net: get rid of rtnl_lock_unregistering() · 8a4fc54b
      Eric Dumazet authored
      After recent patches, and in particular commits
       faab39f6 ("net: allow out-of-order netdev unregistration") and
       e5f80fcf ("ipv6: give an IPv6 dev to blackhole_netdev")
      we no longer need the barrier implemented in rtnl_lock_unregistering().
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8a4fc54b
    • Volodymyr Mytnyk's avatar
      net: prestera: flower: fix destroy tmpl in chain · b3ae2d35
      Volodymyr Mytnyk authored
      Fix flower destroy template callback to release template
      only for specific tc chain instead of all chain tempaltes.
      
      The issue was intruduced by previous commit that introduced
      multi-chain support.
      
      Fixes: fa5d824c ("net: prestera: acl: add multi-chain support offload")
      Signed-off-by: default avatarVolodymyr Mytnyk <vmytnyk@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b3ae2d35