The commit 75a46d2 introduced a timeout mechanism for event_loop, but this patch can lead to stack corruption caused by leftover PDUs when exiting due to a timeout (refer to: PR #434).
Although a fix was provided in this commit, it overlooked a specific scenario: if a reconnection is triggered during event_loop and succeeds, the PDUs from the old_iscsi instance may be reallocated. This resets the scsi_timeout for those PDUs, potentially causing their timeout to exceed the timeout of the event_loop. Consequently, when the event_loop times out and exits, invoking iscsi_timeout_scan may still leave residual PDUs, thus reintroducing the issue described in PR #434.
Currently, I don't have a robust solution for this issue. A straightforward but heavy-handed approach would be to cancel all PDUs when event_loop times out. However, this could interfere with some internally generated asynchronous PDUs in libiscsi, such as login PDUs.
The commit 75a46d2 introduced a timeout mechanism for event_loop, but this patch can lead to stack corruption caused by leftover PDUs when exiting due to a timeout (refer to: PR #434).
Although a fix was provided in this commit, it overlooked a specific scenario: if a reconnection is triggered during event_loop and succeeds, the PDUs from the old_iscsi instance may be reallocated. This resets the scsi_timeout for those PDUs, potentially causing their timeout to exceed the timeout of the event_loop. Consequently, when the event_loop times out and exits, invoking iscsi_timeout_scan may still leave residual PDUs, thus reintroducing the issue described in PR #434.
Currently, I don't have a robust solution for this issue. A straightforward but heavy-handed approach would be to cancel all PDUs when event_loop times out. However, this could interfere with some internally generated asynchronous PDUs in libiscsi, such as login PDUs.