Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp7965421rwb; Tue, 6 Dec 2022 12:08:19 -0800 (PST) X-Google-Smtp-Source: AA0mqf5iFYcbpZGkAiQsZIdriU86FaX0J3+69vp3+bqmEyXdekl4gQB52qnK8Nnhilnn0r5MRBLf X-Received: by 2002:a63:dd43:0:b0:45c:5a74:9a92 with SMTP id g3-20020a63dd43000000b0045c5a749a92mr62982275pgj.473.1670357298705; Tue, 06 Dec 2022 12:08:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670357298; cv=none; d=google.com; s=arc-20160816; b=qtpecawE3ZcLtyMSacjTt15V/ahWmML39xRAvsjSVTOv+ooAA/XAN40zsIF82xTwri b/CzMQV38ygg3GPAbIVvtTkdVXmo9Zle+kOqtk0AT9cZzlEhtapOQxGvjoxWlOsKmAXI 3Du4AZdkCbeI1dT7emeNnDDb65eQn/Q6P2tMSKLkGSDR3IgyMy5glCHGcFm5QHEmEele vrpSdoqFfhfsuxbPUniOnKII648TZK6Rz/Husc1hYsDT9do91uxUeK4n3JBad2Yy4cdU ac4puGbFMhZ2MzY7jCGDS9qYtbOPUlkC/LvdsuoYso67CC4rQWIYZj66I/vH6yN3sZEJ 6knw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=IfFKOBr66s1CwYSG2TTOFX37oTDo5VCSWbNTI8/Kwv4=; b=JJUgwYzOS7ZG8FCUj73N4MMWxFPZZDtWdC1kNhKAtyR2CcY7bHkneg1wjE6rE7MXP2 ZWQU33xWWWDJbK4fPIozBokvRpXFnerO420anKGekI4+7tHCy3KUKHafVVMdJy7al7tG H1fkO+o1qyiSkCwW9jxnIEJVaxZ9Qa1AfNbBGa02TtDKIv28ykB3W3Hp3Fcm5hIA3T3+ b8lS9dXR0af3JME/RNEdFIdcDkjQgD2LjHhLLqIF9ZAiRaxCaOaK2ChRc2aOEhVjk/bv Ino/4OD+OwzkXeu0WQBaFWELZhj6mwkU9wJUUqj/G4yQg+5bQwEgNtDvv4TJNgihVkYx Ax7g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=FbR73fIs; 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 h11-20020a056a001a4b00b00547d55a4d3bsi18579580pfv.285.2022.12.06.12.08.08; Tue, 06 Dec 2022 12:08:18 -0800 (PST) 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=FbR73fIs; 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 S229632AbiLFTPP (ORCPT + 77 others); Tue, 6 Dec 2022 14:15:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51932 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229602AbiLFTPL (ORCPT ); Tue, 6 Dec 2022 14:15:11 -0500 Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 32E724047C; Tue, 6 Dec 2022 11:15:10 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id p8so25189073lfu.11; Tue, 06 Dec 2022 11:15:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=IfFKOBr66s1CwYSG2TTOFX37oTDo5VCSWbNTI8/Kwv4=; b=FbR73fIsdMR2GPrgHhHD+UTq9hQpNRGnvsBYxAjUFp6pfvgZr0f3krQfwdG05HyEy1 GrqzuNBjEozr5uCrq355J5hfAROhjBeuriFoK7Wx/8Y+5uepSm64UppuyPyZyBXJu7sb t6hTT7Q7l6Yc3Vsc/E0zrw8cEhE1vTktFBImAKIE213k6f94zcrTVKWhHa3F6N2u+JYs YXCI/iRDp+4YGirsctZXJg5BTeMwuqg8KGgarVtxG2GiWC/WVUXJvhMIOaR5YNxPHSiS U1SMKtmtkVQdQSiGjdGkp6vMI05YWsRoFBqIh9b+qKNbsMfSXUli4dHVKTvkNWaIWHYj PQoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=IfFKOBr66s1CwYSG2TTOFX37oTDo5VCSWbNTI8/Kwv4=; b=Bq+fjXkV9XCW52L0vzfKYvXgTw2AmDobiKRcI9TbvZ3OCUNop4knXEfa2yzpRo2f00 aV6eqyj1SYDN4Ow3/I7kOV1ha9XI+0jpz2nZe/1crr6QtOZFVcLe1JLyvVVI5B6G20pt srbnA8eHVIlCV51P6TQl0/JG3ZsQ/4tIwDWhCdKck0sqayPIwstuUkpNXWuXgSUX5rDa K77zWWKYBxZjpDoZbwbc4T3Z72tz0NeFNksGsz1WGqGCyu//5TMVOF/HOFzsEiPxHWX4 1uQFCGh4lVm2MekKy/K7T7sdD7+AfnO1HN1LogXT5zlgM53ICh0LYnSYbHPRQxpFhyfL zlzA== X-Gm-Message-State: ANoB5pkokmyqVR7IATEvQoXD9OjJk9dXH1EJVJrLtKVHURSgaaoAUvfc SPmOpezqF8XtdFHR9XgABHHJV1ZfmKXdmWgwVtQ= X-Received: by 2002:a19:760b:0:b0:4b5:67d8:e3c2 with SMTP id c11-20020a19760b000000b004b567d8e3c2mr4872095lff.166.1670354108416; Tue, 06 Dec 2022 11:15:08 -0800 (PST) MIME-Version: 1.0 References: <20221206070029.7342-1-fmdefrancesco@gmail.com> In-Reply-To: From: "Fabio M. De Francesco" Date: Tue, 6 Dec 2022 20:14:52 +0100 Message-ID: Subject: Re: [PATCH] mm/highmem: Add notes about conversions from kmap{,_atomic}() To: Sebastian Andrzej Siewior Cc: Jonathan Corbet , Andrew Morton , Ira Weiny , Mike Rapoport , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Mike Rapoport , Peter Zijlstra , Thomas Gleixner Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, 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 On marted=C3=AC 6 dicembre 2022 09:00:10 CET Sebastian Andrzej Siewior wrot= e: > On 2022-12-06 08:00:29 [+0100], Fabio M. De Francesco wrote: > > diff --git a/Documentation/mm/highmem.rst b/Documentation/mm/highmem.rs= t > > index 0f731d9196b0..9523e92299f6 100644 > > --- a/Documentation/mm/highmem.rst > > +++ b/Documentation/mm/highmem.rst > > @@ -100,10 +101,21 @@ list shows them in order of preference of use. > > > > (included in the "Functions" section) for details on how to manage nested > > mappings. > > > > -* kmap_atomic(). This permits a very short duration mapping of a sing= le > > - page. Since the mapping is restricted to the CPU that issued it, it > > - performs well, but the issuing task is therefore required to stay on that > > - CPU until it has finished, lest some other task displace its mapping= s. > > +* kmap_atomic(). This function has been deprecated; use kmap_local_page(). > > + > > + NOTE: Conversions to kmap_local_page() must take care to follow the > > mapping + restrictions imposed on kmap_local_page(). Furthermore, code > > between the + map/unmap operations may implicitly depended on the side > > effects of + kmap_atomic(), such as disabling pagefaults, migration, > > and/or preemption. + Such conversions should be changed to make explic= it > > calls for those + requirements. Sebastian, thanks for taking a look at my patch and replying. > Furthermore, code between the kmap_atomic() and kunmap_atomic() > functions may implicitly depended I suppose it should be "depend"? Shouldn't it? > on the side effects of kmap_atomic() > namely disabling pagefaults or preemption or both. I agree with you for rephrasing, mainly because it is written in poor English. However, I still have doubts about why you deleted "migration". AFAIK, __kmap_local_pfn_prot() always takes care of disabling migration for HIGHMEM enabled kernels. How about !HIGHMEM, where kmap_local_page() is an indirect call to page_address()? Did you mean that, if the code between kmap_atomic() and kunmap_atomic() depended on migrate_disable() (in PREEMPT_RT) we should alw= ays just stay safe and call preempt_disable() together with conversion to kmap_local_page()? If so, I understand and I again agree with you. If not, I'm missing somethi= ng; so please let me understand properly. Aside from the above, I'm not sure whether you deleted the last phrase befo= re your suggestion. What about making it to become "For the above-mentioned cases, conversions should also explicitly disable page-faults and/or preemption"? Thanks again for noticing my mistakes. Fabio > > > + [Legacy documentation] > > + > > + This permits a very short duration mapping of a single page. Since = the > > + mapping is restricted to the CPU that issued it, it performs well, b= ut > > + the issuing task is therefore required to stay on that CPU until it = has > > + finished, lest some other task displace its mappings. > > > > kmap_atomic() may also be used by interrupt contexts, since it does = not > > sleep and the callers too may not sleep until after kunmap_atomic() = is > > Sebastian