Subject: Re: [vpp-dev] Race condition between bihash deletion and searching -
misuse or bug?
Hi Dave,
I tested the change and found some issue. Please check gerrit comments. Thanks!
Best regards,
Hao Tian
-Original Message-
From: vpp-dev@lists.fd.io on behalf of Dave Barach
Sent: Friday
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] Race condition between bihash deletion and searching -
misuse or bug?
Hi Dave,
Thanks for your work. I am ready to test whenever needed.
Best regards,
Hao Tian
From: v
Hi Dave,
What if just to use highest bit of key as free mark?
While having clib_crc32c_uses_intrinsics defined, hash result will be 32bit
only, highest bit of 64bit key is completely “free”.
If not defined, - highest but can be just stripped off while computation in
clib_bihash_*.
With such
ts.fd.io> mailto:vpp-dev@lists.fd.io> > on behalf of Dave Barach mailto:v...@barachs.net> >
Sent: Thursday, March 16, 2023 7:02 AM
To: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] Race condition between bihash deletion and searching -
.
D.
-Original Message-
From: vpp-dev@lists.fd.io On Behalf Of Andrew Yourtchenko
Sent: Wednesday, March 15, 2023 12:33 PM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Race condition between bihash deletion and searching -
misuse or bug?
Hao,
I noticed the same behavior when stress
: Thursday, March 16, 2023 12:33 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Race condition between bihash deletion and searching -
misuse or bug?
Hao,
I noticed the same behavior when stress-testing the multi thread session
handling for the ACL plugin a while ago. I thought this trade off
-dev@lists.fd.io On Behalf Of Andrew Yourtchenko
Sent: Wednesday, March 15, 2023 12:33 PM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Race condition between bihash deletion and searching -
misuse or bug?
Hao,
I noticed the same behavior when stress-testing the multi thread session
handling
Hao,
I noticed the same behavior when stress-testing the multi thread session
handling for the ACL plugin a while ago. I thought this trade off is there to
avoid having to do the hard locks in bihash code, rather than it being a bug.
As you say - the special value comes only if the deletion is
Hi,
I tried but could not come up with any way that is able to ensure the kvp being
valid upon return without using the full bucket lock.
Maybe we can make a copy of the value before returning, validate the copy and
return that copy instead. Critical section can be shrinked to cover only the
.
-Original Message-
From: vpp-dev@lists.fd.io On Behalf Of Hao Tian
Sent: Tuesday, March 14, 2023 9:47 PM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Race condition between bihash deletion and searching
- misuse or bug?
Hi,
I've done the change you asked, and the "suspicious
Hi,
I've done the change you asked, and the "suspicious value" warnings are all
gone. Here is the diff:
diff --git a/src/vppinfra/bihash_template.h b/src/vppinfra/bihash_template.h
index c4e120e4a..b9f658db3 100644
--- a/src/vppinfra/bihash_template.h
+++ b/src/vppinfra/bihash_template.h
@@
Quick experiment: in
src/vppinfra/bihash_template.h:clib_bihash_search_inline_2_with_hash(),
replace this:
if (PREDICT_FALSE (b->lock))
{
volatile BVT (clib_bihash_bucket) * bv = b;
while (bv->lock)
CLIB_PAUSE ();
}
With:
BV(clib_bihash_lock_bucket(b));
and make
12 matches
Mail list logo
