Re: [External] : ipsec acquire mutex refcount

2022-03-17 Thread Alexandr Nedvedicky
Hello, > > > +ipsp_delete_acquire_locked(struct ipsec_acquire *ipa) > > > +{ > > > + if (timeout_del(&ipa->ipa_timeout) == 1) > > > + refcnt_rele(&ipa->ipa_refcnt); > >^^ > > can we also put ASSERT/check into this branch > > to verify we are no rele

Re: [External] : ipsec acquire mutex refcount

2022-03-16 Thread Alexander Bluhm
On Mon, Mar 14, 2022 at 11:09:48AM +0100, Alexandr Nedvedicky wrote: > 667 ipsec_delete_policy(struct ipsec_policy *ipo) > > 668 { > 669 struct ipsec_acquire *ipa; > 670 struct radix_node_head *rnh; > 671 struct radix_node *rn =

Re: [External] : ipsec acquire mutex refcount

2022-03-14 Thread Alexandr Nedvedicky
Hello, On Tue, Mar 15, 2022 at 12:58:48AM +0300, Vitaliy Makkoveev wrote: > > > >I think local var `ipa` needs to be initialized to NULL > >to avoid random value/pointer when no `ipa` for given `seq` > >is found. > > > >ipsp_pending_acquire() plays the same gamble. > > #define

Re: [External] : ipsec acquire mutex refcount

2022-03-14 Thread Vitaliy Makkoveev
> On 15 Mar 2022, at 00:45, Alexandr Nedvedicky > wrote: > > Hello, > > On Tue, Mar 15, 2022 at 12:37:00AM +0300, Vitaliy Makkoveev wrote: >> Hi, >> >> Why do you want to initialize `ipa’ variable in >> ipsp_pending_acquire() and ipsec_get_acquire()? This doesn’t >> require. > >after loo

Re: [External] : ipsec acquire mutex refcount

2022-03-14 Thread Alexandr Nedvedicky
Hello, On Tue, Mar 15, 2022 at 12:37:00AM +0300, Vitaliy Makkoveev wrote: > Hi, > > Why do you want to initialize `ipa’ variable in > ipsp_pending_acquire() and ipsec_get_acquire()? This doesn’t > require. after looking at code with bluhm's diff applied I see this: 936 struct ipsec_acquire

Re: [External] : ipsec acquire mutex refcount

2022-03-14 Thread Vitaliy Makkoveev
Hi, Why do you want to initialize `ipa’ variable in ipsp_pending_acquire() and ipsec_get_acquire()? This doesn’t require. > On 14 Mar 2022, at 13:09, Alexandr Nedvedicky > wrote: > > Hello, > > > > changes looks good. just few nits. > >I took a closer look at ipsec_delete_policy(): >

Re: [External] : ipsec acquire mutex refcount

2022-03-14 Thread Alexandr Nedvedicky
Hello, changes looks good. just few nits. I took a closer look at ipsec_delete_policy(): 667 ipsec_delete_policy(struct ipsec_policy *ipo) 668 { 669 struct ipsec_acquire *ipa; 670 struct radix_node_head *rnh; 671 struct

Re: ipsec acquire mutex refcount

2022-03-13 Thread Hrvoje Popovski
On 9.3.2022. 19:14, Alexander Bluhm wrote: > Hi, > > Hrvoje has hit a crash with IPsec acquire while testing the parallel > ip forwarding diff. Analysis with sashan@ concludes that this part > is not MP safe. Mutex and refcount should fix the memory management. > > Hrvoje: Could you test this d

Re: ipsec acquire mutex refcount

2022-03-11 Thread Hrvoje Popovski
On 9.3.2022. 21:02, Hrvoje Popovski wrote: > On 9.3.2022. 19:14, Alexander Bluhm wrote: >> Hi, >> >> Hrvoje has hit a crash with IPsec acquire while testing the parallel >> ip forwarding diff. Analysis with sashan@ concludes that this part >> is not MP safe. Mutex and refcount should fix the memo

Re: ipsec acquire mutex refcount

2022-03-09 Thread Hrvoje Popovski
On 9.3.2022. 19:14, Alexander Bluhm wrote: > Hi, > > Hrvoje has hit a crash with IPsec acquire while testing the parallel > ip forwarding diff. Analysis with sashan@ concludes that this part > is not MP safe. Mutex and refcount should fix the memory management. > > Hrvoje: Could you test this d

ipsec acquire mutex refcount

2022-03-09 Thread Alexander Bluhm
Hi, Hrvoje has hit a crash with IPsec acquire while testing the parallel ip forwarding diff. Analysis with sashan@ concludes that this part is not MP safe. Mutex and refcount should fix the memory management. Hrvoje: Could you test this diff? ok? bluhm Index: net/pfkeyv2.c ==