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 335E3C7619A for ; Wed, 5 Apr 2023 10:39:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 82C606B0071; Wed, 5 Apr 2023 06:39:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7DC736B0072; Wed, 5 Apr 2023 06:39:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6CB966B007E; Wed, 5 Apr 2023 06:39:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 5DEA26B0071 for ; Wed, 5 Apr 2023 06:39:16 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 316A41A1184 for ; Wed, 5 Apr 2023 10:39:16 +0000 (UTC) X-FDA: 80646990312.09.E11DA76 Received: from outbound-smtp02.blacknight.com (outbound-smtp02.blacknight.com [81.17.249.8]) by imf22.hostedemail.com (Postfix) with ESMTP id 42933C0018 for ; Wed, 5 Apr 2023 10:39:14 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf22.hostedemail.com: domain of mgorman@techsingularity.net designates 81.17.249.8 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680691154; 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; bh=mvB9npGWQFwrqKSjHhyitvudP9oMfuXQt6r9bIhbFzE=; b=sM8332MIcJKPxBGR9DPonNUfQukgGekHtKDndv01KdD+JPr32UzvV3YgzVm/zihQarWxMM zz10lumM4T7ZfjJxZ+BQmGHICbW3GDNgrsJlTmv9s3xwrrfxwEN/um5nLpUGq3kqiJK4cD JynpPD4Yymhom6oMF7HlNXZ/TXHeNfU= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf22.hostedemail.com: domain of mgorman@techsingularity.net designates 81.17.249.8 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680691154; a=rsa-sha256; cv=none; b=yXBfC0lv7CDaJTr2rK0wU1XkKgn2zyywp61EgT5e1Gr3g9S1JLwrXbTu0lWsA8keuwOrVz BDacsI9W+Wi+R+SlPOqLGYGpkhRullKjLsMge/6D7/T9bVzw95OIjl5Xmxg13qnjgg42Qw MdpWB7NgK4fPTTZedkhpCa5X/M06iTg= Received: from mail.blacknight.com (pemlinmail02.blacknight.ie [81.17.254.11]) by outbound-smtp02.blacknight.com (Postfix) with ESMTPS id 8B5A5BAC55 for ; Wed, 5 Apr 2023 11:39:12 +0100 (IST) Received: (qmail 9016 invoked from network); 5 Apr 2023 10:39:12 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.21.103]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 5 Apr 2023 10:39:12 -0000 Date: Wed, 5 Apr 2023 11:39:10 +0100 From: Mel Gorman To: Baolin Wang Cc: akpm@linux-foundation.org, osalvador@suse.de, vbabka@suse.cz, william.lam@bytedance.com, mike.kravetz@oracle.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 2/2] mm: compaction: fix the possible deadlock when isolating hugetlb pages Message-ID: <20230405103910.t2774qzhs2tne72q@techsingularity.net> References: <73d6250a90707649cc010731aedc27f946d722ed.1678962352.git.baolin.wang@linux.alibaba.com> <7ab3bffebe59fb419234a68dec1e4572a2518563.1678962352.git.baolin.wang@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <7ab3bffebe59fb419234a68dec1e4572a2518563.1678962352.git.baolin.wang@linux.alibaba.com> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 42933C0018 X-Stat-Signature: apkdkfm6uc7kbeb8wjgykuj6z3eugzjk X-Rspam-User: X-HE-Tag: 1680691154-784110 X-HE-Meta: U2FsdGVkX1+qVkWAbmb00h50dEXRpU3CUE2EfAWxv+I+ewmaW5VatCtr4Dbw/CmbNMq+wgMgpQXLPksyvZ0SBIxUudSsl8AcEo7F5ciohiSoniExykpGkhHqtNm4HFcEG1dYWAuQHt6ITT9RJPb1FGdFDYqc2vN7Bqpzu/8gVNzfe73HFpbLEBoZXRhAvIzHQ7vrDgWZcuoi+nI0SWH1x0lN9mXncxPorzO8he7bqLv12HyDPGOi5it1At+X6I1oMDYou2FGYlY0ORm+IXq4xLQjbZ1NaKVhy+CpGuIeT5XWYJB93pKeilpW2Nc/ZpgnEGx3G0egNTebAoZa55A+8UHrisrXrhxhiMRwvatRQ5KuPL8t927Ir1LUbQG0cepdxwuDov/BkiHtk+Nt7QzRqlaD4FJkuB3IwPEunGAxGBeK+7iPABOYOlnwKqUOsFi4KACfSx3N1wDThbrSj1gLZ/BJLZgEc9loDQ1ja/Xn4jfn+c4st6qhlPUl9aTuMC37HITXbwFr+eOnbEDqTVaSJPDYO6mR/cXU9IH10slGXkjtOv1HpAbPzxp2lgXuQdtL7CmJqGroU3NJTnHduWbyVRp8sZcnQ1tPTkOCbrQOAIbFC3L1Vvj9ew2uYCKpr22otQvbzCjx2feXgWsPw8dVdqM8Rl+OlB1lNngBp2YIKJWDTYQbc7VPIj/kapoAqZ9oM0lKn7vioGa/0oksPpI61URkol0KUpWXAzWOaz76SkAcOPo0Zcmhdg4tpdeeddfJFVAsWWqmG0QkqbHx6AObpkf+7O7tir8/o8YhDYUJoB+NWGlvrCECGngw0IqjgvKB7Pr45/L4xO7dOkNzFjeiLV+kndaSiTMN1jJlve6jwKitXkehdGsh5lCeeEloV9axCCq9bqsvE75OjU2sSRZsQgaM8QAY7QdJTew2olcU4+Dhem2/OG5uJowknc/iEuutJvscvsskg2wP+oDXIPP djI+FWjS S6uPk/L37jeTOo2RjWofMcgTgWqGR1m2E52O6WTZS7b0wBgpnCZW8IdGwVdbB99IrymExpGCQXJ4FqP/lvHbT1oCV8Q8A0pdOWEKEXkT0A8Bo0WUEdFQqQ46SgzFnj+eBAJvN3ySoZFRlPd2O9zWZ+mrEOWBa/dXD6aRxUS3RZfPbNa+yiel01ZTJPlHeuy/LquoRxJ/+gLd2QJFayUEdS9oFXOHF+3u/DfOBf0pToBGtfZv0/BTXR6nrD6FzQX2lnq8L1IuPqlZFKb8h5vjAbWRhnpZxdW8QvPL1 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 Thu, Mar 16, 2023 at 07:06:47PM +0800, Baolin Wang wrote: > When trying to isolate a migratable pageblock, it can contain several > normal pages or several hugetlb pages (e.g. CONT-PTE 64K hugetlb on arm64) > in a pageblock. That means we may hold the lru lock of a normal page to > continue to isolate the next hugetlb page by isolate_or_dissolve_huge_page() > in the same migratable pageblock. > > However in the isolate_or_dissolve_huge_page(), it may allocate a new hugetlb > page and dissolve the old one by alloc_and_dissolve_hugetlb_folio() if the > hugetlb's refcount is zero. That means we can still enter the direct compaction > path to allocate a new hugetlb page under the current lru lock, which > may cause possible deadlock. > > To avoid this possible deadlock, we should release the lru lock when trying > to isolate a hugetbl page. Moreover it does not make sense to take the lru > lock to isolate a hugetlb, which is not in the lru list. > > Fixes: 369fa227c219 ("mm: make alloc_contig_range handle free hugetlb pages") > Signed-off-by: Baolin Wang > Reviewed-by: Vlastimil Babka > Reviewed-by: Mike Kravetz Acked-by: Mel Gorman -- Mel Gorman SUSE Labs