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=-3.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 36683C433E2 for ; Wed, 9 Sep 2020 21:18:10 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A034121D46 for ; Wed, 9 Sep 2020 21:18:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="BXgwd7VW" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A034121D46 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D43FD6B005C; Wed, 9 Sep 2020 17:18:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CCFD18E0001; Wed, 9 Sep 2020 17:18:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B96256B0068; Wed, 9 Sep 2020 17:18:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 9F5136B005C for ; Wed, 9 Sep 2020 17:18:08 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 5FE8D3623 for ; Wed, 9 Sep 2020 21:18:08 +0000 (UTC) X-FDA: 77244785856.17.judge30_40096f8270e0 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin17.hostedemail.com (Postfix) with ESMTP id 38485180D0180 for ; Wed, 9 Sep 2020 21:18:08 +0000 (UTC) X-HE-Tag: judge30_40096f8270e0 X-Filterd-Recvd-Size: 6650 Received: from mail-il1-f193.google.com (mail-il1-f193.google.com [209.85.166.193]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Wed, 9 Sep 2020 21:18:07 +0000 (UTC) Received: by mail-il1-f193.google.com with SMTP id a8so3760194ilk.1 for ; Wed, 09 Sep 2020 14:18:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xnLzSOXwd9TzDajenlu2J/UiYOI35S3s5MuiwhlH4dw=; b=BXgwd7VW3D3nGXoWuK0FaTrkufYeUNak7/0+6RtcEnJ6W0bmLyQ8zDp5kSvnRkQRRl nQYVOIWQcjJGaJ03/x71oDgv3WVCi/AyxI3Ntb92FxAKYj+sZnd6Wyk4Ippt0GFEeH3b rmifuCEuadf0B5UcFG1ybSAa1DOzQv4RXqxnaoVmVTzo4ufsGEFMezNJIIuMaybQmwkC tSHyhp8b2IjekP3cWYiJTBdy5FZkMRALFIRoAhcBW7VxIPayqkS78WFqnnvZuNZ0tOFv EoBf//6JwwM7FPz3JvVbrPx028RKxbnau6F8bjFIDs0qEdOVMqiwFiR0NhDeittZt3Vs crPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xnLzSOXwd9TzDajenlu2J/UiYOI35S3s5MuiwhlH4dw=; b=cGXpuLXZ6fOgAOTLGzRXNlm9VQ3wHfuln3646DoSK0NFEAkSJtTD1LAWTr5R+Ob3it /wynfEGDlQaM3dTVns6CxaQWNiRiFp0+kUvuheEYP26kpSD+1K5FlFLxGTSiQ7YCOIyB 8chy4IGTQkUN8Kni0x3XyJTLS+rh8oHvoQsOSdCDHiCx0BGpDYjGNCLyYzuLt1hqjWoj 3KGhqU4i4ywiaT03zLsaiNpkKmMfv0elfZ9FdrRwUMXeKyjHn+J2YI+gTI4eNATr/Z3z cx/b/WpWTg2Fb3UhO/1A6BJhLDhwyqQdcUmKJRTZUXwWIzKGcteZhIkH8NghIxvtUTsC V/Ng== X-Gm-Message-State: AOAM533H6BW42YrlOker9Y7LEJSORXkJq9V+jVvLNwGJH7t0cUCttEJL nrMcg11AUhlgY9It+CkkmlDL1LjirweFzsH8JEw= X-Google-Smtp-Source: ABdhPJwDD9q+evydM5JmAavC1Zqt3CVOe19TZwOLeuyYz1KIvKPky3ySacOGEqLKS13x8QwzEJXnWJG0Hg6o41n7+Kk= X-Received: by 2002:a92:1a48:: with SMTP id z8mr5299188ill.95.1599686286899; Wed, 09 Sep 2020 14:18:06 -0700 (PDT) MIME-Version: 1.0 References: <1598273705-69124-1-git-send-email-alex.shi@linux.alibaba.com> <1598273705-69124-32-git-send-email-alex.shi@linux.alibaba.com> <20200909010118.GB6583@casper.infradead.org> In-Reply-To: From: Alexander Duyck Date: Wed, 9 Sep 2020 14:17:56 -0700 Message-ID: Subject: Re: [PATCH v18 31/32] mm: Add explicit page decrement in exception path for isolate_lru_pages To: Hugh Dickins Cc: Matthew Wilcox , Alex Shi , Andrew Morton , Mel Gorman , Tejun Heo , Konstantin Khlebnikov , Daniel Jordan , Johannes Weiner , kbuild test robot , linux-mm , LKML , cgroups@vger.kernel.org, Shakeel Butt , Joonsoo Kim , Wei Yang , "Kirill A. Shutemov" , Rong Chen , Michal Hocko , Vladimir Davydov , shy828301@gmail.com, Alexander Duyck Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 38485180D0180 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 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 9, 2020 at 11:24 AM Hugh Dickins wrote: > > On Wed, 9 Sep 2020, Alexander Duyck wrote: > > On Tue, Sep 8, 2020 at 6:01 PM Matthew Wilcox wrote: > > > On Mon, Aug 24, 2020 at 08:55:04PM +0800, Alex Shi wrote: > > > > +++ 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; > > > > > > I read Hugh's review and that led me to take a look at this. We don't > > > do it like this. Use the same pattern as elsewhere in mm: > > > > > > page_ref_sub(page, nr); > > > VM_BUG_ON_PAGE(page_count(page) <= 0, page); > > > > > > > > > > Actually for this case page_ref_dec(page) would make more sense > > wouldn't it? Otherwise I agree that would be a better change if that > > is the way it has been handled before. I just wasn't familiar with > > those other spots. > > After overnight reflection, my own preference would be simply to > drop this patch. I think we are making altogether too much of a > fuss here over what was simply correct as plain put_page() > (and further from correct if we change it to leak the page in an > unforeseen circumstance). > > And if Alex's comment was not quite grammatically correct, never mind, > it said as much as was worth saying. I got more worried by his > placement of the "busy:" label, but that does appear to work correctly. > > There's probably a thousand places where put_page() is used, where > it would be troublesome if it were the final put_page(): this one > bothered you because you'd been looking at isolate_migratepages_block(), > and its necessary avoidance of lru_lock recursion on put_page(); > but let's just just leave this put_page() as is. I'd be fine with that, but I would still like to see the comment updated. At a minimum we should make it clear that we believe that put_page is safe here as it should never reach zero and if it does then we are looking at a bug. Then if this starts triggering soft lockups we at least have documentation somewhere that someone can reference on what we expected and why we triggered a lockup. - Alex