* Hugh Dickins <hughd@xxxxxxxxxx> [230129 01:49]: > On Fri, 27 Jan 2023, Hugh Dickins wrote: > > On Fri, 27 Jan 2023, David Hildenbrand wrote: > > > On 26.01.23 19:57, Matthew Wilcox wrote: > > > > On Wed, Jan 25, 2023 at 11:59:16PM +0000, Sanan Hasanov wrote: > > > >> Good day, dear maintainers, > > > >> > > > >> We found a bug using a modified kernel configuration file used by syzbot. > > > >> > > > >> We enhanced the coverage of the configuration file using our tool, > > > >> klocalizer. > > > >> > > > >> Kernel Branch: 6.2.0-rc5-next-20230124 > > > >> Kernel > > > >> config: https://drive.google.com/file/d/1MZSgIF4R9QfikEuF5siUIZVPce-GiJQK/view?usp=sharing > > > >> Reproducer: https://drive.google.com/file/d/1H5KWkT9VVMWTUVVgIaZi6J-fmukRx-BM/view?usp=sharing > > > >> > > > >> Thank you! > > > >> > > > >> Best regards, > > > >> Sanan Hasanov > > This is a very interesting find: the thanks go to you. > ... > Upstream's fine; on next-20230127 (with David's repro) it bisects to > 5ddaec50023e ("mm/mmap: remove __vma_adjust()"). I think I'd better > hand on to Liam, rather than delay you by puzzling over it further myself. Thanks Hugh! ... > > > Indeed, the mapcount of the subpage is 2 instead of 1. The subpage is only > > > mapped into a single > > > page table (no fork() or similar). > > Yes, that mapcount:2 is weird; and what's also weird is the index:0x20003: > what is remove_migration_pte(), in an mbind(0x20002000,...), doing with > index:0x20003? > > My guess is that the remove-__vma_adjust() commit is not properly updating > vm_pgoff into non_vma in some case: so that when remove_migration_pte() > looks for where to insert the new pte, it's off by one page. That looks to be exactly correct. I am setting the vm_pgoff to the wrong value in case 8 (for lack of a better name). > > > > > > > I created this reduced reproducer that triggers 100%: > > Very helpful, thank you. Yes, thank you very much for find this bug and the reproducer. ... Thanks, Liam
