1. 19 9月, 2020 1 次提交
    • S
      devlink: add timeout information to status_notify · f92970c6
      Shannon Nelson 提交于
      Add a timeout element to the DEVLINK_CMD_FLASH_UPDATE_STATUS
      netlink message for use by a userland utility to show that
      a particular firmware flash activity may take a long but
      bounded time to finish.  Also add a handy helper for drivers
      to make use of the new timeout value.
      
      UI usage hints:
       - if non-zero, add timeout display to the end of the status line
       	[component] status_msg  ( Xm Ys : Am Bs )
           using the timeout value for Am Bs and updating the Xm Ys
           every second
       - if the timeout expires while awaiting the next update,
         display something like
       	[component] status_msg  ( timeout reached : Am Bs )
       - if new status notify messages are received, remove
         the timeout and start over
      Signed-off-by: NShannon Nelson <snelson@pensando.io>
      Reviewed-by: NJakub Kicinski <kuba@kernel.org>
      Reviewed-by: NJacob Keller <jacob.e.keller@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f92970c6
  2. 16 9月, 2020 1 次提交
  3. 11 9月, 2020 1 次提交
    • J
      devlink: don't crash if netdev is NULL · 3ea87ca7
      Jakub Kicinski 提交于
      Following change will add support for a corner case where
      we may not have a netdev to pass to devlink_port_type_eth_set()
      but we still want to set port type.
      
      This is definitely a corner case, and drivers should not normally
      pass NULL netdev - print a warning message when this happens.
      
      Sadly for other port types (ib) switches don't have a device
      reference, the way we always do for Ethernet, so we can't put
      the warning in __devlink_port_type_set().
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3ea87ca7
  4. 10 9月, 2020 3 次提交
    • P
      devlink: Use controller while building phys_port_name · 66b17082
      Parav Pandit 提交于
      Now that controller number attribute is available, use it when
      building phsy_port_name for external controller ports.
      
      An example devlink port and representor netdev name consist of controller
      annotation for external controller with controller number = 1,
      for a VF 1 of PF 0:
      
      $ devlink port show pci/0000:06:00.0/2
      pci/0000:06:00.0/2: type eth netdev ens2f0c1pf0vf1 flavour pcivf controller 1 pfnum 0 vfnum 1 external true splittable false
        function:
          hw_addr 00:00:00:00:00:00
      
      $ devlink port show pci/0000:06:00.0/2 -jp
      {
          "port": {
              "pci/0000:06:00.0/2": {
                  "type": "eth",
                  "netdev": "ens2f0c1pf0vf1",
                  "flavour": "pcivf",
                  "controller": 1,
                  "pfnum": 0,
                  "vfnum": 1,
                  "external": true,
                  "splittable": false,
                  "function": {
                      "hw_addr": "00:00:00:00:00:00"
                  }
              }
          }
      }
      
      Controller number annotation is skipped for non external controllers to
      maintain backward compatibility.
      Signed-off-by: NParav Pandit <parav@nvidia.com>
      Reviewed-by: NJiri Pirko <jiri@nvidia.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      66b17082
    • P
      devlink: Introduce controller number · 3a2d9588
      Parav Pandit 提交于
      A devlink port may be for a controller consist of PCI device.
      A devlink instance holds ports of two types of controllers.
      (1) controller discovered on same system where eswitch resides
      This is the case where PCI PF/VF of a controller and devlink eswitch
      instance both are located on a single system.
      (2) controller located on external host system.
      This is the case where a controller is located in one system and its
      devlink eswitch ports are located in a different system.
      
      When a devlink eswitch instance serves the devlink ports of both
      controllers together, PCI PF/VF numbers may overlap.
      Due to this a unique phys_port_name cannot be constructed.
      
      For example in below such system controller-0 and controller-1, each has
      PCI PF pf0 whose eswitch ports can be present in controller-0.
      These results in phys_port_name as "pf0" for both.
      Similar problem exists for VFs and upcoming Sub functions.
      
      An example view of two controller systems:
      
                   ---------------------------------------------------------
                   |                                                       |
                   |           --------- ---------         ------- ------- |
      -----------  |           | vf(s) | | sf(s) |         |vf(s)| |sf(s)| |
      | server  |  | -------   ----/---- ---/----- ------- ---/--- ---/--- |
      | pci rc  |=== | pf0 |______/________/       | pf1 |___/_______/     |
      | connect |  | -------                       -------                 |
      -----------  |     | controller_num=1 (no eswitch)                   |
                   ------|--------------------------------------------------
                   (internal wire)
                         |
                   ---------------------------------------------------------
                   | devlink eswitch ports and reps                        |
                   | ----------------------------------------------------- |
                   | |ctrl-0 | ctrl-0 | ctrl-0 | ctrl-0 | ctrl-0 |ctrl-0 | |
                   | |pf0    | pf0vfN | pf0sfN | pf1    | pf1vfN |pf1sfN | |
                   | ----------------------------------------------------- |
                   | |ctrl-1 | ctrl-1 | ctrl-1 | ctrl-1 | ctrl-1 |ctrl-1 | |
                   | |pf1    | pf1vfN | pf1sfN | pf1    | pf1vfN |pf0sfN | |
                   | ----------------------------------------------------- |
                   |                                                       |
                   |                                                       |
                   |           --------- ---------         ------- ------- |
                   |           | vf(s) | | sf(s) |         |vf(s)| |sf(s)| |
                   | -------   ----/---- ---/----- ------- ---/--- ---/--- |
                   | | pf0 |______/________/       | pf1 |___/_______/     |
                   | -------                       -------                 |
                   |                                                       |
                   |  local controller_num=0 (eswitch)                     |
                   ---------------------------------------------------------
      
      An example devlink port for external controller with controller
      number = 1 for a VF 1 of PF 0:
      
      $ devlink port show pci/0000:06:00.0/2
      pci/0000:06:00.0/2: type eth netdev ens2f0pf0vf1 flavour pcivf controller 1 pfnum 0 vfnum 1 external true splittable false
        function:
          hw_addr 00:00:00:00:00:00
      
      $ devlink port show pci/0000:06:00.0/2 -jp
      {
          "port": {
              "pci/0000:06:00.0/2": {
                  "type": "eth",
                  "netdev": "ens2f0pf0vf1",
                  "flavour": "pcivf",
                  "controller": 1,
                  "pfnum": 0,
                  "vfnum": 1,
                  "external": true,
                  "splittable": false,
                  "function": {
                      "hw_addr": "00:00:00:00:00:00"
                  }
              }
          }
      }
      Signed-off-by: NParav Pandit <parav@nvidia.com>
      Reviewed-by: NJiri Pirko <jiri@nvidia.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3a2d9588
    • P
      devlink: Introduce external controller flag · 05b595e9
      Parav Pandit 提交于
      A devlink eswitch port may represent PCI PF/VF ports of a controller.
      
      A controller either located on same system or it can be an external
      controller located in host where such NIC is plugged in.
      
      Add the ability for driver to specify if a port is for external
      controller.
      
      Use such flag in the mlx5_core driver.
      
      An example of an external controller having VF1 of PF0 belong to
      controller 1.
      
      $ devlink port show pci/0000:06:00.0/2
      pci/0000:06:00.0/2: type eth netdev ens2f0pf0vf1 flavour pcivf pfnum 0 vfnum 1 external true splittable false
        function:
          hw_addr 00:00:00:00:00:00
      $ devlink port show pci/0000:06:00.0/2 -jp
      {
          "port": {
              "pci/0000:06:00.0/2": {
                  "type": "eth",
                  "netdev": "ens2f0pf0vf1",
                  "flavour": "pcivf",
                  "pfnum": 0,
                  "vfnum": 1,
                  "external": true,
                  "splittable": false,
                  "function": {
                      "hw_addr": "00:00:00:00:00:00"
                  }
              }
          }
      }
      Signed-off-by: NParav Pandit <parav@nvidia.com>
      Reviewed-by: NJiri Pirko <jiri@nvidia.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      05b595e9
  5. 25 8月, 2020 2 次提交
  6. 24 8月, 2020 1 次提交
  7. 17 8月, 2020 1 次提交
  8. 04 8月, 2020 2 次提交
  9. 31 7月, 2020 1 次提交
    • J
      devlink: ignore -EOPNOTSUPP errors on dumpit · 82274d07
      Jakub Kicinski 提交于
      Number of .dumpit functions try to ignore -EOPNOTSUPP errors.
      Recent change missed that, and started reporting all errors
      but -EMSGSIZE back from dumps. This leads to situation like
      this:
      
      $ devlink dev info
      devlink answers: Operation not supported
      
      Dump should not report an error just because the last device
      to be queried could not provide an answer.
      
      To fix this and avoid similar confusion make sure we clear
      err properly, and not leave it set to an error if we don't
      terminate the iteration.
      
      Fixes: c62c2cfb ("net: devlink: don't ignore errors during dumpit")
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      Reviewed-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      82274d07
  10. 30 7月, 2020 1 次提交
  11. 23 7月, 2020 1 次提交
    • P
      devlink: Always use user_ptr[0] for devlink and simplify post_doit · 637989b5
      Parav Pandit 提交于
      Currently devlink instance is searched on all doit() operations.
      But it is optionally stored into user_ptr[0]. This requires
      rediscovering devlink again doing post_doit().
      
      Few devlink commands related to port shared buffers needs 3 pointers
      (devlink, devlink_port, and devlink_sb) while executing doit commands.
      Though devlink pointer can be derived from the devlink_port during
      post_doit() operation when doit() callback has acquired devlink
      instance lock, relying on such scheme to access devlik pointer makes
      code very fragile.
      
      Hence, to avoid ambiguity in post_doit() and to avoid searching
      devlink instance again, simplify code by always storing devlink
      instance in user_ptr[0] and derive devlink_sb pointer in their
      respective callback routines.
      Signed-off-by: NParav Pandit <parav@mellanox.com>
      Reviewed-by: NJiri Pirko <jiri@mellanox.com>
      Acked-by: NJakub Kicinski <kuba@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      637989b5
  12. 22 7月, 2020 3 次提交
  13. 14 7月, 2020 1 次提交
    • I
      devlink: Fix use-after-free when destroying health reporters · 5d037b4d
      Ido Schimmel 提交于
      Dereferencing the reporter after it was destroyed in order to unlock the
      reporters lock results in a use-after-free [1].
      
      Fix this by storing a pointer to the lock in a local variable before
      destroying the reporter.
      
      [1]
      ==================================================================
      BUG: KASAN: use-after-free in devlink_health_reporter_destroy+0x15c/0x1b0 net/core/devlink.c:5476
      Read of size 8 at addr ffff8880650fd020 by task syz-executor.1/904
      
      CPU: 0 PID: 904 Comm: syz-executor.1 Not tainted 5.8.0-rc2+ #35
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0xf6/0x16e lib/dump_stack.c:118
       print_address_description.constprop.0+0x1c/0x250 mm/kasan/report.c:383
       __kasan_report mm/kasan/report.c:513 [inline]
       kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530
       devlink_health_reporter_destroy+0x15c/0x1b0 net/core/devlink.c:5476
       nsim_dev_health_exit+0x8b/0xe0 drivers/net/netdevsim/health.c:317
       nsim_dev_reload_destroy+0x7f/0x110 drivers/net/netdevsim/dev.c:1134
       nsim_dev_reload_down+0x6e/0xd0 drivers/net/netdevsim/dev.c:712
       devlink_reload+0xc6/0x3b0 net/core/devlink.c:2952
       devlink_nl_cmd_reload+0x2f1/0x7c0 net/core/devlink.c:2987
       genl_family_rcv_msg_doit net/netlink/genetlink.c:691 [inline]
       genl_family_rcv_msg net/netlink/genetlink.c:736 [inline]
       genl_rcv_msg+0x611/0x9d0 net/netlink/genetlink.c:753
       netlink_rcv_skb+0x152/0x440 net/netlink/af_netlink.c:2469
       genl_rcv+0x24/0x40 net/netlink/genetlink.c:764
       netlink_unicast_kernel net/netlink/af_netlink.c:1303 [inline]
       netlink_unicast+0x53a/0x750 net/netlink/af_netlink.c:1329
       netlink_sendmsg+0x850/0xd90 net/netlink/af_netlink.c:1918
       sock_sendmsg_nosec net/socket.c:652 [inline]
       sock_sendmsg+0x150/0x190 net/socket.c:672
       ____sys_sendmsg+0x6d8/0x840 net/socket.c:2363
       ___sys_sendmsg+0xff/0x170 net/socket.c:2417
       __sys_sendmsg+0xe5/0x1b0 net/socket.c:2450
       do_syscall_64+0x56/0xa0 arch/x86/entry/common.c:359
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      RIP: 0033:0x4748ad
      Code: Bad RIP value.
      RSP: 002b:00007fd0358adc38 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 000000000056bf00 RCX: 00000000004748ad
      RDX: 0000000000000000 RSI: 00000000200000c0 RDI: 0000000000000003
      RBP: 00000000ffffffff R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
      R13: 00000000004d1a4b R14: 00007fd0358ae6b4 R15: 00007fd0358add80
      
      Allocated by task 539:
       save_stack+0x1b/0x40 mm/kasan/common.c:48
       set_track mm/kasan/common.c:56 [inline]
       __kasan_kmalloc mm/kasan/common.c:494 [inline]
       __kasan_kmalloc.constprop.0+0xc2/0xd0 mm/kasan/common.c:467
       kmalloc include/linux/slab.h:555 [inline]
       kzalloc include/linux/slab.h:669 [inline]
       __devlink_health_reporter_create+0x91/0x2f0 net/core/devlink.c:5359
       devlink_health_reporter_create+0xa1/0x170 net/core/devlink.c:5431
       nsim_dev_health_init+0x95/0x3a0 drivers/net/netdevsim/health.c:279
       nsim_dev_probe+0xb1e/0xeb0 drivers/net/netdevsim/dev.c:1086
       really_probe+0x287/0x6d0 drivers/base/dd.c:525
       driver_probe_device+0xfe/0x1d0 drivers/base/dd.c:701
       __device_attach_driver+0x21e/0x290 drivers/base/dd.c:807
       bus_for_each_drv+0x161/0x1e0 drivers/base/bus.c:431
       __device_attach+0x21a/0x360 drivers/base/dd.c:873
       bus_probe_device+0x1e6/0x290 drivers/base/bus.c:491
       device_add+0xaf2/0x1b00 drivers/base/core.c:2680
       nsim_bus_dev_new drivers/net/netdevsim/bus.c:336 [inline]
       new_device_store+0x374/0x590 drivers/net/netdevsim/bus.c:215
       bus_attr_store+0x75/0xa0 drivers/base/bus.c:122
       sysfs_kf_write+0x113/0x170 fs/sysfs/file.c:138
       kernfs_fop_write+0x25d/0x480 fs/kernfs/file.c:315
       __vfs_write+0x7c/0x100 fs/read_write.c:495
       vfs_write+0x265/0x5e0 fs/read_write.c:559
       ksys_write+0x12d/0x250 fs/read_write.c:612
       do_syscall_64+0x56/0xa0 arch/x86/entry/common.c:359
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Freed by task 904:
       save_stack+0x1b/0x40 mm/kasan/common.c:48
       set_track mm/kasan/common.c:56 [inline]
       kasan_set_free_info mm/kasan/common.c:316 [inline]
       __kasan_slab_free+0x12c/0x170 mm/kasan/common.c:455
       slab_free_hook mm/slub.c:1474 [inline]
       slab_free_freelist_hook mm/slub.c:1507 [inline]
       slab_free mm/slub.c:3072 [inline]
       kfree+0xe6/0x320 mm/slub.c:4063
       devlink_health_reporter_free net/core/devlink.c:5449 [inline]
       devlink_health_reporter_put+0xb7/0xf0 net/core/devlink.c:5456
       __devlink_health_reporter_destroy net/core/devlink.c:5463 [inline]
       devlink_health_reporter_destroy+0x11b/0x1b0 net/core/devlink.c:5475
       nsim_dev_health_exit+0x8b/0xe0 drivers/net/netdevsim/health.c:317
       nsim_dev_reload_destroy+0x7f/0x110 drivers/net/netdevsim/dev.c:1134
       nsim_dev_reload_down+0x6e/0xd0 drivers/net/netdevsim/dev.c:712
       devlink_reload+0xc6/0x3b0 net/core/devlink.c:2952
       devlink_nl_cmd_reload+0x2f1/0x7c0 net/core/devlink.c:2987
       genl_family_rcv_msg_doit net/netlink/genetlink.c:691 [inline]
       genl_family_rcv_msg net/netlink/genetlink.c:736 [inline]
       genl_rcv_msg+0x611/0x9d0 net/netlink/genetlink.c:753
       netlink_rcv_skb+0x152/0x440 net/netlink/af_netlink.c:2469
       genl_rcv+0x24/0x40 net/netlink/genetlink.c:764
       netlink_unicast_kernel net/netlink/af_netlink.c:1303 [inline]
       netlink_unicast+0x53a/0x750 net/netlink/af_netlink.c:1329
       netlink_sendmsg+0x850/0xd90 net/netlink/af_netlink.c:1918
       sock_sendmsg_nosec net/socket.c:652 [inline]
       sock_sendmsg+0x150/0x190 net/socket.c:672
       ____sys_sendmsg+0x6d8/0x840 net/socket.c:2363
       ___sys_sendmsg+0xff/0x170 net/socket.c:2417
       __sys_sendmsg+0xe5/0x1b0 net/socket.c:2450
       do_syscall_64+0x56/0xa0 arch/x86/entry/common.c:359
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      The buggy address belongs to the object at ffff8880650fd000
       which belongs to the cache kmalloc-512 of size 512
      The buggy address is located 32 bytes inside of
       512-byte region [ffff8880650fd000, ffff8880650fd200)
      The buggy address belongs to the page:
      page:ffffea0001943f00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff8880650ff800 head:ffffea0001943f00 order:2 compound_mapcount:0 compound_pincount:0
      flags: 0x100000000010200(slab|head)
      raw: 0100000000010200 ffffea0001a06a08 ffffea00010ad308 ffff88806c402500
      raw: ffff8880650ff800 0000000000100009 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff8880650fcf00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff8880650fcf80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      >ffff8880650fd000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                     ^
       ffff8880650fd080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff8880650fd100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ==================================================================
      
      Fixes: 3c5584bf ("devlink: Rework devlink health reporter destructor")
      Fixes: 15c724b9 ("devlink: Add devlink health port reporters API")
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: NMoshe Shemesh <moshe@mellanox.com>
      Reviewed-by: NJiri Pirko <jiri@mellanox.com>
      Reviewed-by: NJakub Kicinski <kuba@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5d037b4d
  14. 11 7月, 2020 5 次提交
  15. 10 7月, 2020 6 次提交
  16. 23 6月, 2020 5 次提交
  17. 02 6月, 2020 5 次提交