linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Jan Kara <jack@suse.cz>
Cc: Liebes Wang <wanghaichi0403@gmail.com>,
	ojaswin@linux.ibm.com, Theodore Ts'o <tytso@mit.edu>,
	yi.zhang@huawei.com, linux-fsdevel@vger.kernel.org,
	syzkaller@googlegroups.com
Subject: Re: kernel BUG in zero_user_segments
Date: Mon, 28 Apr 2025 13:55:02 +0100	[thread overview]
Message-ID: <aA96phKBQvJFby_S@casper.infradead.org> (raw)
In-Reply-To: <uxweupjmz7pzbj77cciiuxduxnbuk33mx75bimynzcjmq664zo@xqrdf6ouf5v6>

On Mon, Apr 28, 2025 at 10:14:10AM +0200, Jan Kara wrote:
> So there's something suspicious about this report. The stacktrace shows
> we've crashed in punch hole code (call from ioctl_preallocate()) but the
> reproducer actually never calls this. Anyway, the reported stack trace ends
> with truncate_inode_partial_folio() -> folio_zero_range() ->
> zero_user_segments(). The assertion that's failing is:
> 
> BUG_ON(end1 > page_size(page) || end2 > page_size(page));
> 
> Now it seems that this assertion can indeed easily trigger when we have
> a large folio because truncate_inode_partial_folio() is called to zero out
> tail of the whole folio which can certainly be more than a page. Matthew,
> am I missing something (I guess I am because otherwise I'd expect we'd be
> crashing left and right) or is the folio conversion on this path indeed
> broken?

page_size(page) is not PAGE_SIZE (necessarily).  It's from the bad
old days (ie 2019) when we didn't have folios yet.  We haven't yet
got round to removing zero_user_segments() and related functions, so
folio_zero_range() is still implemented in terms of it.

Anyway, ext4 doesn't have large folio support, so all this is really
telling you is that the truncation path called folio_zero_range() with
bad arguments.

But I'm not sure I see how.  truncate_inode_pages_range() takes (mapping,
start, end) and looks up the folios and calculates everything there.
You'd think if there were a bug in the calculations we'd see it by now,
and in any case it wouldn't be bisectable to an ext4 commit.

It does look like there's a deliberately-corrupt ext4 image involved
here, but I'm not sure how that could upset the page cache like this.

