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 8223FC77B75 for ; Mon, 22 May 2023 13:57:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 036B8280004; Mon, 22 May 2023 09:57:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F28D8900006; Mon, 22 May 2023 09:57:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DF087280004; Mon, 22 May 2023 09:57:16 -0400 (EDT) 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 CCA50900006 for ; Mon, 22 May 2023 09:57:16 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 8C900C01C8 for ; Mon, 22 May 2023 13:57:16 +0000 (UTC) X-FDA: 80818042872.26.1FAE370 Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by imf27.hostedemail.com (Postfix) with ESMTP id DEDEF40016 for ; Mon, 22 May 2023 13:57:13 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=none; spf=none (imf27.hostedemail.com: domain of penguin-kernel@I-love.SAKURA.ne.jp has no SPF policy when checking 202.181.97.72) smtp.mailfrom=penguin-kernel@I-love.SAKURA.ne.jp; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684763834; 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; bh=DibLnXcCC3IVLELB+dAQvUPq0shmDUdNjruHoIGO8f8=; b=ZhWKvO5EcFvRW3cnBWILXWvHtkB8IT+6UfEalPxfTc1nYqVYR/wMy/Ej8JXiON2jGdORT0 REgYWifSV+9RRmdDrza2qxJShzYgqLGubRjkzrHEVqJc12id+wPEZon0XCta/dzWG1m9iU XH0mlJghV0SjrhHAL+DN7ZOCDlTC3XA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684763834; a=rsa-sha256; cv=none; b=ySAlBazeXhyGwCY3CzgAtQh+6qtR+iEzh5Y9F1HlDJoypLaLl4vRV385PBr3AGjZkcTI8a RAjQXs+Nw2IOGewXcSt8kZkHI0zA3MzRtpxnY5GEqBouCA32oSo6mEUMorSu29j3NGFXHl pC8Jzwg0AN2qpBw6SFkE1lhjgSlvWjE= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=none; spf=none (imf27.hostedemail.com: domain of penguin-kernel@I-love.SAKURA.ne.jp has no SPF policy when checking 202.181.97.72) smtp.mailfrom=penguin-kernel@I-love.SAKURA.ne.jp; dmarc=none Received: from fsav114.sakura.ne.jp (fsav114.sakura.ne.jp [27.133.134.241]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 34MDv69P084831; Mon, 22 May 2023 22:57:06 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav114.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav114.sakura.ne.jp); Mon, 22 May 2023 22:57:06 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav114.sakura.ne.jp) Received: from [192.168.1.6] (M106072142033.v4.enabler.ne.jp [106.72.142.33]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id 34MDv5Pq084828 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 May 2023 22:57:06 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Message-ID: <65c99fe7-c6b8-aca9-e74a-754d882e64ba@I-love.SAKURA.ne.jp> Date: Mon, 22 May 2023 22:57:03 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH v2] mm/page_alloc: don't wake kswapd from rmqueue() unless __GFP_KSWAPD_RECLAIM is specified Content-Language: en-US To: "Huang, Ying" , Mel Gorman Cc: Andrew Morton , Vlastimil Babka , linux-mm References: <6d6fb601-6100-92b9-cea3-e7ebacc7693a@I-love.SAKURA.ne.jp> <20230513102314.md5ugj22xnv6mxob@techsingularity.net> <20230515073840.6yos3cisg2rlyw6i@techsingularity.net> <87wn196oew.fsf@yhuang6-desk2.ccr.corp.intel.com> From: Tetsuo Handa In-Reply-To: <87wn196oew.fsf@yhuang6-desk2.ccr.corp.intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: DEDEF40016 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: o4z37sf8iidkkuonzrtww6hg8t3fnkg4 X-HE-Tag: 1684763833-698106 X-HE-Meta: U2FsdGVkX18FfOnF9XKiTXJcyGu41a3Ll1SSQYW4qcX68GeQz3KGA8cfm6Prr+DruJoYVtOwMIUf2HF/dEJfPVm2cEBLJBqH3G/16FUvuH6wbNRn1cwAinwh27GUxaJ8JsBb9wSH3KZOnB3FrVecuIX1yZG5dt7wg74Rh/0GNtOWmfpNQe8mNxMD7MpdE5XzIUbcAhBiJ1k2hV57R0qIFbxVlZmDSKebDJS1NQmaLamd86MLriEGw4gsZTNvwGL7CvoOBwZErco5/tOq0Yu8e8Jk6Xnj4tEGxdTZYDq7VauE36JpgryQSBQF406KHq0KXXrmEU1bsZBfB7SWSu4JWS/N3sEPqF6wD9Hy5LrUf5TGycYgQiCQzzXpC78mmi0W+JNvXC18N2eqg6vJEQQcEipD9S7AtIRpx8z/VURqbh1i2g1Ts95j+S8JG9JNwRO2z12Pg8yRhweJv6DvM756lE3Y5jrlJd2SVm49Uw1F7fJ9xAblrvWQNG4/t29jIRCGMapsFfMGbpFTUuKuQWGn/rDWjWQcONVhvOuEf3VbkmqOUiB813CV76lZo856mibK6PZFYh/F+5n/ziriQaVOjorqyyYSL0JlWhyb1KTzKlk6N06G1j3rExJVUBBebVzpCGk2Ezw5p1vkdxMfEH9aZY1zeLYQ/s76KLkrOYObPhhaHjtUGqRvBEwKi9x//IoW5JWsGhBrsP2SsKzaPS0JcUl8XxxzqYGVEWSA3nrPry55pjmR7OgbHpaCHKxdue+aiV6qFnhNktciDBFgN9c5lwklbCJTUXU9Y2xn5LcUhR1+Rd5rOLKodeIAt3vXvBeNEQBc49I7x6qiJebxvE8S24cjuJZzBwfmR+Gz25m8A8+KMXYq9fsz0cmOONu2KM784wAlP4MxpH4CO3l4UjOnX8okAi2oKwyCuj6aRmyDwQdSYZxKI5yZE313ChnmBh5DhYyFltZYuLrXYA2hZY4 vVq+MNiv Wri0bTOfG4CsOBqAdxrSM4JqPewSe8FhAe6+q+nemfKOT/QT0ZFpMJUWRZrLqs1SAIFBRfv7SdbDtbHycg8yiyFnRyp1jPHOyifCPTqznuza7NlLW0OghFCg3D2dTHwO5nBHd319rnCdQz0z9bTQAOY4Cm8kMbu2+mWePc4ourlkc06TeMOW8IFFk3yWJcNDIYkUofZGW+f/LIviRo6F2c2wZuNHBort1DAlX3k3Nbv4Hj5JjyJNCAGhbIhrU2OnYaTum1llXJ7ZDlnwIcxFe19pdCEdp56fUa5+IEGSmFqsaln11S5UivvsHd/HsTX7/VVXqcVqz7+zzVFBfEtjUPzK6lKheGxxajog3fnIMj20G4DiVz6lAAcu6mTGVKpQGXUB5aTrts21CKI+7025z9i30zWYY6YDnAzw61xcpLp2Dds22GwDntTg/ag== 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 2023/05/16 10:44, Huang, Ying wrote: > Tetsuo Handa writes: > >> On 2023/05/15 16:38, Mel Gorman wrote: >>> On Sun, May 14, 2023 at 09:28:56AM +0900, Tetsuo Handa wrote: >>>> Commit 73444bc4d8f9 ("mm, page_alloc: do not wake kswapd with zone lock >>>> held") moved wakeup_kswapd() from steal_suitable_fallback() to rmqueue() >>>> using ZONE_BOOSTED_WATERMARK flag. >>>> >>>> Only allocation contexts that include ALLOC_KSWAPD (which corresponds to >>>> __GFP_KSWAPD_RECLAIM) should wake kswapd, for callers are supposed to >>>> remove __GFP_KSWAPD_RECLAIM if trying to hold pgdat->kswapd_wait has a >>>> risk of deadlock. >>> >>> kswapd_wait is a waitqueue so what is being held? It's safe for kswapd >>> to try wake itself as the waitqueue will be active when wakeup_kswapd() >>> is called so no wakeup occurs. If there is a deadlock, it needs a better >>> explanation. I believe I already stated why this patch is fixing a bug >>> but it wasn't deadlock related. >>> >> >> I noticed this problem ( pgdat->kswapd_wait might be held without >> __GFP_KSWAPD_RECLAIM ) when analyzing a different problem ( debugobject code >> is holding pgdat->kswapd_wait due to __GFP_KSWAPD_RECLAIM ) reported at >> https://syzkaller.appspot.com/bug?extid=fe0c72f0ccbb93786380 . >> >> I'm calling pgdat->kswapd_wait a lock, as lockdep uses it as a lock name. > > This has confused me much before. IIUC, the deadlock is unrelated with > kswapd wakeup itself. pgdat->kswapd_wait is the lock name and the lock > in fact is the spinlock: pgdat->kswapd_wait.lock. So the deadlock is, > > pgdat->kswapd_wait.lock holders take the pi lock > pi lock holders take the rq lock > rq lock holders take the timer base lock > timer base lock holders take the pgdat->kswapd_wait.lock (missing __GFP_KSWAPD_RECLAIM check) Yes, thank you for explanation. > > The above is based on analysis in > > https://lore.kernel.org/all/20190107204627.GA25526@cmpxchg.org/ > https://lore.kernel.org/linux-mm/d642e597-cf7d-b410-16ce-22dff483fd8e@I-love.SAKURA.ne.jp/ > > Tetsuo's patch avoids to take pgdat->kswapd_wait.lock when timer base > lock is held via adding check for __GFP_KSWAPD_RECLAIM, so breaks the > circular dependency chain. Yes. Mel, any questions on this patch? Thomas Gleixner described this lock as kswapd_wait::lock at https://lkml.kernel.org/r/168476016890.404.6911447269153588182.tip-bot2@tip-bot2 . Should I resubmit this patch with s/pgdat->kswapd_wait/pgdat->kswapd_wait.lock/ or s/pgdat->kswapd_wait/kswapd_wait::lock/ ? > >> The latter was explained at >> https://lore.kernel.org/linux-mm/d642e597-cf7d-b410-16ce-22dff483fd8e@I-love.SAKURA.ne.jp/ >> and we agreed that debugobject code needs to drop __GFP_KSWAPD_RECLAIM at >> https://lore.kernel.org/linux-mm/87fs809fwk.ffs@tglx/ . >> >> This patch is for making sure that debugobject code will not try to hold >> pgdat->kswapd_wait after debugobject code dropped __GFP_KSWAPD_RECLAIM. >> >> Thus, the problem this patch will fix is a deadlock related, isn't it? > > Best Regards, > Huang, Ying