From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from kylie.crudebyte.com (kylie.crudebyte.com [5.189.157.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 64F26328B43; Fri, 5 Dec 2025 11:15:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=5.189.157.229 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764933339; cv=none; b=mHJFZC1Oor91U28uySKI+ZDVeKxYBfD6+kP3uLqgWZkTNkuANRwVwG4aIQ4wRlZv36XLoUejJI8qi/vd7w/e6F53duxISz6W/suL5RvBrgCMTHmLkjH8S7ohjXCd4bKm/b+x0m200WdoExEvoZbOV91pBijhcFbKXEY94m2ZGPU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764933339; c=relaxed/simple; bh=SGtzcykmhdRF+aLLNy8E4GVaOh7BWxiotZCqcgpgJNw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ZEjRLnZw0B925EwnXc2mKbEE8Lmb5S+6DCv3hVJfpBaog5f2DnY/CsAIdZQhgJZPPtiy+TSYXmZH7hd+bQEC9kRouSWxGgu3r7ZA3q33mEKovsFGEWRjuzlkWzg6HAhIfhmb2gYlGnaQ4CZXNVvtjPeYuwBtiH53zp+IdaKafJs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=crudebyte.com; spf=pass smtp.mailfrom=crudebyte.com; dkim=pass (4096-bit key) header.d=crudebyte.com header.i=@crudebyte.com header.b=mkJNAfH0; arc=none smtp.client-ip=5.189.157.229 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=crudebyte.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=crudebyte.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (4096-bit key) header.d=crudebyte.com header.i=@crudebyte.com header.b="mkJNAfH0" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=crudebyte.com; s=kylie; h=Content-Type:Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: Content-ID:Content-Description; bh=+HuSsIe/gXmLHPaD4fB3tfD9sauoFI3cxqGeG6W0P/E=; b=mkJNAfH02HAvC+vMm58JJElXxP krZXekIi7DXVm0Niek5jCcIUm7cTDwMq59xhYpX5f6KYOjHfSqdYvj1LtcTKgpsqOGbGIg+tv8mr9 jzFSFOsN2qvIavBjzJ4Pq3X8/+7e/nk8pg6KkYRzUSDtcaN3gQuv5h6jL3lIpwEXGbACzKkXbtVoA WkYluRT+36GpFb12cGgs7fNkIUyJIToZnch8uOaHkp/rlDIVDdQSj+4bZ47vOdA+RzG8sBUrIm1u7 wy9O+yVbJ8vhxiXu4NP7wiCFAO039YQGaTF/tgEBPr7XklXMx8A6D8M9H/cXzfQAlTLzDj25f8Y/+ 2nV7Cyoz+VcYFzflgBmAGwAJURlF+1DvUBg+DhmdoK8RwM2fEehKlKulwwToM0mPscZ386rRwXwsU OKa+RUeuvIIwdZKDefv5a1ofy4KXb6YwbWfB4exlxsnBaZoxZvh9KLUyRfs0mJ5W7Hcw7o5UPhzLo 3zN4I8pFTWERIn7cr94aDLgTRw7T0uZvhgefUXJ3ZyWuzFE0v1RCDt/cICNdneFq+TqGrqGtJMI/d +FF9sjxplnVMhpxD5i8UsB3WzROLsmx/gVKDUsOLTrWhDta+Fs8AMfqdO1pOl8ZsuIzr+JcHKnqoR OvO7800XtvZUph2s4OZjzKNmEeCLv0AHsrtaE95i0=; From: Christian Schoenebeck To: Dominique Martinet , Matthew Wilcox Cc: Chris Arges , David Howells , ericvh@kernel.org, lucho@ionkov.net, v9fs@lists.linux.dev, linux-kernel@vger.kernel.org, kernel-team@cloudflare.com Subject: Re: kernel BUG when mounting large block xfs backed by 9p (folio ref count bug) Date: Fri, 05 Dec 2025 11:47:10 +0100 Message-ID: <5945634.DvuYhMxLoT@weasel> In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" On Tuesday, 25 November 2025 00:55:59 CET Matthew Wilcox wrote: > On Tue, Nov 25, 2025 at 08:12:17AM +0900, Dominique Martinet wrote: > > > When the loop-back mount occurs the system crashes immediately with > > > the following: > > > [ 31.276957][ T255] loop0: detected capacity change from 0 to 614400 > > > [ 31.286377][ T255] XFS (loop0): EXPERIMENTAL large block size > > > feature enabled. Use at your own risk! [ 31.286624][ T255] XFS > > > (loop0): Mounting V5 Filesystem fa3c2d3c-b936-4ee3-a5a8-e80ba36298cc [ > > > 31.395721][ T62] page: refcount:0 mapcount:0 > > > mapping:0000000000000000 index:0x0 pfn:0x102600 [ 31.395833][ T62] > > > head: order:9 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 > > > [ 31.395915][ T62] flags: > > > 0x2ffff800000040(head|node=0|zone=2|lastcpupid=0x1ffff) [ 31.395976][ > > > T62] page_type: f8(unknown) > > PGTY_large_kmalloc = 0xf8, > > So somebody called kmalloc(2 * 1024 * 1024). Not sure if that's helpful > in tracking this down? > > > > [ 31.396004][ T62] raw: 002ffff800000040 0000000000000000 > > > dead000000000122 0000000000000000 [ 31.396092][ T62] raw: > > > 0000000000000000 0000000000000000 00000000f8000000 0000000000000000 [ > > > 31.396174][ T62] head: 002ffff800000040 0000000000000000 > > > dead000000000122 0000000000000000 [ 31.396251][ T62] head: > > > 0000000000000000 0000000000000000 00000000f8000000 0000000000000000 [ > > > 31.396339][ T62] head: 002ffff800000009 ffffea0004098001 > > > 00000000ffffffff 00000000ffffffff [ 31.396425][ T62] head: > > > ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000200 [ > > > 31.396523][ T62] page dumped because: VM_BUG_ON_FOLIO(((unsigned int) > > > folio_ref_count(folio) + 127u <= 127u)) [ 31.396641][ T62] > > > ------------[ cut here ]------------ > > > [ 31.396689][ T62] kernel BUG at include/linux/mm.h:1386! > > > [ 31.396748][ T62] Oops: invalid opcode: 0000 [#1] SMP NOPTI > > > [ 31.396820][ T62] CPU: 4 UID: 0 PID: 62 Comm: kworker/u32:1 Not > > > tainted 6.18.0-rc7-cloudflare-2025.11.11-21-gab0ed6ff #1 > > > PREEMPT(voluntary) [ 31.396947][ T62] Hardware name: QEMU Standard > > > PC (i440FX + PIIX, 1996), BIOS 2025.02-8 05/13/2025 > > > > > > [ 31.397031][ T62] Workqueue: loop0 > > > loop_rootcg_workfn [ 31.397084][ T62] RIP: > > > 0010:__iov_iter_get_pages_alloc+0x7b6/0x920 [ 31.397152][ T62] > > > Code: 08 4c 89 5d 10 44 88 55 20 e9 0d fb ff ff 0f 0b 4d 85 ed 0f 85 fc > > > fb ff ff e9 38 fd ff ff 48 c7 c6 20 88 6d 83 e8 fa 2f b7 ff <0f> 0b 31 > > > f6 b9 c0 0c 00 00 ba 01 00 00 00 4c 89 0c 24 48 8d 3 c dd > > > [ 31.397310][ T62] RSP: 0018:ffffc90000257908 EFLAGS: 00010246 > > > [ 31.397365][ T62] RAX: 000000000000005c RBX: 0000000000000020 RCX: > > > 0000000000000003 [ 31.397424][ T62] RDX: 0000000000000000 RSI: > > > 0000000000000003 RDI: ffffffff83f38508 [ 31.397498][ T62] RBP: > > > ffff888101af90f8 R08: 0000000000000000 R09: ffffc900002577a0 [ > > > 31.397571][ T62] R10: ffffffff83f084c8 R11: 0000000000000003 R12: > > > 0000000000020000 [ 31.397654][ T62] R13: ffffc90000257a70 R14: > > > ffffc90000257a68 R15: ffffea0004098000 [ 31.397727][ T62] FS: > > > 0000000000000000(0000) GS:ffff8882b3266000(0000) knlGS:0000000000000000 > > > [ 31.397819][ T62] CS: 0010 DS: 0000 ES: 0000 CR0: > > > 0000000080050033 [ 31.397890][ T62] CR2: 00007f846eb985a0 CR3: > > > 0000000004620003 CR4: 0000000000772ef0 [ 31.397964][ T62] PKRU: > > > 55555554 > > > [ 31.398005][ T62] Call Trace: > > > [ 31.398045][ T62] > > > [ 31.398075][ T62] ? kvm_sched_clock_read+0x11/0x20 > > > [ 31.398131][ T62] ? sched_clock+0x10/0x30 > > > [ 31.398179][ T62] ? sched_clock_cpu+0xf/0x1d0 > > > [ 31.398234][ T62] iov_iter_get_pages_alloc2+0x20/0x50 > > > [ 31.398277][ T62] > > > p9_get_mapped_pages.part.0.constprop.0+0x6f/0x280 [9pnet_virtio] > Oh, hang on. You're passing a kmalloc'ed page to > iov_iter_get_pages_alloc(). That's not allowed ... > > see > https://lore.kernel.org/all/20250310142750.1209192-1-willy@infradead.org/ I'm confused. Looking at p9_get_mapped_pages(), iov_iter_get_pages_alloc2() is only called for user space iovec data, isn't it? > > > [ 31.398354][ T62] ? p9pdu_vwritef+0xe0/0x6e0 [9pnet] > > > [ 31.398413][ T62] ? pdu_write+0x2d/0x40 [9pnet] > > > [ 31.398464][ T62] p9_virtio_zc_request+0x92/0x69a [9pnet_virtio] > > > [ 31.398530][ T62] ? p9pdu_vwritef+0xe0/0x6e0 [9pnet] > > > [ 31.398582][ T62] ? p9pdu_finalize+0x32/0x90 [9pnet] > > > [ 31.398620][ T62] ? p9_client_prepare_req+0xbe/0x150 [9pnet] > > > [ 31.398693][ T62] p9_client_zc_rpc.constprop.0+0xf4/0x2f0 [9pnet] > > > [ 31.398768][ T62] ? p9_client_xattrwalk+0x148/0x1d0 [9pnet] > > > [ 31.398840][ T62] p9_client_write+0x16a/0x240 [9pnet]