Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp4281035pxb; Mon, 8 Feb 2021 12:19:08 -0800 (PST) X-Google-Smtp-Source: ABdhPJxDp856rs+BZrHApHuqaUYDuivDqrCl69yoOTABQ4gnR+NIHLFv7gslqsM3sFa4a0dGGd7O X-Received: by 2002:a17:906:cc5d:: with SMTP id mm29mr19241397ejb.183.1612815547949; Mon, 08 Feb 2021 12:19:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612815547; cv=none; d=google.com; s=arc-20160816; b=JjuMcejQmwdhYcQj3uBFsZm1ljFTMK6c4NccGC3nIwzM0Zjib9sxXb/68DoEqFNib9 wDwIEjN27MNhM4XBWESyW4TpPESucIt0GcsC3kRH73/Y/sD6Ssz705oGiJcN5XqWTyD1 bBSzi/BzXCLS6NetZmwNPj2ULhrFPsRQ76TCVpWYaS2UPyx6ltsEhSbptPm/wkbAq29t xd4Yd8/hw2GNrp+YYDESlx0Dylsp73hdvqNRZcmKQ7MPfkcB9bqGrVwMCN9S78oRQp7u 2bbGLPK2QKWn1W1gIjFoXDA/y0XoZu6RVPkcHW4NRB1AuKOSZS7B/AZKnVYPUWPioxgy 0rpw== 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:from:references :cc:to:subject:ironport-sdr:ironport-sdr; bh=0uQgZizpAXqwyRA6xWxZE8/+24lHMDoSqMewhQRnuw4=; b=En18Hat3gMewd+IhLa6OrrprLOPfCaLQ65UYjKYE2VBI4EhY9D4LOxoDbW7qZlHVwO 6gnmI44XtP+CrmSPBdsJhi5VLwLgf/hVd31sy4d+ZolqJn1E/C+ETfpqG0sJjtZgOMxC R5YGZKF3HFaHeySM4ZUJI6ZhrTQ6f/mTbW23GY9tgCiukhU8IkW4OC6/GLkkwnTw/XyN eYtUJLhkhsZVNM0w9aQXTOMWkURVuwLfQTfZP58gSzFvWJrQggiA2CNUA4gBeFN4h2hF mEw36NGjpHSjYyo4Xb3RQKpMV3W2l+rvS3SLWSYmO29zVzEN2gIfxFb3SAqJP9l9UwDU x6Fg== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (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 ho39si4688605ejc.708.2021.02.08.12.18.43; Mon, 08 Feb 2021 12:19:07 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236715AbhBHURL (ORCPT + 99 others); Mon, 8 Feb 2021 15:17:11 -0500 Received: from mga11.intel.com ([192.55.52.93]:19742 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235781AbhBHSvA (ORCPT ); Mon, 8 Feb 2021 13:51:00 -0500 IronPort-SDR: jtO57MKjPDT2Hi85PUtM1GHO3bFumY+0XQqEcMQmoqatUfBm/XjK/o76hIlLmzIye30poOffZq IyRhZY/ccS1A== X-IronPort-AV: E=McAfee;i="6000,8403,9889"; a="178251561" X-IronPort-AV: E=Sophos;i="5.81,163,1610438400"; d="scan'208";a="178251561" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Feb 2021 10:50:11 -0800 IronPort-SDR: RKBHoDdAWK2blnUYN00Qk4/M1GPezTS0E9lZ/If3NWriwtfE4VnzSdkvSBoLQzNvY2P1WCjvA+ SuIcuc84nSYQ== X-IronPort-AV: E=Sophos;i="5.81,163,1610438400"; d="scan'208";a="487522995" Received: from yyu32-mobl1.amr.corp.intel.com (HELO [10.251.11.33]) ([10.251.11.33]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Feb 2021 10:50:08 -0800 Subject: Re: [PATCH v19 06/25] x86/cet: Add control-protection fault handler To: Borislav Petkov Cc: x86@kernel.org, "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Arnd Bergmann , Andy Lutomirski , Balbir Singh , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , "H.J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , "Ravi V. Shankar" , Vedvyas Shanbhogue , Dave Martin , Weijiang Yang , Pengfei Xu , Michael Kerrisk References: <20210203225547.32221-1-yu-cheng.yu@intel.com> <20210203225547.32221-7-yu-cheng.yu@intel.com> <20210205135927.GH17488@zn.tnic> <2d829cba-784e-635a-e0c5-a7b334fa9b40@intel.com> <20210208182009.GE18227@zn.tnic> From: "Yu, Yu-cheng" Message-ID: <690bc3b9-2890-e68d-5e4b-cda5c21b496b@intel.com> Date: Mon, 8 Feb 2021 10:50:07 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <20210208182009.GE18227@zn.tnic> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/8/2021 10:20 AM, Borislav Petkov wrote: > On Fri, Feb 05, 2021 at 10:00:21AM -0800, Yu, Yu-cheng wrote: >> The ratelimit here is only for #CP, and its rate is not counted together >> with other types of faults. If a task gets here, it will exit. The only >> condition the ratelimit will trigger is when multiple tasks hit #CP at once, >> which is unlikely. Are you suggesting that we do not need the ratelimit >> here? > > I'm trying to first find out why is it there. > > Is this something you've hit during testing and thought, oh well, this > needs a ratelimit or was it added just because? > I have not run into the situation. Initially it was there because other faults have it. When you asked, I went through it and put out my reasoning. I think it still makes sense to keep it. -- Yu-cheng