From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DF45FC433E9 for ; Mon, 15 Mar 2021 09:47:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B258B64EC3 for ; Mon, 15 Mar 2021 09:47:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229893AbhCOJrG (ORCPT ); Mon, 15 Mar 2021 05:47:06 -0400 Received: from mx2.suse.de ([195.135.220.15]:59336 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229546AbhCOJqc (ORCPT ); Mon, 15 Mar 2021 05:46:32 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id D97FDAD74; Mon, 15 Mar 2021 09:46:30 +0000 (UTC) Received: from localhost (brahms [local]) by brahms (OpenSMTPD) with ESMTPA id 335e3db6; Mon, 15 Mar 2021 09:47:45 +0000 (UTC) Date: Mon, 15 Mar 2021 09:47:45 +0000 From: Luis Henriques To: Matthew Wilcox Cc: Miklos Szeredi , "Kirill A. Shutemov" , Andrew Morton , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: fuse: kernel BUG at mm/truncate.c:763! Message-ID: References: <20210312131123.GZ3479805@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210312131123.GZ3479805@casper.infradead.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 12, 2021 at 01:11:23PM +0000, Matthew Wilcox wrote: > 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. Just to make sure I got this right, you want to test something like this: } } - BUG_ON(page_mapped(page)); + VM_BUG_ON_PAGE(page_mapped(page), page); ret2 = do_launder_page(mapping, page); if (ret2 == 0) { if (!invalidate_complete_page2(mapping, page)) Cheers, -- Luís > > > > 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)