At first I thought like Andrew, that it's glaringly wrong on the exitpath; but then changed my mind.

When munmapping, we certainly can arrive here with an unaligned addrand next; but in that case rwsem_is_locked.

Whereas in exiting, rwsem is not locked, but we're going linearly upwards,and whenever we walk into a pmd_trans_huge area, both addr and next shouldbe hpage aligned: the vma bounds are unsuited to THP if they're unaligned.

Other cases equally should not arise: madvise MADV_DONTNEED shouldhave rwsem_is_locked; and truncation or hole-punching shouldn't bepossible on a pure-anonymous (!vma->vm_ops) area considered for THP.

But I cannot remember what brought me here before: a crash in testingon one of my machines, which further investigation root-caused elsewhere?or a report from someone else? or noticed when auditing another problem?I'm frustrated not to recall.

> > I'm not sure if that's indeed the issue or not, but note that this is> the first time I've managed to trigger that with the fuzzer, and it's> not that easy to reproduce. Which is a bit odd for code that was there> for 4 months...

I'm keeping off the linux-next for the moment; I'll worry about thismore if it shows up when we try 3.5-rc1. Your fuzzing tells that mylogic above is wrong, but maybe it's just a passing defect in next.