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 37E73EB64DC for ; Mon, 17 Jul 2023 11:15:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230057AbjGQLPE (ORCPT ); Mon, 17 Jul 2023 07:15:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36364 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229469AbjGQLPD (ORCPT ); Mon, 17 Jul 2023 07:15:03 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9E2E91B9; Mon, 17 Jul 2023 04:15:02 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 32E7461014; Mon, 17 Jul 2023 11:15:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 93ED9C433C7; Mon, 17 Jul 2023 11:14:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1689592501; bh=jQaqrSCg/yz5THxsM9cGnoZroPykdynjBcPlSG9vNuk=; h=Date:Cc:Subject:From:To:References:In-Reply-To:From; b=biVF7s9jcxMdUb2BNF9qZV5HtosaQalGOMAHtL4rHUPEpnq91DGXn039B5C6Cnk4D ZDGEtBMAhLOQRwl6lIW+Zv6UhejI96Lz8bLsEjJiBaiIu2HLW+yFSrgtZdjXy+wXRV vwMyz9EawHrE40q6tPROYq5yMLOKotg0Um/vk16UgL/Rdt/uP9kMiImhKhngT/mcCc XwEQOxPLuR/eKw4HzDcXIWJbf+a1irlyFJM1wAtOHCJ/CWHxeAcbWlt55tVxcbu534 j9zH0Ggcj/mIULA/QUqd5AsxHezqVSOVMIs9NJUIe+JPVKyxbnhBP0c/SbXTdozyZr LfPjYFzHfuLtQ== Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 17 Jul 2023 11:14:56 +0000 Message-Id: Cc: , , , , Subject: Re: [PATCH v3 01/28] x86/sgx: Store struct sgx_encl when allocating new VA pages From: "Jarkko Sakkinen" To: "Haitao Huang" , , , , , , "Thomas Gleixner" , "Ingo Molnar" , "Borislav Petkov" , , "H. Peter Anvin" X-Mailer: aerc 0.14.0 References: <20230712230202.47929-1-haitao.huang@linux.intel.com> <20230712230202.47929-2-haitao.huang@linux.intel.com> In-Reply-To: <20230712230202.47929-2-haitao.huang@linux.intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-sgx@vger.kernel.org On Wed Jul 12, 2023 at 11:01 PM UTC, Haitao Huang wrote: > In a later patch, when a cgroup has exceeded the max capacity for EPC pag= es > and there are no more Enclave EPC pages associated with the cgroup that c= an > be reclaimed, the only pages still associated with an enclave will be the > unreclaimable Version Array (VA) pages or SECS pages, and the entire > enclave will need to be killed to free up those pages. > > Currently, given an enclave pointer it is easy to find the associated VA > pages and free them, however, OOM killing an enclave based on cgroup limi= ts > will require examining a cgroup's unreclaimable page list, and finding an > enclave given a SECS page or a VA page. This will require a backpointer > from a page to an enclave, including for VA pages. > > When allocating new Version Array (VA) pages, pass the struct sgx_encl of > the enclave that is allocating the page. sgx_alloc_epc_page() will store > this value in the owner field of the struct sgx_epc_page. In a later > patch, VA pages will be placed in an unreclaimable queue, and then when t= he > cgroup max limit is reached and there are no more reclaimable pages and t= he > enclave must be OOM killed, all the VA pages associated with that enclave > can be uncharged and freed. > > To avoid casting needed to access the two types of owners: sgx_encl for V= A > pages, sgx_encl_page for other pages, replace 'owner' field in sgx_epc_pa= ge > with a union of the two types. I think the action taken is correct but the reasoning is a bit convoluted. Why not instead put something like: "Because struct sgx_epc_page instances of VA pages are not owned by an sgx_encl_page instance in the first place, mark their owner as sgx_encl, in order to make it reachable from the unreclaimable list." The code change itself, and rest of the paragraphs do look reasonable. BR, Jarkko