Re: [PATCH v2 08/39] x86/mm: Remove _PAGE_DIRTY from kernel RO pages

[Andrew Cooper]

On 05/10/2022 12:16, Peter Zijlstra wrote:
> 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 <yu-cheng.yu@xxxxxxxxx>
>>>
>>> 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.

Sure, but that's got nothing to do with hardware errata.

Having hardware set A/D bits is expensive.  Being a locked operation,
it's roughly a smp_mb() behind the scenes.

Therefore, when A/D tracking doesn't matter, traditional wisdom says set
both of them when creating the PTE.

It's only now that R/O+Dirty has a meaning (other than being a slightly
weird but safe bit combination), and we've got to be more careful about
using it.

~Andrew