On Wed, 20 Jul 2022, Zach O'Keefe wrote: > On Wed, Jul 20, 2022 at 10:22 AM Yang Shi <shy828301@xxxxxxxxx> wrote: > > On Wed, Jul 20, 2022 at 4:13 AM Zach O'Keefe <zokeefe@xxxxxxxxxx> wrote: > > > > > > A pmd should not cross a VMA boundary, which is normally enforced by > > > vma_adjust_trans_huge(), and assumed by e.g. __split_huge_pmd_locked(). > > > > > > In this regard, the transhuge_vma_suitable() check in > > > hugepage_vma_check() is not redundant with the transhuge_vma_suitable() > > > check previously in hugepage_vma_revalidate(). > > > > > > The former validates the VMA itself, and checks that *some* memory > > > in the VMA is suitable to collapse while the latter validates if > > > collapsing at a specific address is suitable. By removing the check on > > > the faulting address, we've inadvertently allowed collapse of a pmd that > > > can cross vma->vm_end. Revert this change. > > > > Aha, yeah, nice catch. > > > > Reviewed-by: Yang Shi <shy828301@xxxxxxxxx> > > > > Thanks Yang. Also, hughd found it :) In hindsight, I think it's > actually customary to add a "Reported-by: Hugh Dickins > <hughd@xxxxxxxxxx>" - but since the previous patch will just be > dropped and never see the light of day, I guess the value there is > diminished. Anyways - credit goes to Hugh :) Thanks Zach, no probs, and as you say it would have vanished anyway. It was something I hit in testing maple tree, and at first thought a consequence of maple tree's (previous) brk handling: https://lore.kernel.org/linux-mm/a6736ccf-fb45-5777-ca28-575297f1879f@xxxxxxxxxx/ (the "coincident" paragraph). But a similar crash occurred when I took that out of the picture: maple tree not to blame at all - apology to Liam. Hugh
