On 1/4/24 08:36, Matthew Wilcox (Oracle) wrote: > I've learned why it's safe to call __folio_mark_dirty() from > mark_buffer_dirty() without holding the folio lock, so update > the description to explain why. > > Signed-off-by: Matthew Wilcox (Oracle) <willy@xxxxxxxxxxxxx> > --- > mm/page-writeback.c | 14 +++++++++----- > 1 file changed, 9 insertions(+), 5 deletions(-) > > diff --git a/mm/page-writeback.c b/mm/page-writeback.c > index cd4e4ae77c40..96da6716cb86 100644 > --- a/mm/page-writeback.c > +++ b/mm/page-writeback.c > @@ -2652,11 +2652,15 @@ void folio_account_cleaned(struct folio *folio, struct bdi_writeback *wb) > * If warn is true, then emit a warning if the folio is not uptodate and has > * not been truncated. > * > - * The caller must hold folio_memcg_lock(). Most callers have the folio > - * locked. A few have the folio blocked from truncation through other > - * means (eg zap_vma_pages() has it mapped and is holding the page table > - * lock). This can also be called from mark_buffer_dirty(), which I > - * cannot prove is always protected against truncate. > + * The caller must hold folio_memcg_lock(). It is the caller's > + * responsibility to prevent the folio from being truncated while > + * this function is in progress, although it may have been truncated > + * before this function is called. Most callers have the folio locked. > + * A few have the folio blocked from truncation through other means (eg preferably s/eg/e.g./ > + * zap_vma_pages() has it mapped and is holding the page table lock). > + * When called from mark_buffer_dirty(), the filesystem should hold a > + * reference to the buffer_head that is being marked dirty, which causes > + * try_to_free_buffers() to fail. > */ > void __folio_mark_dirty(struct folio *folio, struct address_space *mapping, > int warn) -- #Randy
