Re: [PATCH v2 0/1] bcache: track active bypass writes to prevent stale cache reads

[Ankit Kapoor <ankitkap@google.com>]

Hi Coly,

A quick update on my cover letter questions: after thinking more about
those edge cases, I realized my initial reasoning was flawed and
could lead to the exact stale-data reads this patch aims to prevent.

kzalloc failures: Bypassing the counter increment on memory failure
means the chunk is untracked. A subsequent read will incorrectly fail
to bypass the cache, but worse, if a later write does get tracked, the
decrements will become asymmetrical. I am wondering if a pre-allocated
fallback pool could be a potential solution other than the hijack
approach used by md-bitmap.

u16 counters: I realized clamping at U16_MAX completely breaks the
decrement path. If an I/O burst exceeds 65,535 writes, clamping loses
the true count. The counter will drop to 0 prematurely while writes
are still in flight, leaving a window for stale reads.

To ensure absolute robustness, using u32 and a fallback memory pool
seems necessary. I will hold off on sending a v3 so you can review
the core page-lock tracking logic in v2 first and provide your
suggestions on these two cases, but I wanted to correct my own
reasoning before you spend time reviewing those specific questions.

Thanks,
Ankit Kapoor