From patchwork Fri Jan 27 06:40:04 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Randy Dunlap X-Patchwork-Id: 49104 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp686000wrn; Thu, 26 Jan 2023 22:45:28 -0800 (PST) X-Google-Smtp-Source: AMrXdXsdkuGO8hJqrpMARu9DM2ahFjKN5uoLt+xkhxhKgozsxsomYT2jgN/md8eTU0/l3H/Xq27I X-Received: by 2002:a05:6402:501e:b0:48e:bf0d:f3a8 with SMTP id p30-20020a056402501e00b0048ebf0df3a8mr45130560eda.38.1674801928293; Thu, 26 Jan 2023 22:45:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674801928; cv=none; d=google.com; s=arc-20160816; b=OgypWmAp0KLLItvcpGTsTL/xe6XL52nQffk+2PEYZJAs6PBp2ubzNVmDLn76R0lk73 IrMkQ6yGtpdMqspi2raw2F8pyNuHKf/EBvfRMcxei/uIF5ebQHBhXJ78z1ukvcfk/daZ HuUa34ryMKS1KztDh1Qo9BCG4KUDlDlUEFU8wUuTmrMlzA2AMo3n1IaOHqNP8U8td2b0 opeBa7Cg0eZ5Ubg0i7+KYtX++yRdvaCrUbVva4eK5gALjvrHc4XhKJ/CiMV+YAUGJh98 xuWiJfk6Aycfap5EH9Noxy0fdDTPhUeq82KVPoqq0qYRFrIMbIrnJpPilZiQOZc/EOF3 jJJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=RabzW2onkbK88Jry4X6k/vy1HM1YZdyLqoiuOttw51A=; b=v7QYjDUH8G8UjcWY+MzSDl6lzAm0gcJMt/A9JlNgLwZAz0sBxlcuLW11pJfimoNLvr Kcpue2eceJKeGabnJCSTM9Bw5MSCQOy7tqUPP4dxPF5+HN0wqWKCoTXXu6Y4JjrAOHZJ /oMCOELrLH97CAXRjiIYsdIWmGq6yaFAL9lFfHbh3QBRwqyLUtPlq9uOsZZZ/0/JZ9XD etOGmzdEUhgBLXswA8Z7YZ+chOU0gLChJlLhwSyvMrAPctj4hLH0ChhE7T5uoXqV5+n+ qHrlbjoDYTrb2rrcSqblkpP0nyae9rkHhM2za5AO7PHwCu+5m24onWaj8rCvOWmZgV9r R6FQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=kNDwnnuX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id eh17-20020a0564020f9100b0049e6678d9d8si4219696edb.618.2023.01.26.22.45.05; Thu, 26 Jan 2023 22:45:28 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=kNDwnnuX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231810AbjA0GmI (ORCPT + 99 others); Fri, 27 Jan 2023 01:42:08 -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 X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1756157107081955450?= X-GMAIL-MSGID: =?utf-8?q?1756157107081955450?= 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. -Sample Boot Configuartion +Sample Boot Configuration ========================= 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 -------------------------------------- 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. #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 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. 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: 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. -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.