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 20FEDC48BF6 for ; Thu, 7 Mar 2024 14:05:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 89D2A6B018A; Thu, 7 Mar 2024 09:05:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 84D546B018B; Thu, 7 Mar 2024 09:05:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 715826B018C; Thu, 7 Mar 2024 09:05:15 -0500 (EST) 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 618E06B018A for ; Thu, 7 Mar 2024 09:05:15 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 067A8410E1 for ; Thu, 7 Mar 2024 14:05:15 +0000 (UTC) X-FDA: 81870414990.10.B8D3B29 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf11.hostedemail.com (Postfix) with ESMTP id 8D13D40027 for ; Thu, 7 Mar 2024 14:05:12 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=CWE42bpX; spf=none (imf11.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709820312; 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=0BFPdo3x6bKtuxsXYyMnW7z+zx34+euOCJ5PiqoikPE=; b=C05Ys67usncycVLqJXiOexKsi3bW4Mi3myMOrRag4jE07iNwtFGDEB0zjYKkg/bCQeA2LP 3hNyIHqZzTWNCpGEASQgvOgrZCajeA/7FD7vL2WOlgsH3rZnGaXDalp90fgeBI/Lw7Xmw6 PWzxWQEDIVRGbx/zFMEZyVF8bcQUCvg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709820312; a=rsa-sha256; cv=none; b=e7Tbpr/N/tarwza3mZptSXyHkrcjLfCNpKGxmi4THGoRupPENWnaGxBiN1jJ3GSVW9SrD3 HEbvl2MMmmSLT22evA45UY7sVa4Z6BIQMqrlYBdKbbDfOUhDFVkbF1dJcB0IVzdIaSF+so N5HSfHPiRpRFWjDB0MSA8PK+lAoxPb8= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=CWE42bpX; spf=none (imf11.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none 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=0BFPdo3x6bKtuxsXYyMnW7z+zx34+euOCJ5PiqoikPE=; b=CWE42bpXsWlJcQVTFpCdlc3bd9 etGUksLNym3TayiE1PSTWZIWSLe5G9MgVOhP9tV8JMSYjQpS7GFW8VAe5tz8oJyFBCW04xdhsEzgA 74elPXvNYgRBiveefwCf7dKKKUNBLKKtKEuG9Emuj7zLRmvXd7eCp9bMkCy5qASQKj0Hpxuib/te7 oCe9PoxP3HKaCU5/l1QbVhTSK1CnwVEZzLN1tfxdd9UGEech6UFiAAZgC90OBhNwNIR0MKOnQMw3R Jj4lK4jX6gUulw1Sii4cNnd72876fmwn/FlcaelVZYLuP6NEgJaDRU+DQUUZjnEiVsy7RPICccbuH s6lEYXng==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1riEMu-00000009Hu4-0rxH; Thu, 07 Mar 2024 14:05:08 +0000 Date: Thu, 7 Mar 2024 14:05:08 +0000 From: Matthew Wilcox To: "Yin, Fengwei" Cc: Ryan Roberts , Zi Yan , Andrew Morton , linux-mm@kvack.org, Yang Shi , Huang Ying Subject: Re: Message-ID: References: <20240227174254.710559-11-willy@infradead.org> <367a14f7-340e-4b29-90ae-bc3fcefdd5f4@arm.com> <85cc26ed-6386-4d6b-b680-1e5fba07843f@arm.com> <36bdda72-2731-440e-ad15-39b845401f50@arm.com> <03CE3A00-917C-48CC-8E1C-6A98713C817C@nvidia.com> <0f5bdbf3-725b-49c7-ba66-973b7cfc93be@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0f5bdbf3-725b-49c7-ba66-973b7cfc93be@intel.com> X-Rspamd-Queue-Id: 8D13D40027 X-Rspam-User: X-Stat-Signature: 5ramn1o18hgbdte3izq3mocjj9oj679f X-Rspamd-Server: rspam03 X-HE-Tag: 1709820312-710132 X-HE-Meta: U2FsdGVkX1+9JuSkhrGMVkdysFwWu/DNvib9JdbsKY9v57puJ9+Z/5ne4JX7D671punoJ4fF23dpP4tOu8ADBG1J/cBSrpc3FKP14uyJxliXmiIe8Y+uOe25pnDYLBg9BdAARIYZFIwm+ifCz2Yb4BwSplSSCM4Is5V5XKTKqYAkvGyl/UnMVAqSkXVYy9Tkcz+Vc3mIXZw3UYrW2zPfatwN2vpOw9pnIqTtSNcna+krQsFwScDZ7GtK0JRz9NMqeAbmU6dWezMDGLceNrM4uU56cUSJrfKoOLijR79OEF1exLJYfwkYTEek9H5ua7ZJxcxWqaRBem3Ewy4+7RjyykX2UwhwWbydQQXZfyUd+WicYVRNLWMZ30nP6vI0uw/NUX/hfiODuWt5nHAFpFch859+8El8PdaIzAlbEgnHt7sxliw6xbbBkY/k3CwnklsEdb1OuqfEs4rqu2wHK07OihueYjDopWERmtrF4L+wwvL+MT079Zw4W6sY5KrAsJg55VC1bhsd6KXrDSllyHdV/ioJCYwExtCgOT0wbtUG3nRu1k5ye8Ix7lA8sEjfFMfoNkHq2it15SagZa3uMSbiSKAZhVIMBrJHWH4zl37HvGdm7PWjdcmI769qTzGq8UzsDPc0sDSjKEoFYajsF5ALckMHMDvHaY00ulKxX+nfYENol7avJ3Nnvje8SriOUsSzrCUe1hYp35OuYnnWaYy+dDPv190Mg71JZT2gqqJLfW45XMY/c80+KUl0Wd7143YTRUprAHd3BXjWm6tk1d4GLr4TPCGIAltQ5Ji1YjgwGAoFskqUEa4kVbY/PiM3Bsl5K+g3d9YCSKULevvy9B5PPx86xO1MFBmryr1hyFoYThumlfN/tX8X9GkxmQNg6+pQEaZI1/eIJ01gDviMeqJf/wGGHM6l2tzO3AtvLCq3oPiGbhLc6AG5MWFKGW6kRsHRbjMvIn55zRNgw4ooZff 08JTs7xT ATQ+lM2jCpsmQ8Q0U2SHV3b2N253mTBegxZVaq30J6NpR9BD7hzaIgov2rkN03Ai0UBBtnQwMGJ4MXqntj/TReeKSSvdgvsWBr0mMdjRWKb1A64ZNqHa3CShzX8brk58hgftUgsxu2Zlul4wHO8Gxyed/RSkU2Nsv+gEToT09CNOymehAT5aUKXGuqw== 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 Thu, Mar 07, 2024 at 09:50:09PM +0800, Yin, Fengwei wrote: > > > On 3/7/2024 4:56 PM, wrote: > > I just want to make sure I've understood correctly: CPU1's folio_put() > > is not the last reference, and it keeps iterating through the local > > list. Then CPU2 does the final folio_put() which causes list_del_init() > > to modify the local list concurrently with CPU1's iteration, so CPU1 > > probably goes into the weeds? > > My understanding is this can not corrupt the folio->deferred_list as > this folio was iterated already. I am not convinced about that at all. It's possible this isn't the only problem, but deleting something from a list without holding (the correct) lock is something you have to think incredibly hard about to get right. I didn't bother going any deeper into the analysis once I spotted the locking problem, but the proof is very much on you that this is not a bug! > But I did see other strange thing: > [ 76.269942] page: refcount:0 mapcount:1 mapping:0000000000000000 > index:0xffffbd0a0 pfn:0x2554a0 > [ 76.270483] note: kcompactd0[62] exited with preempt_count 1 > [ 76.271344] head: order:0 entire_mapcount:1 nr_pages_mapped:0 pincount:0 > > This large folio has order 0? Maybe folio->_flags_1 was screwed? > > In free_unref_folios(), there is code like following: > if (order > 0 && folio_test_large_rmappable(folio)) > folio_undo_large_rmappable(folio); > > But with destroy_large_folio(): > if (folio_test_large_rmappable(folio)) > > folio_undo_large_rmappable(folio); > > Can it connect to the folio has zero refcount still in deferred list > with Matthew's patch? > > > Looks like folio order was cleared unexpected somewhere. No, we intentionally clear it: free_unref_folios -> free_unref_page_prepare -> free_pages_prepare -> page[1].flags &= ~PAGE_FLAGS_SECOND; PAGE_FLAGS_SECOND includes the order, which is why we have to save it away in folio->private so that we know what it is in the second loop. So it's always been cleared by the time we call free_page_is_bad().