From nobody Sun Sep 14 03:52:00 2025 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 6BE79C38142 for ; Fri, 27 Jan 2023 06:42:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232194AbjA0GmJ (ORCPT ); Fri, 27 Jan 2023 01:42:09 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39588 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232050AbjA0Gka (ORCPT ); Fri, 27 Jan 2023 01:40:30 -0500 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8F277751A8; Thu, 26 Jan 2023 22:40:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:Sender :Reply-To:Content-Type:Content-ID:Content-Description; bh=RabzW2onkbK88Jry4X6k/vy1HM1YZdyLqoiuOttw51A=; b=kNDwnnuXkhvoQdYEJI6kdc4LS5 ZGwL/ehZkHYq5TO1Z2c8XfREfcaK/RM8a0TOIlF+sY5KTOCfrrYwBRr81jUbQk9a3tudg2Kgx0Ar9 d+63Eeste5xjtUQYwS+oRnVH8+zQiHNBUFOb4AxDUQd+yOqtkOd+V5VEd2cEmk9VevHvYfZAxY8MK apT69YJdcdZZCgWeFYIpjDMdykMEhs44nloeM5WH8WhAHw25xC+wv6mqA5S9ag28yvefjEIQF1J+/ Z5ftzpL6VIX7TJoxygUzts12Ev9WIrWT06VaafGKEXJhbhByUKwf9gpIse7QP0Lrvz+45HbsNsdAT LKgyTcNw==; Received: from [2601:1c2:d80:3110::9307] (helo=bombadil.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1pLIPR-00DM0u-Us; Fri, 27 Jan 2023 06:40:26 +0000 From: Randy Dunlap To: linux-kernel@vger.kernel.org Cc: Randy Dunlap , Jarkko Sakkinen , linux-sgx@vger.kernel.org, Fenghua Yu , Reinette Chatre , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, Jonathan Corbet , linux-doc@vger.kernel.org Subject: [PATCH 34/35] Documentation: x86: correct spelling Date: Thu, 26 Jan 2023 22:40:04 -0800 Message-Id: <20230127064005.1558-35-rdunlap@infradead.org> X-Mailer: git-send-email 2.39.1 In-Reply-To: <20230127064005.1558-1-rdunlap@infradead.org> References: <20230127064005.1558-1-rdunlap@infradead.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Correct spelling problems for Documentation/x86/ as reported by codespell. Signed-off-by: Randy Dunlap Cc: Jarkko Sakkinen Cc: linux-sgx@vger.kernel.org Cc: Fenghua Yu Cc: Reinette Chatre Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: x86@kernel.org Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org --- Documentation/x86/boot.rst | 2 +- Documentation/x86/buslock.rst | 2 +- Documentation/x86/mds.rst | 2 +- Documentation/x86/resctrl.rst | 2 +- Documentation/x86/sgx.rst | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff -- a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst --- a/Documentation/x86/boot.rst +++ b/Documentation/x86/boot.rst @@ -1105,7 +1105,7 @@ The kernel command line should not be lo code, nor should it be located in high memory. =20 =20 -Sample Boot Configuartion +Sample Boot Configuration =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D =20 As a sample configuration, assume the following layout of the real diff -- a/Documentation/x86/buslock.rst b/Documentation/x86/buslock.rst --- a/Documentation/x86/buslock.rst +++ b/Documentation/x86/buslock.rst @@ -32,7 +32,7 @@ mechanisms to detect split locks and bus -------------------------------------- =20 Beginning with the Tremont Atom CPU split lock operations may raise an -Alignment Check (#AC) exception when a split lock operation is attemped. +Alignment Check (#AC) exception when a split lock operation is attempted. =20 #DB exception for bus lock detection ------------------------------------ diff -- a/Documentation/x86/mds.rst b/Documentation/x86/mds.rst --- a/Documentation/x86/mds.rst +++ b/Documentation/x86/mds.rst @@ -60,7 +60,7 @@ needed for exploiting MDS requires: data =20 The existence of such a construct in the kernel cannot be excluded with -100% certainty, but the complexity involved makes it extremly unlikely. +100% certainty, but the complexity involved makes it extremely unlikely. =20 There is one exception, which is untrusted BPF. The functionality of untrusted BPF is limited, but it needs to be thoroughly investigated diff -- a/Documentation/x86/resctrl.rst b/Documentation/x86/resctrl.rst --- a/Documentation/x86/resctrl.rst +++ b/Documentation/x86/resctrl.rst @@ -487,7 +487,7 @@ this would be dependent on number of cor depending on # of threads: =20 For the same SKU in #1, a 'single thread, with 10% bandwidth' and '4 -thread, with 10% bandwidth' can consume upto 10GBps and 40GBps although +thread, with 10% bandwidth' can consume up to 10GBps and 40GBps although they have same percentage bandwidth of 10%. This is simply because as threads start using more cores in an rdtgroup, the actual bandwidth may increase or vary although user specified bandwidth percentage is same. diff -- a/Documentation/x86/sgx.rst b/Documentation/x86/sgx.rst --- a/Documentation/x86/sgx.rst +++ b/Documentation/x86/sgx.rst @@ -245,7 +245,7 @@ SGX will likely become unusable because limited. However, while this may be fatal to SGX, the rest of the kernel is unlikely to be impacted and should continue to work. =20 -As a result, when this happpens, user should stop running any new +As a result, when this happens, the user should stop running any new SGX workloads, (or just any new workloads), and migrate all valuable workloads. Although a machine reboot can recover all EPC memory, the bug should be reported to Linux developers.