Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp2122988pxa; Mon, 24 Aug 2020 06:00:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx6vysA883QJ5nLFUri8iyGb697ZF4+ZcOUfTUMjb6L8ldK5ghNxdttIdvtf9M6yZuVfrRm X-Received: by 2002:a17:906:a3d6:: with SMTP id ca22mr5362438ejb.78.1598274040246; Mon, 24 Aug 2020 06:00:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598274040; cv=none; d=google.com; s=arc-20160816; b=IdTl1/KOxMjcs9PtVyNNvFNWmebsiEgSv1ABAhPbQsCgEQEhL50lV/SJTsYKjUum00 s839SfZ2dxwpNb7vVd/r6TFPACzc82VwrGtA8qabyB6sWT1ieDUO1I8s2AoWGLlzFQKx 1bX+3aubdXG0V2BUm1oH5MkbI5x/0M1v27Fr+yKLL6itn9I7uhfT8DGFLN3YvgeX4DAV AbhR0tiy8jEnlYz9Y5oMMY2gFuN0AnYsbk/vjaImKhYSQ+58hdXhqARLEy1+/NTgLkn4 5UzW2cMuHkmsIZ3UuLqOpoqw60lbh6zBHPG/hK9IjFSBr8iNLU17moDRts2pHNTzUH2p lq/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=3VRHsyHMrtoqyDJdhpXmwMzqOR7lpiCvokDLSPjN2o0=; b=hu5SUnJw30YCdtSYbmLpHAXmVy9keEEph7yob8rv6iRBTzwvogogAus1kD02ltvYWz QUrnw1PmWU6+3Own8MvqFzk3BhFJGq/UM9pr1E9LzZ+PwaKVUH8GHG36SmywOwg3xA8J 3rgZcPXpguyyMzYg3UFC9ZkOC9lfRuFdk3gMuIMLGhJMGR2LcGig8ZcA7iZ0qMJhSze1 nyuRB6uLoMs31K1r0X7qndqZCYtfpEeRK02+ZXNnYkZQXjKjZkhk8tFTQDvDSYKcgpWn ygsaKzBVGcH7toZXitfIVc8bP3nRFE5055nfAWvhfHJXKhsD3hvelILTA0GAMIz92FC+ xmPQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y11si7254987edm.191.2020.08.24.06.00.17; Mon, 24 Aug 2020 06:00:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728024AbgHXM4y (ORCPT + 99 others); Mon, 24 Aug 2020 08:56:54 -0400 Received: from out30-132.freemail.mail.aliyun.com ([115.124.30.132]:39478 "EHLO out30-132.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727841AbgHXMzd (ORCPT ); Mon, 24 Aug 2020 08:55:33 -0400 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> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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