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=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 B361EC4332D for ; Fri, 20 Mar 2020 11:45:38 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4944A20732 for ; Fri, 20 Mar 2020 11:45:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=shutemov-name.20150623.gappssmtp.com header.i=@shutemov-name.20150623.gappssmtp.com header.b="nFFjlvQ7" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4944A20732 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=shutemov.name Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 801616B0003; Fri, 20 Mar 2020 07:45:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 78B326B0006; Fri, 20 Mar 2020 07:45:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6552B6B0007; Fri, 20 Mar 2020 07:45:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0120.hostedemail.com [216.40.44.120]) by kanga.kvack.org (Postfix) with ESMTP id 4AE9E6B0003 for ; Fri, 20 Mar 2020 07:45:37 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id F3A4952DD for ; Fri, 20 Mar 2020 11:45:36 +0000 (UTC) X-FDA: 76615560672.19.train30_6b2f089aef80b X-HE-Tag: train30_6b2f089aef80b X-Filterd-Recvd-Size: 7175 Received: from mail-lf1-f68.google.com (mail-lf1-f68.google.com [209.85.167.68]) by imf39.hostedemail.com (Postfix) with ESMTP for ; Fri, 20 Mar 2020 11:45:36 +0000 (UTC) Received: by mail-lf1-f68.google.com with SMTP id j188so411713lfj.11 for ; Fri, 20 Mar 2020 04:45:36 -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:content-transfer-encoding:in-reply-to; bh=pWbPjHYC+o2SW9jmTmeqllECnseGArz1efl29XkdYuY=; b=nFFjlvQ7pQEp2l9CFv+38pFxZZwmMMuZTaolsXZt4iZiwpWJJkoI0hFQUCj8zuNv6D suZ783bs6HKFp3AGVaSz7/wsX8WqMMM8C5RePhwhX/atSbqb64pyD5RNsh5UuwllVx3k 8N7bztTPxMqls2wtBZT+9htJH0kF6FLzugXlNheJXjQgEqBMkyik0HwbWqt6vC+iMFz6 jnz7Or8rFFHtd/4ItqK+52y6E9vKLgADOB7xktp6XKfN+op5SzLCnDbpqvOWe8jG+6UW i5JI+Zia6qoO3Seka0lUYfqx6kw5nsn3dmHX4FLKSXY+ueVLq55HiGsfqF3m6gX/fAG1 fKTA== 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:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=pWbPjHYC+o2SW9jmTmeqllECnseGArz1efl29XkdYuY=; b=HDD2PH/fpMQJY/BXYhLfP2VwOGcGPdfHuL4MMwEtJHRAx2nYEzt0d0hZtNpnpDBhRL tMLNeH5kNjpKOYYHaPKxCDhKp3sgxcAYoWAH6C3VwudqFCiWi+kDzkBzi3awejom0qmi wTm/EFoXTFt5IP92UkHLMW7xD93D3A2tTPQUU6xmbUtzhPYlgEy52EvCANaN9/rvkIwz ZPTBsSYJuYpKo1UQ4NV2UFRu2+XdzjOXr3au1auUCvMcUdVr4cQvB/MT0ztoAini+503 RD3KzSa5Q6yZgsr0UrRdXqgH2c/6qmBfEh5YVbJ2vgOWij1HnIj1FjgZriDqjko+zv0G OLdA== X-Gm-Message-State: ANhLgQ3VQ589DkbowRj7hDVPlygPH8MGWigiRja87drV1iJRjiYHZ5vs KOqvvIjoKq3qEpS2G9YK+LOoxg== X-Google-Smtp-Source: ADFU+vsVfDBHgLfeD0LZC7cAqByG7wtuUVuzjaAYMXDUbwY/wS+RQ4hVLw2jNExdjkagIYFhP8aN0A== X-Received: by 2002:ac2:59c6:: with SMTP id x6mr5155659lfn.177.1584704734826; Fri, 20 Mar 2020 04:45:34 -0700 (PDT) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id u10sm3211342ljk.56.2020.03.20.04.45.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Mar 2020 04:45:33 -0700 (PDT) Received: by box.localdomain (Postfix, from userid 1000) id CC2231020EE; Fri, 20 Mar 2020 14:45:36 +0300 (+03) Date: Fri, 20 Mar 2020 14:45:36 +0300 From: "Kirill A. Shutemov" To: Yang Shi Cc: kirill.shutemov@linux.intel.com, hughd@google.com, aarcange@redhat.com, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: khugepaged: fix potential page state corruption Message-ID: <20200320114536.brigxjkgjmxyhdu5@box> References: <1584573582-116702-1-git-send-email-yang.shi@linux.alibaba.com> <20200319001258.creziw6ffw4jvwl3@box> <2cdc734c-c222-4b9d-9114-1762b29dafb4@linux.alibaba.com> <20200319104938.vphyajoyz6ob6jtl@box> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: quoted-printable 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, Mar 19, 2020 at 09:57:47AM -0700, Yang Shi wrote: >=20 >=20 > On 3/19/20 3:49 AM, Kirill A. Shutemov wrote: > > On Wed, Mar 18, 2020 at 10:39:21PM -0700, Yang Shi wrote: > > >=20 > > > On 3/18/20 5:55 PM, Yang Shi wrote: > > > >=20 > > > > On 3/18/20 5:12 PM, Kirill A. Shutemov wrote: > > > > > On Thu, Mar 19, 2020 at 07:19:42AM +0800, Yang Shi wrote: > > > > > > When khugepaged collapses anonymous pages, the base pages wou= ld > > > > > > be freed > > > > > > via pagevec or free_page_and_swap_cache().=A0 But, the anonym= ous page may > > > > > > be added back to LRU, then it might result in the below race: > > > > > >=20 > > > > > > =A0=A0=A0=A0CPU A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= CPU B > > > > > > khugepaged: > > > > > > =A0=A0 unlock page > > > > > > =A0=A0 putback_lru_page > > > > > > =A0=A0=A0=A0 add to lru > > > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 page reclaim: > > > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 isolate = this page > > > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 try_to_u= nmap > > > > > > =A0=A0 page_remove_rmap <-- corrupt _mapcount > > > > > >=20 > > > > > > It looks nothing would prevent the pages from isolating by re= claimer. > > > > > Hm. Why should it? > > > > >=20 > > > > > try_to_unmap() doesn't exclude parallel page unmapping. _mapcou= nt is > > > > > protected by ptl. And this particular _mapcount pin is reachabl= e for > > > > > reclaim as it's not part of usual page table tree. Basically > > > > > try_to_unmap() will never succeeds until we give up the _mapcou= nt on > > > > > khugepaged side. > > > > I don't quite get. What does "not part of usual page table tree" = means? > > > >=20 > > > > How's about try_to_unmap() acquires ptl before khugepaged? > > The page table we are dealing with was detached from the process' pag= e > > table tree: see pmdp_collapse_flush(). try_to_unmap() will not see th= e > > pte. > >=20 > > try_to_unmap() can only reach the ptl if split ptl is disabled > > (mm->page_table_lock is used), but it still will not be able to reach= pte. >=20 > Aha, got it. Thanks for explaining. I definitely missed this point. Yes= , > pmdp_collapse_flush() would clear the pmd, then others won't see the pa= ge > table. >=20 > However, it looks the vmscan would not stop at try_to_unmap() at all, > try_to_unmap() would just return true since pmd_present() should return > false in pvmw. Then it would go all the way down to __remove_mapping(),= but > freezing the page would fail since try_to_unmap() doesn't actually drop= the > refcount from the pte map. No. try_to_unmap() checks mapcount at the end and only returns true if it's zero. > It would not result in any critical problem AFAICT, but suboptimal and = it > may causes some unnecessary I/O due to swap. >=20 > >=20 > > > > > I don't see the issue right away. > > > > >=20 > > > > > > The other problem is the page's active or unevictable flag mi= ght be > > > > > > still set when freeing the page via free_page_and_swap_cache(= ). > > > > > So what? > > > > The flags may leak to page free path then kernel may complain if > > > > DEBUG_VM is set. > > Could you elaborate on what codepath you are talking about? >=20 > __put_page -> > =A0=A0=A0 __put_single_page -> > =A0=A0=A0 =A0=A0=A0 free_unref_page -> > =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 put_unref_page_prepare -> > =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 free_pcp_prepare -> > =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 free_pages_prepare -> > =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 free_pages_= check >=20 > This check would just be run when DEBUG_VM is enabled. I'm not 100% sure, but I belive these flags will ge cleared on adding int= o lru: release_pte_page() putback_lru_page() lru_cache_add() __lru_cache_add() __pagevec_lru_add() __pagevec_lru_add_fn() __pagevec_lru_add_fn() --=20 Kirill A. Shutemov