Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp723177pxb; Fri, 14 Jan 2022 15:02:56 -0800 (PST) X-Google-Smtp-Source: ABdhPJxAsSuF2HgM+bhxgVrqP2y4AugHb+DSzjGkiJg/k8as71UtcHyAWc/m+grkkQiouiYshrqm X-Received: by 2002:a05:6402:16d1:: with SMTP id r17mr1005784edx.284.1642201376524; Fri, 14 Jan 2022 15:02:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642201376; cv=none; d=google.com; s=arc-20160816; b=FSHjmm50IPliQCVw6AWyl/4XzjxP48uFMQNXfTHp1dK8QpUMXL9Er+xycApSruKIX+ kDMztkkI7A8QvRIAy3OHNEqE5D8g3e9NApyQeoogk22AxG9c6lWLEc+IF41ccU0ubWEJ 9qP+hcDtIA0NJnedy469bl2HwqfAmcsafzmd/wT1nIUZ++WEY3SoNpCIucwdlS04UJcG VrMiS9FOy1i9/PL1NqoDJTWheC3cdsmFBpkKLpDKFgmNIAtpDuQSk+OU2aA/wPmHXSXV WPFRH8Rah0JJTZ9jYuQnI61iS67nv650hzCQuFyMRn+q2ioBCKHuHPThm2O73EAmgtGr IzVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:subject:from :references:cc:to:dkim-signature; bh=Way5r78eEojf1YYI7UEw5EOaOWKo7nYLKlpTbv1m+KU=; b=ePEDmI88JLeGe09Jd1jTMCChFMzOgE82aaKUNImOm/l8kkqYnMH/XxzlvBT+tvFsKW nQlz4lmXF4xTQKzYmMaMtQJKGx2jBYpyyb5vGFPUJzG47fJCm6YZI9uUe6N5LNZhEhIm LwiOhwJNTznE+Scmt65bs0W4+clnvyAJttgCG5sHkUO62dfQjMie16ISnkiV1ims5njt G5o4X2l9bZ4aa77f7nv/ZtWGbHNEchEgD6/hdJfkjFfI7mwpvLgJIpfLylmzEPIFp8Sz Ern6UfUAT/6/hQtp4nC3RNWLBKS6Yiwf9hVWuQMLWbH6D7nCoZleC4sUe3RXp4AFwqap r66Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=nVw8K7bR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u3si2802615edo.517.2022.01.14.15.02.31; Fri, 14 Jan 2022 15:02:56 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=nVw8K7bR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244036AbiANR4L (ORCPT + 99 others); Fri, 14 Jan 2022 12:56:11 -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.