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 4FF73C27C79 for ; Tue, 18 Jun 2024 03:27:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B8C808D000F; Mon, 17 Jun 2024 23:27:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B39868D0002; Mon, 17 Jun 2024 23:27:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A01648D000F; Mon, 17 Jun 2024 23:27:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 80FFC8D0002 for ; Mon, 17 Jun 2024 23:27:28 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 10DAF120362 for ; Tue, 18 Jun 2024 03:27:28 +0000 (UTC) X-FDA: 82242574176.25.455B796 Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) by imf20.hostedemail.com (Postfix) with ESMTP id 3900E1C0008 for ; Tue, 18 Jun 2024 03:27:25 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=HU72DoqH; spf=pass (imf20.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.167.52 as permitted sender) smtp.mailfrom=huangzhaoyang@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=1718681240; 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=7z9a+aiDWUAko5EXHgSDmbWHvqSyfSRuPyb/I8NtUUo=; b=JoF9xWxO15u7NGD388w3xcC4Chc4CLvcoCx7elL/hK/rs2EXcMqJF2MaNxqG5x6xe06n2F /Hq4uLka6DszH7vxU53avjrUuD3Yo8ReFLcWFD5zFQWsVbW81M+0GeBpww5+ouenFfoOIy Kuyj+gEzaRagYQrQDT1Lo7oPEtTccj0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718681240; a=rsa-sha256; cv=none; b=OC76ZRcT8EAB1TlKBlAvsLnN8CRiUyZ1Ajbb+j1XOguaRmdKkoAUkUwP0pRQIW/wqorXYO x708JLELdARJeoDAxjDSza9BllsZL9tNRDwboAKfGj+TCcXHIQvOQNVWjZgYjL7+0dEIqI MB2OuyvTMLpKcRHUS2HQPoSYAhd1xik= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=HU72DoqH; spf=pass (imf20.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.167.52 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-lf1-f52.google.com with SMTP id 2adb3069b0e04-5295eb47b48so5928147e87.1 for ; Mon, 17 Jun 2024 20:27:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718681244; x=1719286044; 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=7z9a+aiDWUAko5EXHgSDmbWHvqSyfSRuPyb/I8NtUUo=; b=HU72DoqHZV31bkoNQU7HFVvA9XRDCg3JvTdmYlZWA4SDoJweF4DT81Mkl9koq6GXfv 2vKahuYHfiPohnjb6nWsa/NuLHYZU7lSocHIYGJOgbbUAinkOuUrqXyb5dUNVPkUqiFB fpmsX7Pnf6gxKZS9wZ8pR8cAXBGjUTyPLv3C720bnhep4CrTH4RWUL3G6fX8IYP4aV8F YVxdR8dvgzAozgH8pBVqWZiY3nmsMd6Mq+2rgvgGqIK5IAhUngl1SDVqf7k0TGX79BKT 3mgu+qjzaoNasRktrK0LZuT9z/InO+Ib2gzdr72m66WVkV5cT3/kAmfGC9BwpouS/Puq /zTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718681244; x=1719286044; 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=7z9a+aiDWUAko5EXHgSDmbWHvqSyfSRuPyb/I8NtUUo=; b=X/Y7DtvHyXulLZTzAJ2TiXyTANtjEQW1bOgNlQIqaIaHNS6IQ3uh7tnsqJXz0flkh+ T+G3sDL83BoL2UyQPhHgWfRXEtxWQJj4MbCFm1CLpSiHbNxVq51B5MurxSzfXOqxwJ5N 8foiaYym1ICD4UPW5+IrRVcL2fGI4qPWUwNSJhs8dthw3Qy6PwYwXhKZzM/e+QKVf1gb +OgL20WAu1hHXmjtJPQJewotmD/kEzzfVI8cYGdNq+giVt3R5TN1d5Qg4NpmX+tFkL/y mSnx2uhc8rYYqYsPbrtOdZ/leGH3sQcKpLo6rVckjXd7Uo1YZ8jCl3uiroAr30/m792y e7Ew== X-Forwarded-Encrypted: i=1; AJvYcCUNzR4dFXF3nT7qc41pvhqiAHmcPMZf0CjIIivIJa6gfVFRnBPh3SFuP6Ul98IqXQbXDHrHyFPoH2TjutrzFt0SlJo= X-Gm-Message-State: AOJu0YxP9MbSiMr6zR0SrNIPIuvcAG/QqSmfS4/wRZcHc6BHeyP1FffP M2f32WNY9e4GJfdD1KQjLM5fYU4gtNsLdZcnj0Ud2jb6kzdPQfc3pRViNSipJwunoMyy3zhxgoA 7JFKZfgnUWIXhthpkHgXvu3VLczo= X-Google-Smtp-Source: AGHT+IFE6sEWcgvPtU6BxDzi44k5FkUo5xfBn+1t17DgiU8KOfxx1qHZQB3r/9XpjTBjKJcFefu4EI0T/L2jQJY9Tnc= X-Received: by 2002:a19:2d06:0:b0:52c:8fba:e2a6 with SMTP id 2adb3069b0e04-52ca6e6e32cmr6856603e87.41.1718681243979; Mon, 17 Jun 2024 20:27:23 -0700 (PDT) MIME-Version: 1.0 References: <20240618020926.1911903-1-zhaoyang.huang@unisoc.com> In-Reply-To: From: Zhaoyang Huang Date: Tue, 18 Jun 2024 11:27:12 +0800 Message-ID: Subject: Re: [PATCH] mm: fix hard lockup in __split_huge_page To: Matthew Wilcox Cc: "zhaoyang.huang" , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, steve.kang@unisoc.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 3900E1C0008 X-Stat-Signature: uo5xyrd8dza5yxuk7nh8r1boni3tmtwh X-HE-Tag: 1718681245-123202 X-HE-Meta: U2FsdGVkX1/4lV37nspzHUMMCrjLybU2+bspv8x20PJKamsiSAeHUSEDwB50h6mhL06unjzZVLa/st4SFDe84AsQgH1gdj+KO1GyMPFR9KqbS4ZJa4raU0GSr3Pgs42btOI50ylGYvRDIA6GSuyLxKGfFcaMg4vlIDTXI9WMfvC5vGxy+bMlWPV8c+81n+L2I4Hjh4Rv2X4b+tBjacN1jDY4zPJnrncVX4cfklRd3GM441jXhMeazWG5OaQI+uHWCLNflVt9F67akY7LeOsOVvrxinVvEmpK3RlMhzs+TrUfEu/mCXkq3NBBhZ+aL+sqzaOqgVCg6y7FT3jKQ2umSyIuVKnKu5QvlDMU5xHgY0iBDhqK0NNO87fs8lURoIgAQP/REzMeF/TB9Gw0AI72JkdL7Jy2XnaYgriRPZ43q2WLFBvJsTOwi0TM7Cfsj+EfCfojA+q/ijNmlLD4Ruj3YWg+NFqy6r8D4eVZ/PVvrfNWPfNwt8UAJ7yd+GR91i4SuZct3Yg819Hb56JVXFd6sB2uJ9j05PnnpuuBi5oaWuKsPNLOoikwx1d2H5SS+Vi4YDR3eY/9dsLEe6inTiaq732dxTyKmgNNT6E5zecmq+7kQYXo3QdaARTb+T+66/FIDbRj2z/iMnqQ772aNWhYEugOLgTBsC0pFWA/iAex06YvE4LeXPukga3mgPJRq8hvOlFAjSgj3gNJoV62e4fRePPflLXknt+somR/1Ue/+QEvBZhMoRf8dx2KuuZWmD6192UmFe4fryKbAK7mkfeyw8zukSqtLJ2YRCqhC/zb426G8m6EmBEpK7Q2FZgrWboUFeL+ZLphFcReNa9SMsMtuyHHwU+a6j4HFr4CrFB2RJ8gQP0D8uVhXuF9KRITddrJbEQC573YtVFU6Td9iSKzoKyHajY6yTunzcgfHNZRl2CmAU3GKxiyFl2AnVprLfHED0v0kV+0odnOccpDIj8 3cwXcrMh uKRn6eKqd0IjgX5IJuwokuh44qKr2UVk8PEDzTXYN144cYgpTKcebWGlxqcsRYS9LjhOsNHw6p+oQCAU2xNPjZIfUO5Exr1B8e+jV3dNFSsQ2HPk/DX2naMHot7Kv9H5eAOhHu2C6nfySqGFnmFdyk8KU1R9PLXyfZqtz6SAhhSLiGo7hp+/ZPTfbfBt2Uj2t7TfDKh4rATj4UNyKcObTWkL5A7Y9R6PEBO7vcVzM2jMwuC6on4A5PttOEF+CNOp3Rf4vPiI8iPyQvaI1PTRbIjscFnuRZYmt6Hn5lzMTyjgA3SpUVU5ztVAi2SaMtuSjrNRHeNPHwAWCzq8ro71wtW+Su57H9IfU0Lv7I+iMM4naWdJBVOsZQpXYCxB6kZ1N1p0DKeJaCkTsYWcOrHAUSet/7Gz8ERsUb9aihgnVTxG9/50kdv6jwyz3VUElbouchpOUkqBbc1wEnMs= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000023, 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 Tue, Jun 18, 2024 at 11:19=E2=80=AFAM Matthew Wilcox wrote: > > On Tue, Jun 18, 2024 at 10:09:26AM +0800, zhaoyang.huang wrote: > > Hard lockup[2] is reported which should be caused by recursive > > lock contention of lruvec->lru_lock[1] within __split_huge_page. > > > > [1] > > static void __split_huge_page(struct page *page, struct list_head *list= , > > pgoff_t end, unsigned int new_order) > > { > > /* lock lru list/PageCompound, ref frozen by page_ref_freeze */ > > //1st lock here > > lruvec =3D folio_lruvec_lock(folio); > > > > for (i =3D nr - new_nr; i >=3D new_nr; i -=3D new_nr) { > > __split_huge_page_tail(folio, i, lruvec, list, new_orde= r); > > /* Some pages can be beyond EOF: drop them from page ca= che */ > > if (head[i].index >=3D end) { > > folio_put(tail); > > __page_cache_release > > //2nd lock here > > folio_lruvec_relock_irqsave > > Why doesn't lockdep catch this? It is reported by a regression test of the fix patch which aims at the find_get_entry livelock issue as below. I don't know the details of the kernel configuration. https://lore.kernel.org/linux-mm/5f989315-e380-46aa-80d1-ce8608889e5f@marci= nwanat.pl/ > > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > > index 9859aa4f7553..ea504df46d3b 100644 > > --- a/mm/huge_memory.c > > +++ b/mm/huge_memory.c > > @@ -2925,7 +2925,9 @@ static void __split_huge_page(struct page *page, = struct list_head *list, > > folio_account_cleaned(tail, > > inode_to_wb(folio->mapping->host)= ); > > __filemap_remove_folio(tail, NULL); > > + unlock_page_lruvec(lruvec); > > folio_put(tail); > > + folio_lruvec_lock(folio); > > Why is it safe to drop & reacquire this lock? Is there nothing we need > to revalidate? My stupid. I will take that into consideration in the next version. >