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 F25E8C83F22 for ; Tue, 15 Jul 2025 12:35:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 92EF58D0008; Tue, 15 Jul 2025 08:35:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8DE1D8D0001; Tue, 15 Jul 2025 08:35:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7CCC28D0008; Tue, 15 Jul 2025 08:35:30 -0400 (EDT) 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 6CA2F8D0001 for ; Tue, 15 Jul 2025 08:35:30 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 07AF016048F for ; Tue, 15 Jul 2025 12:35:30 +0000 (UTC) X-FDA: 83666444820.23.1FE94C7 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf21.hostedemail.com (Postfix) with ESMTP id 240811C0004 for ; Tue, 15 Jul 2025 12:35:27 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=NnVvDVh+; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf21.hostedemail.com: domain of bfoster@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bfoster@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752582928; a=rsa-sha256; cv=none; b=s17dc4uBny+rOIE9/71HJkeHaqMiVmQWxsW9yV85krEWsPTXsIuuPL5EaIhW0ZHGTaW2LQ b0edlGnCPhblo8mVdL+VGxxorMkyMmytKaS0IFUP5Vk543eR5kVbSUgYw5lsEbcYNQOE5o 4wi/q2hZWlQymzdcyU1FaRzwl6hx0aw= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=NnVvDVh+; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf21.hostedemail.com: domain of bfoster@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bfoster@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752582928; 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=xCgiUZcwT6C9cPLH2UufX6wt62EgnsmD7bHGYbxxqSQ=; b=LMP8b58kD1pUOXq7h8OReFuUq89i1SuRstqoHdHQOL2UfxfVzTmV5sFKrq0atInVJI5iN4 hXBDVDhPOmmOZ6Hw6Fw+xlI203Az2ueAU9j2YEWU1/W8FhgZiWyTdWIjgHUUyos+rrnv5q UG7nznvhXHaIZCr4OiO+O7MPrmie6iI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1752582927; 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: in-reply-to:in-reply-to:references:references; bh=xCgiUZcwT6C9cPLH2UufX6wt62EgnsmD7bHGYbxxqSQ=; b=NnVvDVh+8MDVwKQomDQFeNEBZDjb5edDERmgjs9iGKkHzUFYq9TPW8xKgYVbA3MR/x1Aav /tOeBJBnN8OIPdfUEiGLvp1Hiu+axeasE3CvkuDUefD1Vu4lZQbNjRsoPW3c9hnIqYs7OB cHvf4tdNstxQFYc8Gi7y1M23GSrFKa0= Received: from mx-prod-mc-04.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-76-WhJq1xnwNICfvmFowoSl_A-1; Tue, 15 Jul 2025 08:35:24 -0400 X-MC-Unique: WhJq1xnwNICfvmFowoSl_A-1 X-Mimecast-MFC-AGG-ID: WhJq1xnwNICfvmFowoSl_A_1752582923 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (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-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 16F7519560BA; Tue, 15 Jul 2025 12:35:23 +0000 (UTC) Received: from bfoster (unknown [10.22.64.43]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id A98B7180045B; Tue, 15 Jul 2025 12:35:21 +0000 (UTC) Date: Tue, 15 Jul 2025 08:39:03 -0400 From: Brian Foster To: "Darrick J. Wong" Cc: linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-mm@kvack.org, hch@infradead.org, willy@infradead.org Subject: Re: [PATCH v3 7/7] xfs: error tag to force zeroing on debug kernels Message-ID: References: <20250714204122.349582-1-bfoster@redhat.com> <20250714204122.349582-8-bfoster@redhat.com> <20250715052444.GP2672049@frogsfrogsfrogs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250715052444.GP2672049@frogsfrogsfrogs> X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Rspamd-Queue-Id: 240811C0004 X-Stat-Signature: i5f6ecq3djxjquhh1679nmzze63u1ony X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1752582927-299662 X-HE-Meta: U2FsdGVkX19stSsjaJHvTfQK7nAtlUWrMASwDRsczoCYiBwJAjeTc5eecgCPr6XyiQ+08IQO/6Rk+I6k7TmkA8veR55iAGXrASQtyJR5d4vKpLpj3ihGtmdSN6GdBNkSvy7HlF2oqm1oZe4Refeynb4Ov1zR+ABWCYfSUIAho+l5fzpx8+vIOpeW+ggvPhcfiStaiXK/HcnEIIrMBbpn09xk13x+BSseXRR2wTfk84B9Z5xC/jJQvs79ng178cedZo9grrZc5sJg8aMYYulf1k8FHcMYHH4xG6SJFmO507CFOHt4EXBE4ygw9AUq//e0h6CWhp4UUnEqsRdpdzLpEtRgeLPyP/jEsSnwUGCP6aRdCZ+tnbPqGtXn5fbYVy0vdIiPl+JlxGy2E3GxWi+Qz4mdxpcpv28q+21bjCIn/A5TPKGr0iM/Wma7ys/P+6qv9L9/miyO7QPOSrfvNP+fTaI3bsOoVHd77fpqA10HWLM533EOTA7U1Q5amXaglP6lQT9Q31aXCv7R6n9u8zE7BTAGtnTiI1D0rT9YUuDO0SgXtQb5YNjdrpMIBdxjz1kfjDEwWOFDSvAg6O+UQDQ2IAmERDjYpdeyr1TyIhgUQyQu4+ySXFwSmPVAah7CWC0UrVEXGTFtXAZ5RJfWqRWU28tBn8Vhtb6p+hQoPA3iE2isxbiYn7aP8J4Pj7HHDIeeS1tkhx24bTvCnAh9bvOAyvZPEf+KiX3bp3jvNARaSnb/z+UJaV9ZowvRDbfkY0YI1rKr7F1krNXEefpGWnJop22Li3Gy46XGMQWgdxNccqA5uyi1kWO7V7Q40S/d4SvrHSjFyq+zFFMTnlKwkAARD7JRMmu9p7d8zW+VKrSuMdz1J+JkFNC9jnEpwMuSrpWtC0Sk62OBadKvJxtNZIEMuTKkVBgfzOXNBswj2yUblL58HoW/lKGElLx/sjpMXwb4a2lG5SrZGV1iSDnlIoG uzaCsI2n 2cU8E4+Frx1qgnOLmMe93bxY6xig5Eq/PwgU0Lio2nb9XTAv0QSfMmiMew3rOV9AK7YGLybqfpKzQ62CxzKxn1IpP3iVqz9ud4M9X562rD249iZdOEM8EdwrxnpHdDvC1ED96YmX7Z/23M8wt5wED/AIJOXuoT7K/RBA9nO1kSE2plWySAu6/4cExKCXsJ1xhu0mm/l0JlxrPLXjlS/x3WxudBFe5lNB0Sc9XpPF9cpsEgNzlXlwsLo50GpR8TNqHeCQ4o6Qf2gOFmjM4fFI1uqvB7WIJY/FbRQ+77xaSlqXgmEFvhZdFS0uVdtbq6zMCF9vac0Xp0OmHnXSlsDq3bMXqdl3hjOBUHr9Zqbe0hvNCBtBn+7hB6+m90skaMzR+s6GL 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, Jul 14, 2025 at 10:24:44PM -0700, Darrick J. Wong wrote: > On Mon, Jul 14, 2025 at 04:41:22PM -0400, Brian Foster wrote: > > iomap_zero_range() has to cover various corner cases that are > > difficult to test on production kernels because it is used in fairly > > limited use cases. For example, it is currently only used by XFS and > > mostly only in partial block zeroing cases. > > > > While it's possible to test most of these functional cases, we can > > provide more robust test coverage by co-opting fallocate zero range > > to invoke zeroing of the entire range instead of the more efficient > > block punch/allocate sequence. Add an errortag to occasionally > > invoke forced zeroing. > > > > Signed-off-by: Brian Foster > > Reviewed-by: Christoph Hellwig > > --- > > fs/xfs/libxfs/xfs_errortag.h | 4 +++- > > fs/xfs/xfs_error.c | 3 +++ > > fs/xfs/xfs_file.c | 26 ++++++++++++++++++++------ > > 3 files changed, 26 insertions(+), 7 deletions(-) > > ... > > diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c > > index 0b41b18debf3..c865f9555b77 100644 > > --- a/fs/xfs/xfs_file.c > > +++ b/fs/xfs/xfs_file.c > > @@ -27,6 +27,8 @@ > > #include "xfs_file.h" > > #include "xfs_aops.h" > > #include "xfs_zone_alloc.h" > > +#include "xfs_error.h" > > +#include "xfs_errortag.h" > > > > #include > > #include > > @@ -1269,13 +1271,25 @@ xfs_falloc_zero_range( > > if (error) > > return error; > > > > - error = xfs_free_file_space(XFS_I(inode), offset, len, ac); > > - if (error) > > - return error; > > + /* > > + * Zero range implements a full zeroing mechanism but is only used in > > + * limited situations. It is more efficient to allocate unwritten > > + * extents than to perform zeroing here, so use an errortag to randomly > > + * force zeroing on DEBUG kernels for added test coverage. > > + */ > > + if (XFS_TEST_ERROR(false, XFS_I(inode)->i_mount, > > + XFS_ERRTAG_FORCE_ZERO_RANGE)) { > > + error = xfs_zero_range(XFS_I(inode), offset, len, ac, NULL); > > Isn't this basically the ultra slow version fallback version of > FALLOC_FL_WRITE_ZEROES ? > ~/linux$ git grep FALLOC_FL_WRITE_ZEROES ~/linux$ IIRC write zeroes is intended to expose fast hardware (physical) zeroing (i.e. zeroed written extents)..? If so, I suppose you could consider this a fallback of sorts. I'm not sure what write zeroes is expected to do in the unwritten extent case, whereas iomap zero range is happy to skip those mappings unless they're already dirty in pagecache. Regardless, the purpose of this patch is not to add support for physical zeroing, but rather to increase test coverage for the additional code on debug kernels because the production use case tends to be more limited. This could easily be moved/applied to write zeroes if it makes sense in the future and test infra grows support for it. Brian > --D > > > + } else { > > + error = xfs_free_file_space(XFS_I(inode), offset, len, ac); > > + if (error) > > + return error; > > > > - len = round_up(offset + len, blksize) - round_down(offset, blksize); > > - offset = round_down(offset, blksize); > > - error = xfs_alloc_file_space(XFS_I(inode), offset, len); > > + len = round_up(offset + len, blksize) - > > + round_down(offset, blksize); > > + offset = round_down(offset, blksize); > > + error = xfs_alloc_file_space(XFS_I(inode), offset, len); > > + } > > if (error) > > return error; > > return xfs_falloc_setsize(file, new_size); > > -- > > 2.50.0 > > > > >