On Thu, Mar 16, 2017 at 1:45 AM, Parthasarathy Bhuvaragan < parthasarathy.bhuvara...@ericsson.com> wrote: > > Hi John, > > Can you run your test with my series and provide some feedback? > Hi Partha I have started running some tests and will be in touch later today with initial results. Thanks Jt
> > [PATCH v3 net-next 0/3] solve two deadlock issues: > > tipc: advance the time of calling tipc_nametbl_unsubscribe > tipc: advance the time of deleting subscription from > subscriber->subscrp_list > tipc: adjust the policy of holding subscription kref > > regards > partha > ------------------------------ > *From:* Ying Xue <ying....@windriver.com> > *Sent:* Wednesday, March 15, 2017 12:33 PM > *To:* Parthasarathy Bhuvaragan; Jon Maloy; thompa....@gmail.com > *Cc:* tipc-discussion@lists.sourceforge.net > *Subject:* Re: [tipc-discussion] [PATCH v2 net-next 6/6] tipc: delete > expired subscription > > Hi Partha, > > Thank you for the review and improvement. > > On 03/14/2017 01:43 AM, Parthasarathy Bhuvaragan wrote: > > Hi Ying, > > > > I have a new patch sets which fixes this issue using fixes from your > > patches. It deviates from your patch the following way: > > In my solution, the subscription refcount keeps track of a subscription > > with or without timer. I do not increment refcount for timer, and use > > the subscriber lock plus the del_timer to find outstanding timers. I > > will send the series shortly. > > I have carefully reviewed your solution as well as your revised patches. > Your method is pretty simpler than mine. Instead the thing I image is > too complex. Now I can confirm that it's unnecessary to increase > subscription refcount before its timer is started, and it's absolutely > safe for us now. Good work Parth! > > > > > I applied your series and ran some tests with it. If I run test against > > each patch individually, they seem to introduce new warnings/panics. I > > think every patch should be as correct as possible. I tried to moved > > around the patches in this series to get every patch correct, which led > > me to my series above. > > > > If we can ensure every single patch of a patchset can independently work > very well, that's very good. But in many cases, it's hard to reach that > goal. The most reason is that on one hand, we must have patch easily > readable for reviewer, on another hand, we must keep every single work > well. So it is sometimes very hard. > > Anyway, your revised patches are very good. If Jon or other guys have no > any different opinion, please submit them to net-next as soon as possible. > > Of course, if possible, please let John verify them again. > > Thanks, > Ying > > ------------------------------------------------------------------------------ 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
