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 6A0F8C47073 for ; Mon, 1 Jan 2024 11:33:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C5D6C6B026F; Mon, 1 Jan 2024 06:33:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C0C736B0270; Mon, 1 Jan 2024 06:33:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B21BB6B0271; Mon, 1 Jan 2024 06:33:42 -0500 (EST) 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 A5DDA6B026F for ; Mon, 1 Jan 2024 06:33:42 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 6A6A6C03A6 for ; Mon, 1 Jan 2024 11:33:42 +0000 (UTC) X-FDA: 81630532284.12.CC38907 Received: from mail115-80.sinamail.sina.com.cn (mail115-80.sinamail.sina.com.cn [218.30.115.80]) by imf17.hostedemail.com (Postfix) with ESMTP id 867E040003 for ; Mon, 1 Jan 2024 11:33:38 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=none; spf=pass (imf17.hostedemail.com: domain of hdanton@sina.com designates 218.30.115.80 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704108820; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wPEIQpuK12G16pnEFqEJ6FrRWV23vQHDAdkeuTBDezw=; b=F8xdpz8ZDHKY9dRi96I1z4FlGuPCTQBwpjsD2LTIhsJvfB98sUz1AW2XcHZl2C3H2nmTFl Bmyx7NnHJyHMtWqqjcp9ownLvTj87GtrjMHXUkAZIW+EVFowdEKuP+dPr1NTmQfodICp8w efGFnzU2UJxtKVCIeVC9DSv4H6FjhFc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704108820; a=rsa-sha256; cv=none; b=DMKpNKx5m8xso+s1qXNklGrTUal9E53WULn8AB5ZpKyV+IAf3KtnRq9kc/cOzQdmnuaTqg bPic8tP06LaIrWlsmL8mVocvLfz4jUC6+sgIAQ6kYHNIFZ9vmHXLBWHH7xP6Tkvm7BmDre BZErEuZpPbMWHK13le2cHMhbTrIOZi4= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=none; spf=pass (imf17.hostedemail.com: domain of hdanton@sina.com designates 218.30.115.80 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none X-SMAIL-HELO: localhost.localdomain Received: from unknown (HELO localhost.localdomain)([113.118.68.122]) by sina.com (10.75.12.45) with ESMTP id 6592A30500007E54; Mon, 1 Jan 2024 19:33:31 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 3265331457689 X-SMAIL-UIID: 05E51E30F69B439BA57A35AEF53799B8-20240101-193331-1 From: Hillf Danton To: Matthew Wilcox Cc: Genes Lists , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: 6.6.8 stable: crash in folio_mark_dirty Date: Mon, 1 Jan 2024 19:33:16 +0800 Message-Id: <20240101113316.2595-1-hdanton@sina.com> In-Reply-To: References: <8bb29431064fc1f70a42edef75a8788dd4a0eecc.camel@sapience.com> <20231231012846.2355-1-hdanton@sina.com> <20240101015504.2446-1-hdanton@sina.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Stat-Signature: tycw6zm1osggpohjjptdiyczf68hmqhr X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 867E040003 X-Rspam-User: X-HE-Tag: 1704108818-757789 X-HE-Meta: U2FsdGVkX194knNnzY/eVPKsk0C0KOFrffJPJsjd07U6qbAiDswxc2i5zdbhfLl8ZDLmKzfTKT46gV2ubDJ5Auk7pEcD2pe4MFVEks1X2XCD07a11Z0wKNRhUX/OgcODfaewKegPv2qPmzpWuCQtV7e2Sih8pzPQVNqrMczK1ly/Fa0CRW+xxpxIGB+XJAr5WBmi6nNLlB/i1uhljz558Du7DzjODZUOp+vaTr8hWjej3GV1iYQgKhDVcM+YvpnzZR9HdrGioPwh28d5QSXKnsMqC6+F8lo7vFmSXI/7f3ySjp46zX6aKakpWKS0PyUi46TYuUbEiMHbuipkvXiqhwnhhlU1MrW3ibyjvECuBxv9suAftUgEpB2IP3z91A6Wj/R0k5fgA6B5eyOVGMRPkrOwwCtIIoyLU/aCKUzBHtqZJRSq6mcAUaKDzIEjQ2/qa9e+NQ3/7FKBQ67IXz/TJcpI7DXNyfnMqhID5iI1VU2XJhX+9KoWGXqmPaGWcY8XK1XqDUT4AdjTvcSx4pl6eexvZQg75EGZT/X7SazhyBFVL5SXE5WUsRYndwawOIs3dUAltAuH0uqOspEopXZ5l1InwyvLtth0yEXWWZW5+ACoIBpMw+VUd1JJ2JwkwLnEMfhAolY6eFKywDU62CvNvHvOiOC51TZlNfx3YPQMHdVr/i5fiVJTpFzbk02AIUSCy13bSfWrdn7zGujI1TqvB6b0SngNg9sluMhDSe3Z0kL/4v9M/nfKlgvjfEhu5UrG9ZMcdRQpXOMBaYu0z9s3szvi3G1f2UfDfCrKomYw8uNw1nh3iawVYTAx8xX/YH5PPwiL8o0nX6mNr4fAnenmhoVrYE2pBJbVb7aEgIcnxDJfnFEa7EbQUU79CFqPlIOjbhoDqkSoT8PP83ZeeqjkK+eQnpEXXoG6M64Tm2e96MO6bLtEmIzRssFDP2va/BDlv6rboWY98cxi6OoC6YS xvmpOqyc vAaTcQkoeM3cVFVpb1fxOQ35Pg8Uv93CaaXmh+aW3UfSzjldzRsGYjnhxTYERGqn0meKu8uy/okxDG86an+39mvTu9X/3DvWqYIsqTdujrHvncrFwc2N8CcsjGhUGidlFMUVMVW9NAMuoZBDcFVcZSgKC5ToQhv+biLtYO02vGaBihOAiPAIo5XgjzWrarWXiRgFRY90vlhuYfWSl5+NnpSr5rVoC21vfHwUhnwHEu+15zJ2ig53LumqnFg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000021, 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 Mon, 1 Jan 2024 09:07:52 +0000 Matthew Wilcox > On Mon, Jan 01, 2024 at 09:55:04AM +0800, Hillf Danton wrote: > > On Sun, 31 Dec 2023 13:07:03 +0000 Matthew Wilcox > > > I don't think this can happen. Look at the call trace; > > > block_dirty_folio() is called from unmap_page_range(). That means the > > > page is in the page tables. We unmap the pages in a folio from the > > > page tables before we set folio->mapping to NULL. Look at > > > invalidate_inode_pages2_range() for example: > > > > > > unmap_mapping_pages(mapping, indices[i], > > > (1 + end - indices[i]), false); > > > folio_lock(folio); > > > folio_wait_writeback(folio); > > > if (folio_mapped(folio)) > > > unmap_mapping_folio(folio); > > > BUG_ON(folio_mapped(folio)); > > > if (!invalidate_complete_folio2(mapping, folio)) > > > > > What is missed here is the same check [1] in invalidate_inode_pages2_range(), > > so I built no wheel. > > > > folio_lock(folio); > > if (unlikely(folio->mapping != mapping)) { > > folio_unlock(folio); > > continue; > > } > > > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/truncate.c#n658 > > That's entirely different. That's checking in the truncate path whether > somebody else already truncated this page. What I was showing was why > a page found through a page table walk cannot have been truncated (which > is actually quite interesting, because it's the page table lock that > prevents the race). > Feel free to shed light on how ptl protects folio->mapping.