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 5DC28C47422 for ; Mon, 29 Jan 2024 14:42:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C9E076B0098; Mon, 29 Jan 2024 09:42:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C243C6B0099; Mon, 29 Jan 2024 09:42:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AC4F66B00A4; Mon, 29 Jan 2024 09:42:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 99E306B0098 for ; Mon, 29 Jan 2024 09:42:06 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 639BA1C097A for ; Mon, 29 Jan 2024 14:42:06 +0000 (UTC) X-FDA: 81732613452.19.A164F25 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf20.hostedemail.com (Postfix) with ESMTP id 356011C0013 for ; Mon, 29 Jan 2024 14:42:03 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=ROFlSVTd; spf=none (imf20.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=1706539324; a=rsa-sha256; cv=none; b=OlBkQgzbGRSzBg3oEgwlXke1tsRn278QYXkFABfxFb9PoTIo/ZyXgrsG2qrIeSL4CI7f3N Hja8D83e6oO0UafYjYy9dPUX4+nD8+lES0ZLPkq9Uu7PKJ7d1t5SpcnaIur/hfFLM9Fw74 x0f4PBwpV8EU9v2RoYCNKhXF7FUgwiI= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=ROFlSVTd; spf=none (imf20.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=1706539324; 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=qvYyv6g1p9HNR7/QDn+cPswg81RWpt5qBAdgn5bPezw=; b=fJ0XsR4uh4GzCBRqxTQHpaGB1I8Moo91aMxKCQ3583hqcPzp21yUKL4SpkQqMNJEc1yMNO HezJ+Km49a/VyYA4Cam4Eavp4qHzXoKxN9zmSvT0drAkeYGlmwZESFw3oRPahcg+5BHlNW +wp2WEdQaiedzzxAuzxG5kMHGOjRK7g= 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=qvYyv6g1p9HNR7/QDn+cPswg81RWpt5qBAdgn5bPezw=; b=ROFlSVTd1kgyssYmy6tVpcJUtf z3nFeKi0OwU5HmznNOR0u7CHaLQpg7AYX2wmPgHRowOIvC5ms9mynHoDW4KyEJczHdCnZryoZzhSc 13f5Ek8zW2WcfHs67PtWBmFS09IG5TUOb6mQTqDnonns/nvSs+kb9x+tsUVWVw6AhV/VHA+za0HRb 5asZ0gGvCYBhJ3f380lurNdYu5OVgiJFPu3rsQy84Gq/vezfDirvghj3WX6HCin+KRYbvXMY+fc4O MKf6iRbHnmzZVjlwP3+WULzjVoTpXQkr2vjRgYf75aO7RtrQ1uhpQzjuTwLsuss9xiXH0Yi7UPaNO PSDhf1Fw==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rUSph-00000006sUh-0ImC; Mon, 29 Jan 2024 14:41:57 +0000 Date: Mon, 29 Jan 2024 14:41:56 +0000 From: Matthew Wilcox To: Jan Kara Cc: Roman Smirnov , stable@vger.kernel.org, Greg Kroah-Hartman , Andrew Morton , Alexey Khoroshilov , Sergey Shtylyov , Karina Yankevich , lvc-project@linuxtesting.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-ext4@vger.kernel.org, Theodore Ts'o , Andreas Dilger , Jan Kara Subject: Re: [PATCH 5.10/5.15 v2 0/1 RFC] mm/truncate: fix WARNING in ext4_set_page_dirty() Message-ID: References: <20240125130947.600632-1-r.smirnov@omp.ru> <20240129091124.vbyohvklcfkrpbyp@quack3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240129091124.vbyohvklcfkrpbyp@quack3> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 356011C0013 X-Stat-Signature: 13tctkcpwxy7sd4m9qgt18izrnhiryfr X-Rspam-User: X-HE-Tag: 1706539323-541359 X-HE-Meta: U2FsdGVkX1/Cr7uKdtN3XWuefEJNTW55Lrn/P2wCH37Q1oeCrd2sraNgswBaN/041bKRe/oiKtBe/8huT3e1+yuMt1nb1zRqyfEm30sb2MdqO1cZMQy5Tt0/RnMARyAxOgt2lnFf4/pCcntUa6pIDPBExfOQPECEJtIPPbsXBFROvnfZ4E9cyjFc1PIrIbYFZqLT4D253oTta7iPdWSHNo+R6IDrHv7/wy+zc7yZnPS+qHYejk40ab5YPJ7pt54wP8G8FVKlClPfRVSWJdMr1xVGfFTtQFPaxyKd6uplpX56CgKTRB69dAkt3XYKqSRMdcKAIcBfFJ34jSjw2dwTfVOzOUtmsawnglwVF1HLfTlpuBX4OTff7goxVZwkFdit69KbAwMCiQtjms2tcnHicCSxLOzCzu0/EieL4N++626wup6gJRo6pYh/xwoo2TsFybFU0TLMjmzjW1svuXkMOqH9umAJ9lRJgji3Iluhf1uIKq1/VxtFFAHgBtSorWssCi9aHL6xeDpTP0LxdkepwiPb3+pLRGcsyqMR/U3CwEKoB1Mm5vPTNri1D2J5TNCzV9M4Xq9+A0zqRolLiEFYljhIsyDeP7XSrlr/KwxK7ZTr+JrXkqwMXkQ0AceaY25mxQQCd1Y2WggMama2fRBwYM0VvhpCVYv71QYwkQty4LCfPdoVp2YFpJdE9kr0XXg/KZoMhslLUFYSQd5sdH7WV2Uwu13Ovj9qZn3KzgQc1H/A5QJFlg+y3D7vTN+fgyIOscDCfaWYcf1Vx6RNtKbfVTT8g1gxMHxRhYASNv0WTiPTMjOlScAMS+K3EpLdaF7Sw0jvHofqxIgGLcDyJ/Hlt8PcGa8wvm3tmXX6iODDkMz/f4IMZ+UZhoa5uhh7pLxbWI2Eh7ys0m+mQVlDYN6mie++AUrP0PF0t+WyYm+d52IO/iwRqZdQDBXY7nZ/hejtBDqaN+fr63iGqS0kGIu 5OFG31jE 7kH6VyoH21yfhjlcwCto7qZRh9s46+82Udj4ocrpmlkKnqBHXh62WXH/snHJy3aaKsPG27zrAVfAmmW8dNIo6FlWVb4B6GjXixk0WKNfKJYw9tELJA+3uQUawybgSVGfOccFCIoFQUaP3JeU1OTBeDejxyK8HdqCA34cZ4s+YLBQU9d3vaYIy6054hCIEHd6gNHWXWZ9mTz5aEf39iRiJh1s7DvveVliHXs9hknxlh6FD9DTVAYuLzqh9yTcQQ57WebzFcZzn+H4WVewpCbCB66n1RUN9/eSPD7xdrf8i+xW9uz01e5emEYk8lg== 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 Mon, Jan 29, 2024 at 10:11:24AM +0100, Jan Kara wrote: > On Thu 25-01-24 14:06:58, Matthew Wilcox wrote: > > On Thu, Jan 25, 2024 at 01:09:46PM +0000, Roman Smirnov wrote: > > > Syzkaller reports warning in ext4_set_page_dirty() in 5.10 and 5.15 > > > stable releases. It happens because invalidate_inode_page() frees pages > > > that are needed for the system. To fix this we need to add additional > > > checks to the function. page_mapped() checks if a page exists in the > > > page tables, but this is not enough. The page can be used in other places: > > > https://elixir.bootlin.com/linux/v6.8-rc1/source/include/linux/page_ref.h#L71 > > > > > > Kernel outputs an error line related to direct I/O: > > > https://syzkaller.appspot.com/text?tag=CrashLog&x=14ab52dac80000 > > > > OK, this is making a lot more sense. > > > > The invalidate_inode_page() path (after the page_mapped check) calls > > try_to_release_page() which strips the buffers from the page. > > __remove_mapping() tries to freeze the page and presuambly fails. > > Yep, likely. > > > ext4 is checking there are still buffer heads attached to the page. > > I'm not sure why it's doing that; it's legitimate to strip the > > bufferheads from a page and then reattach them later (if they're > > attached to a dirty page, they are created dirty). > > Well, we really need to track dirtiness on per fs-block basis in ext4 > (which makes a difference when blocksize < page size). For example for > delayed block allocation we reserve exactly as many blocks as we need > (which need not be all the blocks in the page e.g. when writing just one > block in the middle of a large hole). So when all buffers would be marked > as dirty we would overrun our reservation. Hence at the moment of dirtying > we really need buffers to be attached to the page and stay there until the > page is written back. Thanks for the clear explanation! Isn't the correct place to ensure that this is true in ext4_release_folio()? I think all paths to remove buffer_heads from a folio go through ext4_release_folio() and so it can be prohibited here if the folio is part of a delalloc extent? I worry that the proposed fix here cuts off only one path to hitting this WARN_ON and we need a more comprehensive fix.