linux-kernel - Re: [syzbot] [mm?] [fs?] BUG: sleeping function called from invalid context in folio_mc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2ccb9f828ea392eb22f8deb7d9644a4575fa9ee5.camel@surriel.com>
Date: Sat, 29 Mar 2025 22:05:34 -0400
From: Rik van Riel <riel@...riel.com>
To: Luis Chamberlain <mcgrof@...nel.org>, syzbot	
 <syzbot+f3c6fda1297c748a7076@...kaller.appspotmail.com>, Jan Kara
 <jack@...e.cz>,  Dave Chinner <david@...morbit.com>
Cc: brauner@...nel.org, hare@...e.de, joel.granados@...nel.org, 
	john.g.garry@...cle.com, kees@...nel.org, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-mm@...ck.org, 
	syzkaller-bugs@...glegroups.com, willy@...radead.org
Subject: Re: [syzbot] [mm?] [fs?] BUG: sleeping function called from invalid
 context in folio_mc_copy

On Thu, 2025-03-27 at 14:42 -0700, Luis Chamberlain wrote:
> On Thu, Mar 27, 2025 at 09:26:41AM -0700, syzbot wrote:
> > Hello,
> 
> Thanks, this is a known issue and we're having a hard time
> reproducing [0].
> 
> > C reproducer:  
> > https://syzkaller.appspot.com/x/repro.c?x=152d4de4580000
> 
> Thanks! Sadly this has not yet been able to let me reprodouce the
> issue,
> and so we're trying to come up with other ways to test the imminent
> spin
> lock + sleep on buffer_migrate_folio_norefs() path different ways
> now,
> including a new fstests [1] but no luck yet.

The backtrace in the report seems to make the cause
of the bug fairly clear, though.

The function folio_mc_copy() can sleep.

The function __buffer_migrate_folio() calls
filemap_migrate_folio() with a spinlock held.

That function eventually calls folio_mc_copy():

 __might_resched+0x5d4/0x780 kernel/sched/core.c:8764
 folio_mc_copy+0x13c/0x1d0 mm/util.c:742
 __migrate_folio mm/migrate.c:758 [inline]
 filemap_migrate_folio+0xb4/0x4c0 mm/migrate.c:943
 __buffer_migrate_folio+0x3ec/0x5d0 mm/migrate.c:874
 move_to_new_folio+0x2ac/0xc20 mm/migrate.c:1050
 migrate_folio_move mm/migrate.c:1358 [inline]
 migrate_folios_move mm/migrate.c:1710 [inline]

The big question is how to safely release the
spinlock in __buffer_migrate_folio() before calling
filemap_migrate_folio()

-- 
All Rights Reversed.