[LTP] [linux-next:master] [block/bdev] 3c20917120: BUG:sleeping_function_called_from_invalid_context_at_mm/util.c

[Luis Chamberlain]

On Thu, Mar 27, 2025 at 06:44:56PM -0700, Luis Chamberlain wrote:
> On Tue, Mar 25, 2025 at 02:52:49PM +0800, Oliver Sang wrote:
> > hi, Luis,
> > 
> > On Sun, Mar 23, 2025 at 12:07:27AM -0700, Luis Chamberlain wrote:
> > > On Sat, Mar 22, 2025 at 06:02:13PM -0700, Luis Chamberlain wrote:
> > > > On Sat, Mar 22, 2025 at 07:14:40PM -0400, Johannes Weiner wrote:
> > > > > Hey Luis,
> > > > > 
> > > > > This looks like the same issue the bot reported here:
> > > > > 
> > > > > https://lore.kernel.org/all/20250321135524.GA1888695@cmpxchg.org/
> > > > > 
> > > > > There is a fix for it queued in next-20250318 and later. Could you
> > > > > please double check with your reproducer against a more recent next?
> > > > 
> > > > Confirmed, at least it's been 30 minutes and no crashes now where as
> > > > before it would crash in 1 minute. I'll let it soak for 2.5 hours in
> > > > the hopes I can trigger the warning originally reported by this thread.
> > > > 
> > > > Even though from code inspection I see how the kernel warning would
> > > > trigger I just want to force trigger it on a test, and I can't yet.
> > > 
> > > Survied 5 hours now. This certainly fixed that crash.
> > > 
> > > As for the kernel warning, I can't yet reproduce that, so trying to
> > > run generic/750 forever and looping
> > > ./testcases/kernel/syscalls/close_range/close_range01
> > > and yet nothing.
> > > 
> > > Oliver can you reproduce the kernel warning on next-20250321 ?
> > 
> > the issue still exists on
> > 9388ec571cb1ad (tag: next-20250321, linux-next/master) Add linux-next specific files for 20250321
> > 
> > but randomly (reproduced 7 times in 12 runs, then ltp.close_range01 also failed.
>a> on another 5 times, the issue cannot be reproduced then ltp.close_range01 pass)
> 
> OK I narrowed down a reproducer to requiring the patch below 
> 
> 
> diff --git a/mm/util.c b/mm/util.c
> index 448117da071f..3585bdb8700a 100644
> --- a/mm/util.c
> +++ b/mm/util.c
> @@ -735,6 +735,8 @@ int folio_mc_copy(struct folio *dst, struct folio *src)
>  	long nr = folio_nr_pages(src);
>  	long i = 0;
>  
> +	might_sleep();
> +
>  	for (;;) {
>  		if (copy_mc_highpage(folio_page(dst, i), folio_page(src, i)))
>  			return -EHWPOISON;
> 
> 
> And  then just running:
> 
> dd if=/dev/zero of=/dev/vde bs=1024M count=1024
> 
> For some reason a kernel with the following didn't trigger it so the
> above patch is needed
> 
> 
> CONFIG_PROVE_LOCKING=y
> CONFIG_DEBUG_SPINLOCK=y
> CONFIG_ACPI_SLEEP=y
> 
> It may have to do with my preemtpion settings:
> 
> CONFIG_PREEMPT_BUILD=y
> CONFIG_ARCH_HAS_PREEMPT_LAZY=y
> # CONFIG_PREEMPT_NONE is not set
> CONFIG_PREEMPT_VOLUNTARY=y
> # CONFIG_PREEMPT is not set
> # CONFIG_PREEMPT_LAZY is not set
> CONFIG_PREEMPT_COUNT=y
> CONFIG_PREEMPTION=y
> CONFIG_PREEMPT_DYNAMIC=y
> CONFIG_PREEMPT_RCU=y
> 
> And so now to see how we should fix it.

Would the extra ref check added via commit 060913999d7a9e50 ("mm:
migrate: support poisoned recover from migrate folio") make the removal
of the spin lock safe now given all the buffers are locked from the
folio? This survives some basic sanity checks on my end with
generic/750 against ext4 and also filling a drive at the same time with
fio. I have a feeling is we are not sure, do we have a reproducer for
the issue reported through ebdf4de5642fb6 ("mm: migrate: fix reference
check race between __find_get_block() and migration")? I suspect the
answer is now. The only other thing I can think of at this tie is to add
the lru_cache_disabled() || cpu_is_isolated(smp_processor_id())) checks
on __find_get_block_slow() as we do in bh_lru_install() but I am not
sure if that suffices for the old races.

Thoughts?

diff --git a/mm/migrate.c b/mm/migrate.c
index 97f0edf0c032..6a5d125ecde9 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -859,12 +859,12 @@ static int __buffer_migrate_folio(struct address_space *mapping,
 			}
 			bh = bh->b_this_page;
 		} while (bh != head);
+		spin_unlock(&mapping->i_private_lock);
 		if (busy) {
 			if (invalidated) {
 				rc = -EAGAIN;
 				goto unlock_buffers;
 			}
-			spin_unlock(&mapping->i_private_lock);
 			invalidate_bh_lrus();
 			invalidated = true;
 			goto recheck_buffers;
@@ -882,8 +882,6 @@ static int __buffer_migrate_folio(struct address_space *mapping,
 	} while (bh != head);
 
 unlock_buffers:
-	if (check_refs)
-		spin_unlock(&mapping->i_private_lock);
 	bh = head;
 	do {
 		unlock_buffer(bh);
diff --git a/mm/util.c b/mm/util.c
index 448117da071f..3585bdb8700a 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -735,6 +735,8 @@ int folio_mc_copy(struct folio *dst, struct folio *src)
 	long nr = folio_nr_pages(src);
 	long i = 0;
 
+	might_sleep();
+
 	for (;;) {
 		if (copy_mc_highpage(folio_page(dst, i), folio_page(src, i)))
 			return -EHWPOISON;