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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5997DC352A1 for ; Wed, 7 Dec 2022 13:01:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EDC608E0003; Wed, 7 Dec 2022 08:01:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E8CA68E0001; Wed, 7 Dec 2022 08:01:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D54358E0003; Wed, 7 Dec 2022 08:01:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id C8BEA8E0001 for ; Wed, 7 Dec 2022 08:01:55 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 3980B40AA9 for ; Wed, 7 Dec 2022 13:01:55 +0000 (UTC) X-FDA: 80215522590.16.0FA9C1B Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) by imf22.hostedemail.com (Postfix) with ESMTP id 6E1CBC001E for ; Wed, 7 Dec 2022 13:01:54 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=CMORAutN; spf=pass (imf22.hostedemail.com: domain of fmdefrancesco@gmail.com designates 209.85.221.41 as permitted sender) smtp.mailfrom=fmdefrancesco@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1670418114; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=0YVq0+UudzmdQRaa093Lbr3RyPe8FvBPlb/bI7jjFrI=; b=4vl/89Vv206tvgsu9DRfYJS7El10ynCdnpSJhNLKE85N35bZr4Th7OOxGZ7V2vpcFN5ecq m+n4FfCT3sIMLCWXVcQJ4FNsizkneKdYV/edZHj6i7ylVjtZhaJJGaYnNKpyKhABS80Moj gQ++Xwn0rxyAGsMr8wDd91URs2Kmad0= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=CMORAutN; spf=pass (imf22.hostedemail.com: domain of fmdefrancesco@gmail.com designates 209.85.221.41 as permitted sender) smtp.mailfrom=fmdefrancesco@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1670418114; a=rsa-sha256; cv=none; b=jZJk5MoH+ylGqnQLlIawUWrqkt4tDUSknblVTkBYffZ2f2ct2UVDiO6L9WzBVf1kIWf11b UMQXp0MY6DYylqpfcgtV7kcBATKb7W9bC+hJnEUDElXpeJT5sBNtHoeEzkU4xk04R0us2Q L92e4P5Dj2J3ZBcvOKwPr5MPc7ZlkBM= Received: by mail-wr1-f41.google.com with SMTP id o5so28002130wrm.1 for ; Wed, 07 Dec 2022 05:01:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=0YVq0+UudzmdQRaa093Lbr3RyPe8FvBPlb/bI7jjFrI=; b=CMORAutNrxMOSyZ3nsb0/8TpMLFDIPZ1Qz88/ymw+/kMn53Q+YInmlWDf+8eXThgQP pUArjM4WqUjQv0jcKnrLBQ1l74ru2Ca4yQkYzeqpqamSIhlhLgmkbwsWkiznpae1DFzd OEx/COJhWbu07iLBtfhMjVhjZEvnYxtVJha7KpunLVu9soEiJW7v2q3StiQXbtjUapkf 8P0fbk8Yak01+o9CcBErx3J3UDmDGKQmj9JgAbtgcaCXoMbz0i8Hlv3fOToMJX0aW87y j3goQM/7HUnfnInWniUErWN+jKWLADK8mbhPWSmBFYqK3X69t5vOF67W5e0TBLkeLOJL qczw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0YVq0+UudzmdQRaa093Lbr3RyPe8FvBPlb/bI7jjFrI=; b=cLtWbWOB9n956g2ztslWGhhtrP9cql8eYYuNlynXcUDF58NQkqFwP7KzhnHEhw3jGG pbKah/SmMLMYbvUhO+mqJ2Y7zDnPjc5+eI/kl+uTl1gXPGJSYpO9M39lLZQhxuZ4MCz1 jViEdKcGBWWGw9uRJ+wpAUJEAE0jUXWPdo+MzojJsmy+PZQrmABgNEx0Km/MSQDcWf4m qnUe/c5q/RvdgTt/SeTPldk4ik0jIndcurb8APM0UhHJVXQiUYJ3lr15HUG1E0vFIS08 E9fP7ZDtlqBdYYBSlWQu/dg0MeKQLQ6QFJjm4xZGDg3c8GRJyx4A2Fz5NnL9qaaGIkrm sAJA== X-Gm-Message-State: ANoB5pl1SJS0gkcpuITVAsCyz2Qutj/LkHUeDksRKOdzjVIA9td0hZLp AnOmG1fj1N4ywHD8Uqz4JG4= X-Google-Smtp-Source: AA0mqf6XKt9c4pFnmhN0NNmHU8welUubyeVCDFFUuu+/FqSi0mi4la0JgJ4FBHRH0u3/QFEiWQ2ICA== X-Received: by 2002:adf:da4c:0:b0:242:137d:9ce4 with SMTP id r12-20020adfda4c000000b00242137d9ce4mr325754wrl.3.1670418112988; Wed, 07 Dec 2022 05:01:52 -0800 (PST) Received: from suse.localnet (host-79-26-108-238.retail.telecomitalia.it. [79.26.108.238]) by smtp.gmail.com with ESMTPSA id m18-20020adfe952000000b002421888a011sm19432882wrn.69.2022.12.07.05.01.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Dec 2022 05:01:52 -0800 (PST) From: "Fabio M. De Francesco" 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 Subject: Re: [PATCH] mm/highmem: Add notes about conversions from kmap{,_atomic}() Date: Wed, 07 Dec 2022 14:01:50 +0100 Message-ID: <2130641.irdbgypaU6@suse> In-Reply-To: References: <20221206070029.7342-1-fmdefrancesco@gmail.com> <2093077.OBFZWjSADL@suse> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Spamd-Result: default: False [-1.40 / 9.00]; BAYES_HAM(-6.00)[100.00%]; SORBS_IRL_BL(3.00)[209.85.221.41:from]; SUBJECT_HAS_UNDERSCORES(1.00)[]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; BAD_REP_POLICIES(0.10)[]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_SEVEN(0.00)[11]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_ALLOW(0.00)[gmail.com:s=20210112]; R_SPF_ALLOW(0.00)[+ip4:209.85.128.0/17:c]; DMARC_POLICY_ALLOW(0.00)[gmail.com,none]; TO_MATCH_ENVRCPT_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[linux-mm@kvack.org]; DKIM_TRACE(0.00)[gmail.com:+]; ARC_SIGNED(0.00)[hostedemail.com:s=arc-20220608:i=1]; RCVD_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 6E1CBC001E X-Stat-Signature: mc5mexpxq5z9cz3m5ptigcibwmhawnfo X-HE-Tag: 1670418114-249614 X-Bogosity: Ham, tests=bogofilter, spamicity=0.006213, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On mercoled=EC 7 dicembre 2022 09:00:29 CET Sebastian Andrzej Siewior wrote: > On 2022-12-06 20:12:13 [+0100], Fabio M. De Francesco wrote: > > > Furthermore, code between the kmap_atomic() and kunmap_atomic() > > > functions may implicitly depended > >=20 > > I suppose it should be "depend"? Shouldn't it? >=20 > Ehm, yes, correct. >=20 > > > on the side effects of kmap_atomic() > > > namely disabling pagefaults or preemption or both. > >=20 > > I agree with you for rephrasing, mainly because it is > > written in poor English. > >=20 > > However, I still have doubts about why you deleted "migration". > > AFAIK, __kmap_local_pfn_prot() always takes care of disabling migration= =20 for > > HIGHMEM enabled kernels. >=20 > That is correct. Historically kmap_atomic() never had a > migrate_disable() statement - only preempt_disable(). With disabled > preemption the task migration is implicitly disabled. Sure, I understand this mechanism: task migration is implicitly disabled wi= th=20 disabled preemption. >=20 > > 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 > > always just stay safe and call preempt_disable() together with conversi= on > > to kmap_local_page()? >=20 > Even in the !HIGHMEM case it always uses preempt_disable(). With the only exception of PREEMPT_RT kernels, which instead use=20 migrate_disable(). > With > PREEMPT_RT it is different as it never disabled preemption and always > did a migrate_disable() instead. OK, I see that I'm recalling correctly :-)=20 > If you talk about what needs to be > considered while migrating away from kmap_atomic() Yes, I'm trying to explain what needs to be considered while converting fro= m=20 kmap_atomic() by looking at all the different cases. > then I wouldn't add > the PREEMPT_RT bits to it since it was never in the picture while the > code (using kmap_atomic()) was originally written. Ah, OK. Now I understand why you changed my last phrase. I agree with you, so I won't add anything about the special PREEMPT_RT case. > > If so, I understand and I again agree with you. If not, I'm missing > > something; so please let me understand properly. > >=20 > > Aside from the above, I'm not sure whether you deleted the last phrase > > before > > your suggestion. What about making it to become "For the above-mentioned > > cases, conversions should also explicitly disable page-faults and/or > > preemption"? >=20 > They need to disable preemption or page-faults or both if it is needed > (not unconditionally) and where it is needed. This means not > unconditionally over the whole kmap-ed section. I never meant to suggest to _unconditionally_ disable page-faults=20 and/or preemption. I was only trying to say that developers must carefully= =20 check whether or not the whole kmap-ed section depended on those side effec= ts. If so, they must _explicitly_ disable preemption or page-faults or both=20 together with the use of kmap_local_page(). Instead, if the section doesn't= =20 depend on preemption and/or page-faults disabling, they must only replace=20 kmap_atomic() with kmap_local_page(). I had probably used a bad wording when trying to say the same things that y= ou=20 wrote much more clearly. Thanks, =46abio >=20 > > Thanks again for noticing my mistakes. > >=20 > > Fabio >=20 > Sebastian