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

On Wed, Jun 17, 2026 at 07:01:52PM +0800, Ankit Kapoor wrote:
> 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.
> 

Yes, you may consider to use a deciate mempool to alocate these refcounter
pages with GFP_NOIO. If I missed this point in replying your patch, please
add this into my review comments.


> 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.
> 

Using u32 is good. For 100TB cache, the refcount pages may occupy around
100MB more or less memory. IMHO that's acceptable.

> 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.
> 

Yes, that's what I think of at this moment. Also you should think of
using RCU in bch_has_active_bypass_writes() to replace the spin_lock on
read path. I will explain that in the patch.

Thanks.

Coly Li