From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 30ED6E77187 for ; Wed, 18 Dec 2024 19:08:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A59776B0083; Wed, 18 Dec 2024 14:08:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9E10F6B0085; Wed, 18 Dec 2024 14:08:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 85AB16B0088; Wed, 18 Dec 2024 14:08:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 640176B0083 for ; Wed, 18 Dec 2024 14:08:22 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id D4E3DB0570 for ; Wed, 18 Dec 2024 19:08:21 +0000 (UTC) X-FDA: 82909014342.06.8E4BA48 Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) by imf17.hostedemail.com (Postfix) with ESMTP id 69AC940004 for ; Wed, 18 Dec 2024 19:07:55 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=WFf8bwqI; spf=pass (imf17.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.208.176 as permitted sender) smtp.mailfrom=ryncsn@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1734548864; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=v0vEmagc0Uw2kVt1LsnMJ9amUc/CZvkb/qoJZ4IqFhE=; b=ryePtVKDhZ3UjYq5JVS1qCDSRdm91PUVm5CbAyvcpOYHBtNB7KWy1cD/dGD6QdmWxX+GEa HcJbB4c30etMA0/0GwmZ9Ru4FhXvAoW0UJ8KEJxqrQpsOn0gaLeOul6ISh6/Ej+eZ01jB0 U5celOStqQykGpMoTPb4OkH7b+2ucNI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734548864; a=rsa-sha256; cv=none; b=qk2uIKiFm5jDUfGw/mi1lfY/KYxuuKPjgAMhxNo6LfbTfRtqWbVMvJrwJfla0DuCKHBneE RalWRuLbaf63ymC+mILHfLnPafR0cfOVGhQRrIZwThYI1VRRwtAUnCoREX7ehxvhFEmCjU oiSMB2SRXgq6sU/xNb9YB11IJ98rmkM= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=WFf8bwqI; spf=pass (imf17.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.208.176 as permitted sender) smtp.mailfrom=ryncsn@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-lj1-f176.google.com with SMTP id 38308e7fff4ca-30227ccf803so445111fa.2 for ; Wed, 18 Dec 2024 11:08:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734548898; x=1735153698; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=v0vEmagc0Uw2kVt1LsnMJ9amUc/CZvkb/qoJZ4IqFhE=; b=WFf8bwqIE6UM7ztOjHx5jhyX3r+7Q4aqMGmzGXFTCAYQ9aV++VKJ0FPbgls/TzwriC efbHZswPA9t02OxSS2kgrih4LbToC8tzjnrAdOV5B1srFueCyjtYnQSqD0MEz9+lWhw9 lTtmGSMQYkYeCialH7bbDLIR+Vdg5ZaeohcJZWUlxoiFOUmaHhOPyCuO07Fmucb5PsLd 0sqMcrHj9cTOAUFEP9uQ939zG9GIAE0FR+yxfW3RuaxNBYchW0AQehFgFDzgWcoKCfI7 bcNIhIBrm8keqnyQbYoPY0/F8flsuwac2VhXJK9/L2NS2u2KQDC4OpxsC5Ick+Etamu6 CHAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734548898; x=1735153698; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=v0vEmagc0Uw2kVt1LsnMJ9amUc/CZvkb/qoJZ4IqFhE=; b=CfRyroPzuYFeQ4VBjR2ebRg6PTYZKfwpLytts9Rvqdyk89X3x5piiU6QUyMKSnCX3f I+z4g4XGI+N5l3ZvlX71YUKKMEJxTMmGZX3d9wNXg5WFaozukVEmjcpdim2qqCUCMhr7 isXnkf1r1PAmKs6R2sdjeH29ZW4eqTbJHVCp4wD299HmrkIf7Ru3iliCKnVFk5vOXhYd w7g8NOvs9z10nDsYXRyesLkw3J2MpQJzyoEhcltoIsQDDS+DxubBA4x66tOQ3QQJL4Bj VmVEfeoFHEfzDX2jo+gOmtNEoSpf0ifCLoPPwMIWVZnvPS6er+LUCL+egfINvuxc8blZ Do7w== X-Forwarded-Encrypted: i=1; AJvYcCUj1l8kSooq7OjB+71TZQWMvDLlXMC9JjW3o1SByBL6IGQ2lwD+EPdlcpsi+5uSnp8JSl4hBQvLPg==@kvack.org X-Gm-Message-State: AOJu0YzXKzwp5Sg5A/B/ueqybagdMJDn/rfvYeNuQdxmt14prk2/AAkc uMYXDQRHTO7EwJ+wi6TvD5UnIr6GH3as7V/p3BauH6V2V9qEJUN5DOiTPQ6ktR5npyj61at1hhF E9QV4PH7kS+ely+zuojq04Q+UdHE= X-Gm-Gg: ASbGncsmYFE4fwq1O4+YHNwTotrEJSzpNARzV18k/AdQHag0hOouG0RtgfW4YWucW+h 60l4iVfVCu55ro1/0h9NuTdOScWmS7pxw8SzIpg== X-Google-Smtp-Source: AGHT+IEk26FztkaEDI9wu3X4gElQGYUn/IizPeIAHN5BrO+n7rDKym9OUWxwonLO2GoaGxGdAberQeOmBrKMnPDNDso= X-Received: by 2002:a05:651c:b22:b0:300:5c57:5242 with SMTP id 38308e7fff4ca-3044da70d31mr13810811fa.7.1734548897548; Wed, 18 Dec 2024 11:08:17 -0800 (PST) MIME-Version: 1.0 References: <675d01e9.050a0220.37aaf.00be.GAE@google.com> In-Reply-To: From: Kairui Song Date: Thu, 19 Dec 2024 03:08:01 +0800 Message-ID: Subject: Re: [syzbot] [mm?] WARNING in lock_list_lru_of_memcg To: syzkaller-bugs@googlegroups.com Cc: Sasha Levin , Yu Zhao , syzbot , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 69AC940004 X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: ky8yc7117fdskd3epntmodwa18krxtr7 X-HE-Tag: 1734548875-640225 X-HE-Meta: U2FsdGVkX1+QJ+OJyBtWlm82RUp4ZQ6o3YiRy8+/mHImt8qKAzF9yEPZSxQHsb01N1+E5/i5g4YTOPGTAdw5/ZxH6YhRPHPLajIYI443Pd2sks57BxiZhMhshowauKkV1xEXkTy8bcA5L95yY40D6MZv1sSGrFvrjOfjP7S044nQlSv5h2sNmwzxp9GNSpgfm4eLJQPLC7rfnjzfhrMmk7P51QQdnsKIMe4N8xN1smwgPoPAV9rcypAEsSekN7SzRNfWppddPbD3GX9q6PNoIBSAvvaJA8re3wNk2PnVM3akjjynxDIwWgIYVhOSzcxv3T4/LC6SfADRB9je5Y98Ha4YDnN109JRn/DyGQ+ITj4qyR4qaNtCyvAMFH/Di9XnSZt88JRr2avqEofTTmAfe4ddTNRZnzdKvRX+0KYGb7F7ayq7e0WCrgDMsI+m/scoIgMOkgJm3rvRlstNnx+v5VGYJF0sSjRNfCn4c7kvCoWg5/7/DUS6R7qJra6OX3ZYQkSj34TjnHAOKnWjBeEhHos0Vtx+97vj2iHtKDAjHwa7F13A64xbulW9B2iYeUfTW60N6xPmwR7LckXVgK9qz7BHtj+2SkkmFmoVzl8WvT6+0OYtstvvTef+rBdKhdyXko551tNr7ztCDwYxmb7bhz0Lzf9DAUrRT+9ZwIn/2U/Nn/oYqvqDp34K3lUQYSw6HroCT+IjcTQJFHEU/Bttr23JR6t3tAcvA5NNZLZgCLMgXeoV5ubMNGhnA+lWmw5rPT1LCOYZFkZsBahPDbATmE0/dmGAPj7PxDOx/Rar9YLI/a/i3Gn3Y8IMaFOLAU9rE5wn1jIdHvbidaWO2H0BUnraif2qxZdsz9+7pAsWc0XxrsdD93cN4Ogd4EDhU2UXEEfSlbYLXxRnJi8HZr4E464uGxxnQ5MEv0Gv8ROMKxF5K7g58m0xHEqY72A/x0b/dAgdjkG5M3zQxJGzl32 +CyaV2og KNtjsm8yDzXtTl/INe2IfdNhsm7WyTfJh3lJZJOhFjL+kQOXQpxzn3jgo+NctuewqcEtmhJOE4V6XDWBt+iIGWnskiBraxIA+7pVUjyVNB32iBcDiN+OZsJFV5rJox5PsvVvIuHux5m1vxz0VorBLf4nsWHqghkLRVHQsbbBokUd7Px+2N35Nt6dGeuS3Ex/+L8xtBwvutFXMP5SEw5xDtrrBsN+dZMgYslJmRBXapu/vnE1hLzRwCT/qtAATVA2ARHrDqtEfQvx7CpHlfmZ+mm/pD2Qoclh1K/Nd/tvFh2+6f3FpM4zN5httLRMlIH7LQgdAABeNykK1YHk/cVVgRZT3+M9DPLy5q6xK5bCqGZ2eHdPnE3l6zMy6k29FoNg4Uu9uhZFj4q5BPZB2T0dg8OdEdXEyNaCvpHu40mpQhomCeRAeSC145XxYR2Q9csHDdlSzPGZc8TQb8BfFPiyrkmIFnLNE/Ln+Ms9yReiLsTQJPDINXz7LS4SRXkiSwmBTdXKY1SDEduKhR4QgqbkmoGU6eAQPm4qnMTVfNdpgc0iXqbtbtXSqLxjcFGb4wKCyyunKA59rPoG4+2xn56nmOBLmgsQrjlTC8KDyjxlJ/+vPzSv4x0x/AaRRFU0Ii1+EeIO2DntCNaHMbisaMqcxyl/qaZ4WFKeaj1JmLTj95VjrSPvABqe5eNur0HtHQHt1jh+Wi502iL/gadhALwiSstJOFxDR2Wz4tUxMvntNFP2Ll/ZbLjMD2cA+XZ8pS+KB9pVDz3WcXwKJbOMaVcLGNT01bFQUGwE1QHjSHH8Fzbo3rcLiPgsMu3tRyirhWQcNlkGQ8yokSWJAHuhR7wcR9QhvXVqBwt3rHUcjQ9Ta+3ISgjqtrXArSx4CxGoITqWAWQ2i1HaMGdr1SfFU1io6E30Do1G+esQeEIC1XQ+D/d2z4jftNXhttTJz7ObP0Xz54Tre5ElR22drAI8vx1WYCymr9dlg e71aMzNw uxi+UoQXONvwK24RkCXTdfE98vsVBPJSIKFPO7vd3tMZcMtyCGVNxb8t3rtKH8KCyuASJw1MV19DRQWHFXqfnVgk1qy+uu3SFIN+C4Ote5Wm0MMG+eJtcCR5y33oCp+7 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Dec 18, 2024 at 2:19=E2=80=AFAM Kairui Song wrot= e: > > Thanks! Looking > > > Sasha Levin =E4=BA=8E 2024=E5=B9=B412=E6=9C=8817=E6= =97=A5=E5=91=A8=E4=BA=8C 02:39=E5=86=99=E9=81=93=EF=BC=9A > > > > On Sun, Dec 15, 2024 at 07:45:38PM -0700, Yu Zhao wrote: > > >Hi Kairui, > > > > > >On Sun, Dec 15, 2024 at 10:45=E2=80=AFAM Kairui Song wrote: > > >> > > >> On Sun, Dec 15, 2024 at 3:43=E2=80=AFAM Kairui Song wrote: > > >> > > > >> > On Sat, Dec 14, 2024 at 2:06=E2=80=AFPM Yu Zhao wrote: > > >> > > > > >> > > On Fri, Dec 13, 2024 at 8:56=E2=80=AFPM syzbot > > >> > > wrote: > > >> > > > > > >> > > > Hello, > > >> > > > > > >> > > > syzbot found the following issue on: > > >> > > > > > >> > > > HEAD commit: 7cb1b4663150 Merge tag 'locking_urgent_for_v6.= 13_rc3' of g.. > > >> > > > git tree: upstream > > >> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=3D16= e96b30580000 > > >> > > > kernel config: https://syzkaller.appspot.com/x/.config?x=3Dfe= e25f93665c89ac > > >> > > > dashboard link: https://syzkaller.appspot.com/bug?extid=3D38a0= cbd267eff2d286ff > > >> > > > compiler: Debian clang version 15.0.6, GNU ld (GNU Binut= ils for Debian) 2.40 > > >> > > > > > >> > > > Unfortunately, I don't have any reproducer for this issue yet. > > >> > > > > > >> > > > Downloadable assets: > > >> > > > disk image (non-bootable): https://storage.googleapis.com/syzb= ot-assets/7feb34a89c2a/non_bootable_disk-7cb1b466.raw.xz > > >> > > > vmlinux: https://storage.googleapis.com/syzbot-assets/13e08332= 9dab/vmlinux-7cb1b466.xz > > >> > > > kernel image: https://storage.googleapis.com/syzbot-assets/fe3= 847d08513/bzImage-7cb1b466.xz > > >> > > > > > >> > > > IMPORTANT: if you fix the issue, please add the following tag = to the commit: > > >> > > > Reported-by: syzbot+38a0cbd267eff2d286ff@syzkaller.appspotmail= .com > > >> > > > > > >> > > > ------------[ cut here ]------------ > > >> > > > WARNING: CPU: 0 PID: 80 at mm/list_lru.c:97 lock_list_lru_of_m= emcg+0x395/0x4e0 mm/list_lru.c:97 > > >> > > > Modules linked in: > > >> > > > CPU: 0 UID: 0 PID: 80 Comm: kswapd0 Not tainted 6.13.0-rc2-syz= kaller-00018-g7cb1b4663150 #0 > > >> > > > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.= 3-debian-1.16.3-2~bpo12+1 04/01/2014 > > >> > > > RIP: 0010:lock_list_lru_of_memcg+0x395/0x4e0 mm/list_lru.c:97 > > >> > > > Code: e9 22 fe ff ff e8 9b cc b6 ff 4c 8b 7c 24 10 45 84 f6 0f= 84 40 ff ff ff e9 37 01 00 00 e8 83 cc b6 ff eb 05 e8 7c cc b6 ff 90 <0f> = 0b 90 eb 97 89 e9 80 e1 07 80 c1 03 38 c1 0f 8c 7a fd ff ff 48 > > >> > > > RSP: 0018:ffffc9000105e798 EFLAGS: 00010093 > > >> > > > RAX: ffffffff81e891c4 RBX: 0000000000000000 RCX: ffff88801f53a= 440 > > >> > > > RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000= 000 > > >> > > > RBP: ffff888042e70054 R08: ffffffff81e89156 R09: 1ffffffff2032= cae > > >> > > > R10: dffffc0000000000 R11: fffffbfff2032caf R12: ffffffff81e88= e5e > > >> > > > R13: ffffffff9a3feb20 R14: 0000000000000000 R15: ffff888042e70= 000 > > >> > > > FS: 0000000000000000(0000) GS:ffff88801fc00000(0000) knlGS:00= 00000000000000 > > >> > > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > >> > > > CR2: 0000000020161000 CR3: 0000000032d12000 CR4: 0000000000352= ef0 > > >> > > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000= 000 > > >> > > > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000= 400 > > >> > > > Call Trace: > > >> > > > > > >> > > > list_lru_add+0x59/0x270 mm/list_lru.c:164 > > >> > > > list_lru_add_obj+0x17b/0x250 mm/list_lru.c:187 > > >> > > > workingset_update_node+0x1af/0x230 mm/workingset.c:634 > > >> > > > xas_update lib/xarray.c:355 [inline] > > >> > > > update_node lib/xarray.c:758 [inline] > > >> > > > xas_store+0xb8f/0x1890 lib/xarray.c:845 > > >> > > > page_cache_delete mm/filemap.c:149 [inline] > > >> > > > __filemap_remove_folio+0x4e9/0x670 mm/filemap.c:232 > > >> > > > __remove_mapping+0x86f/0xad0 mm/vmscan.c:791 > > >> > > > shrink_folio_list+0x30a6/0x5ca0 mm/vmscan.c:1467 > > >> > > > evict_folios+0x3c86/0x5800 mm/vmscan.c:4593 > > >> > > > try_to_shrink_lruvec+0x9a6/0xc70 mm/vmscan.c:4789 > > >> > > > shrink_one+0x3b9/0x850 mm/vmscan.c:4834 > > >> > > > shrink_many mm/vmscan.c:4897 [inline] > > >> > > > lru_gen_shrink_node mm/vmscan.c:4975 [inline] > > >> > > > shrink_node+0x37c5/0x3e50 mm/vmscan.c:5956 > > >> > > > kswapd_shrink_node mm/vmscan.c:6785 [inline] > > >> > > > balance_pgdat mm/vmscan.c:6977 [inline] > > >> > > > kswapd+0x1ca9/0x36f0 mm/vmscan.c:7246 > > >> > > > kthread+0x2f0/0x390 kernel/kthread.c:389 > > >> > > > ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 > > >> > > > ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 > > >> > > > > > >> > > > > >> > > This one seems to be related to "mm/list_lru: split the lock to > > >> > > per-cgroup scope". > > >> > > > > >> > > Kairui, can you please take a look? Thanks. > > >> > > > >> > Thanks for pinging, yes that's a new sanity check added by me. > > >> > > > >> > Which is supposed to mean, a list_lru is being reparented while th= e > > >> > memcg it belongs to isn't dying. > > >> > > > >> > More concretely, list_lru is marked dead by memcg_offline_kmem -> > > >> > memcg_reparent_list_lrus, if the function is called for one memcg,= but > > >> > now the memcg is not dying, this WARN triggers. I'm not sure how t= his > > >> > is caused. One possibility is if alloc_shrinker_info() in > > >> > mem_cgroup_css_online failed, then memcg_offline_kmem is called ea= rly? > > >> > Doesn't seem to fit this case though.. Or maybe just sync issues w= ith > > >> > the memcg dying flag so the user saw the list_lru dying before see= ing > > >> > memcg dying? The object might be leaked to the parent cgroup, seem= s > > >> > not too terrible though. > > >> > > > >> > I'm not sure how to reproduce this. I will keep looking. > > >> > > >> Managed to boot the image and using the kernel config provided by bo= t, > > >> so far local tests didn't trigger any issue. Is there any way I can > > >> reproduce what the bot actually did? > > > > > >If syzbot doesn't have a repro, it might not be productive for you to > > >try to find one. Personally, I would analyze stacktraces and double > > >check the code, and move on if I can't find something obviously wrong. > > > > > >> Or provide some patch for the bot > > >> to test? > > > > > >syzbot only can try patches after it finds a repro. So in this case, > > >no, it can't try your patches. > > > > > >Hope the above clarifies things for you. > > > > Chiming in here as LKFT seems to be able to hit a nearby warning on > > boot. > > > > The link below contains the full log as well as additional information > > on the run. > > > > https://qa-reports.linaro.org/lkft/linux-mainline-master/build/v6.13-rc= 2-232-g4800575d8c0b/testrun/26323524/suite/log-parser-test/test/exception-w= arning-cpu-pid-at-mmlist_lruc-list_lru_del/details/ > > > After some investigation, this mm/list_lru.c:80 warn should be fixed by: diff --git a/mm/list_lru.c b/mm/list_lru.c index f93ada6a207b..7d69434c70e0 100644 --- a/mm/list_lru.c +++ b/mm/list_lru.c @@ -77,7 +77,6 @@ lock_list_lru_of_memcg(struct list_lru *lru, int nid, struct mem_cgroup *memcg, spin_lock(&l->lock); nr_items =3D READ_ONCE(l->nr_items); if (likely(nr_items !=3D LONG_MIN)) { - WARN_ON(nr_items < 0); rcu_read_unlock(); return l; } @@ -450,6 +449,7 @@ static void memcg_reparent_list_lru_one(struct list_lru *lru, int nid, list_splice_init(&src->list, &dst->list); if (src->nr_items) { + WARN_ON(src->nr_items < 0); dst->nr_items +=3D src->nr_items; set_shrinker_bit(dst_memcg, nid, lru_shrinker_id(lru)); } This should be caused by a short time window between `mlru =3D xas_store(&xas, NULL);` and `memcg_reparent_list_lru_one` in memcg_reparent_list_lrus, if any user delete an item from list lru during this time window, it may cause the parents nr_items went negative and trigger this warning, as the child list_lru still holding the actual item but it's the parents counter get updated. The counter will be synced by the reparent so it is not a problem. We can keep this WARN_ON just move it to the time of the reparent progress, this removes this false warning while still keep avoiding misuse from users. I'm not 100% sure this is exactly the LKFT warning, but will send this out after double confirmation as it does need to be fixed. And the mm/list_lru.c:97 seems a different problem, I suspect memcg_list_lru_alloc wasn't called for shadow_nodes but kswapd started early. If this is the case, it might not be a new issue, just get exposed by this new sanity check, this can be bypassed with: diff --git a/mm/list_lru.c b/mm/list_lru.c index f93ada6a207b..5f124a661ee8 100644 --- a/mm/list_lru.c +++ b/mm/list_lru.c @@ -81,6 +81,7 @@ lock_list_lru_of_memcg(struct list_lru *lru, int nid, struct mem_cgroup *memcg, rcu_read_unlock(); return l; } + VM_WARN_ON(!css_is_dying(&memcg->css)); if (irq) spin_unlock_irq(&l->lock); else @@ -94,7 +95,6 @@ lock_list_lru_of_memcg(struct list_lru *lru, int nid, struct mem_cgroup *memcg, rcu_read_unlock(); return NULL; } - VM_WARN_ON(!css_is_dying(&memcg->css)); memcg =3D parent_mem_cgroup(memcg); goto again; } But I'm not sure if it indicates some potential (and previously existing) list_lru leak, keeping this sanity check at current place could be helpful for catching missing memcg_list_lru_alloc call. Will try to send a proper fix after checking the root cause and reproduce it locally.