Received: by 2002:a05:6602:2086:0:0:0:0 with SMTP id a6csp4224411ioa; Tue, 26 Apr 2022 21:30:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwUz/E5sGhM/EMSj7/+AETS7r92a2uUFoSrNqOO1oFStbqCae6DvLmUnyZfKRHdHZKTp9TI X-Received: by 2002:a17:906:19c6:b0:6ce:98a4:5ee6 with SMTP id h6-20020a17090619c600b006ce98a45ee6mr24460470ejd.567.1651033805098; Tue, 26 Apr 2022 21:30:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651033805; cv=none; d=google.com; s=arc-20160816; b=NJOANdB4K4OM1k/xmfDmm+ZyygPnlTDTlQ7TpPwbFOPx58uFwm2Vm04Je3S63S1eDB hPS99YzKO4qooHfCqspcjtmrd6s0nrraP+RSJkO9lr+PUUEsXjJXYvq6tmpL7ieHRGzT qy5hab7LzH4tVx1o/vTOt1pi8pyyqB1eVhecm4y5LJ+Zl/uc7px6fqTcQbb6kU1tQinN 8PvlEI5DiUi2YbYC28672NZ4U1O8sXcVlbwKVztfgD3iaP9j03S7Eb+JF0qbxs/lNeNl u6THOaTU14IbnRbl2ZmKxP//jY10tiA0marWZrhEm5iyNW11sfyoC42BOIzmL61PcIHq iyBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=UXpWaaRmGnZjQpqeRY15jGRgaTNc7B1+ySXCFXyXBRI=; b=wUP/Etw1GRc8EXnmwQ4G3MC0DB1U0eMO6kK2RZoKcgGs/emqt/PlFtmyHtW1md4rdB 4yoKPZ+2QisQT4cfFQ0lDV3Db4KYdZU2mpZofo0AsodH+KycE0ZyfG+lxssbTPvVsD84 /z5s8YB9npegUoXmK0hRCt7MlXTnC9U90p5F7hhveEjaOKR1fdeDuqwKdlu57A/XmwK9 IggP1PW7pjSUK1XI0hSkPaCCH7CLFa8wXopY/qQTU1VKY1n3pLATlFwQi+TISMiO4Y1Q EyYC4wn4FWoOyMRgCoZgKfwoBKp4a+kdRaPrUWemIB+SEcZR2B8Y9AyPCWHw5027PDPg Kb3Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b="pybP3w/+"; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id wc10-20020a170907124a00b006f3a331b5bbsi197649ejb.391.2022.04.26.21.29.41; Tue, 26 Apr 2022 21:30:05 -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=@gmail.com header.s=20210112 header.b="pybP3w/+"; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237331AbiDZKUO (ORCPT + 99 others); Tue, 26 Apr 2022 06:20:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54056 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348825AbiDZKS4 (ORCPT ); Tue, 26 Apr 2022 06:18:56 -0400 Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E95CB7C797; Tue, 26 Apr 2022 02:43:07 -0700 (PDT) Received: by mail-ej1-x62f.google.com with SMTP id k23so34897008ejd.3; Tue, 26 Apr 2022 02:43:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=UXpWaaRmGnZjQpqeRY15jGRgaTNc7B1+ySXCFXyXBRI=; b=pybP3w/+N+OcgwzWtmwntk3lxR6h9mQ391PMJx2VTma/UT4L7sQGvKIgZ25XhHZEwH b+xKL6/wkW1eUkxtmMTtIs34tCpl/fZW6F/DVwZzi/X7gza46AZJUovBvXttWt/jiB9l IKm1CUAyKOJjyeNJ/N8PUuNGfBdRVn0dSAojBCCfZVlqccAPwPF+aJ3siKwpdNLG4Dsb bYy1OTRf9rcQj17LbRxxrAqd5hV5DNuDRq/MSj3xSkDg9G0+VH0ckcqa8iggTlTnMVPn kR3JFwfjeknjMqA9nkkNcDLywIPOnuJyHeDmLDTbPsFh2nQDTMXrMXJ4+Nj7Y5BRQJYq xARQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=UXpWaaRmGnZjQpqeRY15jGRgaTNc7B1+ySXCFXyXBRI=; b=kOi6G92Xwyl7Dd3ozUQ73GUBv2ktCI5aLm4uVEYybT9q+77X5qPuiiZeVj70h2OHNo yK58zRITpOyyqrsshp9CC+CmvV3GMx2R3x88fm0d/akY2L0gzYW5BmbQ4BuSuQ1LYlmf LQgw3GB9MZU6CgOybC4Nibxjy/mpmI9/FVwL17xtpzCWD+qntUMaltMvdyRpK82SZkNg 4zkVfmXQXYfazgk8n/cZq5ZmfDh36lWbOFcjorrEeq/NwlHL5xZX2q2XiK82m6O1iCq0 0bonLXUhTQbjrXebo8NHJ/HxU5LLDUfi19Mn/GjdtUDnVNsRUhPmdOsfgHW7k/kZtFNy Xmbw== X-Gm-Message-State: AOAM533emJl3d7h1w1uonEJrkwVRw7vsweqa6WK4SW/dO8/b30ZGuDSw uKuFddB+nqLCiQQ06Jk7b2Y= X-Received: by 2002:a17:906:5d04:b0:6db:7262:570e with SMTP id g4-20020a1709065d0400b006db7262570emr20578793ejt.8.1650966186345; Tue, 26 Apr 2022 02:43:06 -0700 (PDT) Received: from leap.localnet (host-79-50-86-254.retail.telecomitalia.it. [79.50.86.254]) by smtp.gmail.com with ESMTPSA id g16-20020a170906521000b006d58773e992sm4630221ejm.188.2022.04.26.02.43.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Apr 2022 02:43:05 -0700 (PDT) From: "Fabio M. De Francesco" To: Sebastian Andrzej Siewior Cc: Ira Weiny , Andrew Morton , Catalin Marinas , "Matthew Wilcox (Oracle)" , Will Deacon , Peter Collingbourne , Vlastimil Babka , linux-kernel@vger.kernel.org, Jonathan Corbet , linux-doc@vger.kernel.org, outreachy@lists.linux.dev, "Acked-by : Mike Rapoport" Subject: Re: [PATCH v2 1/4] mm/highmem: Fix kernel-doc warnings in highmem*.h Date: Tue, 26 Apr 2022 11:43:03 +0200 Message-ID: <4396926.LvFx2qVVIh@leap> In-Reply-To: References: <20220425162400.11334-1-fmdefrancesco@gmail.com> <20220425162400.11334-2-fmdefrancesco@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE 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 On marted=C3=AC 26 aprile 2022 09:01:32 CEST Sebastian Andrzej Siewior wrot= e: > On 2022-04-25 18:23:57 [+0200], Fabio M. De Francesco wrote: > > index a77be5630209..aa22daeed617 100644 > > --- a/include/linux/highmem-internal.h > > +++ b/include/linux/highmem-internal.h > > @@ -236,9 +236,17 @@ static inline unsigned long totalhigh_pages(void)= =20 { return 0UL; } > > =20 > > #endif /* CONFIG_HIGHMEM */ > > =20 > > -/* > > - * Prevent people trying to call kunmap_atomic() as if it were=20 kunmap() > > - * kunmap_atomic() should get the return value of kmap_atomic, not the= =20 page. > > +/** > > + * kunmap_atomic - Unmap the virtual address mapped by kmap_atomic() > > + * @__addr: Virtual address to be unmapped > > + * > > + * Unmaps an address previously mapped by kmap_atomic() and re-enables > > + * pagefaults and preemption. Mappings should be unmapped in the=20 reverse >=20 > You mind adding "Deprecated!" like kmap_atomic() has?=20 I might add "Deprecated!", however Ira Weiny asked me to rephrase an=20 earlier version of one of the patch which is is this series. I wrote that=20 "The use of kmap_atomic() is deprecated in favor of kmap_local_page()." and= =20 Ira replied "I'm not sure deprecated is the right word. [] This series=20 should end up indicating the desire to stop growing kmap() and kmap_atomic() call sites and that their deprecation is on the horizon.". What Ira suggested is exactly what I'm doing in v2.=20 @Ira: what about adding "Deprecated!" for consistency with kmap_atomic()=20 kdoc? > The part about > disabling/ enabling preemption is true for !PREEMPT_RT. To me it looks that this is not what Thomas Gleixner wrote in the cover=20 letter of his series ("[patch V2 00/18] mm/highmem: Preemptible variant of= =20 kmap_atomic & friends") at=20 https://lore.kernel.org/lkml/20201029221806.189523375@linutronix.de/ =46or your convenience: "[] there is not a real reason anymore to confine migration disabling to=20 RT. [] Removing the RT dependency from migrate_disable/enable()". Is there anything I'm still missing? > The part that > worries me is that people use it and rely on disabled preemption like > some did in the past.=20 This is something I'd prefer to hear also from other developers who are=20 CC'ed for this patch :)=20 > I've been told this API is about to be removed (or so I have been told) > so I hope that it will be gone soon ;) >=20 > > + * order that they were mapped. See kmap_local_page() for details. > > + * @__addr can be any address within the mapped page, so there is no=20 need > > + * to subtract any offset that has been added. In contrast to=20 kunmap(), > > + * this function takes the address returned from kmap_atomic(), not=20 the > > + * page passed to it. The compiler will warn you if you pass the page. > > */ > > #define kunmap_atomic(__addr) =09 \ > > do { =09 \ >=20 > Sebastian >=20 Thanks for your review, =46abio