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.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 68C9FC433F5 for ; Wed, 15 Sep 2021 17:48:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1363D611CA for ; Wed, 15 Sep 2021 17:48:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1363D611CA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 45D56900002; Wed, 15 Sep 2021 13:48:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 40CAE6B0072; Wed, 15 Sep 2021 13:48:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 32436900002; Wed, 15 Sep 2021 13:48:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0052.hostedemail.com [216.40.44.52]) by kanga.kvack.org (Postfix) with ESMTP id 2399F6B0071 for ; Wed, 15 Sep 2021 13:48:29 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id C561D181C9670 for ; Wed, 15 Sep 2021 17:48:28 +0000 (UTC) X-FDA: 78590542296.22.9E7B089 Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by imf29.hostedemail.com (Postfix) with ESMTP id 8C8C49000163 for ; Wed, 15 Sep 2021 17:48:28 +0000 (UTC) Received: by mail-ed1-f41.google.com with SMTP id v5so6511745edc.2 for ; Wed, 15 Sep 2021 10:48:28 -0700 (PDT) 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=aUutvbwT+ImtyWQ/R4PZfCaPNu83uCoI/leGQrb46ts=; b=I3I/U/NyzLP3yFWBxVWrBHFbyqaxPdxCb8peY1C7jxRnsB3zaIdcFd0G0ax8uHHLSg Wh07Q+v5zhISaPdAvnMcMo8suNiSnQgsZqkdJ5YWTrluY3cZVrjxt2+/EvYq5+NLoxdC Dno0yngof71yCYbPMuqIlhTGHWWUVdy7amp2Se7R6BV+5/WWoTVQ+umNQT1pOAPSlN7t BsPoFoHF3FbBuhWUufXysW+vWeyxkjVRBpeDbxjFXUhG1moyLIuWnfXns/lj1OFTCKXP 3SFLGRhGqaGPO6q3ljF3rxki5uQWP7NHH47MXpLMBeAKQBXt6+hgPKyxqm0Y/NQl8QWm ubAA== 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=aUutvbwT+ImtyWQ/R4PZfCaPNu83uCoI/leGQrb46ts=; b=5r80pjnsNWJttx/2px7SJZqLK3j/Ybg3ELv2oG41m7y+MdkBK/lPc3PLncrc846cvM tEk4RiYYP6r7t8x6Bbe5UYCvBMkiP7TYT+lIfxxfSSx+pO/nO8ZVpgQx4aEv/ehez8QB v9VFscqXO8h7KFRgcIHyA6mQFnn8D+jkLG3jmAy5neRQhDPa5mzTKbwf533UL+stZoHI y0JtbqDShDI7irC2opS0Zfj+ozmI/+5mRPv/ooRJvJzF4z/dGFUEg6LJDCN+mOgK2ooG cIln9r2QoNNheRwMkaxf3zEtWSlUHo6f85p1MoKystmLRdrKUi5/d7o9wlaXCR5U3XFI VtKw== X-Gm-Message-State: AOAM533wv8XLgSTKr4yytU3S1eUqq/AB6hVv0+/s21nYWRbl5kaSoJzO NqYII1bvofXZrvZ2FpwQnijgnR1Znw/6KtHeawo= X-Google-Smtp-Source: ABdhPJyy6f9Q3pSMERBs4nQGD6A6iXjhxlJuqh1C/eP3fH6JCxRs0swIVnvjOlH1UirN3P/elCitiV2PY7WPHwfdXqc= X-Received: by 2002:a17:906:680c:: with SMTP id k12mr1314252ejr.85.1631728107020; Wed, 15 Sep 2021 10:48:27 -0700 (PDT) MIME-Version: 1.0 References: <20210914183718.4236-1-shy828301@gmail.com> <20210914183718.4236-3-shy828301@gmail.com> <20210915114947.2zh7inouztenth6o@box.shutemov.name> In-Reply-To: <20210915114947.2zh7inouztenth6o@box.shutemov.name> From: Yang Shi Date: Wed, 15 Sep 2021 10:48:15 -0700 Message-ID: Subject: Re: [PATCH 2/4] mm: khugepaged: check if file page is on LRU after locking page To: "Kirill A. Shutemov" Cc: =?UTF-8?B?SE9SSUdVQ0hJIE5BT1lBKOWggOWPoyDnm7TkuZ8p?= , Hugh Dickins , "Kirill A. Shutemov" , Matthew Wilcox , Oscar Salvador , Andrew Morton , Linux MM , Linux FS-devel Mailing List , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 8C8C49000163 Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="I3I/U/Ny"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf29.hostedemail.com: domain of shy828301@gmail.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=shy828301@gmail.com X-Stat-Signature: uabosktqnhfpmkzi1sghduyeqc1gasye X-HE-Tag: 1631728108-34058 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 15, 2021 at 4:49 AM Kirill A. Shutemov wrote: > > 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. Hmm... you are definitely right. How could I miss this point. It might be because of I messed up the page state by some tests which may do hole punch then reread the same index. That could drop the poisoned page then collapse succeed. But I'm not sure. Anyway I didn't figure out how the poisoned page could be collapsed. It seems impossible. I will drop this patch. > > > result = SCAN_DEL_PAGE_LRU; > > goto out_unlock; > > -- > > 2.26.2 > > > > > > -- > Kirill A. Shutemov