At Thu, 01 Jun 2023 08:42:45 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in
> The attached ad-hoc patch appears to be working somehow for this
> specific scenario. (It can contain any defects including possible
> shared entry leaks.) We need to find a better approach to prevent the
> reuse of an already-reinited entry. I believe it can be fixed by
> adding a reuse count to both the cached entry and shared entry, then
> we could compare these numbers to verify the cached entry. However, I
> can't think of a solution that wouldn't require additional struct
> members for now. Thus I'm not sure how to fix this for older versions
> without them..
Here's the alpha version of that. This doesn't modify on-disk data
format and I don't think anyone outside the core relies on the
internal data structure. So it would be back-patcheable.
This problem brings another concern regarding how concurrent reusing
and refetching existing entries work safely. At least, it is not
great to have to check two variables. It would be better combining
"dropped" with the reuse-count. In other words, checking if an entry
is in the dropped state by examining the reuse-count value.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center