From patchwork Thu Sep 19 16:07:39 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Brian Foster X-Patchwork-Id: 13807832 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 DDFA9CF395D for ; Thu, 19 Sep 2024 16:06:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5342E6B008C; Thu, 19 Sep 2024 12:06:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4E3946B0092; Thu, 19 Sep 2024 12:06:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3D2176B0093; Thu, 19 Sep 2024 12:06:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 205356B008C for ; Thu, 19 Sep 2024 12:06:41 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id BB9B9C0EA1 for ; Thu, 19 Sep 2024 16:06:40 +0000 (UTC) X-FDA: 82581965760.25.FFE124A Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf15.hostedemail.com (Postfix) with ESMTP id F0B14A0028 for ; Thu, 19 Sep 2024 16:06:37 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=T1QBxM5q; spf=pass (imf15.hostedemail.com: domain of bfoster@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bfoster@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726761940; a=rsa-sha256; cv=none; b=8PoRhtMfcmpuZRB2SJugGMQw6r6ShDEXfEcvUqG4ePTqaJt03VmcPQTodRSsfVZXebVBy5 OuFsdPJI/C/0LTp6cwJJ9uN9ux6monFchcc0l0uRHOqlFKEOP8aaKbtyDFr0B0CVqjFORx cfEN/tdlbCPTuOYEzdUIEEyb/UTLUOQ= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=T1QBxM5q; spf=pass (imf15.hostedemail.com: domain of bfoster@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bfoster@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726761940; 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:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=21rYFMXb31lvADICgRw9dmiluvbLAQsvS5HBqpSM0e4=; b=3Ofh6/lmL0uxOJ7X3ZZBvyVobLLMYlPS4fwBGntvD82jqJPAJ3WRUN0IHbBX4JgHq8B98W 8nmFthQYtWK9Jj2FfHJsmdh+4OUiALZQvG8Towv409oq6siqFz8a0ptkEfXfcLEiroGwL4 S11l/n31g4/GRYaTfo2+0CGe7OJlTeU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1726761997; h=from:from: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:content-transfer-encoding; bh=21rYFMXb31lvADICgRw9dmiluvbLAQsvS5HBqpSM0e4=; b=T1QBxM5q9UCP2BWtSPeL4XULZEu8Xq2W5eYegKOEv31NYwJQW1d2vwb1IPLpGsSK2pzMFa O6MDxcieH+y+2RHLKFP8idrYO25xjSdHlw7IcmYi+hANiB55sVFx1J2c+jiyDyL+z7Woz8 ktKFTOfw76yIC6lPBDEQqNdYHAup5oo= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-464-U3qnpmrpMeKr523u27Cxxg-1; Thu, 19 Sep 2024 12:06:35 -0400 X-MC-Unique: U3qnpmrpMeKr523u27Cxxg-1 Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (unknown [10.30.177.17]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id E7A0B1955D47; Thu, 19 Sep 2024 16:06:33 +0000 (UTC) Received: from bfoster.redhat.com (unknown [10.22.9.175]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 0AF7019560A3; Thu, 19 Sep 2024 16:06:32 +0000 (UTC) From: Brian Foster To: linux-ext4@vger.kernel.org, linux-mm@kvack.org Cc: linux-fsdevel@vger.kernel.org, willy@infradead.org Subject: [PATCH 0/2] ext4, mm: improve partial inode eof zeroing Date: Thu, 19 Sep 2024 12:07:39 -0400 Message-ID: <20240919160741.208162-1-bfoster@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17 X-Stat-Signature: pud74cjsa45n9hbgxy58i419btztkw3r X-Rspamd-Queue-Id: F0B14A0028 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1726761997-604407 X-HE-Meta: U2FsdGVkX18sSlP0dYMB2iz2EYNfTVercyEMbKrBd2KlyNtFwUb5Ta2RmRWctxKPp0l1gYXFEkvLmZS2plO/D3qg1A+IUj/dnyhmGWuTb7Z4w5hidJ42KcslAgtA1uM/B0DFVa/seCzXtLTCadUH1ur1tLUp/qiFhuRewZ+k9MUTNXIfPT9b9mIDvmJf66lbeNc0Gy3IL7ZFscyfvyHcgVSdumENjGLeRAWEx4XDEZJ+C7AGKxRCUvE7ytrPtDEyVa2iLihxpdAY7MGV/V/S//51Nt2L6TErx8/JT8QZH0AdwMy9Zz/ZYQllkb66KmtVC5pkM/H4tIlcVlddjW45uzcz0VqzbkZxoUUM2wmH3YfSqymhHTQsPwA/Sa/k1YOCQmIfShnU6a6tb0ZdQLvHtE3eEhaT+KlknUXK4LdtddZ4sG8Xh3jIs8YqdQjxUuaNqn7O/3YjdbM/H679rzAEv0oUt8gLQZwKPmRkOlkFZjGpfbjebhN85+Rhkb06b3hasPiq8g6k9cTs8OtPNTNEpxIfykJI8jTg5UxidWJsrU4fvS8MamigVDucsWFQbJ+9vhOviTIl+jWECuLIEjSHSEXCqtuhufRC75wX+/Ys0uoRVV7Nb1SclGRZm7LxMZyN9x/tvVPHMRUHJbOjPXIcX3ALbeLoqZG2f1akku310mChAELz1mnMvxMIbmUzXx6XFUiYNKPonR/PYuRcruDsWDc2bXaDIDmNYRmF6eTyMwVbW1DtrgRZgede6M3eZMdhD2UVK+tPY/MYQ2DkFcPCJ2EpEZlYQHD+LNHwe/zMdlzhKEQCYyTEW1AtOjHNmIrm1CBTcd7wMAo2KB3MloBVSBkqGaZfKkrMXQ+bwDPsa6FhiN9IUVQAcTE0gCly517QZ+lPqIbU62uQAzFws1ZTEikzz0fCceODVsWzaJ0tjgUNhcyo2NR6w4uSCLcgh4n8hPDxTLUEdINh9N7KsvX WEjc9CiA fv/c178uvvCAV9drGHn+AFDNlSgbCnPUObmDWfE4kLMGhiv4lb9j961gHPV79adOnVCETloJ/2bvNgGiBL0b5/O4ar18x5dGp8PtAGqteB3DWRCfsedbGiDB44RkPXiedRLVDSajVzwxH82lRJ1vtT+ppc5LicWNJhl1qLw1qDuaBy1CoeTjxKF54S8/Vkz3RwdNEiD/T4G7azfKGq1LTbICSRxNHimJ/IVkr2xoJmAdmz9dRPkoVlgBTu9Tb/OavW/AEwx1ckASVT1zCJTnsD26ejvDR7Z2oOUwTwKfCiELI8/sY9UGLh/W6vU64AclqlgIOiEYNX9K90pOjFHygRAGipGWjm9YBa/WL 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: Hi all, I've been poking around at testing zeroing behavior after a couple recent enhancements to iomap_zero_range() and fsx[1]. Running [1] on ext4 has uncovered a couple issues that I think share responsibility between the fs and pagecache. The details are in the commit logs, but patch 1 updates ext4 to do partial eof block zeroing in more cases and patch 2 tweaks pagecache_isize_extended() to do eof folio zeroing similar to as is done during writeback (i.e., ext4_bio_write_folio(), iomap_writepage_handle_eof(), etc.). These kind of overlap, but the fs changes handle the case of a block straddling eof (so we're writing to disk in that case) and the pagecache changes handle the case of a folio straddling eof that might be at least partially hole backed (i.e. sub-page block sizes, so we're just clearing pagecache). Aside from general review, my biggest questions WRT patch 1 are 1. whether the journalling bits are handled correctly and 2. whether the verity case is handled correctly. I recall seeing verity checks around the code and I don't know enough about the feature to quite understand why. FWIW, I have run fstests against this using various combinations of block size and journalling modes without any regression so far. That includes enabling generic/363 [1] for ext4, which afaict is now possible with these two proposed changes. WRT patch 2, I originally tested with unconditional zeroing and added the dirty check after. This still survives testing, but I'm having second thoughts on whether that is correct or introduces a small race window between writeback and an i_size update. I guess there's also a question of whether the fs or pagecache should be responsible for this, but given writeback and truncate_setsize() behavior this seemed fairly consistent to me. Thoughts, reviews, flames appreciated. Brian [1] https://lore.kernel.org/fstests/20240828181534.41054-1-bfoster@redhat.com/ Brian Foster (2): ext4: partial zero eof block on unaligned inode size extension mm: zero range of eof folio exposed by inode size extension fs/ext4/extents.c | 7 ++++++- fs/ext4/inode.c | 51 +++++++++++++++++++++++++++++++++-------------- mm/truncate.c | 15 ++++++++++++++ 3 files changed, 57 insertions(+), 16 deletions(-)