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 0DAAFC48285 for ; Mon, 29 Jan 2024 16:09:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 985506B0087; Mon, 29 Jan 2024 11:09:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9350A6B0088; Mon, 29 Jan 2024 11:09:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7AE166B0089; Mon, 29 Jan 2024 11:09:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 6AE2B6B0087 for ; Mon, 29 Jan 2024 11:09:48 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 10C14409ED for ; Mon, 29 Jan 2024 16:09:48 +0000 (UTC) X-FDA: 81732834456.06.C848E19 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf30.hostedemail.com (Postfix) with ESMTP id 92BD180025 for ; Mon, 29 Jan 2024 16:09:44 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=XEmM3qYl; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=pHOAXzVZ; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=v0bghz1e; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=o2TK9+Jj; dmarc=none; spf=pass (imf30.hostedemail.com: domain of jack@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=jack@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706544585; 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=0q2MLUrv1k7d9D5+/BdCoPmlbiZZ17Ok8bpHpkSmRSY=; b=6CZlDCUW0eN9j0qsBzSATuXQsTecuq+LmsX3ikt17a8k2bXAH77Rte4jmj2TNLBDbC8ByF h3VLsOclz2ro8/DJMYSuzeiW6MAiN2AvbjVM9KcyBSd47TEzuu281CtLyAEfWMQnoagi+c zSQh7sSUl1rWUFp+1oaZWOIseLglUHs= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=XEmM3qYl; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=pHOAXzVZ; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=v0bghz1e; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=o2TK9+Jj; dmarc=none; spf=pass (imf30.hostedemail.com: domain of jack@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=jack@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706544585; a=rsa-sha256; cv=none; b=oebzN+OfoR/wAik4TIj58cLNArIHWx32luZOnL8OpoIYHHorUSfCS9V0UDj7ChgzD2jbta odgIuxHVxfCU5v+MpAyVFENFNKT31OEez/4Rdve0nD6TcyAJPTRAKYnTRbXIYenbBRXypW PGdGCOv49W7zhYew8RQgLuE9yjq+oqQ= Received: from imap2.dmz-prg2.suse.org (imap2.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id BD34C1F7F6; Mon, 29 Jan 2024 16:09:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1706544582; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0q2MLUrv1k7d9D5+/BdCoPmlbiZZ17Ok8bpHpkSmRSY=; b=XEmM3qYlI0CUrEqb7kPUhszOWOQHrlokbHhrZc7EGwa2SHsGXXDHs28Y1liMhb8eVSRDeO zatQeIr5WQa7C018hiHg56nH3gGKBWdULRUkIytPR2X8MllN8+cuqIC1jlmM9H7jAE4AEK FizcKVhqgW1iD6E/ABYBy/eaXsx6HxA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1706544582; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0q2MLUrv1k7d9D5+/BdCoPmlbiZZ17Ok8bpHpkSmRSY=; b=pHOAXzVZkyeIJmcfgNypcReo3Jf9iwdmiAJjbf9PZXcOsFH1rsl1yy9JI5Ch2qME7PBVfo x7CM5qd5SElWPxDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1706544580; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0q2MLUrv1k7d9D5+/BdCoPmlbiZZ17Ok8bpHpkSmRSY=; b=v0bghz1eqSg+/3eBpgiT5psyrda9f5aC+lV5JzdkYb2pQcpf8whF4MwtOFF1+nwpPoZfYI KbB9mB8y4ZcLBV2pgYTRKbwoZe9O2ilikNY2Mtihm1Zz592TvhQ+xEEVq0S1ExdH7wUPkL uuMBhbM3mblZ9tOrhFRxTnLP+JkzkKU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1706544580; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0q2MLUrv1k7d9D5+/BdCoPmlbiZZ17Ok8bpHpkSmRSY=; b=o2TK9+JjZ+NMF9RV1bTujh4tyCF2Ql59qLB7eN/Mzp3OOKiLYgY59GiPARiAgNiFdm1hIV MtBKvHGUbHtJZeBA== Received: from imap2.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap2.dmz-prg2.suse.org (Postfix) with ESMTPS id ACF4D132FA; Mon, 29 Jan 2024 16:09:40 +0000 (UTC) Received: from dovecot-director2.suse.de ([10.150.64.162]) by imap2.dmz-prg2.suse.org with ESMTPSA id v5ItKsTNt2V/JAAAn2gu4w (envelope-from ); Mon, 29 Jan 2024 16:09:40 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id 1B926A0807; Mon, 29 Jan 2024 17:09:39 +0100 (CET) Date: Mon, 29 Jan 2024 17:09:39 +0100 From: Jan Kara To: Matthew Wilcox Cc: Jan Kara , 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: <20240129160939.jgrhzrh5l2paezvp@quack3> 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: X-Rspamd-Queue-Id: 92BD180025 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: c3osmkgpdi65qfrk6je6ybq73qwedemm X-HE-Tag: 1706544584-88188 X-HE-Meta: U2FsdGVkX18bj3+X374cnXz6+jJE/RWT5jmfyH4o9yGof8hfD07o+lFd7YUI8wHzIZOsoLdRSN0b96/0hf/PdHAapTyEf8GgscGQapPjEm4ZTia2DFtCycltYnayjhH0aWDq6X7uU5/60AGqnRV6zRCts33CGaGM4oU4lw+Vxc4sm0pQT3cJ37bv7qqLdL5hgAMdj6zwoydjBS8sqGE7b1qNpzk/VY0UoxXMHRfwz32+jbecfJZOc7en34mXaDqsSTmEWuK63yn2wvyx2Ztfd4gKUw/BLUElD5caMh/b0uaNxabx7G2i0r1+1jc0jGIaZ7FFWdHbRv1kzsiqfPS/pqLlmEsWnkbYukeHAWaXxWgnZmLF+vrJOqtUdZhCUPur4WtKQ1rEbBWSlBTIDaxjDjlmlln1SzZouZZI59nWVplZOhvlN1fjoftKn8nMRbIitU0L2pn+LIXeHUnvo8aPLdGHX/+4Wfu2Gk7uwbxtMP8f4FwLlsaXgbBj1oxmbhKfTw78qDWVXjW9GAqFmS3qPyhTw+2yjvaujs0xldzyTKZebA90OAgKWJgE/FyoC4r7T25UnSPwg9yjGyDs/zvtOxUovqPhrxh2+BcYWejAFvliD38gz1DSNodBa4ur8rPPgj7ojY5hSVztIXh93UkOHtlwngpy0L9Zu3qrePWEih1HJXrDDTHpVLX34UX0UyzyrmNIEaafE0r9RXVEBw5wJOLgF/Ax/nVsSpYrHr5w2Tzbcb1+ZTkgfIlqGNCeemIV6sFKyoKDxPfOxNJwE8iYPRLOg3u5O50eIybmMgWa+0/RkZ4H/GLUI+PCvSwpVGuwuiM38NTO5CLEE726q9BTk5GsDDmqL8wFELqic2y0hFAPqeKqkwXrAr+cUHqNPEPWFiD5StcXAWr8LlTSFbvU0IBXxFjurvA5TZNQYHX8NphORBy24boIJOimmQPsVcCo5Ja53Vco9TeUsZRU4/A I6A8uvi1 KALUIx3DDPZXGdARmKn9ldxTonICqwnEHhV6DYVt2xfzRNiNoQMA6NpZEedVsBZZpwBVh3nxJigLCQjjjqEhoye72c7P3IGlCp7cSV6It5JhKttaBAk4sgI4x09tGwBOcUQMYrt84bukHLgzN2mY8mlpjhOp4WokM1g/+thyazH3h9fK+VCRv+bTYQaaxqESdVrghpkyNr9xnYBAYu3gXhv7j23I9ZdtwSmrYU8TUKGwOlFguTMgPz1nqDDC7n/Slf7BnY58Be7Gj+TVoGwxaWCVTaMeDaoK2AGHbYPmKGsF7ZAuq91fLXHpvrg0wJD2s2ykYksksXUiYBXcpHNx8rz61/ivrYEjVKafS5gmkwar06xRS5xY9K/sgnQgaJebousnJiukOYIkGm+sFPXQfxeosF8G1JasK/PbquKlNsNLOS0NJiPIwHUbbofIHJ6XhmoQ0 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 29-01-24 14:41:56, Matthew Wilcox wrote: > 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? OK, I tried to keep it simple but now I have to go into more intricate details of GUP and the IO path so please bear with me. Normally, how things happen on write or page_mkwrite time is: lock_page(page) check we have buffers, create if not do stuff with page mark appropriate buffers (and thus the page) dirty unlock_page(page) Now the page and buffers are dirty so nothing can be freed as reclaim doesn't touch such pages (and neither does try_to_free_buffers()). So we are safe until page writeback time. But GUP users such as direct IO are different. They do the page_mkwrite() dance at GUP time so we are fine at that moment. But on direct IO completion they recheck page dirty bits and call set_page_dirty() *again* if they find the page has been cleaned in the mean time. And this is where the problem really happens. If writeback of the pages serving as direct IO buffer happen while the IO is running, buffers get cleaned, and can be reclaimed, and we then hit the warning in ext4_set_page_dirty(). So what we really need is "don't reclaim page buffers if the page is pinned by GUP". This is what MM checks in recent kernels (since d824ec2a15467 "mm: do not reclaim private data from pinned page") and the patch discussed here is effectively an equivalent of it for stable. So AFAICT it really closes all the problematic paths. Sure we could implement that check in ext4_release_folio() but I don't think there's a great reason for that. And yes, technically I assume we could reconstruct the buffer state from other data structures if we find the buffers are missing. But in ext4_set_page_dirty() that is not easily possible as it may be called in softirq context. And elsewhere it is prone to hiding other bugs we may introduce. So just not stripping the buffer heads when the page is pinned is by far the easiest solution for ext4, in particular for stable... Honza -- Jan Kara SUSE Labs, CR