Re: [PATCH v3 3/9] mm/huge_memory: honor MM_CP_TRY_CHANGE_WRITABLE in change_huge_pud()

["Carlos López" <clopez@suse.de>]

On 11/13/26 9:48 PM, Lorenzo Stoakes (ARM) wrote:
> On Thu, Nov 12, 2026 at 03:20:32PM +0100, Carlos López wrote:
>> change_protection() applies vma->vm_page_prot, which lacks the write bit
>> for CoW and write-notified mappings. MM_CP_TRY_CHANGE_WRITABLE makes
>> entries writable again if a write fault would only set the write bit.
>>
>> However, change_huge_pud() ignores the flag. For example, device DAX
>> mappings are write-notified once soft-dirty tracking is armed through
>> /proc/pid/clear_refs, and a protection change then leaves dirty PUDs
>> read-only, so the next write to each of them faults.
>>
>> Fix this by adding can_change_pud_writable(), based on
>> can_change_pmd_writable(). It omits the NUMA and uffd-wp checks, as
>> change_huge_pud() bails out on those changes.
>>
>> Signed-off-by: Carlos López <clopez@suse.de>
> 
> Is this a real problem that actual people have had?
> 
> The why of all this is still eluding me, especially for THP PUD...

Nobody reported it, but the new flag depends on it, see my reply to
David for this same patch.

>> [...]
>> +#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
>> +static inline bool can_change_pud_writable(struct vm_area_struct *vma,
>> +					   unsigned long addr, pud_t pud)
>> +{
>> +	struct page *page;
>> +
>> +	if (WARN_ON_ONCE(!(vma->vm_flags & VM_WRITE)))
>> +		return false;
>> +
>> +	/* Do we need write faults for softdirty tracking? */
>> +	if (vma_soft_dirty_enabled(vma) && !pud_soft_dirty(pud))
>> +		return false;
>> +
>> +	if (!(vma->vm_flags & VM_SHARED)) {
> 
> This is getting annoying now, you're seemingly _knowingly_ writing deprecated
> VMA flag API code on purpose.

Sorry, I based it on can_change_pmd_writable(), I'll use vma_test() instead.