From: Dominique Martinet <asmadeus@codewreck.org>
To: Christian Schoenebeck <linux_oss@crudebyte.com>
Cc: Matthew Wilcox <willy@infradead.org>,
Chris Arges <carges@cloudflare.com>,
David Howells <dhowells@redhat.com>,
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, 5 Dec 2025 22:03:12 +0900 [thread overview]
Message-ID: <aTLYEF4ZaTwF3tdL@codewreck.org> (raw)
In-Reply-To: <5945634.DvuYhMxLoT@weasel>
Christian Schoenebeck wrote on Fri, Dec 05, 2025 at 11:47:10AM +0100:
> > 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?
I think that doesn't hold true when mounting a filesystem with -o
loop -- afaiu the kernel issues IOs to 9p from the XFS subsystem, so
these can come from kmalloc or whatever it is they get memory with.
As to what to do with this, given Willy's last reply (thanks!), I'm
honestly still not sure... If we can detect the pages are coming from
somewhere we don't like I guess we can return EIO instead as a stop-gap
measure (better than a crash)?
If we check early enough (in client.c generic code) perhaps we could
route these to the non-zc path that doesn't require this, so let's start
by trying to figure out how to check what kind of page we got...?
--
Dominique Martinet | Asmadeus
next prev parent reply other threads:[~2025-12-05 13:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-24 15:47 kernel BUG when mounting filesystem on 9p Chris Arges
2025-11-24 23:12 ` kernel BUG when mounting large block xfs backed by 9p (folio ref count bug) Dominique Martinet
2025-11-24 23:55 ` Matthew Wilcox
2025-11-25 9:03 ` Dominique Martinet
2025-12-05 4:53 ` Matthew Wilcox
2025-12-05 10:47 ` Christian Schoenebeck
2025-12-05 13:03 ` Dominique Martinet [this message]
2025-12-05 13:36 ` Christian Schoenebeck
2025-12-05 13:48 ` Dominique Martinet
2025-12-07 7:18 ` Matthew Wilcox
2025-12-07 13:49 ` Dominique Martinet
2025-12-08 17:21 ` Chris Arges
2025-12-09 9:52 ` Christian Schoenebeck
2025-11-25 15:52 ` Chris Arges
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=aTLYEF4ZaTwF3tdL@codewreck.org \
--to=asmadeus@codewreck.org \
--cc=carges@cloudflare.com \
--cc=dhowells@redhat.com \
--cc=ericvh@kernel.org \
--cc=kernel-team@cloudflare.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux_oss@crudebyte.com \
--cc=lucho@ionkov.net \
--cc=v9fs@lists.linux.dev \
--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