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 59CE3C43334 for ; Thu, 23 Jun 2022 02:52:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BBFF68E0111; Wed, 22 Jun 2022 22:52:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B6F6A8E00FA; Wed, 22 Jun 2022 22:52:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A5E328E0111; Wed, 22 Jun 2022 22:52:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 96E9E8E00FA for ; Wed, 22 Jun 2022 22:52:34 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 56726811CF for ; Thu, 23 Jun 2022 02:52:34 +0000 (UTC) X-FDA: 79607977428.08.BB99924 Received: from out1.migadu.com (out1.migadu.com [91.121.223.63]) by imf01.hostedemail.com (Postfix) with ESMTP id BAAEB40019 for ; Thu, 23 Jun 2022 02:52:33 +0000 (UTC) Date: Wed, 22 Jun 2022 19:52:21 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1655952751; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Ef3A1jFIk2ghqaCFE7HOz1021sh7n1eb4f8YSnsvNOY=; b=ViJppFGoJrwP5h680sfYXw1Y9s8cIL0aKAFEl4ZiYQmr6iSkfPVYxsUcUNGXKZIiTskxQU vmVaYfTWetOSQCr9u8cv9FiHmJy6qauUqIRPKcmypu9C/UxZtdgNyFLNfUl6Mh2NEklMIR +cRZGMjxvfj5QKmWeBjqr3rN77zYeqI= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Muchun Song Cc: syzbot , akpm@linux-foundation.org, cgroups@vger.kernel.org, hannes@cmpxchg.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mhocko@kernel.org, shakeelb@google.com, syzkaller-bugs@googlegroups.com Subject: Re: [syzbot] WARNING in folio_lruvec_lock_irqsave Message-ID: References: <0000000000004b03c805e2099bf0@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655952754; a=rsa-sha256; cv=none; b=T5ZOGLMkDthlM641ZJEZtZiM2la3FaZPKIfe5MwgFRDp2QgsW3vG42wMrFSW8BsFmjNfgr Mv6HRrqpLpCMcTCFV3Rl3KFOvfavkMtXUr7pZa6mhan/JPOp81vi7TFCTNl5vF9lERuVPY ek+9OUynFlIuaNMtK2tSnWqO1R6dWQw= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=ViJppFGo; spf=pass (imf01.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.121.223.63 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655952754; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Ef3A1jFIk2ghqaCFE7HOz1021sh7n1eb4f8YSnsvNOY=; b=gWRgMjQ/Xn03HF8a5s9f9heFbbypXab/wvbdwx7XWPNQko35C5efD0iq1ZwMOK8i2AsDKP Z5tBM+JdeDxUmlqaktGMvpycoGY6pGZxQpBlbOUV/NbYI3jHPectNuGlv8ug/lUVSTec4C zUxkk6d+SJjqWRvzbqsh+78IKZgBkkA= X-Rspamd-Queue-Id: BAAEB40019 X-Rspam-User: Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=ViJppFGo; spf=pass (imf01.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.121.223.63 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev X-Rspamd-Server: rspam08 X-Stat-Signature: bf399jnrqwzxmnjjnwh5ssoqxj36wuxa X-HE-Tag: 1655952753-244596 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: On Wed, Jun 22, 2022 at 11:33:48PM +0800, Muchun Song wrote: > On Wed, Jun 22, 2022 at 06:49:31AM -0700, syzbot wrote: > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit: ac0ba5454ca8 Add linux-next specific files for 20220622 > > git tree: linux-next > > console output: https://syzkaller.appspot.com/x/log.txt?x=14354c18080000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=12809dacb9e7c5e0 > > dashboard link: https://syzkaller.appspot.com/bug?extid=ec972d37869318fc3ffb > > compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2 > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > Reported-by: syzbot+ec972d37869318fc3ffb@syzkaller.appspotmail.com > > > > folio_put include/linux/mm.h:1227 [inline] > > put_page+0x217/0x280 include/linux/mm.h:1279 > > unmap_and_move_huge_page mm/migrate.c:1343 [inline] > > migrate_pages+0x3dc3/0x5a10 mm/migrate.c:1440 > > do_mbind mm/mempolicy.c:1332 [inline] > > kernel_mbind+0x4d7/0x7d0 mm/mempolicy.c:1479 > > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > > do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 > > entry_SYSCALL_64_after_hwframe+0x46/0xb0 > > page has been migrated, last migrate reason: mempolicy_mbind > > ------------[ cut here ]------------ > > WARNING: CPU: 1 PID: 18925 at include/linux/memcontrol.h:800 folio_lruvec include/linux/memcontrol.h:800 [inline] > > The warning here is "VM_WARN_ON_ONCE_FOLIO(!memcg && !mem_cgroup_disabled(), folio)", > the memcg returned by folio_memcg() seems to be NULL which has 2 possibility, one is > that objcg returned by folio_objcg() is NULL, another is that obj_cgroup_memcg(objcg) > returns NULL. However, obj_cgroup_memcg() always returns a valid memcg. So Most likely > objcg is NULL meaning this page is not charged to memcg. Is this possible for LRU pages? > > I am not sure if this issue is caused by my commit cca700a8e695 ("mm: lru: use lruvec > lock to serialize memcg changes") since I have removed folio_test_clear_lru() check > from folio_batch_move_lru(). We know that a non-lru page may be not charged to memcg. > But is it possible for a non-lru page to be passed to folio_batch_move_lru()? Seems > impossible. Right? I am not very confident about this commit, hopefully, someone can > review it. How about to temporarily drop it? I was about to suggest it anyway during the review: it's a standalone optimization and the main patchset is already quite big and complex, so probably easier to validate it separately. Thanks!