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));