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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 34A92C433F5 for ; Wed, 5 Oct 2022 11:16:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B287C6B0072; Wed, 5 Oct 2022 07:16:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AB0BE8E0001; Wed, 5 Oct 2022 07:16:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 902FC6B0074; Wed, 5 Oct 2022 07:16:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 778106B0072 for ; Wed, 5 Oct 2022 07:16:38 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 4720C80F7A for ; Wed, 5 Oct 2022 11:16:38 +0000 (UTC) X-FDA: 79986642876.12.76D28DF Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf20.hostedemail.com (Postfix) with ESMTP id 1BFAF1C002E for ; Wed, 5 Oct 2022 11:16:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=jlNnOtdLgWp1J9aNwcNLhyUtm43E+rBcw5a9tZw4tKM=; b=jdvZQ1JWuioxO53YHfWyMIlwPO Crt4VyrM4DpQFGABM8ihqD6uCQ9lOmSnu6Vzh+FyURgi5JSApO0rWofMPZ+QiSuRPokJO+4lnLKKP w8oQ7pEDQ3kdIKkejORmZWIrpJAc5JfP6O+8uv9Dg0MZkd7ho74b7BbZ5ARN9R6EJenYFcapm2xiL yat+sxLvMINMLBWuQ7ATpDiS4Z1Kre/qrjly7jJFwPhZhXqksjDWGdEeOoOMcTKlt8HhLvBvmKcCs UC/aAdY8qrxzNlH1LwDNgOtOyOhiMQtjSaPc5HaBMx3+o46qEqgApTLVJs0DRLs/4h7TgkyMODVSv aGglGIUw==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1og2Nl-000JVi-9O; Wed, 05 Oct 2022 11:16:09 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 8ED00300205; Wed, 5 Oct 2022 13:16:03 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 778D620C48C87; Wed, 5 Oct 2022 13:16:03 +0200 (CEST) Date: Wed, 5 Oct 2022 13:16:03 +0200 From: Peter Zijlstra To: Andrew Cooper Cc: Rick Edgecombe , "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 , Borislav Petkov , 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 , Randy Dunlap , "Ravi V . Shankar" , Weijiang Yang , "Kirill A . Shutemov" , "joao.moreira@intel.com" , John Allen , "kcc@google.com" , "eranian@google.com" , "rppt@kernel.org" , "jamorris@linux.microsoft.com" , "dethoma@microsoft.com" , Yu-cheng Yu , Christoph Hellwig Subject: Re: [PATCH v2 08/39] x86/mm: Remove _PAGE_DIRTY from kernel RO pages Message-ID: References: <20220929222936.14584-1-rick.p.edgecombe@intel.com> <20220929222936.14584-9-rick.p.edgecombe@intel.com> <8d58f57f-cece-c197-2a8b-dd02b4e405bc@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8d58f57f-cece-c197-2a8b-dd02b4e405bc@citrix.com> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664968597; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=jlNnOtdLgWp1J9aNwcNLhyUtm43E+rBcw5a9tZw4tKM=; b=XCPpqf/HAhAqnrXQcBDXWRfqcRGAjhIUTUG8MTLmzl9CacrJpYB4KHyeb8UzFxgVKV6lF7 7aL2bLDX4tGGeZAtzTAjaJ22gPwiiuH5LTJsXWwXtLOUCH3qz8OFrl+ZszO/9108PEemJf qjTcCb19Iua2LSECZTQzM/AUch+g9nQ= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=jdvZQ1JW; dmarc=none; spf=none (imf20.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=peterz@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1664968598; a=rsa-sha256; cv=none; b=LV/jDXuYdgfP1Uf/oCfoCrBPpCc3yIPeWss3cxIlB2me68IbMVon1zP9VWLHcVFJJHx2zk I717u3JpQnk6WfDFSW3qMZDnvcjU6F+uurxTs8KRoDF9uz7nebGep7ZGEXy1/VgGHgbFQK c+BPeeQhzShVfBrPXYBGXCPDIyGoPYk= X-Stat-Signature: 3p6xij7du14m9cgfpfcjrtofeijw8jud X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 1BFAF1C002E Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=jdvZQ1JW; dmarc=none; spf=none (imf20.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=peterz@infradead.org X-HE-Tag: 1664968596-890721 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Oct 05, 2022 at 01:31:28AM +0000, Andrew Cooper wrote: > On 29/09/2022 23:29, Rick Edgecombe wrote: > > From: Yu-cheng Yu > > > > Processors sometimes directly create Write=0,Dirty=1 PTEs. > > Do they? (Rhetorical) > > Yes, this is a relevant anecdote for why CET isn't available on pre-TGL > parts, but it one of the more wrong things to have as the first sentence > of this commit message. > > The point you want to express is that under the CET-SS spec, R/O+Dirty > has a new meaning as type=shstk, so stop using this bit combination for > existing mappings. > > I'm not even sure it's relevant to note that CET capable processors can > set D on a R/O mapping, because that depends on !CR0.WP which in turn > prohibits CR4.CET being enabled. Whilst I agree that the Changelog is 'suboptimal' -- I do think it might be good to mention how we ended up at the current state where we explicitly set this non-sensical W=0,D=1 state. Looking at the git history this seems to be a bit of a hysterical accident, not something done on purpose to 'optimize' for these weird CPUs.