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=-24.8 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1,USER_IN_DEF_DKIM_WL autolearn=unavailable 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 8AC41C433ED for ; Fri, 30 Apr 2021 05:41:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 64D4C61186 for ; Fri, 30 Apr 2021 05:41:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230150AbhD3FmO (ORCPT ); Fri, 30 Apr 2021 01:42:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43454 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229482AbhD3FmL (ORCPT ); Fri, 30 Apr 2021 01:42:11 -0400 Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 215D8C06174A for ; Thu, 29 Apr 2021 22:41:22 -0700 (PDT) Received: by mail-qv1-xf33.google.com with SMTP id x27so33873952qvd.2 for ; Thu, 29 Apr 2021 22:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=Zx8pZdhiNX5aPOyXUOIzWq8zYQHmuVtq5hGUZrL+hxk=; b=leXLFTKdISvneTcPmvgUXPy0vucswWlGanD1F9s2b2AM5ZlSIVmek08Oc6xCvLso+i SdFwKFSs0p3/a0i1XzlDr/VTxcPgVkORFyoRglFCTeGrRFseFEJ+CxlNWsvKUSJXuj29 e2usBGYSeWD10SugISYejx9upWSBnBuzwpRZSo5jq7Kyif963vjzwqVdy+G2OMJsuAIY AMax8Z5vPcJOaLCzLCIgM2y5pYstLLiJMIKgGWoto6LU7i998eaIsejstUfW6WVQ2dsA gJyujCd7bfz6Q8RZH3JjXzcVN0TCeMNA46pWSoZitsTFYxkzrDpr00mzSd75n/k3JNmg 1JWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=Zx8pZdhiNX5aPOyXUOIzWq8zYQHmuVtq5hGUZrL+hxk=; b=SVJdQ5PrkEET3Lc9EzIcYAJiaXU/uqHndX6wKmoksAEM9AuIX3FjqhdnxgtYprmNt2 AnBj5nWW8Thkgi7PZqGimO2pVxTYvlBOoMQc1qMzBl1bvRec4acVyswSX/P/kiFskqI4 Dd6K9Yg1t81kC7n5ExV2v8HmORyajc3vZdsXUGPdSYvnZrLqXfrrZGCIFVOrBr39saIH 0gK+rDGHOD1eBuWpq3OtkXSg0hdxh4EUzjzejxdWjCshUB7py8YuB1fCelVTW65s7DbG 5MnqG7COWwMlkLcZLz0Bamvu48OSC1RzPbNKu0uR/yI66OoCe3In7tNGG4mkmiLEWxgB Vk3g== X-Gm-Message-State: AOAM531/GHp6p+Zhmv2LU7BKxQ+NqCWH3RqPsk7PM43jzRJe4uDU0u1G tvoiQgBlB1lxIYJfBz7Lwm/hRg== X-Google-Smtp-Source: ABdhPJzY13DAJCoJ5dcDvmbdoiHlkA74Mjnt1G1gxrRT/Of1Bop6wAym2XmFy51k0T+0YZ2pDLUGsg== X-Received: by 2002:a0c:e242:: with SMTP id x2mr3422063qvl.45.1619761281109; Thu, 29 Apr 2021 22:41:21 -0700 (PDT) Received: from eggly.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id a24sm672835qkn.104.2021.04.29.22.41.19 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Thu, 29 Apr 2021 22:41:20 -0700 (PDT) Date: Thu, 29 Apr 2021 22:41:05 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Andrew Morton cc: Hugh Dickins , Matthew Wilcox , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-nvdimm@lists.01.org, linux-kernel@vger.kernel.org Subject: Re: BUG_ON(!mapping_empty(&inode->i_data)) In-Reply-To: <20210429211634.de4e0fb98d27b3ab9d05757c@linux-foundation.org> Message-ID: References: <20210331024913.GS351017@casper.infradead.org> <20210401170615.GH351017@casper.infradead.org> <20210402031305.GK351017@casper.infradead.org> <20210402132708.GM351017@casper.infradead.org> <20210402170414.GQ351017@casper.infradead.org> <20210429211634.de4e0fb98d27b3ab9d05757c@linux-foundation.org> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 29 Apr 2021, Andrew Morton wrote: > > I'm not sure this ever was resolved? It was not resolved: Matthew had prospective fixes for one way in which it could happen, but they did not help the case which still hits my testing (well, I replace the BUG_ON by a WARN_ON, so not hit badly). > > Is it the case that the series "Remove nrexceptional tracking v2" at > least exposed this bug? Yes: makes a BUG out of a long-standing issue not noticed before. > > IOW, what the heck should I do with > > mm-introduce-and-use-mapping_empty.patch > mm-stop-accounting-shadow-entries.patch > dax-account-dax-entries-as-nrpages.patch > mm-remove-nrexceptional-from-inode.patch If Matthew doesn't have a proper fix yet (and it's a bit late for more than an obvious fix), I think those should go in, with this addition: [PATCH] mm: remove nrexceptional from inode: remove BUG_ON clear_inode()'s BUG_ON(!mapping_empty(&inode->i_data)) is unsafe: we know of two ways in which nodes can and do (on rare occasions) get left behind. Until those are fixed, do not BUG_ON() nor even WARN_ON(). Yes, this will then leak those nodes (or the next user of the struct inode may use them); but this has been happening for years, and the new BUG_ON(!mapping_empty) was only guilty of revealing that. A proper fix will follow, but no hurry. Signed-off-by: Hugh Dickins --- fs/inode.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) --- mmotm/fs/inode.c 2021-04-22 18:30:46.285908982 -0700 +++ linux/fs/inode.c 2021-04-29 22:13:54.096530691 -0700 @@ -529,7 +529,14 @@ void clear_inode(struct inode *inode) */ xa_lock_irq(&inode->i_data.i_pages); BUG_ON(inode->i_data.nrpages); - BUG_ON(!mapping_empty(&inode->i_data)); + /* + * Almost always, mapping_empty(&inode->i_data) here; but there are + * two known and long-standing ways in which nodes may get left behind + * (when deep radix-tree node allocation failed partway; or when THP + * collapse_file() failed). Until those two known cases are cleaned up, + * or a cleanup function is called here, do not BUG_ON(!mapping_empty), + * nor even WARN_ON(!mapping_empty). + */ xa_unlock_irq(&inode->i_data.i_pages); BUG_ON(!list_empty(&inode->i_data.private_list)); BUG_ON(!(inode->i_state & I_FREEING)); 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=-24.8 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1,USER_IN_DEF_DKIM_WL autolearn=unavailable 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 D9376C433B4 for ; Fri, 30 Apr 2021 05:41:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6A50B61186 for ; Fri, 30 Apr 2021 05:41:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6A50B61186 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D130A6B006C; Fri, 30 Apr 2021 01:41:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CE97A6B006E; Fri, 30 Apr 2021 01:41:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B8A3F6B0070; Fri, 30 Apr 2021 01:41:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0158.hostedemail.com [216.40.44.158]) by kanga.kvack.org (Postfix) with ESMTP id 9C80B6B006C for ; Fri, 30 Apr 2021 01:41:23 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 7A24C8249980 for ; Fri, 30 Apr 2021 05:41:22 +0000 (UTC) X-FDA: 78087935604.08.6709456 Received: from mail-qv1-f53.google.com (mail-qv1-f53.google.com [209.85.219.53]) by imf24.hostedemail.com (Postfix) with ESMTP id 0C166A0003B5 for ; Fri, 30 Apr 2021 05:41:10 +0000 (UTC) Received: by mail-qv1-f53.google.com with SMTP id jm10so1635927qvb.5 for ; Thu, 29 Apr 2021 22:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=Zx8pZdhiNX5aPOyXUOIzWq8zYQHmuVtq5hGUZrL+hxk=; b=leXLFTKdISvneTcPmvgUXPy0vucswWlGanD1F9s2b2AM5ZlSIVmek08Oc6xCvLso+i SdFwKFSs0p3/a0i1XzlDr/VTxcPgVkORFyoRglFCTeGrRFseFEJ+CxlNWsvKUSJXuj29 e2usBGYSeWD10SugISYejx9upWSBnBuzwpRZSo5jq7Kyif963vjzwqVdy+G2OMJsuAIY AMax8Z5vPcJOaLCzLCIgM2y5pYstLLiJMIKgGWoto6LU7i998eaIsejstUfW6WVQ2dsA gJyujCd7bfz6Q8RZH3JjXzcVN0TCeMNA46pWSoZitsTFYxkzrDpr00mzSd75n/k3JNmg 1JWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=Zx8pZdhiNX5aPOyXUOIzWq8zYQHmuVtq5hGUZrL+hxk=; b=lluBrUfv9ZuSd2r9NjgK7N2xW3NpuNxYC6mIK1xU7ZiHHBmgTjgsRgrPBMTZlmDA5k gxqYZ/w4aqV918Ne9jAowFRkt+tQMJLv0STqUyyezE+QKt9ty8qp77jySeEnoS3ia8Qe X8Esn8wzy0Wei/4MxrQxdM/gT4FCFlDpEaWB18QJsFtCQrg/42T0Vh1WcTlwo6ASc8Uy 8Hl8Bjj9RyDPwxyI2akT3OEN5tp2GgTzdZw4T70x1TBZeZ3T9K+dd2viTrVru4fuZ0+B owVmcB0IqSG5FyE1hH1laJxnmC0eagy8IKXc3dtSTmsCsCj9Jahq4DrgS1iHqQa3fGhx J+IQ== X-Gm-Message-State: AOAM531F/R7R46OnCX2H3WzwByZus2vpI2HUcT6ufg1zl8QltcBaLhtn k05rfsK0kstFelsbuSs1ZQRw2w== X-Google-Smtp-Source: ABdhPJzY13DAJCoJ5dcDvmbdoiHlkA74Mjnt1G1gxrRT/Of1Bop6wAym2XmFy51k0T+0YZ2pDLUGsg== X-Received: by 2002:a0c:e242:: with SMTP id x2mr3422063qvl.45.1619761281109; Thu, 29 Apr 2021 22:41:21 -0700 (PDT) Received: from eggly.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id a24sm672835qkn.104.2021.04.29.22.41.19 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Thu, 29 Apr 2021 22:41:20 -0700 (PDT) Date: Thu, 29 Apr 2021 22:41:05 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Andrew Morton cc: Hugh Dickins , Matthew Wilcox , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-nvdimm@lists.01.org, linux-kernel@vger.kernel.org Subject: Re: BUG_ON(!mapping_empty(&inode->i_data)) In-Reply-To: <20210429211634.de4e0fb98d27b3ab9d05757c@linux-foundation.org> Message-ID: References: <20210331024913.GS351017@casper.infradead.org> <20210401170615.GH351017@casper.infradead.org> <20210402031305.GK351017@casper.infradead.org> <20210402132708.GM351017@casper.infradead.org> <20210402170414.GQ351017@casper.infradead.org> <20210429211634.de4e0fb98d27b3ab9d05757c@linux-foundation.org> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=leXLFTKd; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.hostedemail.com: domain of hughd@google.com designates 209.85.219.53 as permitted sender) smtp.mailfrom=hughd@google.com X-Rspamd-Server: rspam03 X-Stat-Signature: 31hgqc1rxcmh79etr63ybd61ngqr1ycd X-Rspamd-Queue-Id: 0C166A0003B5 Received-SPF: none (google.com>: No applicable sender policy available) receiver=imf24; identity=mailfrom; envelope-from=""; helo=mail-qv1-f53.google.com; client-ip=209.85.219.53 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1619761270-504742 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, 29 Apr 2021, Andrew Morton wrote: > > I'm not sure this ever was resolved? It was not resolved: Matthew had prospective fixes for one way in which it could happen, but they did not help the case which still hits my testing (well, I replace the BUG_ON by a WARN_ON, so not hit badly). > > Is it the case that the series "Remove nrexceptional tracking v2" at > least exposed this bug? Yes: makes a BUG out of a long-standing issue not noticed before. > > IOW, what the heck should I do with > > mm-introduce-and-use-mapping_empty.patch > mm-stop-accounting-shadow-entries.patch > dax-account-dax-entries-as-nrpages.patch > mm-remove-nrexceptional-from-inode.patch If Matthew doesn't have a proper fix yet (and it's a bit late for more than an obvious fix), I think those should go in, with this addition: [PATCH] mm: remove nrexceptional from inode: remove BUG_ON clear_inode()'s BUG_ON(!mapping_empty(&inode->i_data)) is unsafe: we know of two ways in which nodes can and do (on rare occasions) get left behind. Until those are fixed, do not BUG_ON() nor even WARN_ON(). Yes, this will then leak those nodes (or the next user of the struct inode may use them); but this has been happening for years, and the new BUG_ON(!mapping_empty) was only guilty of revealing that. A proper fix will follow, but no hurry. Signed-off-by: Hugh Dickins --- fs/inode.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) --- mmotm/fs/inode.c 2021-04-22 18:30:46.285908982 -0700 +++ linux/fs/inode.c 2021-04-29 22:13:54.096530691 -0700 @@ -529,7 +529,14 @@ void clear_inode(struct inode *inode) */ xa_lock_irq(&inode->i_data.i_pages); BUG_ON(inode->i_data.nrpages); - BUG_ON(!mapping_empty(&inode->i_data)); + /* + * Almost always, mapping_empty(&inode->i_data) here; but there are + * two known and long-standing ways in which nodes may get left behind + * (when deep radix-tree node allocation failed partway; or when THP + * collapse_file() failed). Until those two known cases are cleaned up, + * or a cleanup function is called here, do not BUG_ON(!mapping_empty), + * nor even WARN_ON(!mapping_empty). + */ xa_unlock_irq(&inode->i_data.i_pages); BUG_ON(!list_empty(&inode->i_data.private_list)); BUG_ON(!(inode->i_state & I_FREEING)); 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=-12.1 required=3.0 tests=BAYES_40, DKIM_ADSP_CUSTOM_MED,DKIM_INVALID,DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=unavailable 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 B50F7C433B4 for ; Fri, 30 Apr 2021 05:41:27 +0000 (UTC) Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 72C5461452 for ; Fri, 30 Apr 2021 05:41:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 72C5461452 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-nvdimm-bounces@lists.01.org Received: from ml01.vlan13.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 53A4C100EB85C; Thu, 29 Apr 2021 22:41:26 -0700 (PDT) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2607:f8b0:4864:20::f32; helo=mail-qv1-xf32.google.com; envelope-from=hughd@google.com; receiver= Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id B757F100EB858 for ; Thu, 29 Apr 2021 22:41:23 -0700 (PDT) Received: by mail-qv1-xf32.google.com with SMTP id b14so8281633qvf.9 for ; Thu, 29 Apr 2021 22:41:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=Zx8pZdhiNX5aPOyXUOIzWq8zYQHmuVtq5hGUZrL+hxk=; b=leXLFTKdISvneTcPmvgUXPy0vucswWlGanD1F9s2b2AM5ZlSIVmek08Oc6xCvLso+i SdFwKFSs0p3/a0i1XzlDr/VTxcPgVkORFyoRglFCTeGrRFseFEJ+CxlNWsvKUSJXuj29 e2usBGYSeWD10SugISYejx9upWSBnBuzwpRZSo5jq7Kyif963vjzwqVdy+G2OMJsuAIY AMax8Z5vPcJOaLCzLCIgM2y5pYstLLiJMIKgGWoto6LU7i998eaIsejstUfW6WVQ2dsA gJyujCd7bfz6Q8RZH3JjXzcVN0TCeMNA46pWSoZitsTFYxkzrDpr00mzSd75n/k3JNmg 1JWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=Zx8pZdhiNX5aPOyXUOIzWq8zYQHmuVtq5hGUZrL+hxk=; b=I5vebI4HxYWXblIVv8RtEZYzj3mXxhkoHQf5ylYJgEE11w7kiPGxb18yPO9YQC1ZH0 GN+ASsEOPA6Rick2Qy/BavA0omTDnW5wSo52r+B9ACj1u6wGQmao2F7MRB6uv1eydeTY U9ygi9GoV4YHDql8jXSL2Zq+McBbzl/78b4k2xa6Zn3nCyF5axdWoyzjGcU187+sjQ97 PZMVYOWmCrKopORCH8k6XuG8Xvbs672N7Hna8VJegYFakIIlOWKpwuO9t95GuOpBhWdC sE1+vZQT7uwuZtG9eHMJeMJBiTIqs6i92GGzI2Xuqf7RUBOtmlaBmimz/xOvbcX6ZTTz zdnw== X-Gm-Message-State: AOAM533Zr98vyd7F3VzS4kg+e4KyeqS4rkd+NOUCbj7h6SBKzN6GmWMK Zo/0HvbtejmRv/7kybgqtwyJ/Q== X-Google-Smtp-Source: ABdhPJzY13DAJCoJ5dcDvmbdoiHlkA74Mjnt1G1gxrRT/Of1Bop6wAym2XmFy51k0T+0YZ2pDLUGsg== X-Received: by 2002:a0c:e242:: with SMTP id x2mr3422063qvl.45.1619761281109; Thu, 29 Apr 2021 22:41:21 -0700 (PDT) Received: from eggly.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id a24sm672835qkn.104.2021.04.29.22.41.19 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Thu, 29 Apr 2021 22:41:20 -0700 (PDT) Date: Thu, 29 Apr 2021 22:41:05 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Andrew Morton Subject: Re: BUG_ON(!mapping_empty(&inode->i_data)) In-Reply-To: <20210429211634.de4e0fb98d27b3ab9d05757c@linux-foundation.org> Message-ID: References: <20210331024913.GS351017@casper.infradead.org> <20210401170615.GH351017@casper.infradead.org> <20210402031305.GK351017@casper.infradead.org> <20210402132708.GM351017@casper.infradead.org> <20210402170414.GQ351017@casper.infradead.org> <20210429211634.de4e0fb98d27b3ab9d05757c@linux-foundation.org> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Message-ID-Hash: 6OVFLY4BFUS2KWAMXWEMOZAA4IGLGNVW X-Message-ID-Hash: 6OVFLY4BFUS2KWAMXWEMOZAA4IGLGNVW X-MailFrom: hughd@google.com X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation CC: Hugh Dickins , Matthew Wilcox , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-nvdimm@lists.01.org, linux-kernel@vger.kernel.org X-Mailman-Version: 3.1.1 Precedence: list List-Id: "Linux-nvdimm developer list." Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: TEXT/PLAIN; charset="us-ascii" Content-Transfer-Encoding: 7bit On Thu, 29 Apr 2021, Andrew Morton wrote: > > I'm not sure this ever was resolved? It was not resolved: Matthew had prospective fixes for one way in which it could happen, but they did not help the case which still hits my testing (well, I replace the BUG_ON by a WARN_ON, so not hit badly). > > Is it the case that the series "Remove nrexceptional tracking v2" at > least exposed this bug? Yes: makes a BUG out of a long-standing issue not noticed before. > > IOW, what the heck should I do with > > mm-introduce-and-use-mapping_empty.patch > mm-stop-accounting-shadow-entries.patch > dax-account-dax-entries-as-nrpages.patch > mm-remove-nrexceptional-from-inode.patch If Matthew doesn't have a proper fix yet (and it's a bit late for more than an obvious fix), I think those should go in, with this addition: [PATCH] mm: remove nrexceptional from inode: remove BUG_ON clear_inode()'s BUG_ON(!mapping_empty(&inode->i_data)) is unsafe: we know of two ways in which nodes can and do (on rare occasions) get left behind. Until those are fixed, do not BUG_ON() nor even WARN_ON(). Yes, this will then leak those nodes (or the next user of the struct inode may use them); but this has been happening for years, and the new BUG_ON(!mapping_empty) was only guilty of revealing that. A proper fix will follow, but no hurry. Signed-off-by: Hugh Dickins --- fs/inode.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) --- mmotm/fs/inode.c 2021-04-22 18:30:46.285908982 -0700 +++ linux/fs/inode.c 2021-04-29 22:13:54.096530691 -0700 @@ -529,7 +529,14 @@ void clear_inode(struct inode *inode) */ xa_lock_irq(&inode->i_data.i_pages); BUG_ON(inode->i_data.nrpages); - BUG_ON(!mapping_empty(&inode->i_data)); + /* + * Almost always, mapping_empty(&inode->i_data) here; but there are + * two known and long-standing ways in which nodes may get left behind + * (when deep radix-tree node allocation failed partway; or when THP + * collapse_file() failed). Until those two known cases are cleaned up, + * or a cleanup function is called here, do not BUG_ON(!mapping_empty), + * nor even WARN_ON(!mapping_empty). + */ xa_unlock_irq(&inode->i_data.i_pages); BUG_ON(!list_empty(&inode->i_data.private_list)); BUG_ON(!(inode->i_state & I_FREEING)); _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-leave@lists.01.org