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 A7CF5C7EE22 for ; Tue, 16 May 2023 01:45:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2F17A900004; Mon, 15 May 2023 21:45:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2A147900002; Mon, 15 May 2023 21:45:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 16A7A900004; Mon, 15 May 2023 21:45:25 -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 039A6900002 for ; Mon, 15 May 2023 21:45:25 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id CD34A1C8C69 for ; Tue, 16 May 2023 01:45:24 +0000 (UTC) X-FDA: 80794425768.19.452B2D7 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by imf03.hostedemail.com (Postfix) with ESMTP id 89D4C20005 for ; Tue, 16 May 2023 01:45:21 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Miq6eEnf; spf=pass (imf03.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.20 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684201522; 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=MP1fJL2Z+/P5tV7BbFLCFKAa061ajLPzRmDAhHvdBdE=; b=MmCIZRV/pMEfl/ier/gypEuG7278O1Tm8sglYIqjS0iSa5tarMtz9nwLp+WizR0dpCrKZL TRlQit6FzAGXvKzitPkZPK7SRN+xly5jsaojxAmPMYeFnJNPHCMmpTox+zzY0703IjazvT phupwpVbjiGz4FImBAIbpawbJGVu3sw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684201522; a=rsa-sha256; cv=none; b=Ot2LUA30+Lf9xMzpoZkxrVw3bHubSPzu8a1rNN1ppnruqgom6BOPBCdJqhlYyV2lsDw7h4 JHykCThvVzM050zIY6n5vY7L76GkdfylENchE3z59ZNE/KYTVtGQUwcsTX4FGr9gdzP/9P UO7d85zgX2Q/e8vAeNA2+TNpLw98LL4= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Miq6eEnf; spf=pass (imf03.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.20 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1684201521; x=1715737521; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=VcTBJMYNV3aVOlqIu8G3jxJkAPMoNwhfARlefIl6LmI=; b=Miq6eEnfnCLJyq6SzwuoR+ZjF6NU89UMbQw8MjcxJIc6fJmQCLgCSQJt Ezocm0NEHDSkw1GTrSm1PqDMPcOKHjv7NL+GPFln/UlzXMWDW8z/YKgZz Fbf3K6b/a4A1068YPD+J2UacokWViqXx/H4kNKGd+u8fxtHkLHdgcONH+ zsfX7zAKrJRtxu6tS7nZjbbwgSw/0aXFfRlJcWDBFSzCQd2mu0VzPGIVU Uy1uZ+LVSw6/4B8YSgRStZYMJ5ImZguPiwaOM0uHd0+NqWyzxdz4tTLYR 4grjDYHifemD+Us/fRg4kQPneXIwZoOppj8TTStAOr9CW8mHImwHY+DpB g==; X-IronPort-AV: E=McAfee;i="6600,9927,10711"; a="340715540" X-IronPort-AV: E=Sophos;i="5.99,277,1677571200"; d="scan'208";a="340715540" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 May 2023 18:45:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10711"; a="790879878" X-IronPort-AV: E=Sophos;i="5.99,277,1677571200"; d="scan'208";a="790879878" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 May 2023 18:45:18 -0700 From: "Huang, Ying" To: Tetsuo Handa , Mel Gorman Cc: Andrew Morton , Vlastimil Babka , linux-mm Subject: Re: [PATCH v2] mm/page_alloc: don't wake kswapd from rmqueue() unless __GFP_KSWAPD_RECLAIM is specified References: <6d6fb601-6100-92b9-cea3-e7ebacc7693a@I-love.SAKURA.ne.jp> <20230513102314.md5ugj22xnv6mxob@techsingularity.net> <20230515073840.6yos3cisg2rlyw6i@techsingularity.net> Date: Tue, 16 May 2023 09:44:07 +0800 In-Reply-To: (Tetsuo Handa's message of "Mon, 15 May 2023 19:17:27 +0900") Message-ID: <87wn196oew.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspamd-Queue-Id: 89D4C20005 X-Rspam-User: X-Rspamd-Server: rspam06 X-Stat-Signature: 7uagtm6karojhdb1u6ktgeamx9obxisx X-HE-Tag: 1684201521-518017 X-HE-Meta: U2FsdGVkX1+Ky35G8LcRxO8/l1AMIALo2r5/hDMKxKsH9Uz6a4j8A9bgcLCt6qCqUXz4JVApZPXn3cGD8BiPKTqGwpc+mn0pJO1KYSElZPTlX6c2xnq38sYY5PTf8Fp+8OsCRADhztxXEOEtNPJ6DO5y/oL8vp11Y0gHFWLpKfJMg1foVKmboCd7S9GJ/mkFJ3uy4scClEVthr8RTLU9a9C2/beYZ8+du+e+qfSuv0A0Vk0O8A9ur1t0VLOL6NCojuK4/7Wptl3r5QJQoor75Gzxj3zSfSceAAuU9hJ0W6oZJ+/Xfr6P+IAUE51RudGDAdG4qFJ1RHfKkjbkQ7E/aM2PEiaO/Xmuym7jtr5XhjjmVG/wo40vS4m0CxFtZiZekWd8ttSyDzb7nccd6XdLtgkkjirTeuc4jrzfmKwTO0LmZWt4zaYZuDXoxp3S2M2mSya/CvXQuUh+jq85kCulVx/MAuLevUvuDyYPx0Y9MrmmEybPgdLSS8Ed5UjiDELj7CVv5V1OjrjPeLN7N2p8RZtiR5PcIxoYUO2pwfoTM8q2zCyqPdcEz9tETJzLTpnF/j7yShsm5SdQ8SlJpQWTEmGU4LwdkCG5Nj3fL689XchwPu/ohEHavEUCb0As22Gm7ySiqdhOpQEMkTx48wT/i72h6KcslrJdUaRzb4DOganeVjnZlvYr0yMegBiTUi1s7yj6u0j+SNwfy5znL7/7p7H64X7tQ1kOv30MIlBzw7Nn7BvBnS5A3m4VNR5N/wy33EMlSopjMNgrnPgvm+9RKKiN3jEePITW1JQRr4RBOudP+IeSO9uaweDe/9jIXFg89SYNc74LSc6kgBfT/VmkahnGp3sQFe4ZY/2+o18A7TOAyltIPtoTrpoPs19w5SA4yIPex1/pKklKcvCX6M0sxdNjIXjxxaLIRvHPQC831dvOlAaxiLHMqEkh3HNS5g5oYU3necvVp4f52SRBSwn bug6qJNI 5FisAQIolfkl2Et+7mLKHmgxGEqaUfiUOCXjo46ddiIPKPN/Yhq+URAOsqEugGp+deZZVIOn8btuyd6l4L9iJni2e4xVjRndS2KXYmnEChfgjZcn6q9mI8iybOCv+rvRc3RlKGwiTYFPIpMF5mBhpLZ1pOn2QGkv3CPHJsqXijq3QJMAxW5rNReDdHRalafjb4weMtHI2PwIetnsDgKN2rbcLw2OBnuafX3r4N/GBxa87SITuOhIsj+S5K0VyOhu8z6wUfxHpxYK8/9vM2P9eDnUq+Ds+Tru5OGO729eC0dBTXF++vMQbv20Qko0EWXsuxH4Y8nn7EP4kPuQaseYiCFh1llFCQvzwbs27NtJHn+LvWFIHbdh+LEBORA== 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: 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) 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. > 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