BUG/MEDIUM: cache: do not release an entry under the cache read lock
In http_action_req_cache_use() the cache lock is taken in read mode rather
than write mode in order to keep decent performance. But the secondary key
lookup releases the primary entry from there with needs_locking = 0, which
means "the caller already holds the write lock", because dropping the last
reference removes the entry from the tree. A removal could therefore run
while other threads were walking the same tree under their own read lock.
Release the entry after the read-locked section instead, where taking the
write lock for the removal is allowed.
The row is handed back only once the reference has been dropped, and no
longer before: a row that returns to the avail list while a reference is
still held on its entry can be recycled by another thread, and the release
would then be applied to blocks that hold a response body. This is also why
the reattach cannot simply be left where it was.
This is present at least as far back as 3.0 and should be backported to all
stable branches.
projects / haproxy.git / commit