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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 45E59C433EF for ; Wed, 29 Sep 2021 23:42:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E59E66152A for ; Wed, 29 Sep 2021 23:42:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org E59E66152A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 724B6940071; Wed, 29 Sep 2021 19:42:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6D3E294003A; Wed, 29 Sep 2021 19:42:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5C421940071; Wed, 29 Sep 2021 19:42:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0038.hostedemail.com [216.40.44.38]) by kanga.kvack.org (Postfix) with ESMTP id 4DA3794003A for ; Wed, 29 Sep 2021 19:42:03 -0400 (EDT) Received: from smtpin33.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 13CFA2D23B for ; Wed, 29 Sep 2021 23:42:03 +0000 (UTC) X-FDA: 78642236526.33.393B0AD Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf27.hostedemail.com (Postfix) with ESMTP id B520C70009D8 for ; Wed, 29 Sep 2021 23:42:02 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id D744061361 for ; Wed, 29 Sep 2021 23:42:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1632958921; bh=otV9VV/sFcF022eYj5odI220EtLVp8iNHKDlnTKMYts=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=MABys8Z/Y8aBZd0ydLplveETTesiDBeKHDu/pTycjplmN3OTjdf5osT6dFwgfjE9w 1WD/AJIsr+eO9oidOxUCby37TKrvZxRNssqyfuOBMe24rwl/4H9mjfe5MwX+0iwn8h h8nGjt8UTvIJbeDF+Dqx0o1+Pi51ejS5s2BPEghw9h2J+SvQy2/Lm755RIkCNBcWmk Q2rZroP9Rxrlp82/jswReK/kTomgAifBS4xkfyStPAwcPTnGwVdl6+8Hs6W5k/YrAZ cWveMGgB50sEnWsZTOygQnAdXcmEna94kFfRFPzkoY/9R620kbQgxEOGllODea3sgD qCX68asy4QjXw== Received: by mail-lf1-f45.google.com with SMTP id i25so17546335lfg.6 for ; Wed, 29 Sep 2021 16:42:01 -0700 (PDT) X-Gm-Message-State: AOAM531INvK7ItaWOmj5xjcQQK+RnhwmLWN6CwQgAZC/ZPtPl0dRoBaQ CFCV7KYYKSFFf8h+N2KgQWwLX3mlA0T4yDmjOm0= X-Google-Smtp-Source: ABdhPJxHqAjSpOeee9Gqzi1rY9sY5DM00t+Nr1XmoZToxp1W8xpUS2LPcFfuGRc/ndeFpb0W/nBQOoEpcB3X7s5V7cE= X-Received: by 2002:a2e:5442:: with SMTP id y2mr2794204ljd.436.1632958920169; Wed, 29 Sep 2021 16:42:00 -0700 (PDT) MIME-Version: 1.0 References: <20210922070645.47345-2-rongwei.wang@linux.alibaba.com> <20210923194343.ca0f29e1c4d361170343a6f2@linux-foundation.org> <9e41661d-9919-d556-8c49-610dae157553@linux.alibaba.com> <68737431-01d2-e6e3-5131-7d7c731e49ae@linux.alibaba.com> In-Reply-To: From: Song Liu Date: Wed, 29 Sep 2021 16:41:48 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 1/2] mm, thp: check page mapping when truncating page cache To: Matthew Wilcox Cc: Rongwei Wang , Andrew Morton , Linux MM , Linux Kernel Mailing List , William Kucharski , Hugh Dickins Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="MABys8Z/"; spf=pass (imf27.hostedemail.com: domain of song@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=song@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: B520C70009D8 X-Stat-Signature: 61mqnuzifmwr76bs9iok3hkj4xfirudo X-HE-Tag: 1632958922-6433 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 Wed, Sep 29, 2021 at 10:56 AM Matthew Wilcox wrote: > [...] > > Now, I am able to crash the system on > > find_lock_entries () { > > ... > > VM_BUG_ON_PAGE(page->index != xas.xa_index, page); > > } > > I guess it is related. I will test more. > > That's a bogus VM_BUG_ON. I have a patch in my tree to delete it. > Andrew has it too, but for some reason, he hasn't sent it on to Linus. > > +++ b/mm/filemap.c > @@ -2093,7 +2093,6 @@ unsigned find_lock_entries(struct address_space *mapping, pgoff_t start, > if (!xa_is_value(page)) { > if (page->index < start) > goto put; > - VM_BUG_ON_PAGE(page->index != xas.xa_index, page); > if (page->index + thp_nr_pages(page) - 1 > end) > goto put; > if (!trylock_page(page)) Yes, after removing this line, I am able to see the same bug. Here is my finding so far: The issue is NOT caused by concurrent khugepaged:collapse_file() and truncate_pagecache(inode, 0). With some printks, we can see a clear time gap (>2 second ) between collapse_file() finishes, and truncate_pagecache() (which crashes soon). Therefore, my earlier suggestion that adds deny_write_access() to collapse_file() does NOT work. The crash is actually caused by concurrent truncate_pagecache(inode, 0). If I change the number of write thread in stress_madvise_dso.c to one, (IOW, one thread_read and one thread_write), I cannot reproduce the crash anymore. I think this means we cannot fix this issue in collapse_file(), because it finishes long before the crash. Thanks, Song