On Fri, Oct 11, 2019 at 12:09:11AM +0200, Phil Sutter wrote: [...] > Maybe we could go with a simpler solution for now, which is to check > kernel genid again and drop the local cache if it differs from what's > stored. If it doesn't, the current cache is still up to date and we may > just fetch what's missing. Or does that leave room for a race condition? My concern with this approach is that, in the dynamic ruleset update scenarios, assuming very frequent updates, you might lose race when building the cache in stages. Hence, forcing you to restart from scratch in the middle of the transaction handling. I prefer to calculate the cache that is needed in one go by analyzing the batch, it's simpler. Note that we might lose race still since kernel might tell us we're working on an obsolete generation number ID cache, forcing us to restart.
