summaryrefslogtreecommitdiff
path: root/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_send.c
diff options
context:
space:
mode:
authorPrashant Malani <pmalani@chromium.org>2019-11-20 11:40:21 -0800
committerDavid S. Miller <davem@davemloft.net>2019-11-20 12:48:13 -0800
commit84811412464d66fcf73661a279aa1d7985166495 (patch)
tree9929dd11897149a19c3cf6ec9b04d2d888e4e28e /drivers/net/ethernet/mellanox/mlx5/core/steering/dr_send.c
parentb172845a4090e52f233e45801ce7f44ecc4cc955 (diff)
r8152: Re-order napi_disable in rtl8152_close
Both rtl_work_func_t() and rtl8152_close() call napi_disable(). Since the two calls aren't protected by a lock, if the close function starts executing before the work function, we can get into a situation where the napi_disable() function is called twice in succession (first by rtl8152_close(), then by set_carrier()). In such a situation, the second call would loop indefinitely, since rtl8152_close() doesn't call napi_enable() to clear the NAPI_STATE_SCHED bit. The rtl8152_close() function in turn issues a cancel_delayed_work_sync(), and so it would wait indefinitely for the rtl_work_func_t() to complete. Since rtl8152_close() is called by a process holding rtnl_lock() which is requested by other processes, this eventually leads to a system deadlock and crash. Re-order the napi_disable() call to occur after the work function disabling and urb cancellation calls are issued. Change-Id: I6ef0b703fc214998a037a68f722f784e1d07815e Reported-by: http://crbug.com/1017928 Signed-off-by: Prashant Malani <pmalani@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/net/ethernet/mellanox/mlx5/core/steering/dr_send.c')
0 files changed, 0 insertions, 0 deletions