It's been a while since I've last touched that code, but... why are you passing this back via idh? This makes sense with, say, idh_max_recv_data_segment_length, because iscsid(8) needs to negotiate this, but for ping and login timeouts the kernel can directly use isc_ping_timeout instead.

Perhaps mention kern.iscsi.ping_timeout, as that's where the '5' comes from? Similar with LoginTimeout (kern.iscsi.login_timeout).

LoginTimeout perhaps, just like in the config warning? (I know, I'm annoying, but consistency can save users a lot of time when trying to understand what's happening.)

Thanks for the good feedback!

Since you're not otherwise changing share/man/man4/iscsi.4 in this diff, you don't need to bump Dd here - and in fact don't need this file at all in here, as long as you remember to bump it in D32540 with the rest of the changes to this file there.

I created this diff on top of the changes of D32540. arcanist sometimes creates funny diffs when doing 2nd / 3rd level stuff. But noted, should I need to apply the patches in a different order.

Since initiator and target are quite symmetric and this structure is now used in both, I think whether it would have sense to make ping timeout configurable in ctl.conf for target.

If the conn_conf comes here from kernel, why not apply the global timeout value there and pass here exact one? iscsid supposed to have minimal capabilities.

Only the initiator is actively sending SCSI IOs; the ctl.conf timeout appears to only be relevant for the login. As ctld is using "timeout" only for the login, there the new "login_timeout" could be used instead of the login variable though.

That would loose the info, if the system global default, or a per-session timeout is in use.