Re: ifg_refcnt atomic operation

2021-02-06 Thread Alexander Bluhm
On Sat, Feb 06, 2021 at 04:44:08PM +0100, Alexander Bluhm wrote: > Or should we go with a self crafted ++ -- refcounting? This would look like this, also fine with me. kasserts are also in refcnt_... API. ok? bluhm Index: net/if.c

Re: ifg_refcnt atomic operation

2021-02-06 Thread Alexander Bluhm
On Sat, Feb 06, 2021 at 05:58:35PM +0300, Vitaliy Makkoveev wrote: > I???m not sure it should be atomic. It seems groups require their own > lock and this lock should be held while we perform if_addgroup() and > if_delgroup(). I also think that atomic refcounting is not needed here. But it does

Re: ifg_refcnt atomic operation

2021-02-06 Thread Vitaliy Makkoveev
> On 6 Feb 2021, at 15:23, Alexander Bluhm wrote: > > On Sat, Feb 06, 2021 at 05:04:20PM +1000, David Gwynne wrote: >> refcnt_init starts counting at 1, while the existing code starts at 0. Do >> the crashes stop because we never fully release all the references and >> never free it now? > >

Re: ifg_refcnt atomic operation

2021-02-06 Thread Alexander Bluhm
On Sat, Feb 06, 2021 at 05:04:20PM +1000, David Gwynne wrote: > refcnt_init starts counting at 1, while the existing code starts at 0. Do > the crashes stop because we never fully release all the references and > never free it now? You are absolutely right. I was too optimistic. Correct diff is

Re: ifg_refcnt atomic operation

2021-02-05 Thread David Gwynne
refcnt_init starts counting at 1, while the existing code starts at 0. Do the crashes stop because we never fully release all the references and never free it now? On Sat, 6 Feb 2021, 10:55 Alexander Bluhm, wrote: > Hi, > > When I replace the ++ and -- of ifg_refcnt with an atomic operation, >