Received: by 2002:ac0:da4c:0:0:0:0:0 with SMTP id a12csp29541imi; Thu, 21 Jul 2022 15:14:49 -0700 (PDT) X-Google-Smtp-Source: AGRyM1te6lx+48XchBwtrraffqZ6mTRpFqw6gosRKzmX/UX/1GNVDpvO+XG2V8Uqv0s8Wvc7vNuw X-Received: by 2002:a17:907:6092:b0:72f:575:722d with SMTP id ht18-20020a170907609200b0072f0575722dmr599782ejc.19.1658441689596; Thu, 21 Jul 2022 15:14:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658441689; cv=none; d=google.com; s=arc-20160816; b=mTyDlQC+SfxjOfU428haFnJ2n0vre9QYf8j9eA5K8HU39GeRKx8t4MGSbWAWUeRSKX ZUd2nSSC7fMkFxnLJM3jgzCiGzTflMmsfwJOwHiBS2sGlHaLLa8Re2glFUIC7+s7lFzk mU/6JigFn3I7+iGlg2KBj7B4K5kbunzktvOeDOHGlWnrCSCI5YLUE+19l5P0szv3jMpU bDSyLXIDQBiWJo4Yf9YXG9o1KV3TF9ooU2rNeJLRxZbild7W4ucpTW0o44RDDCrLfM3R UKO7TwLV7AmxGnSjc19JoVdvtm1CrZuEe0CoXSv1PKrnpIGJEFLuPqLk9LiYcxwztvtc hZbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:dkim-signature:dkim-filter; bh=A/45P4qm24EYhkCZPmUzYfgAKicEoO+XAjAAD6wsy54=; b=znr9cfuThC9rqb+Cio0GMAa+mHFy/RvtMPK5ZjnNipEedF6mNKmIAhAMy2k+IIWRC1 rzJhbEocJ30G+wtQqbbwaLMqsfXrB3MavNp8l0p1fkBpsm1AldnsNgALP8E5q/CfmGKP ouV+OO/Oqe7qSOQCiK5poumBA+moEpvzFFzzcvJu2Z71h7CK0Ag4qYiATsVI5Zu+7s8o cC7VWfjsnIpztTc2+y2TMjOg4JgUOiUeuBt/Zq1da6KtdRlp4uVFBx4GKddmvMYIpJ/b 2fPhfPbgrC1OFVx5T18uPE1dVbHm6wHUFeXZUY/DNNYRE7zT33vo3it61dtVBUOCP+6k nzKA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lwn.net header.s=20201203 header.b=LKAzyduD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sd6-20020a170906ce2600b0072b3a3dfbb7si3137441ejb.887.2022.07.21.15.14.23; Thu, 21 Jul 2022 15:14:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@lwn.net header.s=20201203 header.b=LKAzyduD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233530AbiGUVNE (ORCPT + 99 others); Thu, 21 Jul 2022 17:13:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60926 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229472AbiGUVND (ORCPT ); Thu, 21 Jul 2022 17:13:03 -0400 Received: from ms.lwn.net (ms.lwn.net [45.79.88.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5260F4E61D; Thu, 21 Jul 2022 14:13:01 -0700 (PDT) Received: from localhost (unknown [IPv6:2601:281:8300:73::5f6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ms.lwn.net (Postfix) with ESMTPSA id A6DDB6D9; Thu, 21 Jul 2022 21:13:00 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 ms.lwn.net A6DDB6D9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lwn.net; s=20201203; t=1658437980; bh=A/45P4qm24EYhkCZPmUzYfgAKicEoO+XAjAAD6wsy54=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=LKAzyduD57zhWdrHjbl/08ggRiW0DJJ74HGrZBsBSgkQAAQGO/Z8rckxN5B/J73pD BNNXDRZltmJp7lnEYN/69uKuG0QoIUnaqvlm6AjHNTVZty2SBgHYrKq8bODNoyunHn 2iiVemdhPyaDt5BYUqJB8Sr6FhxIb41ZkHeo99XLEK/i5j4DrNvhImOlwMLf1n/Vel VFhImekkYi7ZDTPxsERfxR2E2n19qtOeOpA66iHTRZxZbcxr0sT5bpU3lzVII5jJDg 3lDWLZeQ/F9KBEdS+AxlrpccFVJQf/cuw44u4c0IEG2q1ajGrGbOfBlTV2aHvPaOgP w7oWUNhzopvTw== From: Jonathan Corbet To: "Fabio M. De Francesco" , Ira Weiny , Andrew Morton , Catalin Marinas , "Matthew Wilcox (Oracle)" , Will Deacon , Peter Collingbourne , Vlastimil Babka , Sebastian Andrzej Siewior , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org Cc: "Fabio M. De Francesco" , Mike Rapoport , Thomas Gleixner Subject: Re: [PATCH 3/7] Documentation/mm: Don't kmap*() pages which can't come from HIGHMEM In-Reply-To: <20220721210206.13774-4-fmdefrancesco@gmail.com> References: <20220721210206.13774-1-fmdefrancesco@gmail.com> <20220721210206.13774-4-fmdefrancesco@gmail.com> Date: Thu, 21 Jul 2022 15:13:00 -0600 Message-ID: <87czdykw4j.fsf@meer.lwn.net> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org "Fabio M. De Francesco" writes: > There is no need to kmap*() pages which are guaranteed to come from > ZONE_NORMAL (or lower). Linux has currently several call sites of > kmap{,_atomic,_local_page}() on pages allocated, for instance, with > alloc_page(GFP_NOFS) and other similar allocations. > > Therefore, add a paragraph to highmem.rst, to explain better that a > plain page_address() should be used for getting the address of pages > which cannot come from ZONE_HIGHMEM. > > Cc: Andrew Morton > Cc: Matthew Wilcox (Oracle) > Cc: Mike Rapoport > Cc: Sebastian Andrzej Siewior > Cc: Thomas Gleixner > Suggested-by: Ira Weiny > Signed-off-by: Fabio M. De Francesco > --- > Documentation/vm/highmem.rst | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/vm/highmem.rst b/Documentation/vm/highmem.rst > index c9887f241c6c..f266354c82ab 100644 > --- a/Documentation/vm/highmem.rst > +++ b/Documentation/vm/highmem.rst > @@ -71,6 +71,12 @@ list shows them in order of preference of use. > kmap_local_page() always returns a valid virtual address and it is assumed > that kunmap_local() will never fail. > > + On CONFIG_HIGHMEM=n kernels and for low memory pages this returns the > + virtual address of the direct mapping. Only real highmem pages are > + temporarily mapped. Therefore, users should instead call a plain > + page_address() for getting the address of memory pages which, depending > + on the GFP_* flags, cannot come from ZONE_HIGHMEM. > + Is this good advice? First, it requires developers to worry about whether their pages might be in highmem, which is kind of like worrying about having coins in your pocket in case you need a payphone. But it would also run afoul of other semantics for kmap*(), such as PKS, should that ever be merged: https://lwn.net/Articles/894531/ Thanks, jon