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=-13.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 29C97C433F5 for ; Wed, 15 Sep 2021 11:49:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A960061246 for ; Wed, 15 Sep 2021 11:49:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org A960061246 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=shutemov.name Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 3A9106B0071; Wed, 15 Sep 2021 07:49:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 358A4900002; Wed, 15 Sep 2021 07:49:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2466F6B0073; Wed, 15 Sep 2021 07:49:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 1336C6B0071 for ; Wed, 15 Sep 2021 07:49:47 -0400 (EDT) Received: from smtpin35.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id BCFC222BEB for ; Wed, 15 Sep 2021 11:49:46 +0000 (UTC) X-FDA: 78589638372.35.FA86E11 Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) by imf06.hostedemail.com (Postfix) with ESMTP id 7A5A3801A8B2 for ; Wed, 15 Sep 2021 11:49:46 +0000 (UTC) Received: by mail-lf1-f47.google.com with SMTP id a4so5463564lfg.8 for ; Wed, 15 Sep 2021 04:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov-name.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=yo03e49CSM9e+sK2Ar3YFN6XJZsOWYWg58Boo0XuPOY=; b=EjiA6mw4cOgTCrsZ4wG5YPQVw0KdpgFKDidA3coOJ1TctrxAlsxb4bTKXkWhXW3bFI z93vhuPvtmANlqMzJ9Xlao4VpnQsiVIdXvVjSuweUxhvHsYiWQ/neKkNQvFBbfcsdXH4 VhGZgQLK/QprQylx1ftGhTBlbEXVUHOkfEkat9GxVvLsh7rVyoMjTZWUKYCE1U2MPrpg tGQaqtCg1iEQZIlUAxToJATzU0vJEFvj23sAjtv/hlGTcLKw38i3InV9n3deIGUXGidG DZZwFW0WmfSkLcorhH/vuI8qpcT6QRsRD21uNZzUUefSum5BEbTKUfx6YOFMorVEbzBb jSxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=yo03e49CSM9e+sK2Ar3YFN6XJZsOWYWg58Boo0XuPOY=; b=FUgrbo3txafs70pIiPUss8nBGsBth1uA5M5pHOYbs45GXc1u7HEqlxXBK7dgwhP1qM eX5W42MMz4NQdg58o2BJgMBr6lpz9Sx8FU1dDXJ8AFbkVUNbvovrOIruthc/sEuD+YZI l8tr9+E7Rsn+weVRCUJWanG1iKkVsw0/UbCDAl8IcQZxjY/ZoZzuplQSx/Ss/0AAT4BW +7AXFq6Ci87tLTKVuqUQDM5FcPRLgQ5HajR0LDwSoeIAumYQDd9BZeBl6mVXBmczh93C 08BAm3iETubqsQL+VUsh2sWnW3QR8V5S1Iw0e652O0wCF7weCFryKfTtSEJvSvANFR1B yd5A== X-Gm-Message-State: AOAM533bYxgCDXGS0WfDJOAO33LnmvsEnTYVPfQ++kiWWEsIYZ2fqss0 Grl1kBCebmpsHcZc98U/3sPGMg== X-Google-Smtp-Source: ABdhPJwJEJa29YCPvHcMHB5ACnZWwPdD9bhSmcU/6aodYg9lHsPZ93xQzZ5mfv3kz6pEGsgCg/Bu5A== X-Received: by 2002:ac2:48bc:: with SMTP id u28mr17390054lfg.370.1631706584674; Wed, 15 Sep 2021 04:49:44 -0700 (PDT) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id z5sm1665264ljz.23.2021.09.15.04.49.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Sep 2021 04:49:44 -0700 (PDT) Received: by box.localdomain (Postfix, from userid 1000) id ADFE1102F4D; Wed, 15 Sep 2021 14:49:47 +0300 (+03) Date: Wed, 15 Sep 2021 14:49:47 +0300 From: "Kirill A. Shutemov" To: Yang Shi Cc: naoya.horiguchi@nec.com, hughd@google.com, kirill.shutemov@linux.intel.com, willy@infradead.org, osalvador@suse.de, akpm@linux-foundation.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/4] mm: khugepaged: check if file page is on LRU after locking page Message-ID: <20210915114947.2zh7inouztenth6o@box.shutemov.name> References: <20210914183718.4236-1-shy828301@gmail.com> <20210914183718.4236-3-shy828301@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210914183718.4236-3-shy828301@gmail.com> Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=shutemov-name.20150623.gappssmtp.com header.s=20150623 header.b=EjiA6mw4; spf=none (imf06.hostedemail.com: domain of kirill@shutemov.name has no SPF policy when checking 209.85.167.47) smtp.mailfrom=kirill@shutemov.name; dmarc=none X-Stat-Signature: bz6ujw895ongrn73qji1whdsesnaycq1 X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 7A5A3801A8B2 X-HE-Tag: 1631706586-437847 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 Tue, Sep 14, 2021 at 11:37:16AM -0700, Yang Shi wrote: > The khugepaged does check if the page is on LRU or not but it doesn't > hold page lock. And it doesn't check this again after holding page > lock. So it may race with some others, e.g. reclaimer, migration, etc. > All of them isolates page from LRU then lock the page then do something. > > But it could pass the refcount check done by khugepaged to proceed > collapse. Typically such race is not fatal. But if the page has been > isolated from LRU before khugepaged it likely means the page may be not > suitable for collapse for now. > > The other more fatal case is the following patch will keep the poisoned > page in page cache for shmem, so khugepaged may collapse a poisoned page > since the refcount check could pass. 3 refcounts come from: > - hwpoison > - page cache > - khugepaged > > Since it is not on LRU so no refcount is incremented from LRU isolation. > > This is definitely not expected. Checking if it is on LRU or not after > holding page lock could help serialize against hwpoison handler. > > But there is still a small race window between setting hwpoison flag and > bump refcount in hwpoison handler. It could be closed by checking > hwpoison flag in khugepaged, however this race seems unlikely to happen > in real life workload. So just check LRU flag for now to avoid > over-engineering. > > Signed-off-by: Yang Shi > --- > mm/khugepaged.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/mm/khugepaged.c b/mm/khugepaged.c > index 045cc579f724..bdc161dc27dc 100644 > --- a/mm/khugepaged.c > +++ b/mm/khugepaged.c > @@ -1808,6 +1808,12 @@ static void collapse_file(struct mm_struct *mm, > goto out_unlock; > } > > + /* The hwpoisoned page is off LRU but in page cache */ > + if (!PageLRU(page)) { > + result = SCAN_PAGE_LRU; > + goto out_unlock; > + } > + > if (isolate_lru_page(page)) { isolate_lru_page() should catch the case, no? TestClearPageLRU would fail and we get here. > result = SCAN_DEL_PAGE_LRU; > goto out_unlock; > -- > 2.26.2 > > -- Kirill A. Shutemov