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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F2A3AC433EF for ; Tue, 16 Nov 2021 14:31:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 760A361BF5 for ; Tue, 16 Nov 2021 14:31:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 760A361BF5 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 0C8916B0082; Tue, 16 Nov 2021 09:31:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 077EA6B0083; Tue, 16 Nov 2021 09:31:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E826B6B0085; Tue, 16 Nov 2021 09:31:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0115.hostedemail.com [216.40.44.115]) by kanga.kvack.org (Postfix) with ESMTP id DC8006B0082 for ; Tue, 16 Nov 2021 09:31:12 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 96FDC88494 for ; Tue, 16 Nov 2021 14:31:12 +0000 (UTC) X-FDA: 78815030826.10.059C17A Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf13.hostedemail.com (Postfix) with ESMTP id 71268106B7E2 for ; Tue, 16 Nov 2021 14:29:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=dl8IoZ6MAGLIhgXEhnN0d3xfaeoF2eUenAyR+CVzOrM=; b=PgGOieImMeqalQ4+tNzV9/H78n eJzGvN9GdWYZ1Dbs3j144iAMAU4UtAQp2sVGa/h8k9heFdjnUaqO2i+lHTyqjiDzI40+t+Fw/OQ2n QojiZB7vf/UvEdg9vekzbiXdVVxPL6f/QzUPejW0Bgnj3PqrR/yrg+Wq+BSEnSfWSv4a1HzmEpXze myb7o4IR5blpM7gbdyRrn8wZEolPt5ov4wCO8hmnSH62xMl0wttWziM+th+oDkDnqShb3v9D5nJIZ W4g42cj8I/5G4Mw6k/au6S5nwIpmXysx+5C2i5UV3ftYFikbGbXiyoEv78XrCL8G40qJF+hQScGFg HQVKoJJg==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mmyEw-006lgt-Js; Tue, 16 Nov 2021 13:11:10 +0000 Date: Tue, 16 Nov 2021 13:11:10 +0000 From: Matthew Wilcox To: John Hubbard Cc: Peter Xu , linux-kernel@vger.kernel.org, linux-mm@kvack.org, David Hildenbrand , Andrea Arcangeli , Yang Shi , Vlastimil Babka , Hugh Dickins , Andrew Morton , Alistair Popple , "Kirill A . Shutemov" Subject: Re: [PATCH RFC v2 2/2] mm: Rework swap handling of zap_pte_range Message-ID: References: <20211115134951.85286-1-peterx@redhat.com> <20211115134951.85286-3-peterx@redhat.com> <8a5e44aa-243f-3a9d-e917-09cd3cf6609a@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8a5e44aa-243f-3a9d-e917-09cd3cf6609a@nvidia.com> X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 71268106B7E2 X-Stat-Signature: 136m7iuhutob43nu11eei6pbf5ncxpo7 Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=PgGOieIm; spf=none (imf13.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-HE-Tag: 1637072950-899427 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 Tue, Nov 16, 2021 at 12:51:13AM -0800, John Hubbard wrote: > On 11/15/21 05:57, Matthew Wilcox wrote: > > On Mon, Nov 15, 2021 at 09:49:51PM +0800, Peter Xu wrote: > > > Clean the code up by merging the device private/exclusive swap entry handling > > > with the rest, then we merge the pte clear operation too. > > > > > > struct* page is defined in multiple places in the function, move it upward. > > > > Is that actually a good thing? There was a time when declaring > > Yes. It is a very good thing. Having multiple cases of shadowed variables > (in this case I'm using programming language terminology, or what I > remember it as, anyway) provides lots of opportunities to create > hard-to-spot bugs. I think you're misremembering. These are shadowed variables: int a; int b(void) { int a; if (c) { int a; } } This is not: int b(void) { if (c) { int a; } else { int a; } } I really wish we could turn on -Wshadow, but we get compilation warnings from header files right now. Or we did last time I checked.