Hi, In 6fdfaf15 (reftable/stack: use stat info to avoid re-reading stack list, 2024-01-11) we have introduced a new mechanism to avoid re-reading the table list in case stat(3P) figures out that the stack didn't change since the last time we read it. Unfortunately, I've been able to hit a bug there that can happen under very specific circumstances when a reading and writing process race with each other. When the writer appends to the stack and then compacts it, it may happen that we recycle the previously-used inode of "tables.list" so that the resulting `struct stat` exactly matches the cached value of the reading process. The first patch is merely cosmetic, whereas the second patch fixes the described race. The topic depends on ps/reftable-optimize-io, which has introduced the issue. Patrick Patrick Steinhardt (2): reftable/stack: unconditionally reload stack after commit reftable/stack: fix race in up-to-date check reftable/stack.c | 101 ++++++++++++++++++++++++++++++++++++++++++---- reftable/stack.h | 4 +- reftable/system.h | 1 - 3 files changed, 96 insertions(+), 10 deletions(-) base-commit: 718a93ecc06ed59dda4e6a5d91b1c2169275694f -- 2.43.GIT
Attachment:
signature.asc
Description: PGP signature
