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.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_GIT 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 68DBFC433E1 for ; Mon, 24 Aug 2020 12:56:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 32A5B20706 for ; Mon, 24 Aug 2020 12:56:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 32A5B20706 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 902EF8D0011; Mon, 24 Aug 2020 08:55:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 88D128D000D; Mon, 24 Aug 2020 08:55:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 77FD68D0011; Mon, 24 Aug 2020 08:55:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0081.hostedemail.com [216.40.44.81]) by kanga.kvack.org (Postfix) with ESMTP id 5AEF98D000D for ; Mon, 24 Aug 2020 08:55:34 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 195A2180AD817 for ; Mon, 24 Aug 2020 12:55:34 +0000 (UTC) X-FDA: 77185458588.17.rifle40_4113f5a27053 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin17.hostedemail.com (Postfix) with ESMTP id D73D4180D0180 for ; Mon, 24 Aug 2020 12:55:33 +0000 (UTC) X-HE-Tag: rifle40_4113f5a27053 X-Filterd-Recvd-Size: 3376 Received: from out30-45.freemail.mail.aliyun.com (out30-45.freemail.mail.aliyun.com [115.124.30.45]) by imf38.hostedemail.com (Postfix) with ESMTP for ; Mon, 24 Aug 2020 12:55:32 +0000 (UTC) X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R191e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e01353;MF=alex.shi@linux.alibaba.com;NM=1;PH=DS;RN=22;SR=0;TI=SMTPD_---0U6k9-bl_1598273712; Received: from aliy80.localdomain(mailfrom:alex.shi@linux.alibaba.com fp:SMTPD_---0U6k9-bl_1598273712) by smtp.aliyun-inc.com(127.0.0.1); Mon, 24 Aug 2020 20:55:24 +0800 From: Alex Shi To: akpm@linux-foundation.org, mgorman@techsingularity.net, tj@kernel.org, hughd@google.com, khlebnikov@yandex-team.ru, daniel.m.jordan@oracle.com, willy@infradead.org, hannes@cmpxchg.org, lkp@intel.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, shakeelb@google.com, iamjoonsoo.kim@lge.com, richard.weiyang@gmail.com, kirill@shutemov.name, alexander.duyck@gmail.com, rong.a.chen@intel.com, mhocko@suse.com, vdavydov.dev@gmail.com, shy828301@gmail.com Cc: Alexander Duyck Subject: [PATCH v18 31/32] mm: Add explicit page decrement in exception path for isolate_lru_pages Date: Mon, 24 Aug 2020 20:55:04 +0800 Message-Id: <1598273705-69124-32-git-send-email-alex.shi@linux.alibaba.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1598273705-69124-1-git-send-email-alex.shi@linux.alibaba.com> References: <1598273705-69124-1-git-send-email-alex.shi@linux.alibaba.com> X-Rspamd-Queue-Id: D73D4180D0180 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 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: From: Alexander Duyck In isolate_lru_pages we have an exception path where if we call get_page_unless_zero and that succeeds, but TestClearPageLRU fails we call put_page. Normally this would be problematic but due to the way that the calls are ordered and the fact that we are holding the LRU lock we know that the caller must be holding another reference for the page. Since we can assume that we can replace the put_page with a call to put_page_testzero contained within a WARN_ON. By doing this we should see if we ever leak a page as a result of the reference count somehow hitting zero when it shouldn't, and can avoid the overhead and confusion of using the full put_page call. Signed-off-by: Alexander Duyck Signed-off-by: Alex Shi Cc: Andrew Morton Cc: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org --- mm/vmscan.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index 601fbcb994fb..604240303ea2 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1688,10 +1688,13 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, if (!TestClearPageLRU(page)) { /* - * This page may in other isolation path, - * but we still hold lru_lock. + * This page is being isolated in another + * thread, but we still hold lru_lock. The + * other thread must be holding a reference + * to the page so this should never hit a + * reference count of 0. */ - put_page(page); + WARN_ON(put_page_testzero(page)); goto busy; } -- 1.8.3.1