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

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

[Wenjie Qi]

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.

Signed-off-by: Wenjie Qi <qiwenjie@xiaomi.com>
---
 mm/filemap.c | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/mm/filemap.c b/mm/filemap.c
index 6afec6368..0616057e6 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -45,6 +45,7 @@
 #include <linux/migrate.h>
 #include <linux/pipe_fs_i.h>
 #include <linux/splice.h>
+#include <linux/rcupdate.h>
 #include <linux/rcupdate_wait.h>
 #include <linux/sched/mm.h>
 #include <linux/sysctl.h>
@@ -1620,6 +1621,15 @@ static void filemap_end_dropbehind(struct folio *folio)
 		folio_unmap_invalidate(mapping, folio, 0);
 }
 
+static bool folio_dropbehind_in_atomic(void)
+{
+	if (IS_ENABLED(CONFIG_PREEMPTION) && rcu_preempt_depth())
+		return true;
+	if (!IS_ENABLED(CONFIG_PREEMPT_COUNT))
+		return true;
+	return !preemptible();
+}
+
 /*
  * If folio was marked as dropbehind, then pages should be dropped when writeback
  * completes. Do that now. If we fail, it's likely because of a big folio -
@@ -1631,13 +1641,12 @@ void folio_end_dropbehind(struct folio *folio)
 		return;
 
 	/*
-	 * Hitting !in_task() should not happen off RWF_DONTCACHE writeback,
-	 * but can happen if normal writeback just happens to find dirty folios
-	 * that were created as part of uncached writeback, and that writeback
-	 * would otherwise not need non-IRQ handling. Just skip the
+	 * Hitting an atomic context should not happen from RWF_DONTCACHE
+	 * writeback, but can happen if normal writeback just happens to find
+	 * dirty folios created as part of uncached writeback. Just skip the
 	 * invalidation in that case.
 	 */
-	if (in_task() && folio_trylock(folio)) {
+	if (!folio_dropbehind_in_atomic() && folio_trylock(folio)) {
 		filemap_end_dropbehind(folio);
 		folio_unlock(folio);
 	}
-- 
2.43.0

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

[Matthew Wilcox]

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?

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@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.

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?

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

[Matthew Wilcox]

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?