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

[Matthew Wilcox <willy@infradead.org>]

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@google.com
> 
>   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@infradead.org> 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?