Re: [PATCH v19 00/40] DEPT(DEPendency Tracker)

On Tue, Aug 25, 2026 at 09:37:34AM +1000, NeilBrown wrote:
> > For readahead, I think that queues / lru are not involved. We submit the I/O,
> > and once the I/O is done, we unlock the folio from interrupt context.
> 
> "submit the I/O" means "attach the page to a "struct bio" (or similar)
> and attach the struct bio to a transmit queue for the device (or
> similar).  So there really is a queue.
> 
> > 
> > end_buffer_async_read() / iomap_finish_folio_read() end up calling
> > folio_end_read(), where we do the magic
> > 
> > 	folio_wake_bit(folio, PG_locked);
> 
> Exactly where the lock ownership should be reclaimed is not immediately
> clear to me.  bio_endio() might be early enough but there are probably
> better points.
> 
> A small difficulty here is that a bio has multiple folios and they are
> all locked.  I cannot see that lockdep has a concept of holding an
> arbitrarily large set of related locks.
> We could just tell lockdep 
>   "I have some folios locked" 
> or maybe enhance lockdep to allow
>   "I have N folios locked"
> or even
>   "I have N folios in address-space A with the highest offset being O".
> 
> This would allow lockdep to check the validity of locking another folio
> - only allowed if the address space is the same and the offset is larger
> than the previous largest.

It's more complex than that; see my other emails on the subject.

I think we need the ability for lockdep to call a function which says "I
hold this lock, is that lock OK to acquire".  But the devil is in the
details.

> > 
> > It's interesting, that for writeback we never unlock the folio on the I/O path,
> > but instead have the dedicated page flag to tell us when writeback is complete.
> 
> PG_locked and PG_writeback are two different lock-bits with two
> different meanings.
> When a folio is PG_locked the content is invalid and shouldn't be accessed.
> When a folio is in PG_writeback its data is not safe even though
> PG_dirty has been cleared (if I remember correctly).
> 
> So these are two separate, though related, lock bits that would both
> need to be tracked.  lockdep would detect how they are related.

Some history ... before we had PG_writeback, we held PG_locked
throughout the writeback process.  People argued convincingly that it
was fine to map a page into a process's address space (which requires
PG_locked) while it was being written back.  And so PG_locked was
split.  Now we take PG_locked at the beginning of the writeback process
and downgrade to PG_writeback at some point.