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;
Date:   Thu, 6 Oct 2022 14:26:41 -0700
From:   Ira Weiny <ira.weiny@intel.com>
To:     Dave Hansen <dave.hansen@intel.com>
CC:     "Fabio M. De Francesco" <fmdefrancesco@gmail.com>,
        <linux-kernel@vger.kernel.org>, <linux-sgx@vger.kernel.org>,
        Jarkko Sakkinen <jarkko@kernel.org>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "Thomas Gleixner" <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>,
        "Borislav Petkov" <bp@alien8.de>, <x86@kernel.org>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Kristen Carlson Accardi <kristen@linux.intel.com>
Subject: Re: [PATCH] x86/sgx: Replace kmap/kunmap_atomic calls
Message-ID: <Yz9IEX1uFNllLjAD@iweiny-desk3>
References: <20220929160647.362798-1-kristen@linux.intel.com>
 <3694452.kQq0lBPeGt@mypc>
 <d64e6e9f-27b9-9bbb-aaf8-fca1681eada5@intel.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <d64e6e9f-27b9-9bbb-aaf8-fca1681eada5@intel.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?QQT06KsvOJovOpby4mMD+zWUU0168jYzJhWFy8K54qUYLkEoQsMKM4RCUs1y?=
 =?us-ascii?Q?WhGrgh+xGqIK+Ok+WqwhccmbV6bNWAvUy2QXgR9/HunPOQjtw4/nuQGqCm9R?=
 =?us-ascii?Q?Y3CKqOn0PSXKo70BJf1z3Wh50ZLZiRQi7tPrDm5dLdqhE7CpTRM/fzH8Orqf?=
 =?us-ascii?Q?eYWakT/EKmDmrkeV+KRaDGFsRZkbTS98MVGEIkJd8mzjMIWEQASNhnOElCCG?=
 =?us-ascii?Q?3kXAIymXokx1u76QDhiWVo7fBhpoEokyOfgVOhu61T07BEeJQscBR3sBnbiH?=
 =?us-ascii?Q?n+JjNSWjdWhQ3xhy5NXMSTrY7ndw+R4vWnkvDyhlcQc2rmoUsn7jjGXml+BZ?=
 =?us-ascii?Q?ZyhX5Kx2UQmQkql1PpnKinXT6Gy2D5WzmVRhOyPSV9u6MYgVbmaQvzo66rkT?=
 =?us-ascii?Q?KshP/uvaP0kva/awF1gxpOK7MNmdoXkxqQKRWu3I1e3cx5p1xUUO8wCslG+x?=
 =?us-ascii?Q?OpfcFoscOYQ8SYW5mFQ1T5XpoD2OeVT0Z5cfYCBKoEcHtG3Naub01uO3ZMzm?=
 =?us-ascii?Q?Tp1CYOaaZqGxBnbE5j4XosiIekZaseJtjkWahGvVMSjMOgjyPSF/Ps6ty7jN?=
 =?us-ascii?Q?PXk29wrMvIUbnp280spKxQmmFhpLHLTdzgrriWcgvAHDOMYu8YIPwyLvxQz7?=
 =?us-ascii?Q?gpQxX7eU7D/11bSdAIap3X8oRnwRJP5Y3XJQlijU+NEkPTTw7Wljn6/V2473?=
 =?us-ascii?Q?wV8qfW6Uaq5CnjWESdBYk+xuvStCPQX0m+bABHbnF59bt2+RjBxfe2FITL61?=
 =?us-ascii?Q?b79D+mJg6Q50/ifDcNUaxxNqU27Q95B5yRrWJs/vBEDndahXn67iiaSy+pLq?=
 =?us-ascii?Q?LBp4WoshfQhm/kQq76JFABxAG3hPMG9ErvhZeNmUR/slDjQAPrh4mE2YM2DV?=
 =?us-ascii?Q?NxseSU/yzQHR/BVjLkE6JHfppyaoa7Ci0cpm2xLRP7nCJw/kIwRZ4T49IUlb?=
 =?us-ascii?Q?9dG4DLldBS4cG3vcF2X3Vw4FBhEZzhwAecVSTfRjmea3RPxnAPFmesWGLpWb?=
 =?us-ascii?Q?bK9vsWs1HsJ7tkXgrIsAOlEGZ6M22OKoplrOl9lbuPKerhYub7hzJvXoT62m?=
 =?us-ascii?Q?p54f3S7ml+v8QSMZqWkzdlRMq28aQjPORws6MyLHxcMlEbjvWlY//ueFV2FG?=
 =?us-ascii?Q?HBOV3Y+5Jqi8/QfcpgMMHCjjOyF6qTXnuMUCN9Qhr1Krnfe4li1sZ6YlXFXW?=
 =?us-ascii?Q?Y86UbsO6Li7SyAIWU4B+nNNed2iwYC/GsUMQqturXMl+oONXUScrYDF9iUod?=
 =?us-ascii?Q?i98cMVRhm5BACXYrNqRoiYrgBWJPSl1aF61lQf4V9BoSXITWtR7F37tZ3CIQ?=
 =?us-ascii?Q?R7TyTXJCNBR+3egnW+2xJtjW+XuLwORDN72whZno5MPL6H7jQpxhpfWV9zaO?=
 =?us-ascii?Q?AKfiQEQy2VK2bJj4ADqzkWGVNZ6IW/xT0E8ixu2GLfqNfJ2cbVVw7dwlnge4?=
 =?us-ascii?Q?9m++fBvtGqi05mRXg6/D/y76NexPvRh0ADvlF59KxGVMMW8yZpoibIYL2GA6?=
 =?us-ascii?Q?HFn+tyYCq7hrAbcJq0XvLadlpPN6KlQZ36/grGDt1220q+YoLarqWOL5JhRW?=
 =?us-ascii?Q?TUdBdRPMtK36SqJ9QKkxiXz1wD/hg0bgVkkuJWNn?=
X-MS-Exchange-CrossTenant-Network-Message-Id: c3fbd32a-1781-4d2a-edb0-08daa7e178fd
X-MS-Exchange-CrossTenant-AuthSource: SA1PR11MB6733.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2022 21:26:46.7140
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: E41geydn5x8C29n2nKCrBhUB6lyjjo0OoYUOJF9CQ2br1L/0X5W7TMeD/hPgPcKD5vWCI5/zci68nVS206t7ig==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR11MB6194
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,
        SPF_HELO_NONE,SPF_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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Oct 06, 2022 at 01:45:56PM -0700, Hansen, Dave wrote:
> On 10/6/22 13:37, Fabio M. De Francesco wrote:
> > kmap() were not suited in those cases because it might sleep. If the intents 
> > of the author are simply map a page while in atomic, so to avoid sleeping in 
> > atomic bugs, your conversions looks good. 
> > 
> > For the reasons above, can you please say something more about why this code 
> > needed a kmap_atomic() instead of calling kmap()?
> 
> This question is backwards.  kmap_atomic() is the default that folks
> use.  You use kmap_atomic() *always* unless you _need_ to sleep or one
> of the other kmap()-only things.
> 
> Folks don't and shouldn't have to explain why this was using kmap_atomic().

I've not looked at the code closely enough but there was some concern that
kmap_atomic() callers are depending on preemption being disabled vs the more
common case of them being used in an atomic context where kmap() can't work.

Ira