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

Reply via email to