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 1B2CBC433EF for ; Mon, 28 Feb 2022 15:32:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237207AbiB1Pcs (ORCPT ); Mon, 28 Feb 2022 10:32:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50880 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236783AbiB1Pcr (ORCPT ); Mon, 28 Feb 2022 10:32:47 -0500 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9D8B882D15; Mon, 28 Feb 2022 07:32:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1646062328; x=1677598328; h=message-id:date:mime-version:to:cc:references:from: subject:in-reply-to:content-transfer-encoding; bh=A3kdMGKBPJg68rq8VDU9FNscngH3Bv2jiEeKZ84eaOw=; b=biKhEqbL/4pJO/5Z/e5X+uftMwbynO0DNV0e5RfST5Ug7eMNSItTrvG2 uUUsxblvF6UytWbQ/wltoVNiP1ib+LBmS8ZGAdOBHBapabnVgg393H1p6 EeaCQ1ijGYATYDcJJ5RwG07mgB8Qlfbx6xf4PNU4gILnHg6DtN5T0yvXv YJvfrnIf0ge6c1JmwUQyUJwfeR0zUTx0fpNO9Teb38VSi0+bmHK3/9gqm 9hO7L2Wz8HXMilMSKJwxmJM1yxwa1E54+exHGFE1DEtM6pMgjwqdzDzxc qeEfL5PpE3eSDs/ZhB+qGGcpp2vmsqcNot2XTF19UIsS7VTmp2hZi6bKt A==; X-IronPort-AV: E=McAfee;i="6200,9189,10271"; a="236412845" X-IronPort-AV: E=Sophos;i="5.90,142,1643702400"; d="scan'208";a="236412845" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Feb 2022 07:32:08 -0800 X-IronPort-AV: E=Sophos;i="5.90,142,1643702400"; d="scan'208";a="550281259" Received: from eliasbro-mobl.amr.corp.intel.com (HELO [10.212.174.65]) ([10.212.174.65]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Feb 2022 07:32:07 -0800 Message-ID: <0e06910b-9313-94ae-11e3-10a2b14645f2@intel.com> Date: Mon, 28 Feb 2022 07:32:02 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US To: Jarkko Sakkinen Cc: linux-sgx@vger.kernel.org, Dave Hansen , stable@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , "H. Peter Anvin" , Sean Christopherson , Jethro Beekman , "open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" References: <20220222120342.5277-1-jarkko@kernel.org> <33646f1e-da44-503a-c454-02658d512926@intel.com> From: Dave Hansen Subject: Re: [PATCH v4] x86/sgx: Free backing memory after faulting the enclave page In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-sgx@vger.kernel.org On 2/28/22 04:55, Jarkko Sakkinen wrote: > I thought that the formula is so simple that it does not matter if it is > just in two sites open coded but I can wrap it too, if required, e.g. > > /* > * Calculate byte offset of a PCMD struct associated to an enclave page. > * PCMD's follow right after the EPC data in the backing storage. In > * addition to the visible enclave pages, there's one extra page slot > * for SECS, before PCMD data. > */ > static pgoff_t *sgx_encl_page_index_to_pcmd_offset(struct sgx_encl *encl, unsigned long page_index) > { > return encl->size + PAGE_SIZE + page_index * sizeof(struct sgx_pcmd); > } Yes, it's required. Please wrap it. There's also nothing wrong with spreading that calculation across several lines. It may be arithmetically simple, but it's combining three or four logical steps. There's no shame in separating and commenting some of those separately.