Re: [PATCH] mm, numa: fix bad pmd by atomically check for pmd_trans_huge when marking page tables prot_numa

[Qian Cai]

> On Mar 9, 2020, at 11:05 AM, Rafael Aquini <aquini@xxxxxxxxxx> wrote:
> I'm still waiting on a similar system to become available, so I can
> work on your reproducer case, as well as to dig and wrap my head around it.
> 
> I still don't think that skipping the pmd_none() in the change-protection walk 
> should cause a big fuss like you observed here (yet, it seems it does), and 
> the fact that we need that race window to take the __split_huge_pmd() suggests,
> at least to me, that we might be missing this proper split somewhere else.

I have sent out another patch which should be more correct,

https://lore.kernel.org/lkml/20200310235846.1319-1-cai@xxxxxx/