mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: syzbot <syzbot+b0a0670332b6b3230a0a@syzkaller.appspotmail.com>,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] [ext4?] WARNING in __folio_mark_dirty (3)
Date: Fri, 21 Nov 2025 11:14:33 -0800	[thread overview]
Message-ID: <20251121111433.91bea9e742dd2a2e0a3ecfff@linux-foundation.org> (raw)
In-Reply-To: <aSC3OsxouD7lFKEy@casper.infradead.org>

On Fri, 21 Nov 2025 19:02:18 +0000 Matthew Wilcox <willy@infradead.org> wrote:

> > I'm guessing that ext4 permitted a non-uptodate folio to find its way
> > into the blockdev mapping then the pagefault code tried to modify it
> > and got upset.
> 
> I think you're right, but the reason it's upset is that it found a
> !uptodate folio that was mapped into userspace, and that's not supposed
> to happen!  Presumably it was uptodate at the point it was initially
> faulted in, then (perhaps when the error happened?) somebody cleared the
> uptodate flag without unmapping the folio.
> 
> Hm.  I wonder if we should do this to catch the offender:
> 
> @@ -831,7 +833,17 @@ static __always_inline void SetPageUptodate(struct page *pa
> ge)
>         folio_mark_uptodate((struct folio *)page);
>  }
> 
> -CLEARPAGEFLAG(Uptodate, uptodate, PF_NO_TAIL)
> +static __always_inline void folio_clear_uptodate(struct folio *folio)
> +{
> +       VM_BUG_ON_FOLIO(folio_mapped(folio), folio);
> +       clear_bit(PG_uptodate, folio_flags(folio, 0));
> +}
> +
> +static __always_inline void ClearPageUptodate(struct page *page)
> +{
> +       VM_BUG_ON_PGFLAGS(PageTail(page), page);
> +       folio_clear_uptodate((struct folio *)page);
> +}
> 
>  void __folio_start_writeback(struct folio *folio, bool keep_write);
>  void set_page_writeback(struct page *page);

We have a reproducer, fortunately.

> ... it doesn't actually compile because folio_mapcount() is in mm.h
> so the declaration is out of order, but I can invest smoe effort into
> making that work if you think it's worth doing.

It's a shame to add more debug stuff into oft-called inline functions.

Maybe some hacky thing which uninlines these functions and adds the
debug?  I can slip that into -next until we fix the bug then throw the
debug patch away.

Of course, there may be other filesystems which are tripped up by this.
Once we fully understand the failure we can decide whether it's worth
adding the extra debug to mainline?

  reply	other threads:[~2025-11-21 19:14 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-20 16:41 syzbot
2025-11-21  1:34 ` Forwarded: [PATCH] ext4: check folio uptodate state in ext4_page_mkwrite() syzbot
2025-11-21 10:44 ` syzbot
2025-11-21 11:52 ` syzbot
2025-11-21 12:41 ` syzbot
2025-11-21 18:11 ` [syzbot] [ext4?] WARNING in __folio_mark_dirty (3) Andrew Morton
2025-11-21 19:02   ` Matthew Wilcox
2025-11-21 19:14     ` Andrew Morton [this message]
2025-12-02 13:25 ` Theodore Tso
2025-12-02 13:47   ` syzbot
2025-12-05  4:54 ` Forwarded: [PATCH v3] ext4: unmap invalidated folios from page tables in mpage_release_unused_pages() syzbot
     [not found] <20251121013443.84021-1-kartikey406@gmail.com>
2025-11-21  8:51 ` [syzbot] [ext4?] WARNING in __folio_mark_dirty (3) syzbot
     [not found] <20251121104426.329600-1-kartikey406@gmail.com>
2025-11-21 11:32 ` syzbot
     [not found] <20251121115221.330869-1-kartikey406@gmail.com>
2025-11-21 12:34 ` syzbot
     [not found] <20251121124101.332104-1-kartikey406@gmail.com>
2025-11-21 13:11 ` syzbot
     [not found] <20251205045415.1392139-1-kartikey406@gmail.com>
2025-12-05  5:33 ` syzbot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251121111433.91bea9e742dd2a2e0a3ecfff@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=syzbot+b0a0670332b6b3230a0a@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®