Re: [PATCH] mm: filemap: tighten dropbehind completion context check

[Wenjie Qi]

  I think fault-around provides such a path.

  do_read_fault() calls do_fault_around() before ->fault.  For generic file
  mappings this reaches filemap_map_pages(), which walks mapping->i_pages
  directly and maps ready folios without going through
  __filemap_get_folio_mpol().  It does not clear dropbehind or exclude dirty
  or writeback folios.

  If the mapped PTE range covers vmf->address, filemap_map_pages() returns
  VM_FAULT_NOPAGE, so do_read_fault() does not fall back to filemap_fault().
  Both the faulting folio and speculative neighboring folios can therefore be
  mapped while retaining dropbehind.

  A fault-around PTE does not necessarily mean that every mapped folio was
  accessed, since neighboring folios are mapped speculatively.  So I do not
  think folio_mapped() alone is sufficient to cancel dropbehind.  Clearing it
  for the folio covering vmf->address may be more precise, but that would be a
  separate semantic change.

  If this distinction makes sense, I can send an RFC to clear dropbehind for
  the faulting folio in filemap_map_pages().

On Fri, Aug 21, 2026 at 11:30 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote:
>
> On Fri, Aug 21, 2026 at 09:23:12AM +0800, Wenjie Qi wrote:
> > This is based on code examination; I have not reproduced it in
> >   folio_end_dropbehind().
> >   There is an analogous EROFS report where bio completion ran under an RCU
> >   read-side critical section and hit a sleeping-function warning even though
> >   in_atomic() and preempt_count were both zero:
> >
> >   https://lore.kernel.org/r/20230621220848.3379029-1-dhavale@xxxxxxxxxx
> >
> >   That is not a reproducer for this path, but it shows why task context alone
> >   does not establish that sleeping is safe. Here, folio_unmap_invalidate() can
> >   reach unmap_mapping_folio(), which takes mapping->i_mmap_rwsem through
> >   i_mmap_lock_read(). I noticed the mismatch while comparing this path with
> >   the stricter bio_in_atomic() check used by the block dropbehind work.
>
> So your analysis is right as far as it goes.  But if a folio has
> been marked as dropbehind, but was then mmaped, we clearly shouldn't
> be discarding it!  I believe that we'll clear the dropbehind flag in
> __filemap_get_folio_mpol(), called from filemap_get_folio() called from
> filemap_fault().
>
> If you can find a way to get a folio with both dropbehind & mapped set,
> I'm interested in hearing how.
>
> > On Thu, Aug 20, 2026 at 10:34 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote:
> > >
> > > On Thu, Aug 20, 2026 at 10:29:56PM +0800, Wenjie Qi wrote:
> > > > folio_end_dropbehind() uses in_task() to keep folio invalidation out of
> > > > interrupt context. Task context alone is not sufficient: preemption can
> > > > still be disabled, or the task can be in a preemptible RCU read-side
> > > > critical section, while filemap_end_dropbehind() may reach
> > > > folio_unmap_invalidate() and sleep.
> > > >
> > > > Use the established conservative three-part atomic-context test: reject
> > > > preemptible RCU read-side sections, reject configurations without
> > > > PREEMPT_COUNT, and otherwise require a preemptible context. Unsafe
> > > > completions retain the existing best-effort behavior and skip invalidation.
> > >
> > > Have you seen this happen in practice, or is this based on code
> > > examination?