aboutsummaryrefslogtreecommitdiffstats
path: root/net/unix/sysctl_net_unix.c
diff options
context:
space:
mode:
authorDaniel Wagner <[email protected]>2025-02-14 08:02:04 +0000
committerKeith Busch <[email protected]>2025-02-20 17:13:55 +0000
commitf13409bb3f9140dad7256febcb478f0c9600312c (patch)
treed1bd6974384b65e9fdd7592d1efeaf2f809a9f42 /net/unix/sysctl_net_unix.c
parentapple-nvme: Support coprocessors left idle (diff)
downloadkernel-f13409bb3f9140dad7256febcb478f0c9600312c.tar.gz
kernel-f13409bb3f9140dad7256febcb478f0c9600312c.zip
nvme-fc: rely on state transitions to handle connectivity loss
It's not possible to call nvme_state_ctrl_state with holding a spin lock, because nvme_state_ctrl_state calls cancel_delayed_work_sync when fastfail is enabled. Instead syncing the ASSOC_FLAG and state transitions using a lock, it's possible to only rely on the state machine transitions. That means nvme_fc_ctrl_connectivity_loss should unconditionally call nvme_reset_ctrl which avoids the read race on the ctrl state variable. Actually, it's not necessary to test in which state the ctrl is, the reset work will only scheduled when the state machine is in LIVE state. In nvme_fc_create_association, the LIVE state can only be entered if it was previously CONNECTING. If this is not possible then the reset handler got triggered. Thus just error out here. Fixes: ee59e3820ca9 ("nvme-fc: do not ignore connectivity loss during connecting") Closes: https://lore.kernel.org/all/denqwui6sl5erqmz2gvrwueyxakl5txzbbiu3fgebryzrfxunm@iwxuthct377m/ Reported-by: Shinichiro Kawasaki <[email protected]> Tested-by: Shin'ichiro Kawasaki <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Signed-off-by: Daniel Wagner <[email protected]> Signed-off-by: Keith Busch <[email protected]>
Diffstat (limited to 'net/unix/sysctl_net_unix.c')
0 files changed, 0 insertions, 0 deletions