summaryrefslogtreecommitdiff
path: root/security/security.c
diff options
context:
space:
mode:
authorAmir Vadai <amirv@mellanox.com>2014-03-06 18:28:17 +0200
committerDavid S. Miller <davem@davemloft.net>2014-03-06 17:09:04 -0500
commit97989356af0ec8b1b1658d804892abb354127330 (patch)
treec73f68a57e4e2a24b8d8d7b071ea9b7658dd3998 /security/security.c
parent57352ef4f5f19969a50d42e84b274287993b576f (diff)
net/mlx4_core: mlx4_init_slave() shouldn't access comm channel before PF is ready
Currently, the PF call to pci_enable_sriov from the PF probe function stalls for 10 seconds times the number of VFs probed on the host. This happens because the way for such VFs to determine of the PF initialization finished, is by attempting to issue reset on the comm-channel and get timeout (after 10s). The PF probe function is called from a kenernel workqueue, and therefore during that time, rcu lock is being held and kernel's workqueue is stalled. This blocks other processes that try to use the workqueue or rcu lock. For example, interface renaming which is calling rcu_synchronize is blocked, and timedout by systemd. Changed mlx4_init_slave() to allow VF probed on the host to immediatly detect that the PF is not ready, and return EPROBE_DEFER instantly. Only when the PF finishes the initialization, allow such VFs to access the comm channel. This issue and fix are relevant only for probed VFs on the hypervisor, there is no way to pass this information to a VM until comm channel is ready, so in a VM, if PF is not ready, the first command will be timedout after 10 seconds and return EPROBE_DEFER. Signed-off-by: Amir Vadai <amirv@mellanox.com> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'security/security.c')
0 files changed, 0 insertions, 0 deletions