srp_tmo_valid(9)

💅 NAME 💅

okay bestie, this is srp_tmo_valid(9) from the Kernel API Manual, and its whole job is literally to check timeout combination validity. no cap, that's the function. 🫶✨

✨ SYNOPSIS ✨

int srp_tmo_valid (int reconnect_delay , int fast_io_fail_tmo , long
       dev_loss_tmo );

🎀 ARGUMENTS 🎀

• reconnect_delay — the reconnect delay, in seconds. yes, seconds, keep up 💅
• fast_io_fail_tmo — the fast I/O fail timeout, in seconds. ⏱️
• dev_loss_tmo — the device loss timeout, in seconds. 🦋

🔥 DESCRIPTION 🔥

so the combo of timeout parameters has to be such that SCSI commands are finished in a reasonable time. that's the whole vibe check. if the numbers are giving chaos, this function is not having it. 😭

that means you do not allow the fast I/O fail timeout to exceed SCSI_DEVICE_BLOCK_MAX_TIMEOUT, and you also do not allow dev_loss_tmo to exceed that limit if failing I/O fast has been disabled. periodt. 💀

plus, these parameters have to be such that multipath can detect failed paths timely. so yeah — do not allow all three parameters to be disabled simultaneously. that's the one-way ticket to bad-path-detection city, and we are not going there. 🚫🦋

🌈 SEE ALSO 🌈

kernel file: ./drivers/scsi/scsi_transport_srp.c

• srp_reconnect_work(9)
• rport_fast_io_fail_timedout(9)
• rport_dev_loss_timedout(9)
• srp_start_tl_fail_timers(9)
• srp_reconnect_rport(9)
• srp_timed_out(9)
• srp_rport_get(9)
• srp_rport_put(9)
• srp_rport_add(9)
• srp_rport_del(9)
• srp_remove_host(9)
• srp_stop_rport_timers(9)
• srp_attach_transport(9)
• srp_release_transport(9)

mwah 💋 this lil page lives under ./drivers/scsi and is dated October 2026 — see you in the group chat, bestie! 🫶✨👑