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 5E4BBC27C79 for ; Tue, 18 Jun 2024 03:19:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9D77B6B00C2; Mon, 17 Jun 2024 23:19:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 988436B02CE; Mon, 17 Jun 2024 23:19:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 827656B02CF; Mon, 17 Jun 2024 23:19:19 -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 6B1526B00C2 for ; Mon, 17 Jun 2024 23:19:19 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id BF3AA1A031C for ; Tue, 18 Jun 2024 03:19:18 +0000 (UTC) X-FDA: 82242553596.25.BFB3ABC Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf07.hostedemail.com (Postfix) with ESMTP id 17DED40007 for ; Tue, 18 Jun 2024 03:19:15 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=qoS97ltU; dmarc=none; spf=none (imf07.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718680752; a=rsa-sha256; cv=none; b=n1HEAOD1ZIJ8kP72nDRhS1V8fRzt6Fm/r+l9isBQfRrCjZwgzcaaCiM+Uo1FQfiECHSDsN LRZpVe7/mbFj1iSi4jlRgMq4tXrel+PC/li0dwNipFRsmcVZjP8Srl4AQpmcLY3k22cilY 6L6AME8g2SnSDgk8vbr7ovjHDuvghJ0= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=qoS97ltU; dmarc=none; spf=none (imf07.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718680752; 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=3oANa1rrA/Me3UE+Z60RNjRWRplG3I0MnseFbw0ZTR4=; b=hs7rVzcghnZHCFDiFhStEt32gARVrLyUw1rRNQRAJ8Ygk/yEzExjPh6fXsCvICU67qwiTu rCseBZeiLnURVb6Es3wHG88vk0Hi8hK6NRM318c1W+vxL6uQP7480OgkyC7MvKNwUn/LIy rHUX0lxnjesRavYBHXHJbT4sjerB7J0= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=3oANa1rrA/Me3UE+Z60RNjRWRplG3I0MnseFbw0ZTR4=; b=qoS97ltUkD4IyV7n7Bfnd1C8Ls NvkhkgXzguxGckgW2jFucHXzxp9tUeKc/bF+vrXTRyzbmDYaD179cERs89bk/LQtQXw953FCv8Z6R FYS47n2XKr5L2lsEYKpEMRG9R+oht/mWAZW1T6loMwke2wxQhjq/mQumCCBKY6yh/d4TAExid/JBe V4g6KZJO4FCWcEWWBqBo7j5qcUWslEykQQCsiwSdvwy6QezQhFUH+oPuDIzUwtUlwuCvx1iPwZcpT xybCaJXethpdZHWh9KPSWzSzi3tivb81SWB4Fbu/+X1ePCAlOvb7J3U6+EsuvKkjMUrCDJdjqfLYf hxBZpUZQ==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1sJPNB-00000002j50-2tce; Tue, 18 Jun 2024 03:19:05 +0000 Date: Tue, 18 Jun 2024 04:19:05 +0100 From: Matthew Wilcox To: "zhaoyang.huang" Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Zhaoyang Huang , steve.kang@unisoc.com Subject: Re: [PATCH] mm: fix hard lockup in __split_huge_page Message-ID: References: <20240618020926.1911903-1-zhaoyang.huang@unisoc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240618020926.1911903-1-zhaoyang.huang@unisoc.com> X-Rspamd-Queue-Id: 17DED40007 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: okdc5mm5gdfe7z68hfxra79uss7ft3ne X-HE-Tag: 1718680755-409867 X-HE-Meta: U2FsdGVkX1/wGa5vTyqU6Z2yozHvEVUBt+RrFnjCddnuaYJwm1AGxaDmGBRFjsmpnTeC81mICWYfTFYOxpRgCimMU/MGYgzsYn1rhuwQxWRoZ3oSQt9UyuN0TW4z2Uno7o1y29KVtihIffCEZ9h8LLvtvxMEqfI+9q1TxiacP1Hc9YlspFBJ0gMYPUyRH0aUQVFnVml1DFXsc0qcnisFrmvys3ucYoCtcnXdTWEaQDFpme7uxyUVTQxUTGe8f3qAvjbhtnTup91xtXet9vPMP59lDTb/aNQ3DdGY7RRElvsv5h5Yz12/7+OBkYB0+oO2L1N5uYpljmGIwTQws4mX/y0kfcmq46PNFPgQqOlKwhSqYMKkZ/muVME9b7O9/qwJhw1HnJ3HwIPgcdTVtKN9RA7LRfXS9LAbUWbVfYX5H9CrC6ZB3slBXPQ5EENndZvSAlvOBEUWL3SaCR8o05GRgi8DFetSJf4Fv7w8QWRTFiTtXsEJ0PBXt1MlpksdkvhqxoOgqxzD4JnpgHUDhRZ2Py3pO5xbHV351PWA+8sO0Y+6s6Y0UIisIbdgvUR6wxwsAv5T7dci3Wv/g3m3amxwv8IoltTy0oqD4+gnuYha4xMprDwWU0GJnpB2UKcArAS6QVjvkJE0StcHj2dQFxBfzzz8Pz0ZCA1k4hoHDwFno5ByXuGFheQmdVzZC3jAVsZBLYk0CPwPClTQWs7HNE1eYmh0cmFafxUjjysqV+XTlKaFMu7ENgqmEgpvzwWW/LYaeJffetD8H0WUizxdgGZNfiMw88lE2WrdhvHHHoFDAf34JD4u3iuAcVJIoMa6RM/2guaz+UXR/c393IImcjSOwgL0/whOvSGYpkKxQEFzdSErylLtH/DosJdl6korqMt1Wo+OBv8YEr6FoyzwmNZJFZZPrjVNQx40KViXLTjqxZngTClUxZ+5A5i/Ph4cKKO+lSkJyJBwjttBiXIIlJB 4boNMKrL moPeDRjKafu261vbY3caWiFLdqXZQMBazS7h8BpkxuJjklD8OyVwmM47/MoD5WRWcVMmvQULWxyOzTIFDe89Ja+JzX/UkvnrIsitG4nfTc3m67aXrvu86q92rmrL0S0MDPEkX1v30kZ3w8bmzsjw5Al99Lmtt2na7ZRfap4YrqDEzMTvgD66stRBKb/DYT4E11CU2lVtN8VJB3a5GzKbjlVldSQxdm37pLFSh2p4MyZON51SSXBebx5SQbPn/85Oh5E6N 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: List-Subscribe: List-Unsubscribe: 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 = folio_lruvec_lock(folio); > > for (i = nr - new_nr; i >= new_nr; i -= new_nr) { > __split_huge_page_tail(folio, i, lruvec, list, new_order); > /* Some pages can be beyond EOF: drop them from page cache */ > if (head[i].index >= end) { > folio_put(tail); > __page_cache_release > //2nd lock here > folio_lruvec_relock_irqsave Why doesn't lockdep catch this? > 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?