From: Matthew Wilcox <willy@infradead.org>
To: Luis Henriques <lhenriques@suse.de>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: fuse: kernel BUG at mm/truncate.c:763!
Date: Fri, 12 Mar 2021 13:11:23 +0000 [thread overview]
Message-ID: <20210312131123.GZ3479805@casper.infradead.org> (raw)
In-Reply-To: <YEtc54pWLLjb6SgL@suse.de>
On Fri, Mar 12, 2021 at 12:21:59PM +0000, Luis Henriques wrote:
> > > I've seen a bug report (5.10.16 kernel splat below) that seems to be
> > > reproducible in kernels as early as 5.4.
If this is reproducible, can you turn this BUG_ON into a VM_BUG_ON_PAGE()
so we know what kind of problem we're dealing with? Assuming the SUSE
tumbleweed kernels enable CONFIG_DEBUG_VM, which I'm sure they do.
> > Page fault locks the page before installing a new pte, at least
> > AFAICS, so the BUG looks impossible. The referenced commits only
> > touch very high level control of writeback, so they may well increase
> > the chance of a bug triggering, but very unlikely to be the actual
> > cause of the bug. I'm guessing this to be an MM issue.
>
> Ok, thank you for having a look at it.
>
> Interestingly, there's a single commit to mm/truncate.c in 5.4:
> ef18a1ca847b ("mm/thp: allow dropping THP from page cache"). I'm Cc'ing
> Andrew and Kirill, maybe they have some ideas.
That's probably not it; unless FUSE has developed the ability to insert
compound pages into the page cache without me noticing.
(if it had, that would absolutely explain it -- i have a fix in my thp
tree for this case, but it doesn't affect any existing filesystem
because only shmem uses compound pages and it doesn't call
invalidate_inode_pages2_range)
next prev parent reply other threads:[~2021-03-12 13:12 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-12 8:52 fuse: kernel BUG at mm/truncate.c:763! Luis Henriques
2021-03-12 9:48 ` Miklos Szeredi
2021-03-12 12:21 ` Luis Henriques
2021-03-12 13:11 ` Matthew Wilcox [this message]
2021-03-15 9:47 ` Luis Henriques
2021-03-15 11:06 ` Matthew Wilcox
2021-03-18 9:26 ` Luis Henriques
2021-03-18 10:59 ` Miklos Szeredi
2021-03-18 11:03 ` Kirill A. Shutemov
2021-03-18 11:29 ` Luis Henriques
2021-03-18 11:55 ` Matthew Wilcox
2021-03-18 12:16 ` Luis Henriques
2021-03-19 9:02 ` Luis Henriques
2021-03-29 9:01 ` Luis Henriques
2021-03-29 12:05 ` Matthew Wilcox
2021-05-03 8:52 ` Luis Henriques
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=20210312131123.GZ3479805@casper.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=lhenriques@suse.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
/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).