Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp1860207pxp; Sun, 13 Mar 2022 01:25:12 -0800 (PST) X-Google-Smtp-Source: ABdhPJwe7TZHAXuiYllXIa1zSUcqDIINlLgAtQ6zUCYr1m2dflzHune7l9ZgNUbRkupcHhPG35VF X-Received: by 2002:a05:6402:14d3:b0:415:f935:66b2 with SMTP id f19-20020a05640214d300b00415f93566b2mr15952585edx.330.1647163512149; Sun, 13 Mar 2022 01:25:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1647163512; cv=none; d=google.com; s=arc-20160816; b=yKCmIZQB/3o5In1jDbNMvpapKt/Bzza8PEnE/Fp84E83aB2PKxgFLNu5ZC2wNi08ZW HiQABSkMF4KGA3sldBPMWC+KzWjzZpEmke+vyXdsQTupIcv/KexogHBmF2WcaY2UTBEz 48DcphWsSIMDEpZNOyvjt+/sShUgLPcovrHH8ud8Mz1jvvrf94EuDps4qMZ4HBdcmOPH zTTWzVQ8mj4bdf6akkYkjF+yEwpBG5ODXhN5skcqogA6wgDWekOo8WArsSMp2t0pghll X9O68RmOVEXHUm/ntdcbv/8naqdGJ14Y0nDMgqOW2BPU2S9MuuT+nN9yHuoCPLMkrYBY LL9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=5hR1Qek6Dt5ZJKGDiQ5dVV6ae1mjFxBIUZ1scNsnvrA=; b=d+JDB12wp9uMw/jvFy5chEKQe14Kvhnhgw9dJ2mQWAYZGrPpsqfLAAToPp8OdccC01 lGAC/diqAmpv2y9S/VKF77bRMhwt0IM8WVhuM0n0+Y7U/lI09u+2GCL/NRzC+XMjUOyh CH9eiDMdTOYwC6nlemQcajCqAt8IjtnNzx48+BuzxQ0R4qEGjqiqcU8a796ZqfSVmIop R8w5GfZ44qwlOxkNwTwXjm3Y+Gm+CLKqWV6Xzzwf4qhmKH4L6ihRRueMDjg0jAQzhZaO dBDqhPZ8qqz+WpNEe47XJ6UDp4t5Q3eA6/NTsfNFm/Wh+gAiRDcHbbgNvFqbnukZbYVL XuNg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=U+zef3au; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id gb22-20020a170907961600b006d79dcb4628si8220380ejc.102.2022.03.13.01.24.47; Sun, 13 Mar 2022 01:25:12 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=U+zef3au; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231618AbiCMH3l (ORCPT + 99 others); Sun, 13 Mar 2022 03:29:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42612 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231147AbiCMH3j (ORCPT ); Sun, 13 Mar 2022 03:29:39 -0400 Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1FE033B3D2; Sat, 12 Mar 2022 23:28:31 -0800 (PST) Received: by mail-yb1-xb2b.google.com with SMTP id v130so24984552ybe.13; Sat, 12 Mar 2022 23:28:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5hR1Qek6Dt5ZJKGDiQ5dVV6ae1mjFxBIUZ1scNsnvrA=; b=U+zef3au6jKLJA6fhaXO7tG152fud3s5ECEi7uZMYolp8xLvx1foI51jhHfWGWspvK xkpnvfpekkogCBwZ2Y0OpxkwTZLzF6PCwSuAyptcCn03McsvGBI/kqRrzmT2c02mCiJd opnzj2F6g9DodGUJi6avraSw3ATz08qYFVT1VhvN38MPV2soCVcyTUSTOh7cNlejuXFG umDEbEXGt8Y6iSVcSjlvWJaSeRK5nsaTecTFjVdxFEhHpvGU88EcCN74XzeK1OPFdWlU YU0Vi5DWyb5Ir1ICrLxWs4YLNq1rfwRgGwFZDcgi1wcn8crvVr9KkqysDxCkjWzah0L1 Ywng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5hR1Qek6Dt5ZJKGDiQ5dVV6ae1mjFxBIUZ1scNsnvrA=; b=3H6cz+kbC18zqw6wnC9K3ABCOW3YqcIcKteLpjkHn+O6emVsenFI23VbZiwTXlxkfL yEbjGRcrJ7iAey0rh2T3XQyAynpcqNjbPhlqdDt9X5JUb3eg6dfpobIojY++VJr8kUm/ TCM0Q0EwxLobbUokfebMAJJm9mHCOrGC3feYkVMLP1VY/fprYa8MYPF3WdMJ0QIPl9u1 XUEryNhA9rZk2NzKE5j69BZp4kXwwLt2PZy1N5rLmvGI8fKPqPwgS6Fw3al5V33t/6sO eXXYlbmwoJMIBLX8bRSYNQulD9dnUQzjHDjSmm8xz0ryyy/NqqSb4ZcHzGglBTG1SHN6 KGew== X-Gm-Message-State: AOAM532ZBSO5AD8JL/tOJCvCYMtT0mB73gop8kQ+ETkKgRAId5b21iez OEUTNq/VZodgac6LtZavl7f1PTeThu7awt7dTZbYrE9FysM2zg== X-Received: by 2002:a25:cb85:0:b0:628:f0db:b2c4 with SMTP id b127-20020a25cb85000000b00628f0dbb2c4mr13434093ybg.531.1647156510213; Sat, 12 Mar 2022 23:28:30 -0800 (PST) MIME-Version: 1.0 References: <9a20b33d-b38f-b4a2-4742-c1eb5b8e4d6c@redhat.com> <20220312222351.89844f74d3cf10212f308caf@linux-foundation.org> In-Reply-To: <20220312222351.89844f74d3cf10212f308caf@linux-foundation.org> From: Ryusuke Konishi Date: Sun, 13 Mar 2022 16:28:18 +0900 Message-ID: Subject: Re: nilfs: WARNING: CPU: 2 PID: 1510 at include/linux/backing-dev.h:269 __folio_mark_dirty+0x31d/0x3b0 To: Andrew Morton Cc: Matthew Wilcox , David Hildenbrand , "linux-kernel@vger.kernel.org" , linux-nilfs , "linux-mm@kvack.org" , Linus Torvalds Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Mar 13, 2022 at 3:23 PM Andrew Morton wrote: > > On Sun, 13 Mar 2022 15:09:27 +0900 Ryusuke Konishi wrote: > > > Hi Matthew, and Andrew, > > > > On Sat, Mar 12, 2022 at 7:56 AM Matthew Wilcox wrote: > > > > > > On Fri, Mar 11, 2022 at 08:43:57PM +0100, David Hildenbrand wrote: > > > > Hi, > > > > > > > > playing with swapfiles on random file systems, I stumbled over the > > > > following nilfs issue (and reproduced it on latest greatest > > > > linux/master -- v5.17-rc7+). I did not try finding out when this > > > > was introduced and I did not run into this issue on other file > > > > systems I tried. > > > > > > It's a known bug in NILFS, and I think yours is the fifth report > > > of it dating back eight months. > > > > The root cause of this issue is that NILFS uses two page caches > > per inode, one for data blocks and another for b-tree node blocks. > > > > Even though __folio_end_writeback(), __folio_start_writeback(), and > > __folio_mark_dirty() acquire lock for mapping->i_pages, > > inode_to_wb(inode) inside them performs lockdep test for the former one > > (i.e. inode->i_mapping->i_pages.xa_lock). > > > > So, mark_buffer_dirty(), end_page_writeback(), and set_page_writeback() > > for pages in the latter NILFS specific page cache hit the LOCKDEP warning. > > > > I tried to find a way to resolve this, but have no good idea so far. > > If things are set up appropriately, inode_to_wb() should be able to > test inode->i_mapping->host->i_mapping->i_pages.xa_lock and get the > desired result. > > At least, that's the case with blockdevs. I don't know if nilfs2 sets > things up that way. Yes, that is the problem of the current implementation of nilfs2. nilfs2 sets the page cache for data to inode->i_mapping but the page cache for b-tree nodes is not set to inode->i_mapping because both are kept in one nilfs_inode together. To satisfy relation inode->i_mapping->host == inode for both page caches, I need to change nilfs_inode to assign inode struct for both. Well, I'll consider if such modification is possible as a solution. Regards, Ryusuke Konishi