On Wed, May 17, 2023 at 07:40:59PM +0100, Lorenzo Stoakes wrote: > On Wed, May 17, 2023 at 02:37:41PM -0400, Peter Xu wrote: > > On Wed, May 17, 2023 at 06:20:55PM +0100, Lorenzo Stoakes wrote: > > > On Wed, May 17, 2023 at 11:04:07AM -0400, Peter Xu wrote: > > > > It seems vma merging with uffd paths is broken with either > > > > register/unregister, where right now we can feed wrong parameters to > > > > vma_merge() and it's found by recent patch which moved asserts upwards in > > > > vma_merge() by Lorenzo Stoakes: > > > > > > > > https://lore.kernel.org/all/ZFunF7DmMdK05MoF@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ > > > > > > > > The problem is in the current code base we didn't fixup "prev" for the case > > > > where "start" address can be within the "prev" vma section. In that case > > > > we should have "prev" points to the current vma rather than the previous > > > > one when feeding to vma_merge(). > > > > > > This doesn't seem quite correct, perhaps - "where start is contained within vma > > > but not clamped to its start. We need to convert this into case 4 which permits > > > subdivision of prev by assigning vma to prev. As we loop, each subsequent VMA > > > will be clamped to the start." > > > > I think it covers more than case 4 - it can also be case 0 where no merge > > will happen? > > Ugh please let's not call a case that doesn't merge by a number :P but sure of > course it might also not merge. To me the original paragraph was still fine. But if you prefer your version (which I'm perfectly fine either way if you'd like to spell out what cases it'll trigger), it'll be: It's possible that "start" is contained within vma but not clamped to its start. We need to convert this into either "cannot merge" case or "can merge" case 4 which permits subdivision of prev by assigning vma to prev. As we loop, each subsequent VMA will be clamped to the start. Does that look good to you? Thanks, -- Peter Xu
