Re: [tipc-discussion] [PATCH v2 net-next 6/6] tipc: delete expired subscription

[John T. <tho...@gm...>]

On Thu, Mar 16, 2017 at 1:45 AM, Parthasarathy Bhuvaragan <
par...@er...> 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 <yin...@wi...>
> *Sent:* Wednesday, March 15, 2017 12:33 PM
> *To:* Parthasarathy Bhuvaragan; Jon Maloy; tho...@gm...
> *Cc:* tip...@li...
> *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
>
>