On 12/14/2016 08:48 PM, Parthasarathy Bhuvaragan wrote: > On 12/14/2016 12:20 PM, Ying Xue wrote: >> On 12/14/2016 03:26 AM, Parthasarathy Bhuvaragan wrote: >>>> > In my opinion, the ideal order is still as belows: >>>> > >>>> > 1, Close connection; >>>> > 2. Call tipc_unregister_callbacks to let sk->sk_user_data. As long as >>>> > sk->sk_user_data is 0, no more data will be submitted to >>>> > con->rwork/on->swork works. >>>> > 3. Release socket. >>> Yes, with your proposed change the soft lockup reported by John will go >>> away but it does not avoid the problem which is fixed by commit >>> 333f796235a527. As long as we yield and let the scheduler schedule a new >>> work item, we will break the single threaded work queue assumption. >>> >>> I tested with the proposed ideal order and does not fix the fault >>> fixed by commit 333f796235a527. >>> >> >> I know. I think we probably can add reference counter into >> tipc_subscription structure to solve the issue fixed by 333f796235a527 >> commit. >> >> What do you think? > I have an idea to fix 333f796235a527 in a simple way and keep your > proposal for John's issue. Now running some tests on it. >
That sounds great, and I waiting for your patches. Regards, Ying > /Partha >> >> Regards, >> Ying >> >>> Thanks for the review. I will spend some more time to find a simpler >>> solution for both. >> > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion