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 5ED52C54E68 for ; Thu, 21 Mar 2024 12:36:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E0B6B6B008A; Thu, 21 Mar 2024 08:36:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DBBCA6B0092; Thu, 21 Mar 2024 08:36:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C83B56B0093; Thu, 21 Mar 2024 08:36:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id ADAC56B008A for ; Thu, 21 Mar 2024 08:36:18 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 7E58FA05B2 for ; Thu, 21 Mar 2024 12:36:18 +0000 (UTC) X-FDA: 81920994036.01.496FA27 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf14.hostedemail.com (Postfix) with ESMTP id 9DF30100005 for ; Thu, 21 Mar 2024 12:36:16 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=I3CZK9S+; spf=none (imf14.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711024576; a=rsa-sha256; cv=none; b=flGx9YS3IpuRERcrXJv3UNBiPbDXIfWGqztqIjFkXSDQNom4ZbtEFC8unc7QOSjmrBXxnc NDcGVAH2K51II6S18Qja1bMro7y49jCeVcjR67nHDjUhr7UBRw57MECy7cV0obOC8qgtQJ f2pQt2EJVQW/0dnAP/nTIZPEPNZ+2E0= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=I3CZK9S+; spf=none (imf14.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=1711024576; 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=J4v4xirv+alWZBlX1A2mLEAEUfB1AfURODTs/cKQ8J0=; b=KoD58iPF9v/1XgjEb38MAGoxdQPl0ktnJnWk1g8131Yerwt6yuNbXepJu2VjEgrwEiBSS6 G3n5LIO69a6AbyV2HnMGJPTPR+hwKf1Qmvm5zJ0SoONQsJv/FyjWlQkWg56w5ZT8eIbGnU BinHJ+4CmqeQTrYubld+MhBXJRRjRUg= 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=J4v4xirv+alWZBlX1A2mLEAEUfB1AfURODTs/cKQ8J0=; b=I3CZK9S+8W08hz7sUGmxiBQpuz myBzWd9z3pRPoqiy4FxS+j59C1f626HLaO3HKDdmcYVuc4qTxZdYxCdu+s4gOckUkCzflMRuQxgy2 pB6wmo6531q7rsdgmtxMVDL+lPzHsBbWGcVNTASGeKXMazAByUJOe4AbLiAoGpfm0U9Xvnw9LICdl 6m3vunIU4E4jR4Y1rgFErFjNvOilkNG+6lax9JbIX0OvE0KjIBBL7/OdHnvyIenNWCbz8fX2JhuXH mkE/w98nC+Ur67s2KdobYxmqB7ucVEfZb6dYHjtXlCGGlIVANtFg1MNKu7gnWb3xU/6p05o9XchsD J4/8y1QA==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rnHeU-00000006j1S-0J5h; Thu, 21 Mar 2024 12:36:10 +0000 Date: Thu, 21 Mar 2024 12:36:09 +0000 From: Matthew Wilcox To: Zhaoyang Huang Cc: =?utf-8?B?6buE5pyd6ZizIChaaGFveWFuZyBIdWFuZyk=?= , Andrew Morton , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , =?utf-8?B?5bq357qq5ruoIChTdGV2ZSBLYW5nKQ==?= Subject: Re: summarize all information again at bottom//reply: reply: [PATCH] mm: fix a race scenario in folio_isolate_lru Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 9DF30100005 X-Stat-Signature: q9s8exqwcpdyamb3a6s13d79tefb4nfn X-Rspam-User: X-HE-Tag: 1711024576-745933 X-HE-Meta: U2FsdGVkX19dcrA0snrYL3mcIKf8L9mwPdufB/SFk6h1mCTKfHzIMfxR/U0xvrvZVF7TG5deiqP53ay1y5dOG5uCXS9mUyYvjT6YgTDJS6D8k+e6oaE3Beyv4QtEBaBR5+MEpUz+W83j3eUmALJ9comjDNB9CiOGIcVn/dS0fqXPKJQZBWb2V33z1lUWJMO1Rjp5rGb7cZng36hrC6eNp8ELllosfpyGh/HWm6iRKS1G988jn7nOErnh7hPoC7SR6+v/2rIU4aLKHRq5WNcAQCKWCBdLMvmA0PRuQQizRj4mzg8keGhheAkexlBvl4FDD3bxaV2FJu2lRz4VYUid+19OjuEq2hlyM+JSjjXxIOU31SI5pGQA+V7NEEKewg3O6YxIDI4uVOd93eD4S7HiYYIP/7kqmMYBdJKWbyMSSmBSEucauTZ+iazPkWY91QhCyoKFb93+v6zDH/0JqmcRABdjd1Fn53Cbq437+xXdCiQcOS2HasxOsUx4EZDMvnycOWO7dPwi60NVJs53CKJDappDuCipvnh0rJWaqufYm6HCp6WRMU/iHbtBZDCbprZZsh5Ym7wkzSJcDqr8FQXktnxcxnzB36u8+EhyN/iPoUApDeXM9ZDuyWt3wKAdWRzmSVctqWHSpYwFKpfD5ZfUtNXxVY2ouaDw+xBBBL9cQnOWUB91Dkm8HpHBStXhWYNtF7e7NaQCELuWWGa07UpqQN9Lty2DklT0BZDP2SFROcBSuY3wj59bflDX0EOXCpx2ec07+QsGVZmcAB7vSVfJ+ihucjURdXKiVdKufrgwFcaWweyl1kL6UWOL/w/5nzxSi3ANQiS+b3EJn8oF561sxqEtWv8uEcMvVH9EOq3EEyTHKD4NXtD9HCYT/MXzE8m3H+2I4MEhhZnCxd+S2uaRzDOXZgpUN4Wnt+99ta0W5MLF8DCxdzcHvsaI/x1M2Ef0dggk7He2h0BYFyDj4VS KRqfNvKo KrVTxl3EeaezkRtffRBtU+Xd9IkyfBVPFhfifXZQhnFv+PuwdAI/oNICfH7XC6XFWTWEl+RE0tqn8NBv2j6yK9D7j/ujIsd8ejJv0xYR6xr2hwq63pegR+gZUozNqGCxvr1L93f3up1YnxksQmxriMbS7oHCxhigWa10OJfLJjfuVVnphObp8T1NAxaG810JqPqF/mEqzK99sfRCTVGSJdQPQ/55ewUfmLUvn X-Bogosity: Ham, tests=bogofilter, spamicity=0.000035, 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 21, 2024 at 04:25:07PM +0800, Zhaoyang Huang wrote: > ok. Could the scenario below be suspicious on leaving an orphan folio > in step 7 and introduce the bug in step 8. In the scenario, > Thread_filemap behaves as a backdoor for Thread_madv by creating the > pte after Thread_truncate finishes cleaning all page tables. > > 0. Thread_bad gets the folio by folio_get_entry and stores it in its > local fbatch_bad and go to sleep There's no function called folio_get_entry(), but clearly thread_bad should have a refcount on it at this point. > 1. Thread_filemap get the folio via > filemap_map_pages->next_uptodate_folio->xas_next_entry and gets > preempted > refcnt == 1(page_cache), PG_lru == true so the refcount should be 2 here. > 2. Thread_truncate get the folio via > truncate_inode_pages_range->find_lock_entries > refcnt == 2(fbatch_trunc, page_cache), PG_lru == true > > 3. Thread_truncate proceed to truncate_cleanup_folio > refcnt == 2(fbatch_trunc, page_cache), PG_lru == true > > 4. Thread_truncate proceed to delete_from_page_cache_batch > refcnt == 1(fbatch_trunc), PG_lru == true > > 5. Thread_filemap schedule back and proceed to setup a pte and have > folio->_mapcnt = 0 & folio->refcnt += 1 > refcnt == 2(pte, fbatch_temp), PG_lru == true > > 6. Thread_madv clear folio's PG_lru by > madvise_xxx_pte_range->folio_isolate_lru->folio_test_clear_lru > refcnt == 2(pte,fbatch_temp), PG_lru == false > > 7. Thread_truncate call folio_fbatch_release and failed in freeing > folio as refcnt not reach 0 > refcnt == 1(pte), PG_lru == false > ********folio becomes an orphan here which is not on the page cache > but on the task's VM********** > > 8. Thread_xxx scheduled back from 0 to do release_pages(fbatch_bad) > and have the folio introduce the bug. ... because if these steps happen as 7, 8, 6, you hit the BUG in folio_isolate_lru().