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 01E91C3DA6E for ; Wed, 3 Jan 2024 17:54:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6A8966B03B4; Wed, 3 Jan 2024 12:54:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 656E46B03BA; Wed, 3 Jan 2024 12:54:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4D0F26B03BB; Wed, 3 Jan 2024 12:54:15 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 3914E6B03B4 for ; Wed, 3 Jan 2024 12:54:15 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 16427A013D for ; Wed, 3 Jan 2024 17:54:15 +0000 (UTC) X-FDA: 81638748870.18.6BF7639 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf07.hostedemail.com (Postfix) with ESMTP id 692AF4001A for ; Wed, 3 Jan 2024 17:54:12 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=L1kvXiEP; 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; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704304453; a=rsa-sha256; cv=none; b=f8G7bSa0prCEZ0f7zJWZBFyzTwrmRJXx91fKVgw4wSgQnj4wr/AcmQu576p0qBePwtJemn 1U8+ECuXCE/omqjDeCmbFWoqqGZ+izlswtxOF/CCfP2UjKiOubkqkv1tc2tGLyDJamOISU 7bUYQxg6rUqTIoZqH+Pa8Z7ZApSlieo= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=L1kvXiEP; 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; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704304453; 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=g3Q6A/OSBTzpvsA+ZueyJpCCrUPX6Gs2jbB2LOMyGZU=; b=JbvuBLeFEhUyeV8jx4inBYSPBhZ7qIDXQe7Xqx7ADr01hcdpObeT7sdKr/RXmPqBzPB4Ls zQ6q57KyL0piCnNqtrtkvC+2B0j5OmCXS6GoXVx81q8u7Y0fFAYpRX44D+y9OI1lHNOwam Otbp6YF3bLHST3FbEryyDI/+LPZoRpM= 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=g3Q6A/OSBTzpvsA+ZueyJpCCrUPX6Gs2jbB2LOMyGZU=; b=L1kvXiEP+N+GxELX905cIpeDO/ Fum/7I+llgkoF6au7+5q5lD7WYxqCxjWc3lxB10+2+oQTvnGvGRGQBspPKliCu3alSezpqXATdGrF YNWzJy1nz0yv7YC9tj9b7XKQvQ1YLphocwT/hY57otg/RVTsIBJj/yPZjBX6Kw5C2Z/V02yuxH3J/ HK2qNkSLlarydo7UesLCYKwkF4LkpIC/IeklCIgKUcoPzmQ2Ij4UI+78N9tgDkZ7m+wmbZOdzrR8e wcN7B/uKTt6BZEUjw/gUYYjw/e0T9HYFGVjZbirAHs8MdhZctVx+ozf7UOu67ciQg5sjpIBfoDnYb nJ7p6cvg==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1rL5RH-00DG5A-Jb; Wed, 03 Jan 2024 17:53:59 +0000 Date: Wed, 3 Jan 2024 17:53:59 +0000 From: Matthew Wilcox To: Hillf Danton 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 Message-ID: References: <8bb29431064fc1f70a42edef75a8788dd4a0eecc.camel@sapience.com> <20231231012846.2355-1-hdanton@sina.com> <20240101015504.2446-1-hdanton@sina.com> <20240101113316.2595-1-hdanton@sina.com> <20240103104907.2657-1-hdanton@sina.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240103104907.2657-1-hdanton@sina.com> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 692AF4001A X-Stat-Signature: ys4irbc5bajbummapiobwyx1an57y83u X-Rspam-User: X-HE-Tag: 1704304452-525949 X-HE-Meta: U2FsdGVkX1+UP3fdwajw0zXUK6yF8R2te5MQHwxi7xEbq73yoOi94RGjp0EHlfVRI1MnLVKvKXFUBTPRxlqI6LT9I/Fxd7R1s0DOllc8hF+48FfkmOhpDXS3NB9XkVfi2xDqTm1PyRSHiJhJTzGyrv6sXkTCGWSw1GpdB6LIej32qm0XpmfPssIpKAEAbDh7Q99RgSGmIvsYZxeZB/9uvlfJdigL5cx3glD2caBg+vS7uOGU3y32tVc8bQt6VeMXE/uSe1Uc5q0kFzkxZpjltRPhhmNNILfkfMlsUgcNAPsuuFv6Jq3Zl6rz/TfB2V0jooKX1ziKNsO6zKxicQoMDvVS3wJhjI+uiFTQuy3NlMhblJvhxoZ2vnwA7bA2rwAhqpV8LGjsCkX43Ut3qGRH5THpXLWzRbxEpir8nuLW6TqRhhce0uk626b8bTlXZFfQ0NdUGhFM1WqhgOKI9ZRrpcuEMdaQi2vj5drmhqyjVReYPNJq1BjKelOg92fPeUVaUtOO9hrE9AXcUBDprWtuG0HrKwT2mtyAlqe6QL6SQBpcxA+jOll/3fTAp44fUDkCrXr530YLdl0NaG+6/GlDjs8C9xJcm++LyP46aFWaEnIrLenikyKrZafkA4cyWvEJN8s/EvWIusTpe4LPEsRLjwlQriX6ZhiYStvDpGXl1DiTpvuKb7b/jRBdsHY07F4I2N/M9G/YOBNUVzwJDM+HQ76yXCvU4F5OfdOxTXfJxr+UxLU7j1h3BRC7oEvnTHzQJnvBtvO7z781/rVQuzxcpZX2T67dGgEsi+2QkYHCWsByQ4BOQgik03blqvcOF28itX3WLRf1CHIseUHUaElxllM0PlPUnBp49rNYBGiTErA6LaPqykpRtxlN+VlA+TW9bd8/By5G5+W6HiIQ1+0OLydG6bRiztqvXK3uBkxido31qun3xX18CEdyos8p7HzFfGwl4k3cDF5WZTi6dN1 mqjT7WfF I+iwQP0323p4RQCf2XiEWZm3aTxBOTNybfB30mIBaFF4F5SyDAke/OUWCiVCQ8LA7Udw6RQHgxQ3zi0oMuDG6Xw1Es1euNDFgBVnpMu32KsYO7xO6aGVYYMZtb2MUYcrORXkqKX+1/dNCRqo5Ft3PhDYkzflf38rBB3dRjWMzzzuWUV/YsnAJx5wh3A== X-Bogosity: Ham, tests=bogofilter, spamicity=0.001315, 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 Wed, Jan 03, 2024 at 06:49:07PM +0800, Hillf Danton wrote: > On Mon, 1 Jan 2024 14:11:02 +0000 Matthew Wilcox > > > > From an mm point of view, what is implicit is that truncate calls > > unmap_mapping_folio -> unmap_mapping_range_tree -> > > unmap_mapping_range_vma -> zap_page_range_single -> unmap_single_vma -> > > unmap_page_range -> zap_p4d_range -> zap_pud_range -> zap_pmd_range -> > > zap_pte_range -> pte_offset_map_lock() > > > > So a truncate will take the page lock, then spin on the pte lock > > until the racing munmap() has finished (ok, this was an exit(), not > > a munmap(), but exit() does an implicit munmap()). > > > But ptl fails to explain the warning reported, while the sequence in > __block_commit_write() > > mark_buffer_dirty(); > folio_mark_uptodate(); > > hints the warning is bogus. The folio is locked when filesystems call __block_commit_write(). Nothing explains the reported warning, IMO. Other than data corruption, and I'm not sure that we've found the last data corrupter.