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 1FF8FC5B552 for ; Tue, 10 Jun 2025 12:23:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AF6F96B009C; Tue, 10 Jun 2025 08:23:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AA88B6B009D; Tue, 10 Jun 2025 08:23:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9E8956B009E; Tue, 10 Jun 2025 08:23:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 7F3126B009C for ; Tue, 10 Jun 2025 08:23:16 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 2EEF0C0165 for ; Tue, 10 Jun 2025 12:23:16 +0000 (UTC) X-FDA: 83539405992.12.941A459 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 3688FA000C for ; Tue, 10 Jun 2025 12:23:14 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="P/3eZ2t+"; 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=quarantine) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749558194; 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=GiWXWdJikqoIX0QaIbtyGeuDqgzC7gx2eetCW8Ce0Fw=; b=kU777mFugLcq96xSnH1xci1RLsyCXVmcx5gedt2KEAeg1RYw7tmRfB0kWP/AjwXuMoNcWb wTm/bEDN+tmozhsi4YWMQGllXFZKZobEAseP3z8tPksUtg8DQHhY3Rm5bnUCMANWCya8SK PKxhpJ07ThHZlBaT1UzuZrmV65KyxyI= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="P/3eZ2t+"; 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=quarantine) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749558194; a=rsa-sha256; cv=none; b=LXS84sZiWjjm8giSOT3WEDElHvay5VC6Drcnrhl7Q745Q13DNZyP1Q0zd0Ill8uXS47nze JhZPmRYai52CqwFySfJjwJsrlpL86zUcnX3N+M6hZCiEvxwOzzIefRIqlZxS32tQC8AdW2 9lVErDzkYLUgQta5WPea0AXic1HDOnM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1749558193; 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=GiWXWdJikqoIX0QaIbtyGeuDqgzC7gx2eetCW8Ce0Fw=; b=P/3eZ2t+0qfMLZGnbIyGJuGxOZpzVyX441dQyspaajGoqlnYx3pJxlYJ3riret9pHrPQlO VNAtaFlHXPuAAzF/VS4XVdvZ4izTNBcsJr53AV9IfK/gz8VRWIUcNzfxtQfFi6PtzVDDVj D97VxfytYyOObnA7tw1LaeH4an8RdKY= Received: from mx-prod-mc-01.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-146-ypkTm2-fP4-Suj9YEK5lUg-1; Tue, 10 Jun 2025 08:23:12 -0400 X-MC-Unique: ypkTm2-fP4-Suj9YEK5lUg-1 X-Mimecast-MFC-AGG-ID: ypkTm2-fP4-Suj9YEK5lUg_1749558191 Received: from mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.40]) (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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 2242D195608E; Tue, 10 Jun 2025 12:23:11 +0000 (UTC) Received: from bfoster (unknown [10.22.80.100]) by mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 59A1E19560A3; Tue, 10 Jun 2025 12:23:10 +0000 (UTC) Date: Tue, 10 Jun 2025 08:26:45 -0400 From: Brian Foster To: Christoph Hellwig Cc: linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH RFC 7/7] xfs: error tag to force zeroing on debug kernels Message-ID: References: <20250605173357.579720-1-bfoster@redhat.com> <20250605173357.579720-8-bfoster@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 3.0 on 10.30.177.40 X-Stat-Signature: zoqidcdtmg9tup9y3335fqhwt8ffjbsj X-Rspamd-Queue-Id: 3688FA000C X-Rspam-User: X-Rspamd-Server: rspam02 X-HE-Tag: 1749558194-838220 X-HE-Meta: U2FsdGVkX197dbKeINj64o0OEDEuTyBV5z0ea4+f8INOSmyXxM2suGPpwZuYxaIbaQFx+7LUtK/rQFaTROSCndnk7Mdlj8XgHclmNrbWMn8PMc41ghei0lvOQFx9TrqQrA0A+kGnrxbTxoxAi3sQGhHAU4sbc2hqjD8U8cVucFfmlVcJUmg8ZcI+xm3AJRBlYE4zvp4klk8Qo+qkkqP5gATbgyvAxs+L6bnX9r3kr9Z74JcBCCSnKml5xUVV3LnWdev5o1O4tVwgM+rn9CzPCrCmh3pVNA1qFMYW0SBL9yvW1LG9mAVuk/xulrJR13CEfzlq+TNKwbcmcWq+UXkxnmRJigk8H4YDverRYqWTRk5mGAAWISrbwgm7UbfOYo4Atea+GzUiZ4LIZowOaYtcrARE3wYBshw2RSP3de+/PAMBn+rNzCRoWojZmizUaFUw2Fx/QBRyJNc0g5gAxUcb4a71+yvU0Ng5SOeox5MRYx7jvLwTGfrnvKZn0vg3Xl+YxyCX9NqwiM9pmDLRYCTpqHg5BdwOHWazL79UXB2DPvJtEgeVcdgUpct2DWr0VqJzPakLDyMpgUnIcXxMyoac5GUXPMdGLpJ71vKVgIIdGlb92zW8IKV/+K2RjhiRFdHhyaJE4LjznxPH2mkzerg0Uro9XI2nvrLdF7j4RepQHjbidevzhuja0ejzPo1xNlbs39cvOenN090nci/e9IyB7hXvGUNZAwzj2DK256Vk2C7uaJIlx0GzbLxGuwsFATffiFkznj50uJNpznOe77ZQJOZ8Qf6lF4Jgmld/gAFWYT+kUq4G0p9MJOVYJHLzm5OGlzb/wbs7MJEgM5r7J6X7SxRlAslrt68E+H0BQA0uS1/lhSnMrFgq4sVLTYyX9+CH6y+ohnUeNtfbZHvtLOoI8yhPx95HI90VNzcvPZmuWBR5NrR96r9g0jGzDp4x0SsMkEn0h4/GSEcmYDIUrHF XT8J2IoM ueSLcjnMgFIRKnfkZOYBseIQd710bHJGVhDm2QwO2N8BgPeJreZesospVoXJqCN735ok3DeOeojE3K6hfc7I33UtAbD34HXgVR2itxxdyvFiOEn2hog4nk9DtAF7pOy/EiToS/Y5REVKDBYB2yS3rxw72SONKSmwitju97JxLEejOzWMHfglRO3MJXAzoiI7GjdelNV8iK5MyjipiEsvczi94pOpSMnATyZvj15lUOjVI9m1l5SN9EYQffQkgCNkDNCvkB+u9+nzM+sgW6w6hrS9jKHxfrBQ8Y2N2ATd+Da8DrH08khdSwxHiTOvSLv9tLOh0efmOSp4XnKJ6x2RV0TFt0T+4PSQjlgufJM/mZ/KV2zs= 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, Jun 09, 2025 at 09:33:37PM -0700, Christoph Hellwig wrote: > On Thu, Jun 05, 2025 at 01:33:57PM -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. > > I like this, having an easy way to improve code coverage using the > existing fallocate and errtag interfaces is always a good thing. > > Can I assume you plan to add a testcase using the errtag to xfstests? > Well that is kind of the question.. ;) My preference was to either add something to fstests to enable select errortags by default on every mount (or do the same in-kernel via XFS_DEBUG[_ERRTAGS] or some such) over just creating a one-off test that runs fsx or whatever with this error tag turned on. [1]. That said, I wouldn't be opposed to just doing both if folks prefer that. It just bugs me to add yet another test that only runs a specific fsx test when we get much more coverage by running the full suite of tests. IOW, whenever somebody is testing a kernel that would actually run a custom test (XFS_DEBUG plus specific errortag support), we could in theory be running the whole suite with the same errortag turned on (albeit perhaps at a lesser frequency than a custom test would use). So from that perspective I'm not sure it makes a whole lot of sense to do both. So any thoughts from anyone on a custom test vs. enabling errortag defaults (via fstests or kernel) vs. some combination of both? Brian [1] Eric also raised the idea of branching off "test tag" variants of errortags that might help distinguish injection points that control behavior vs. those that truly create errors. That could reduce confusion for testers and whatnot. I haven't dug into viability, but in theory that could also define a set of events that don't spew event trigger noise into dmesg if certain events were to be enabled by default (again, on debug kernels only).