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 D30D8C5B543 for ; Tue, 10 Jun 2025 14:17:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6C84D6B0092; Tue, 10 Jun 2025 10:17:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6A03B6B0093; Tue, 10 Jun 2025 10:17:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5B8466B0095; Tue, 10 Jun 2025 10:17:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 3A5E26B0092 for ; Tue, 10 Jun 2025 10:17:03 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id D7BC412049C for ; Tue, 10 Jun 2025 14:17:02 +0000 (UTC) X-FDA: 83539692684.23.F50220A Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf29.hostedemail.com (Postfix) with ESMTP id F051812000D for ; Tue, 10 Jun 2025 14:17:00 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="CQ5DpKy/"; spf=pass (imf29.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=1749565021; 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=XUcZUslNDuQ2HQKyQbnOe3UdhZ+iJ00hJ31vDYu2byM=; b=rzxVSybzxKV2VgtiZm2KzjaRCHHdRzhuSRcCxPT8dZ+eJ1UMjpQ629Po7uBmgK3Kb4G5Bt VhHjx5LAwKv/A7ufda82j7/CPbIdewYhnJu2JgXVUpEMB69AX+7+RRl6EUW/7Qw4+raXwS gMb6c7SLvSE/QkcknbDKNcEClbJ/t3Q= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="CQ5DpKy/"; spf=pass (imf29.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=1749565021; a=rsa-sha256; cv=none; b=IsZsU7yD9/s0f3+vsDBeDhDs4X1AZ1vLteHGHx9zTRNnJsp93V+wN++/Nxvcaoxs9je7gB uXHcs5+CM6KW/L2cGYXCjh3ikKDQdm85VQGNzaB2o5gqyC7ECJL3qPLYQtpZjzX1VMANpO UOnYyddwFDEDQlcTmj/ufDymPxFcl+8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1749565020; 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=XUcZUslNDuQ2HQKyQbnOe3UdhZ+iJ00hJ31vDYu2byM=; b=CQ5DpKy/NyX6ugYQn5FRf4FJvrEmd0Z8VU+rq0S843NkclGu7Q6vH1Slx/3SSLJkO6qu9G itstoAEWS2UG52wrYq6wjieLdQZJaitsXPBY0pF8nKVfZIvaw2P543oDAkXN2Hv7srAkfj xejrKwyCDA4izTj4gKnBEKdQ4QEufps= Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-518-9EMWWKLMMBm0_TWs51s5_Q-1; Tue, 10 Jun 2025 10:16:56 -0400 X-MC-Unique: 9EMWWKLMMBm0_TWs51s5_Q-1 X-Mimecast-MFC-AGG-ID: 9EMWWKLMMBm0_TWs51s5_Q_1749565014 Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (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-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 6CC2518002E4; Tue, 10 Jun 2025 14:16:54 +0000 (UTC) Received: from bfoster (unknown [10.22.80.100]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 7B15B19560B0; Tue, 10 Jun 2025 14:16:53 +0000 (UTC) Date: Tue, 10 Jun 2025 10:20:28 -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.12 X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: F051812000D X-Stat-Signature: caqm3ouae34jq131gfsez9gsjao33cmh X-Rspam-User: X-HE-Tag: 1749565020-214838 X-HE-Meta: U2FsdGVkX1+2xGMzrL0MfeGtJPLZpaiQewpMzKGkSS9aO+g72CwN4E9j7T+Ce6bgsmEsIgr9BswzzVg0RH38HbfQvY+8At+gwaJhK/MgP0wTdocRyUYLY8ShrBsZpScx2jYguFtfCOoqVm+6qZ9x5FGE/FFVYEegs+ZQ6qmALIdO3YuC/XSRJNUBNF++GcHG/zihsN/WOxoFy32Ho6/7qAJm7FRDcyBHbSFQutmI/Li5ReCHSlGy1TraVHXIXOVeyg5RbEq1352c7daa+/Afnjg1XJD6VJ9xFH2M8un13qv6y4NNCxdsnWCkyWWPsfq/ZPVd3rFQkP81IxQzDZkheSLRhRtGcYKYE2o4uqKVmr431VWxMZrC8uIHURI3aYzklvXvuGPYPHM0I0PLyvzj9r2PGRWAguVEp4tlfuvq8lWf9JZLqRblRWSw7fW54YQQQqG5W70yrJ2sbVK1QcReuGpturKjXguRf2ihW4a10D4ijNKCgFkkE6tzAShgwfgLpVryzDTWKTtJQ4UKj71r5B7EB1uVhzIRUcOQv6phXEZVpxvH0569lDzNcWp6CMpk8U4yJwFEarSAh5pNOfmLR61IVc0W13/f9Ay7h4Uv6QqfNtrzDQx7/WKGGDS4iocxWjAfLlEn4criKvlX9c+gB2tAFpTNyj0sOAzakmoiMiEXMR+qR68/KgBMYzz0lxud5/nAWPrbf7SXpJSMxmVVDWd/ag4Ypw5GnbBKb0XS4vkxTj073u53CI6ImarIkoIN9exiUGAh2ZrkWlSDNlD4JRx2vn0Iq6SGlmxWGonQmfHLRtnHMqEdE4kI0KEbLl34Y1b3WndC9O+jtdlKfdLOjFqPhOiDU1IxwQsinQ6L2swi8vd0mCSdnD4kWPngVAvSR+aqiFOi5nr1hy/zgrqblLI7SA9mQSuR3cLy5viTk4gCbumARhFv9QtWVpSelCd9tOhiOPL9arsEsZqSZ4q jW9pm706 RkHsmf58QtKHmWEIwOORtL4vhbZoH/0GGTxlkgtmDrGTtNtuJ8mhtLInSsT2P0aHTGtjpbtd2kP438vIhhnU9crpDYZZ66xHSQ/EqR1mwvsS78R0AoRZ0+udgpYKlkFYwP+1sBqyQpgah4jQXJHae/2GZnQDt2UkOZvch6QsrVflRi/HOPuBvJmmFY0cqgWOKtKjAmaZTvLqP33eLDy3e2841LjVp6Sm7fGDh6w1m2U+v7bh68hbwU8DaatS/MdWPEydGBebZ0KaQbpbdJFDKl6nw/lnhykH+5pufUHF5P4ftNW2vMCEMMBK2WiIp/WZhid4XPhCkPzoAlcqtaSAv0Cb4RC9Fl5mGI7Asth6A+zu9LMI= 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 Tue, Jun 10, 2025 at 06:30:29AM -0700, Christoph Hellwig wrote: > On Tue, Jun 10, 2025 at 08:26:45AM -0400, Brian Foster wrote: > > 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? > > I definitively like a targeted test to exercise it. If you want > additional knows to turn on error tags that's probably fine if it > works out. I'm worried about adding more flags to xfstests because > it makes it really hard to figure out what runs are need for good > test coverage. > > Yeah, an fstests variable would add yet another configuration to test, which maybe defeats the point. But we could still turn on certain tags by default in the kernel. For example, see the couple of open coded get_random_u32_below() callsites in XFS where we already effectively do this for XFS_DEBUG, they just aren't implemented as proper errortags. I think the main thing that would need to change is to not xfs_warn() on those knobs when they are enabled by default. I think there are a few different ways that could possibly be done, ideally so we go back to default/warn behavior when userspace makes an explicit errortag change, but I'd have to play around with it a little bit. Hm? Anyways, given the fstests config matrix concern I'm inclined to at least give something like that a try first and then fall back to a custom test if that fails or is objectionable for some other reason.. Brian