On Tue, 12 Jul 2022 at 14:40, Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > On Tue, Jul 12, 2022 at 08:54:28AM +0200, Dmitry Vyukov wrote: > > On Mon, 11 Jul 2022 at 22:47, Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > > > > > On Mon, Jul 11, 2022 at 01:38:08PM -0700, Andrew Morton wrote: > > > > On Sat, 09 Jul 2022 00:13:23 -0700 syzbot <syzbot+a785d07959bc94837d51@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > > Hello, > > > > > > > > > > syzbot found the following issue on: > > > > > > > > > > HEAD commit: c1084b6c5620 Merge tag 'soc-fixes-5.19-2' of git://git.ker.. > > > > > git tree: upstream > > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=14967ccc080000 > > > > > kernel config: https://syzkaller.appspot.com/x/.config?x=916233b7694a38ff > > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=a785d07959bc94837d51 > > > > > compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2 > > > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=122ae834080000 > > > > > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > > > > Reported-by: syzbot+a785d07959bc94837d51@xxxxxxxxxxxxxxxxxxxxxxxxx > > > > > > > > > > 2022/07/05 05:22:17 executed programs: 828 > > > > > 2022/07/05 05:22:23 executed programs: 846 > > > > > 2022/07/05 05:22:30 executed programs: 866 > > > > > 2022/07/05 05:22:37 executed programs: 875 > > > > > BUG: memory leak > > > > > > > > Thanks. Presumably due to khugepaged changes. > > > > > > Huh, I was expecting it to be something I'd messed up. I've been > > > looking at it today, but no luck figuring it out so far. > > > > > > > Can we expect a bisection search? > > > > > > We only have a syz reproducer so far, and if I understand correctly, > > > it's probably because this is a flaky test (because it's trying to > > > find something that's a race condition). > > > > > > I expect a bisection search to go badly wrong if this is true. > > > > Is it possible that parts of xas are not freed on the error paths? > > I don't immediately see where anything is freed on these error paths: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/xarray.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n681 > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/xarray.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n721 > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/khugepaged.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n1675 > > There's nothing to free; if a node is allocated, then it's stored in > the tree where it can later be found and reused. What I was thinking of is: The leaked memory is allocated with: xas_create_range(&xas); here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/khugepaged.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n1670 So I assumed the nodes stored in the xas object, which is local to the collapse_file() function. So if we do "goto out" here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/khugepaged.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n1676 There does not seem to be anything that frees anything stored in the xas: out: VM_BUG_ON(!list_empty(&pagelist)); if (!IS_ERR_OR_NULL(*hpage)) mem_cgroup_uncharge(page_folio(*hpage)); /* TODO: tracepoints */ }
