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

[Wenjie Qi]

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.

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?