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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B931DC433F5 for ; Thu, 6 Oct 2022 20:46:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232228AbiJFUqA (ORCPT ); Thu, 6 Oct 2022 16:46:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47026 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229540AbiJFUp6 (ORCPT ); Thu, 6 Oct 2022 16:45:58 -0400 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D2190BE2D7; Thu, 6 Oct 2022 13:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1665089157; x=1696625157; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=OwJ1ROhRXZmye0Wodpt5I0o6ytjW0KtspOAjyDYbTpc=; b=NXodHHbywNd7aDXfMNLCEtHsyk5uQ3CUBS7beOTGOYGqhwctv0c/bFMi eTxV+vLwpCJx/dDE19EcA3WMundae/RNtLxLZLmktlf6dTy0yt46RzIgK I2jqjWe1wxJKb3ARrVtH7bqkWmFA2QVhMm8r1ybj2h4A6+NQ+xYbzr9S1 iqQRDB0KdjvNOPK+GLpIP5xvu1NhantgVCjZf8yiS2qyChta/4toggijZ V9o8sUcQzfLdIWSgmSkRf53O25TAESxFtoIcR1IqbS7Qr63eusrn8xyCt 4P4zIxSfK5PkuIm/vgOwXagUV+kyOq3m1IsNDHy8X3gLDJQRB/9twSe39 w==; X-IronPort-AV: E=McAfee;i="6500,9779,10492"; a="329999364" X-IronPort-AV: E=Sophos;i="5.95,164,1661842800"; d="scan'208";a="329999364" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Oct 2022 13:45:57 -0700 X-IronPort-AV: E=McAfee;i="6500,9779,10492"; a="655769471" X-IronPort-AV: E=Sophos;i="5.95,164,1661842800"; d="scan'208";a="655769471" Received: from jlcone-mobl1.amr.corp.intel.com (HELO [10.212.128.129]) ([10.212.128.129]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Oct 2022 13:45:57 -0700 Message-ID: Date: Thu, 6 Oct 2022 13:45:56 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH] x86/sgx: Replace kmap/kunmap_atomic calls Content-Language: en-US To: "Fabio M. De Francesco" , linux-kernel@vger.kernel.org, linux-sgx@vger.kernel.org, Jarkko Sakkinen , Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" , Kristen Carlson Accardi Cc: ira.weiny@intel.com References: <20220929160647.362798-1-kristen@linux.intel.com> <3694452.kQq0lBPeGt@mypc> From: Dave Hansen In-Reply-To: <3694452.kQq0lBPeGt@mypc> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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().