tree a98b2ac5e38388e8b3e7ea384f5f18decb78943b
parent 3801bdc3fc1c2c6d596b4c4ee3449a76f2da8654
author Willy Tarreau <w@1wt.eu> 1588331732 +0200
committer Willy Tarreau <w@1wt.eu> 1588332740 +0200
encoding latin1

BUG/MEDIUM: shctx: bound the number of loops that can happen around the lock

Given that a "count" value of 32M was seen in _shctx_wait4lock(), it
is very important to prevent this from happening again. It's absolutely
essential to prevent the value from growing unbounded because with an
increase of the number of threads, the number of successive failed
attempts will necessarily grow.

Instead now we're scanning all 2^p-1 values from 3 to 255 and are
bounding to count to 255 so that in the worst case each thread tries an
xchg every 255 failed read attempts. That's one every 4 on average per
thread when there are 64 threads, which corresponds to the initial count
of 4 for the first attempt so it seems like a reasonable value to keep a
low latency.

The bug was introduced with the shctx entries in 1.5 so the fix must
be backported to all versions. Before 1.8 the function was called
_shared_context_wait4lock() and was in shctx.c.