pá 3. 2. 2023 v 18:16 odesílatel Serapheim Dimitropoulos <serapheim.dimitro@xxxxxxxxxxx> napsal: > > Looking through the login code it seems like there are two functions that > are expected to call up() on that semaphore by calling iscsit_deaccess_np(): > > A] __iscsi_target_login_thread(): This is the same thread that acquired > the semaphore (by calling iscsit_access_np()). > B] iscsi_target_do_login_rx(): This is a delayed worker thread spawned > by the thread in [A] > > Looking at both of those codepaths it seems like there is one case for each > path that we never call iscsit_deaccess_np() to release the semaphore. > > For [A] that is if iscsi_target_start_negotiation() returns 0 towards the > end of that function. > > For [B] that is if iscsi_target_do_login() returns 0 AND > iscsi_target_sk_check_and_clear(conn, LOGIN_FLAGS_WRITE_ACTIVE) > returns 0. > > Since we have no expertise in this part of the kernel I wanted to ask you > all, are the two above scenarios expected to not release the semaphore > on purpose or is any of them a bug? If they are not bugs, where is the > semaphore expected to be released? It's the expected behaviour, when iscsi_target_do_login() or iscsi_target_start_negotiation() return 0, it means that more PDU exchanges are needed to complete the login process. In case [A]: if iscsi_target_start_negotiation() returns 0, the login thread will pass the control to the "login_work" worker; The latter will take over the login process until either it fails or it's successful and also takes over the responsibility of releasing the semaphore. For case [B]: if iscsi_target_do_login() returns 0 it means that login_work needs more PDU exchanges to complete its job, so it stops and the sk_data_ready/sk_state_change() callbacks will reschedule login_work until the job is done, at the end of which the semaphore is released. I'm looking at the code right now to see if I can spot a bug in the code. Maurizio
