On Tue, 27 Jan 2026, at 17:59, Ryan Roberts wrote:
> On 27/01/2026 15:03, Ard Biesheuvel wrote:
>> On Tue, 27 Jan 2026 at 10:45, Ryan Roberts <[email protected]> wrote:
>>>
>>> On 26/01/2026 09:26, Ard Biesheuvel wrote:
>>>> From: Ard Biesheuvel <[email protected]>
>>>>
>>>> Currently, pgattr_change_is_safe() is overly pedantic when it comes to
>>>> descriptors with the contiguous hint attribute set, as it rejects
>>>> assignments even if the old and the new value are the same.
>>>>
>>>> So relax the check to allow that.
>>>
>>> But why do we require the relaxation? Why are we re-writing a PTE in the
>>> first
>>> place? Either the caller already knows it's the same in which case it can be
>>> avoided, or it doesn't know in which case it is accidentally the same and
>>> couple
>>> probably just as easily been accidentally different? So it's better to warn
>>> regardless I would think?
>>>
>>
>> Based on rule RJQQTC in your reply to another patch in this series, my
>> conclusion here is that we can drop this check entirely.
>
> Hmm, I don't think that would be quite right; The rule permits _some_ bits of
> the PTE to change in a live mapping as long as the CONT bit remains unchanged.
> If you change the CONT bit on a live mapping, you could end up with
> overlapping
> TLB entries which would not go well on a system without bbml2.
I'm not suggesting we add it to 'mask', just to remove the check that forbids
any manipulation of an entry that has PTE_CONT set. So toggling PTE_CONT itself
would still be caught by the check.
