Hi, Karsten Thanks for your reply. The previous discussion about the issue of socket wait queue mismatch in SMC fallback can be referred from: https://lore.kernel.org/all/db9acf73-abef-209e-6ec2-8ada92e2cfbc@xxxxxxxxxxxxx/ This set of patches includes two RFC patches, they are both aimed to fix the same issue, the mismatch of socket wait queue in SMC fallback. In your last reply, I am suggested to add the complete description about the intention of initial patch in order that readers can understand the idea behind it. This has been done in "[RFC PATCH net v2 0/2] net/smc: Fix socket wait queue mismatch issue caused by fallback" of this mail. Unfortunately, I found a defect later in the solution of the initial patch or the v2 patch mentioned above. The defect is about fasync_list and related to 67f562e3e14 ("net/smc: transfer fasync_list in case of fallback"). When user applications use sock_fasync() to insert entries into fasync_list, the wait queue they operate is smc socket->wq. But in initial patch or the v2 patch, I swapped sk->sk_wq of smc socket and clcsocket in smc_create(), thus the sk_data_ready / sk_write_space.. of smc will wake up clcsocket->wq finally. So the entries added into smc socket->wq.fasync_list won't be woken up at all before fallback. So the solution in initial patch or the v2 patch of this mail by swapping sk->sk_wq of smc socket and clcsocket seems a bad way to fix this issue. Therefore, I tried another solution by removing the wait queue entries from smc socket->wq to clcsocket->wq during the fallback, which is described in the "[RFC PATCH net 2/2] net/smc: Transfer remaining wait queue entries" of this mail. In our test environment, this patch can fix the fallback issue well. I am looking forward to hear your opinions. Thank you. Cheers, Wen Gu Wen Gu (2): net/smc: Fix socket wait queue mismatch issue caused by fallback net/smc: Transfer remaining wait queue entries
