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 AB7B6C433FE for ; Fri, 14 Jan 2022 17:56:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244051AbiANR4N (ORCPT ); Fri, 14 Jan 2022 12:56:13 -0500 Received: from mga05.intel.com ([192.55.52.43]:35461 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236840AbiANRzz (ORCPT ); Fri, 14 Jan 2022 12:55:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1642182955; x=1673718955; h=to:cc:references:from:subject:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=v8Ozza0tymQgUc+3naLOKoeYD5ZJqBwVXdu/+vjab4M=; b=nVw8K7bRFVG0ZQiQpq6wl2T/iPB4ZcWGSicb9ZXmxTgU2S4MueLfmHwc SGzC+paeMd7YqX8ThykdPnnNmtsvSaWn23rq/YBIiMCToqr4fk9P1oMPL zB2YdZSzShsNxOLSVt8C7DVHylgJmGWrrjgfG8jTRwnVpupyG2Naxm9Os 8YKj5Nu16CdzRmt0yM8/+8IwRCLm2JEm8gxWI6xwderf1WLHGq0T2uxH8 kcpBB649cRTO4l2ZiBAameGBHMo/epph8sP0NbwNIcdLeTwlaZQJUDu1F ++fmqf/SUlFKSqJUafWRXDx9I/XYdHq6fZyo4tFbNtiyJLmTGvLJoWelO Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10227"; a="330644744" X-IronPort-AV: E=Sophos;i="5.88,289,1635231600"; d="scan'208";a="330644744" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jan 2022 09:55:54 -0800 X-IronPort-AV: E=Sophos;i="5.88,289,1635231600"; d="scan'208";a="491594520" Received: from richasha-mobl.amr.corp.intel.com (HELO [10.251.12.158]) ([10.251.12.158]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jan 2022 09:55:52 -0800 To: Kristen Carlson Accardi , Jarkko Sakkinen Cc: linux-sgx@vger.kernel.org, Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" , linux-kernel@vger.kernel.org References: <20220107181618.6597-1-kristen@linux.intel.com> <20220107181618.6597-3-kristen@linux.intel.com> From: Dave Hansen Subject: Re: [PATCH v2 2/2] x86/sgx: account backing pages Message-ID: Date: Fri, 14 Jan 2022 09:55:51 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/14/22 9:51 AM, Kristen Carlson Accardi wrote: >>> +int sgx_encl_lookup_backing(struct sgx_encl *encl, unsigned long >>> page_index, >>> + struct sgx_backing *backing) >>> +{ >>> + return sgx_encl_get_backing(encl, page_index, backing); >>> +} >> IMHO, sgx_encl_backing() should be open-coded here. > I can understand your hesitation, but I agree with Dave here that > wrapping the function makes the code more clear. I would prefer to keep > this the way it is. I'd also like to see sgx_encl_lookup_backing() and sgx_encl_alloc_backing() diverge more in the future. For instance, sgx_encl_alloc_backing() could ensure that the page does not exist in the file before doing the sgx_encl_get_backing() call. This would ensure that it truly *does* allocate a page and does not just return a previously-allocated page. sgx_encl_lookup_backing() could ensure the opposite: that the page *DOES* exist in the file before doing the sgx_encl_get_backing() call. This would ensure that it does not allocate a page in a case where we expected an old, existing page to be present.