[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aTLYEF4ZaTwF3tdL@codewreck.org>
Date: Fri, 5 Dec 2025 22:03:12 +0900
From: Dominique Martinet <asmadeus@...ewreck.org>
To: Christian Schoenebeck <linux_oss@...debyte.com>
Cc: Matthew Wilcox <willy@...radead.org>,
Chris Arges <carges@...udflare.com>,
David Howells <dhowells@...hat.com>, ericvh@...nel.org,
lucho@...kov.net, v9fs@...ts.linux.dev,
linux-kernel@...r.kernel.org, kernel-team@...udflare.com
Subject: Re: kernel BUG when mounting large block xfs backed by 9p (folio ref
count bug)
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
Powered by blists - more mailing lists