With want card handled at the start of the function, this is dead code.

Can you please briefly explain the recursive lock problem - it is not immediately clear to me.

dead code... : Right, this "continue" thing is the dead code. we should remove it later.

Kleo periodically asks scd getinfo all_active_apps. I have a concern about this, since it has side effects for card access .

In the function send_serialno_and_app_status with WITH_APPS=1, it calls select_all_additional_applications_internal, which has side effects adding another app to the CARD (basically, for Yubikey). (when adding another app, it issues smartcard commands to select the app.)
So, the caller needs to have the lock for the CARD.

The call chain in question is:

• scd getinfo all_active_apps
• app_send_active_apps CARD=NULL
• send_card_and_app_list WITH_APPS=1, WANTCARD=NULL
• send_serialno_and_app_status WITH_APPS=1

So, the commit rG25a140542a91: scd: Serialize CARD access for send_card_and_app_list. added lock_card/unlock_card in send_card_and_app_list.

However, there is another use case, the call chain is:

• scd getinfo active_apps
• app_send_active_apps CARD with locked
• send_card_and_app_list WITH_APPS=1, WANTCARD active

In this case (WANTCARD is active), we should not get the lock again, and we don't need to loop actually.

Thanks for explaining.