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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1864CC433EF for ; Wed, 18 May 2022 18:41:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 876C56B0072; Wed, 18 May 2022 14:41:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 825516B0073; Wed, 18 May 2022 14:41:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6C6A36B0074; Wed, 18 May 2022 14:41:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 5DAB96B0072 for ; Wed, 18 May 2022 14:41:50 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 369A92089D for ; Wed, 18 May 2022 18:41:50 +0000 (UTC) X-FDA: 79479732780.10.C9C7C91 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf02.hostedemail.com (Postfix) with ESMTP id D4E2C800DC for ; Wed, 18 May 2022 18:41:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1652899309; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=U9iCHaSIHP1Sgf+5Eiwd7UGzvw1ix6eN0R9cXmzX7e8=; b=VZtyJLzSMv6IgTrtA7M9tvBPiM6ClsU6UHjCiBUsEODlcwYXAn0tchS0/m+wT0l2cQIh0n dIeOjYHKpbcJ0OX3KwLvRbkkG3gMzfl5CiMyNt3V4zfMrDEpIUtOVb0OJ/x1L1zeZnpXti WaFjKSaSUsJaWrTax44Y7PqICEQ+SBQ= Received: from mail-il1-f198.google.com (mail-il1-f198.google.com [209.85.166.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-8--TWSSmL7Oe2WzuRJ6LcB9Q-1; Wed, 18 May 2022 14:41:48 -0400 X-MC-Unique: -TWSSmL7Oe2WzuRJ6LcB9Q-1 Received: by mail-il1-f198.google.com with SMTP id n2-20020a056e021ba200b002d12462a1d1so1739569ili.15 for ; Wed, 18 May 2022 11:41:48 -0700 (PDT) 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=U9iCHaSIHP1Sgf+5Eiwd7UGzvw1ix6eN0R9cXmzX7e8=; b=vzCzDeW04vBYTIvqnBgsQiJQPNGjFhZx7IArlwxURapT3tz71l+3U4gIaeq2O093bW iSCxwiyEDBfbTGdSy5OwzgUOasV6Fh9jfcxoZjPFEPBSJcocNm9XG/Ss7virG/vdTv+B eOHGHBujrw227PpSTqvOWQyouiDe+gJwufSJsv++rjp/f+DZXDMcWs/JSziKnw8VDPuB VUoUrDYjLOCephpY7qn7PWVDyb2CE2ky54VBaydWZC0VrmIXNnYcvSpn3PGJbOig1xXs R0Zoz7iG9Rxrjnh/YHsXTiHTdB0PL5HmoRbQEI/za15rzdor2M5q77aqihOucQhkb2yV Uzfg== X-Gm-Message-State: AOAM533VOvyToMRe1Jnk6TE6kKdLEZXWWHx30riXq+1/SH47wVztK6DQ THMHxzeHGCP0tJmv0YF36GLtf4EaXEEd2aepcJ9n8oVs9qDZVuasYtV4sl07i/nAj28uar87Qkn NHhqysk24hWE= X-Received: by 2002:a05:6e02:1887:b0:2d1:28ca:82a with SMTP id o7-20020a056e02188700b002d128ca082amr620060ilu.304.1652899305884; Wed, 18 May 2022 11:41:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy+lFccIt/GAFV223N7xyWuuqap1TCdfbZPVG3eGAgpa1avAtM8bNuxF8wPsBwKAcO3guct8Q== X-Received: by 2002:a05:6e02:1887:b0:2d1:28ca:82a with SMTP id o7-20020a056e02188700b002d128ca082amr620032ilu.304.1652899305655; Wed, 18 May 2022 11:41:45 -0700 (PDT) Received: from xz-m1.local (cpec09435e3e0ee-cmc09435e3e0ec.cpe.net.cable.rogers.com. [99.241.198.116]) by smtp.gmail.com with ESMTPSA id z91-20020a0293e4000000b0032b3a781767sm73434jah.43.2022.05.18.11.41.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 May 2022 11:41:44 -0700 (PDT) Date: Wed, 18 May 2022 14:41:42 -0400 From: Peter Xu To: Zach O'Keefe Cc: Alex Shi , David Hildenbrand , David Rientjes , Matthew Wilcox , Michal Hocko , Pasha Tatashin , SeongJae Park , Song Liu , Vlastimil Babka , Yang Shi , Zi Yan , linux-mm@kvack.org, Andrea Arcangeli , Andrew Morton , Arnd Bergmann , Axel Rasmussen , Chris Kennelly , Chris Zankel , Helge Deller , Hugh Dickins , Ivan Kokshaysky , "James E.J. Bottomley" , Jens Axboe , "Kirill A. Shutemov" , Matt Turner , Max Filippov , Miaohe Lin , Minchan Kim , Patrick Xia , Pavel Begunkov , Thomas Bogendoerfer Subject: Re: [PATCH v5 01/13] mm/khugepaged: record SCAN_PMD_MAPPED when scan_pmd() finds THP Message-ID: References: <20220504214437.2850685-1-zokeefe@google.com> <20220504214437.2850685-2-zokeefe@google.com> MIME-Version: 1.0 In-Reply-To: <20220504214437.2850685-2-zokeefe@google.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Queue-Id: D4E2C800DC X-Stat-Signature: tuf79icnbn48wyk7cy9y3atnw1zo8iin X-Rspam-User: Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=VZtyJLzS; spf=none (imf02.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam09 X-HE-Tag: 1652899308-162700 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, May 04, 2022 at 02:44:25PM -0700, Zach O'Keefe wrote: > +static int find_pmd_or_thp_or_none(struct mm_struct *mm, > + unsigned long address, > + pmd_t **pmd) > +{ > + pmd_t pmde; > + > + *pmd = mm_find_pmd_raw(mm, address); > + if (!*pmd) > + return SCAN_PMD_NULL; > + > + pmde = pmd_read_atomic(*pmd); It seems to be correct on using the atomic fetcher here. Though irrelevant to this patchset.. does it also mean that we miss that on mm_find_pmd()? I meant a separate fix like this one: ---8<--- diff --git a/mm/rmap.c b/mm/rmap.c index 69416072b1a6..61309718640f 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -785,7 +785,7 @@ pmd_t *mm_find_pmd(struct mm_struct *mm, unsigned long address) * without holding anon_vma lock for write. So when looking for a * genuine pmde (in which to find pte), test present and !THP together. */ - pmde = *pmd; + pmde = pmd_read_atomic(pmd); barrier(); if (!pmd_present(pmde) || pmd_trans_huge(pmde)) pmd = NULL; ---8<--- As otherwise it seems it's also prone to PAE race conditions when reading pmd out, but I could be missing something. > + > +#ifdef CONFIG_TRANSPARENT_HUGEPAGE > + /* See comments in pmd_none_or_trans_huge_or_clear_bad() */ > + barrier(); > +#endif > + if (!pmd_present(pmde)) > + return SCAN_PMD_NULL; > + if (pmd_trans_huge(pmde)) > + return SCAN_PMD_MAPPED; Would it be safer to check pmd_bad()? I think not all mm pmd paths check that, frankly I don't really know what's the major cause of a bad pmd (either software bugs or corrupted mem), but just to check with you, because potentially a bad pmd can be read as SCAN_SUCCEED and go through. > + return SCAN_SUCCEED; > +} The rest looks good to me, thanks. -- Peter Xu