1. 10 10月, 2020 2 次提交
    • M
      devlink: Add devlink reload limit option · dc64cc7c
      Moshe Shemesh 提交于
      Add reload limit to demand restrictions on reload actions.
      Reload limits supported:
      no_reset: No reset allowed, no down time allowed, no link flap and no
                configuration is lost.
      
      By default reload limit is unspecified and so no constraints on reload
      actions are required.
      
      Some combinations of action and limit are invalid. For example, driver
      can not reinitialize its entities without any downtime.
      
      The no_reset reload limit will have usecase in this patchset to
      implement restricted fw_activate on mlx5.
      
      Have the uapi parameter of reload limit ready for future support of
      multiselection.
      Signed-off-by: NMoshe Shemesh <moshe@mellanox.com>
      Reviewed-by: NJiri Pirko <jiri@nvidia.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      dc64cc7c
    • M
      devlink: Add reload action option to devlink reload command · ccdf0721
      Moshe Shemesh 提交于
      Add devlink reload action to allow the user to request a specific reload
      action. The action parameter is optional, if not specified then devlink
      driver re-init action is used (backward compatible).
      Note that when required to do firmware activation some drivers may need
      to reload the driver. On the other hand some drivers may need to reset
      the firmware to reinitialize the driver entities. Therefore, the devlink
      reload command returns the actions which were actually performed.
      Reload actions supported are:
      driver_reinit: driver entities re-initialization, applying devlink-param
                     and devlink-resource values.
      fw_activate: firmware activate.
      
      command examples:
      $devlink dev reload pci/0000:82:00.0 action driver_reinit
      reload_actions_performed:
        driver_reinit
      
      $devlink dev reload pci/0000:82:00.0 action fw_activate
      reload_actions_performed:
        driver_reinit fw_activate
      Signed-off-by: NMoshe Shemesh <moshe@mellanox.com>
      Reviewed-by: NJakub Kicinski <kuba@kernel.org>
      Reviewed-by: NJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: NJiri Pirko <jiri@nvidia.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      ccdf0721
  2. 26 9月, 2020 3 次提交
    • J
      netdevsim: add support for flash_update overwrite mask · cbb58368
      Jacob Keller 提交于
      The devlink interface recently gained support for a new "overwrite mask"
      parameter that allows specifying how various sub-sections of a flash
      component are modified when updating.
      
      Add support for this to netdevsim, to enable easily testing the
      interface. Make the allowed overwrite mask values controllable via
      a debugfs parameter. This enables testing a flow where the driver
      rejects an unsupportable overwrite mask.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: NJakub Kicinski <kuba@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cbb58368
    • J
      devlink: convert flash_update to use params structure · bc75c054
      Jacob Keller 提交于
      The devlink core recently gained support for checking whether the driver
      supports a flash_update parameter, via `supported_flash_update_params`.
      However, parameters are specified as function arguments. Adding a new
      parameter still requires modifying the signature of the .flash_update
      callback in all drivers.
      
      Convert the .flash_update function to take a new `struct
      devlink_flash_update_params` instead. By using this structure, and the
      `supported_flash_update_params` bit field, a new parameter to
      flash_update can be added without requiring modification to existing
      drivers.
      
      As before, all parameters except file_name will require driver opt-in.
      Because file_name is a necessary field to for the flash_update to make
      sense, no "SUPPORTED" bitflag is provided and it is always considered
      valid. All future additional parameters will require a new bit in the
      supported_flash_update_params bitfield.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: NJakub Kicinski <kuba@kernel.org>
      Cc: Jiri Pirko <jiri@mellanox.com>
      Cc: Jakub Kicinski <kuba@kernel.org>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Michael Chan <michael.chan@broadcom.com>
      Cc: Bin Luo <luobin9@huawei.com>
      Cc: Saeed Mahameed <saeedm@mellanox.com>
      Cc: Leon Romanovsky <leon@kernel.org>
      Cc: Ido Schimmel <idosch@mellanox.com>
      Cc: Danielle Ratson <danieller@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bc75c054
    • J
      devlink: check flash_update parameter support in net core · 22ec3d23
      Jacob Keller 提交于
      When implementing .flash_update, drivers which do not support
      per-component update are manually checking the component parameter to
      verify that it is NULL. Without this check, the driver might accept an
      update request with a component specified even though it will not honor
      such a request.
      
      Instead of having each driver check this, move the logic into
      net/core/devlink.c, and use a new `supported_flash_update_params` field
      in the devlink_ops. Drivers which will support per-component update must
      now specify this by setting DEVLINK_SUPPORT_FLASH_UPDATE_COMPONENT in
      the supported_flash_update_params in their devlink_ops.
      
      This helps ensure that drivers do not forget to check for a NULL
      component if they do not support per-component update. This also enables
      a slightly better error message by enabling the core stack to set the
      netlink bad attribute message to indicate precisely the unsupported
      attribute in the message.
      
      Going forward, any new additional parameter to flash update will require
      a bit in the supported_flash_update_params bitfield.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: NJakub Kicinski <kuba@kernel.org>
      Cc: Jiri Pirko <jiri@mellanox.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Michael Chan <michael.chan@broadcom.com>
      Cc: Bin Luo <luobin9@huawei.com>
      Cc: Saeed Mahameed <saeedm@mellanox.com>
      Cc: Leon Romanovsky <leon@kernel.org>
      Cc: Ido Schimmel <idosch@mellanox.com>
      Cc: Danielle Ratson <danieller@mellanox.com>
      Cc: Shannon Nelson <snelson@pensando.io>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      22ec3d23
  3. 19 9月, 2020 2 次提交
  4. 04 8月, 2020 1 次提交
  5. 11 7月, 2020 1 次提交
  6. 10 7月, 2020 1 次提交
  7. 02 6月, 2020 2 次提交
  8. 23 5月, 2020 1 次提交
  9. 31 3月, 2020 4 次提交
  10. 27 3月, 2020 5 次提交
    • J
      netdevsim: support taking immediate snapshot via devlink · 3fe0fd53
      Jacob Keller 提交于
      Implement the .snapshot region operation for the dummy data region. This
      enables a region snapshot to be taken upon request via the new
      DEVLINK_CMD_REGION_SNAPSHOT command.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3fe0fd53
    • J
      devlink: track snapshot id usage count using an xarray · 12102436
      Jacob Keller 提交于
      Each snapshot created for a devlink region must have an id. These ids
      are supposed to be unique per "event" that caused the snapshot to be
      created. Drivers call devlink_region_snapshot_id_get to obtain a new id
      to use for a new event trigger. The id values are tracked per devlink,
      so that the same id number can be used if a triggering event creates
      multiple snapshots on different regions.
      
      There is no mechanism for snapshot ids to ever be reused. Introduce an
      xarray to store the count of how many snapshots are using a given id,
      replacing the snapshot_id field previously used for picking the next id.
      
      The devlink_region_snapshot_id_get() function will use xa_alloc to
      insert an initial value of 1 value at an available slot between 0 and
      U32_MAX.
      
      The new __devlink_snapshot_id_increment() and
      __devlink_snapshot_id_decrement() functions will be used to track how
      many snapshots currently use an id.
      
      Drivers must now call devlink_snapshot_id_put() in order to release
      their reference of the snapshot id after adding region snapshots.
      
      By tracking the total number of snapshots using a given id, it is
      possible for the decrement() function to erase the id from the xarray
      when it is not in use.
      
      With this method, a snapshot id can become reused again once all
      snapshots that referred to it have been deleted via
      DEVLINK_CMD_REGION_DEL, and the driver has finished adding snapshots.
      
      This work also paves the way to introduce a mechanism for userspace to
      request a snapshot.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      12102436
    • J
      devlink: report error once U32_MAX snapshot ids have been used · 7ef19d3b
      Jacob Keller 提交于
      The devlink_snapshot_id_get() function returns a snapshot id. The
      snapshot id is a u32, so there is no way to indicate an error code.
      
      A future change is going to possibly add additional cases where this
      function could fail. Refactor the function to return the snapshot id in
      an argument, so that it can return zero or an error value.
      
      This ensures that snapshot ids cannot be confused with error values, and
      aids in the future refactor of snapshot id allocation management.
      
      Because there is no current way to release previously used snapshot ids,
      add a simple check ensuring that an error is reported in case the
      snapshot_id would over flow.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7ef19d3b
    • J
      devlink: convert snapshot destructor callback to region op · a0a09f6b
      Jacob Keller 提交于
      It does not makes sense that two snapshots for a given region would use
      different destructors. Simplify snapshot creation by adding
      a .destructor op for regions.
      
      This operation will replace the data_destructor for the snapshot
      creation, and makes snapshot creation easier.
      Noticed-by: NJakub Kicinski <kuba@kernel.org>
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a0a09f6b
    • J
      devlink: prepare to support region operations · e8937681
      Jacob Keller 提交于
      Modify the devlink region code in preparation for adding new operations
      on regions.
      
      Create a devlink_region_ops structure, and move the name pointer from
      within the devlink_region structure into the ops structure (similar to
      the devlink_health_reporter_ops).
      
      This prepares the regions to enable support of additional operations in
      the future such as requesting snapshots, or accessing the region
      directly without a snapshot.
      
      In order to re-use the constant strings in the mlx4 driver their
      declaration must be changed to 'const char * const' to ensure the
      compiler realizes that both the data and the pointer cannot change.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: NJakub Kicinski <kuba@kernel.org>
      Reviewed-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e8937681
  11. 24 3月, 2020 2 次提交
  12. 26 2月, 2020 2 次提交
  13. 05 2月, 2020 1 次提交
  14. 04 2月, 2020 3 次提交
    • T
      netdevsim: use IS_ERR instead of IS_ERR_OR_NULL for debugfs · 6556ff32
      Taehee Yoo 提交于
      Debugfs APIs return valid pointer or error pointer. it doesn't return NULL.
      So, using IS_ERR is enough, not using IS_ERR_OR_NULL.
      Reviewed-by: NJakub Kicinski <kuba@kernel.org>
      Reported-by: Nkbuild test robot <lkp@intel.com>
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      6556ff32
    • T
      netdevsim: fix stack-out-of-bounds in nsim_dev_debugfs_init() · 6fb8852b
      Taehee Yoo 提交于
      When netdevsim dev is being created, a debugfs directory is created.
      The variable "dev_ddir_name" is 16bytes device name pointer and device
      name is "netdevsim<dev id>".
      The maximum dev id length is 10.
      So, 16bytes for device name isn't enough.
      
      Test commands:
          modprobe netdevsim
          echo "1000000000 0" > /sys/bus/netdevsim/new_device
      
      Splat looks like:
      [  249.622710][  T900] BUG: KASAN: stack-out-of-bounds in number+0x824/0x880
      [  249.623658][  T900] Write of size 1 at addr ffff88804c527988 by task bash/900
      [  249.624521][  T900]
      [  249.624830][  T900] CPU: 1 PID: 900 Comm: bash Not tainted 5.5.0+ #322
      [  249.625691][  T900] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [  249.626712][  T900] Call Trace:
      [  249.627103][  T900]  dump_stack+0x96/0xdb
      [  249.627639][  T900]  ? number+0x824/0x880
      [  249.628173][  T900]  print_address_description.constprop.5+0x1be/0x360
      [  249.629022][  T900]  ? number+0x824/0x880
      [  249.629569][  T900]  ? number+0x824/0x880
      [  249.630105][  T900]  __kasan_report+0x12a/0x170
      [  249.630717][  T900]  ? number+0x824/0x880
      [  249.631201][  T900]  kasan_report+0xe/0x20
      [  249.631723][  T900]  number+0x824/0x880
      [  249.632235][  T900]  ? put_dec+0xa0/0xa0
      [  249.632716][  T900]  ? rcu_read_lock_sched_held+0x90/0xc0
      [  249.633392][  T900]  vsnprintf+0x63c/0x10b0
      [  249.633983][  T900]  ? pointer+0x5b0/0x5b0
      [  249.634543][  T900]  ? mark_lock+0x11d/0xc40
      [  249.635200][  T900]  sprintf+0x9b/0xd0
      [  249.635750][  T900]  ? scnprintf+0xe0/0xe0
      [  249.636370][  T900]  nsim_dev_probe+0x63c/0xbf0 [netdevsim]
      [ ... ]
      Reviewed-by: NJakub Kicinski <kuba@kernel.org>
      Fixes: ab1d0cc0 ("netdevsim: change debugfs tree topology")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      6fb8852b
    • T
      netdevsim: fix panic in nsim_dev_take_snapshot_write() · 8526ad96
      Taehee Yoo 提交于
      nsim_dev_take_snapshot_write() uses nsim_dev and nsim_dev->dummy_region.
      So, during this function, these data shouldn't be removed.
      But there is no protecting stuff in this function.
      
      There are two similar cases.
      1. reload case
      reload could be called during nsim_dev_take_snapshot_write().
      When reload is being executed, nsim_dev_reload_down() is called and it
      calls nsim_dev_reload_destroy(). nsim_dev_reload_destroy() calls
      devlink_region_destroy() to destroy nsim_dev->dummy_region.
      So, during nsim_dev_take_snapshot_write(), nsim_dev->dummy_region()
      would be removed.
      At this point, snapshot_write() would access freed pointer.
      In order to fix this case, take_snapshot file will be removed before
      devlink_region_destroy().
      The take_snapshot file will be re-created by ->reload_up().
      
      2. del_device_store case
      del_device_store() also could call nsim_dev_reload_destroy()
      during nsim_dev_take_snapshot_write(). If so, panic would occur.
      This problem is actually the same problem with the first case.
      So, this problem will be fixed by the first case's solution.
      
      Test commands:
          modprobe netdevsim
          while :
          do
              echo 1 > /sys/bus/netdevsim/new_device &
              echo 1 > /sys/bus/netdevsim/del_device &
      	devlink dev reload netdevsim/netdevsim1 &
      	echo 1 > /sys/kernel/debug/netdevsim/netdevsim1/take_snapshot &
          done
      
      Splat looks like:
      [   45.564513][  T975] general protection fault, probably for non-canonical address 0xdffffc000000003a: 0000 [#1] SMP DEI
      [   45.566131][  T975] KASAN: null-ptr-deref in range [0x00000000000001d0-0x00000000000001d7]
      [   45.566135][  T975] CPU: 1 PID: 975 Comm: bash Not tainted 5.5.0+ #322
      [   45.569020][  T975] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [   45.569026][  T975] RIP: 0010:__mutex_lock+0x10a/0x14b0
      [   45.570518][  T975] Code: 08 84 d2 0f 85 7f 12 00 00 44 8b 0d 10 23 65 02 45 85 c9 75 29 49 8d 7f 68 48 b8 00 00 00 0f
      [   45.570522][  T975] RSP: 0018:ffff888046ccfbf0 EFLAGS: 00010206
      [   45.572305][  T975] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
      [   45.572308][  T975] RDX: 000000000000003a RSI: ffffffffac926440 RDI: 00000000000001d0
      [   45.576843][  T975] RBP: ffff888046ccfd70 R08: ffffffffab610645 R09: 0000000000000000
      [   45.576847][  T975] R10: ffff888046ccfd90 R11: ffffed100d6360ad R12: 0000000000000000
      [   45.578471][  T975] R13: dffffc0000000000 R14: ffffffffae1976c0 R15: 0000000000000168
      [   45.578475][  T975] FS:  00007f614d6e7740(0000) GS:ffff88806c400000(0000) knlGS:0000000000000000
      [   45.581492][  T975] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   45.582942][  T975] CR2: 00005618677d1cf0 CR3: 000000005fb9c002 CR4: 00000000000606e0
      [   45.584543][  T975] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [   45.586633][  T975] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [   45.589889][  T975] Call Trace:
      [   45.591445][  T975]  ? devlink_region_snapshot_create+0x55/0x4a0
      [   45.601250][  T975]  ? mutex_lock_io_nested+0x1380/0x1380
      [   45.602817][  T975]  ? mutex_lock_io_nested+0x1380/0x1380
      [   45.603875][  T975]  ? mark_held_locks+0xa5/0xe0
      [   45.604769][  T975]  ? _raw_spin_unlock_irqrestore+0x2d/0x50
      [   45.606147][  T975]  ? __mutex_unlock_slowpath+0xd0/0x670
      [   45.607723][  T975]  ? crng_backtrack_protect+0x80/0x80
      [   45.613530][  T975]  ? wait_for_completion+0x390/0x390
      [   45.615152][  T975]  ? devlink_region_snapshot_create+0x55/0x4a0
      [   45.616834][  T975]  devlink_region_snapshot_create+0x55/0x4a0
      [ ... ]
      
      Fixes: 4418f862 ("netdevsim: implement support for devlink region and snapshots")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      8526ad96
  15. 12 1月, 2020 1 次提交
  16. 11 1月, 2020 2 次提交
  17. 10 11月, 2019 1 次提交
  18. 09 11月, 2019 1 次提交
  19. 07 11月, 2019 1 次提交
  20. 01 11月, 2019 1 次提交
    • I
      netdevsim: Fix use-after-free during device dismantle · 6d6f0383
      Ido Schimmel 提交于
      Commit da58f90f ("netdevsim: Add devlink-trap support") added
      delayed work to netdevsim that periodically iterates over the registered
      netdevsim ports and reports various packet traps via devlink.
      
      While the delayed work takes the 'port_list_lock' mutex to protect
      against concurrent addition / deletion of ports, during device creation
      / dismantle ports are added / deleted without this lock, which can
      result in a use-after-free [1].
      
      Fix this by making sure that the ports list is always modified under the
      lock.
      
      [1]
      [   59.205543] ==================================================================
      [   59.207748] BUG: KASAN: use-after-free in nsim_dev_trap_report_work+0xa67/0xad0
      [   59.210247] Read of size 8 at addr ffff8883cbdd3398 by task kworker/3:1/38
      [   59.212584]
      [   59.213148] CPU: 3 PID: 38 Comm: kworker/3:1 Not tainted 5.4.0-rc3-custom-16119-ge6abb5f0261e #2013
      [   59.215896] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20180724_192412-buildhw-07.phx2.fedoraproject.org-1.fc29 04/01/2014
      [   59.218384] Workqueue: events nsim_dev_trap_report_work
      [   59.219428] Call Trace:
      [   59.219924]  dump_stack+0xa9/0x10e
      [   59.220623]  print_address_description.constprop.4+0x21/0x340
      [   59.221976]  ? vprintk_func+0x66/0x240
      [   59.222752]  __kasan_report.cold.8+0x78/0x91
      [   59.223602]  ? nsim_dev_trap_report_work+0xa67/0xad0
      [   59.224603]  kasan_report+0xe/0x20
      [   59.225296]  nsim_dev_trap_report_work+0xa67/0xad0
      [   59.226435]  ? rcu_read_lock_sched_held+0xaf/0xe0
      [   59.227512]  ? trace_event_raw_event_rcu_quiescent_state_report+0x360/0x360
      [   59.228851]  process_one_work+0x98f/0x1760
      [   59.229684]  ? pwq_dec_nr_in_flight+0x330/0x330
      [   59.230656]  worker_thread+0x91/0xc40
      [   59.231587]  ? process_one_work+0x1760/0x1760
      [   59.232451]  kthread+0x34a/0x410
      [   59.233104]  ? __kthread_queue_delayed_work+0x240/0x240
      [   59.234141]  ret_from_fork+0x3a/0x50
      [   59.234982]
      [   59.235371] Allocated by task 187:
      [   59.236189]  save_stack+0x19/0x80
      [   59.236853]  __kasan_kmalloc.constprop.5+0xc1/0xd0
      [   59.237822]  kmem_cache_alloc_trace+0x14c/0x380
      [   59.238769]  __nsim_dev_port_add+0xaf/0x5c0
      [   59.239627]  nsim_dev_probe+0x4fc/0x1140
      [   59.240550]  really_probe+0x264/0xc00
      [   59.241418]  driver_probe_device+0x208/0x2e0
      [   59.242255]  __device_attach_driver+0x215/0x2d0
      [   59.243150]  bus_for_each_drv+0x154/0x1d0
      [   59.243944]  __device_attach+0x1ba/0x2b0
      [   59.244923]  bus_probe_device+0x1dd/0x290
      [   59.245805]  device_add+0xbac/0x1550
      [   59.246528]  new_device_store+0x1f4/0x400
      [   59.247306]  bus_attr_store+0x7b/0xa0
      [   59.248047]  sysfs_kf_write+0x10f/0x170
      [   59.248941]  kernfs_fop_write+0x283/0x430
      [   59.249843]  __vfs_write+0x81/0x100
      [   59.250546]  vfs_write+0x1ce/0x510
      [   59.251190]  ksys_write+0x104/0x200
      [   59.251873]  do_syscall_64+0xa4/0x4e0
      [   59.252642]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [   59.253837]
      [   59.254203] Freed by task 187:
      [   59.254811]  save_stack+0x19/0x80
      [   59.255463]  __kasan_slab_free+0x125/0x170
      [   59.256265]  kfree+0x100/0x440
      [   59.256870]  nsim_dev_remove+0x98/0x100
      [   59.257651]  nsim_bus_remove+0x16/0x20
      [   59.258382]  device_release_driver_internal+0x20b/0x4d0
      [   59.259588]  bus_remove_device+0x2e9/0x5a0
      [   59.260551]  device_del+0x410/0xad0
      [   59.263777]  device_unregister+0x26/0xc0
      [   59.264616]  nsim_bus_dev_del+0x16/0x60
      [   59.265381]  del_device_store+0x2d6/0x3c0
      [   59.266295]  bus_attr_store+0x7b/0xa0
      [   59.267192]  sysfs_kf_write+0x10f/0x170
      [   59.267960]  kernfs_fop_write+0x283/0x430
      [   59.268800]  __vfs_write+0x81/0x100
      [   59.269551]  vfs_write+0x1ce/0x510
      [   59.270252]  ksys_write+0x104/0x200
      [   59.270910]  do_syscall_64+0xa4/0x4e0
      [   59.271680]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [   59.272812]
      [   59.273211] The buggy address belongs to the object at ffff8883cbdd3200
      [   59.273211]  which belongs to the cache kmalloc-512 of size 512
      [   59.275838] The buggy address is located 408 bytes inside of
      [   59.275838]  512-byte region [ffff8883cbdd3200, ffff8883cbdd3400)
      [   59.278151] The buggy address belongs to the page:
      [   59.279215] page:ffffea000f2f7400 refcount:1 mapcount:0 mapping:ffff8883ecc0ce00 index:0x0 compound_mapcount: 0
      [   59.281449] flags: 0x200000000010200(slab|head)
      [   59.282356] raw: 0200000000010200 ffffea000f2f3a08 ffffea000f2fd608 ffff8883ecc0ce00
      [   59.283949] raw: 0000000000000000 0000000000150015 00000001ffffffff 0000000000000000
      [   59.285608] page dumped because: kasan: bad access detected
      [   59.286981]
      [   59.287337] Memory state around the buggy address:
      [   59.288310]  ffff8883cbdd3280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [   59.289763]  ffff8883cbdd3300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [   59.291452] >ffff8883cbdd3380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [   59.292945]                             ^
      [   59.293815]  ffff8883cbdd3400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [   59.295220]  ffff8883cbdd3480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [   59.296872] ==================================================================
      
      Fixes: da58f90f ("netdevsim: Add devlink-trap support")
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Reported-by: syzbot+9ed8f68ab30761f3678e@syzkaller.appspotmail.com
      Acked-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6d6f0383
  21. 12 10月, 2019 1 次提交
  22. 09 10月, 2019 1 次提交
  23. 07 10月, 2019 1 次提交