> 								Honza
> 
> > 
> > The test case, kernel config and full bisection log are attached.
> > 
> > The report is (The full report is attached):
> > EXT4-fs (loop7): mounted filesystem 00000000-0000-0000-0000-000000000000
> > r/w without journal. Quota mode: writeback.
> > EXT4-fs warning (device loop7): ext4_block_to_path:105: block 2147483648 >
> > max in inode 15
> > ------------[ cut here ]------------
> > kernel BUG at ./include/linux/highmem.h:275!
> > Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
> > CPU: 0 UID: 0 PID: 6795 Comm: syz.7.479 Not tainted
> > 6.15.0-rc3-g9d7a0577c9db #1 PREEMPT(voluntary)
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> > 1.13.0-1ubuntu1.1 04/01/2014
> > RIP: 0010:zero_user_segments.constprop.0+0x10c/0x290
> > include/linux/highmem.h:275
> > Code: 0f b6 4b 40 ba 00 10 00 00 48 d3 e2 49 89 d7 e8 ba d5 e2 ff 4c 89 fe
> > 4c 89 ef e8 3f d0 e2 ff 4d 39 fd 76 08 e8 a5 d5 e2 ff 90 <0f> 0b e8 9d d5
> > e2 ff be 08 00 00 00 48 89 df e8 a0 9c 1d 00 48 89
> > RSP: 0018:ffff8881235ff678 EFLAGS: 00010216
> > RAX: 000000000000025d RBX: ffffea00056071c0 RCX: ffffc90002e0b000
> > RDX: 0000000000080000 RSI: ffffffff818f7b0b RDI: 0000000000000006
> > RBP: 000000000040b000 R08: 0000000000000000 R09: fffff94000ac0e38
> > R10: 0000000000001000 R11: 0000000000000000 R12: 0000000000000005
> > R13: 000000000040b000 R14: 0000000000000000 R15: 0000000000001000
> > FS:  00007fecef19d700(0000) GS:ffff888543948000(0000) knlGS:0000000000000000
> > CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 00007f5e38b40008 CR3: 000000013ebaa001 CR4: 0000000000770ef0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
> > PKRU: 80000000
> > Call Trace:
> >  <TASK>
> >  folio_zero_range include/linux/highmem.h:647 [inline]
> >  truncate_inode_partial_folio+0x6da/0xbd0 mm/truncate.c:219
> >  truncate_inode_pages_range+0x3fc/0xcc0 mm/truncate.c:387
> >  ext4_truncate_page_cache_block_range+0xb3/0x5c0 fs/ext4/inode.c:3974
> >  ext4_punch_hole+0x2cd/0xec0 fs/ext4/inode.c:4049
> >  ext4_fallocate+0x128d/0x32c0 fs/ext4/extents.c:4766
> >  vfs_fallocate+0x3ed/0xd70 fs/open.c:338
> >  ioctl_preallocate+0x190/0x200 fs/ioctl.c:290
> >  file_ioctl fs/ioctl.c:333 [inline]
> >  do_vfs_ioctl+0x149c/0x1850 fs/ioctl.c:885
> >  __do_sys_ioctl fs/ioctl.c:904 [inline]
> >  __se_sys_ioctl fs/ioctl.c:892 [inline]
> >  __x64_sys_ioctl+0x11f/0x200 fs/ioctl.c:892
> >  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> >  do_syscall_64+0xc1/0x1d0 arch/x86/entry/syscall_64.c:94
> >  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> 
> > syz_mount_image$ext4(&(0x7f0000000400)='ext4\x00', &(0x7f00000001c0)='./file0\x00', 0x0, &(0x7f0000000280)={[{@journal_ioprio}, {@mb_optimize_scan}, {@data_err_ignore}, {@grpquota}, {@barrier}]}, 0x1, 0x3cb, &(0x7f00000026c0)="$eJzs3M9rHFUcAPDvTH61aXUjeBC9LAgaELPZpFoFRQUFD55sLx48LLtpLW4aabZgSw4VPHnVf0AE79V/QBDFmzdvgmBFKRRJe/K0Mrsz6ZrsxsTduEn6+cBj35uZzXvfndnhO5OdF8ADqxwRr0bEREQsRUQpX57mJW50S7bdvc2NelaSaLfP/ZlEEhF3Nzfqxd9K8tdTeWM+jUg/jnjixs5+169df7/WbK5cyduV1uoHlfVr15+9tFq7uHJx5XL1hRefX1o+Wz1zdmSx3vz53PKv377+w1e/PfXTj+2Xv8jGezpf1xvHqJSjvPWZbPfcqDsbs+lxDwAAgD1J89x/spP/l2KiU+sqRWVjrIMDAAAARqL9Sv4KAAAAHGOJa38AAAA45orfAdzd3KgXZYw/R/jf3XktIua68RfPN3fXTMaJfJupA3y+tRwRJ95uvJOVOKDnkAEAen2T5T+L/fK/NB7r2W4my1Mi4uSI+y9va+/Mf9LbI+7yH7L876WeuW3u9cSfm5vIWw91UsWp5MKl5spiRDwcEfMxNZO1q7v0cWvmk5lB63rzv6xk/Re5YD6O25Pb3t2otWrDxNzrzkcRj0/2iz/Zyn+TiJgdoo8v/7p5ddC6f4//YLU/j3i67/6/P3NPsvv8RJXO8VApjoqdbq3+8u6g/scdf7b/Z3ePfy7pna9pff99/L54frVT6XPy+K/H/3RyvlMvrss+rLVaV6oR08lbO5cv3X9v0S62z+Kff7L/9784/yX5nFan83PAfn339XufDlp3GPZ/Y1/7f/+VN978fojvf7b/z3Rq8/mSvZz/9jrAYT47AAAAOCrSzn2NJF3YqqfpwkL3fsejMZs219Zbz1xYu3q50b3/MRdTaXGnq9RzP7Ta/Tf6VntpW3s5Ih6JiM9KJzvthfpaszHu4AEAAOABcWrA9X/mj9K4RwcAAACMzNy4BwAAAAAcONf/AAAAcKwNM6+fymGv1ONQDEPlCFbGfWYCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA42v4OAAD///tZxK0=")
> > quotactl_fd$Q_SETINFO(0xffffffffffffffff, 0x2, 0x0, &(0x7f0000000080)={0x80000000000002, 0x80000000005, 0x1, 0x6})
> > r0 = openat(0xffffffffffffff9c, &(0x7f0000000040)='./file1\x00', 0x42, 0x1ff)
> > ioctl$EXT4_IOC_CHECKPOINT(r0, 0x40305829, &(0x7f0000000080)=0x5)
> > r1 = openat(0xffffffffffffff9c, &(0x7f0000000040)='./file1\x00', 0x42, 0x1ff)
> > ioctl$EXT4_IOC_CHECKPOINT(r1, 0x40305829, &(0x7f0000000080)=0x5)
> 
> 
> 
> 
> 
> -- 
> Jan Kara <jack@suse.com>
> SUSE Labs, CR

  reply	other threads:[~2025-04-28 12:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CADCV8spm=TtW_Lu6p-5q-jdHv1ryLcx45mNBEcYdELbHv_4TnQ@mail.gmail.com>
2025-04-28  8:14 ` kernel BUG in zero_user_segments Jan Kara
2025-04-28 12:55   ` Matthew Wilcox [this message]
2025-04-29  7:55   ` Zhang Yi
     [not found]     ` <CADCV8spSjWbnr_cUTzcB=zn0M92s_AhRx-byz0A8zZZa4cZ=Lg@mail.gmail.com>
2025-04-30  1:16       ` Zhang Yi
2025-04-30  3:14     ` Matthew Wilcox
2025-05-01 11:19       ` Jan Kara
2025-05-06  2:25         ` Zhang Yi
2025-05-06 11:33           ` Jan Kara
2025-05-06 12:12             ` Zhang Yi

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=aA96phKBQvJFby_S@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=ojaswin@linux.ibm.com \
    --cc=syzkaller@googlegroups.com \
    --cc=tytso@mit.edu \
    --cc=wanghaichi0403@gmail.com \
    --cc=yi.zhang@huawei.com \
    /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;
as well as URLs for NNTP newsgroup(s).