From: Fedora Kernel Team kernel-team@fedoraproject.org
Hi,
As part of the ongoing rebase effort, the following configuration options need to be reviewed.
As a reminder, the ARK configuration flow involves moving unreviewed configuration options from the pending directory to the ark directory. In the diff below, options are removed from the pending directory and added to the ark hierarchy. The final options that need to be ACKed are the files that are being added to the ark hierarchy.
If the value for a file that is added should be changed, please reply with a better option.
CONFIG_XFS_SUPPORT_V4:
The V4 filesystem format lacks certain features that are supported by the V5 format, such as metadata checksumming, strengthened metadata verification, and the ability to store timestamps past the year 2038. Because of this, the V4 format is deprecated. All users should upgrade by backing up their files, reformatting, and restoring from the backup.
Administrators and users can detect a V4 filesystem by running xfs_info against a filesystem mountpoint and checking for a string beginning with "crc=". If the string "crc=0" is found, the filesystem is a V4 filesystem. If no such string is found, please upgrade xfsprogs to the latest version and try again.
This option will become default N in September 2025. Support for the V4 format will be removed entirely in September 2030. Distributors can say N here to withdraw support earlier.
To continue supporting the old V4 format (crc=0), say Y. To close off an attack surface, say N.
Symbol: XFS_SUPPORT_V4 [=y] Type : bool Defined at fs/xfs/Kconfig:25 Prompt: Support deprecated V4 (crc=0) format Depends on: BLOCK [=y] && XFS_FS [=m] Location: -> File systems -> XFS filesystem support (XFS_FS [=m])
---
Cc: Brian Foster bfoster@redhat.com Cc: Carlos Maiolino cmaiolin@redhat.com Signed-off-by: Fedora Kernel Team kernel-team@fedoraproject.org --- .../common/generic/CONFIG_XFS_SUPPORT_V4 | 1 + .../generic/CONFIG_XFS_SUPPORT_V4 | 34 ------------------- 2 files changed, 1 insertion(+), 34 deletions(-) create mode 100644 redhat/configs/common/generic/CONFIG_XFS_SUPPORT_V4 delete mode 100644 redhat/configs/pending-common/generic/CONFIG_XFS_SUPPORT_V4
diff --git a/redhat/configs/common/generic/CONFIG_XFS_SUPPORT_V4 b/redhat/configs/common/generic/CONFIG_XFS_SUPPORT_V4 new file mode 100644 index 000000000000..12315e1fff2b --- /dev/null +++ b/redhat/configs/common/generic/CONFIG_XFS_SUPPORT_V4 @@ -0,0 +1 @@ +CONFIG_XFS_SUPPORT_V4=y diff --git a/redhat/configs/pending-common/generic/CONFIG_XFS_SUPPORT_V4 b/redhat/configs/pending-common/generic/CONFIG_XFS_SUPPORT_V4 deleted file mode 100644 index aeb9b39ac5da..000000000000 --- a/redhat/configs/pending-common/generic/CONFIG_XFS_SUPPORT_V4 +++ /dev/null @@ -1,34 +0,0 @@ -# CONFIG_XFS_SUPPORT_V4: -# -# The V4 filesystem format lacks certain features that are supported -# by the V5 format, such as metadata checksumming, strengthened -# metadata verification, and the ability to store timestamps past the -# year 2038. Because of this, the V4 format is deprecated. All users -# should upgrade by backing up their files, reformatting, and restoring -# from the backup. -# -# Administrators and users can detect a V4 filesystem by running -# xfs_info against a filesystem mountpoint and checking for a string -# beginning with "crc=". If the string "crc=0" is found, the -# filesystem is a V4 filesystem. If no such string is found, please -# upgrade xfsprogs to the latest version and try again. -# -# This option will become default N in September 2025. Support for the -# V4 format will be removed entirely in September 2030. Distributors -# can say N here to withdraw support earlier. -# -# To continue supporting the old V4 format (crc=0), say Y. -# To close off an attack surface, say N. -# -# Symbol: XFS_SUPPORT_V4 [=y] -# Type : bool -# Defined at fs/xfs/Kconfig:25 -# Prompt: Support deprecated V4 (crc=0) format -# Depends on: BLOCK [=y] && XFS_FS [=m] -# Location: -# -> File systems -# -> XFS filesystem support (XFS_FS [=m]) -# -# -# -CONFIG_XFS_SUPPORT_V4=y
From: Patrick Talbert on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/738#note_48897252...
This merge request has not been updated in over 30 days. Please review this MR's current changes regarding the following configuration option(s):
CONFIG_XFS_SUPPORT_V4
From: Carlos Maiolino on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/738#note_53069646...
So, this MR has been created months ago, that explains why I didn't even know about this until now. I think I didn't even have a gitlab account that time.
Since Brian and I are tagged here, I suppose it's expecting a review from us?
About the change itself, why is this removing V4 support from RHEL-ark? This will require everybody using kernel-ark who is still using V4 to need to recreate their FS'es, all filesystems will become unmountable, and worse, systems using XFS as rootFS will not boot across a reboot, I don't really think that's what we are aiming for here.
From: Carlos Maiolino on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/738#note_53070056...
Ok, so, looks like gitlab interface tricked me... I haven't seen the chunk adding the config option above, only the chunk removing it.
So, for that case, yes, V4 support should stay.
From: Don Zickus on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/738#note_53086722...
@cmaiolino can you ack these change then?
From: Carlos Maiolino on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/738#note_53114035...
[1]Don Zickus [2]commented:
[3]@cmaiolino can you ack these change then?
Oh, sure.
How can I ack this MR without using the web interface? Is it possible?
hmmm, maybe I need to point bichon to the right project....
Cheers
From: Patrick Talbert on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/738#note_53576598...
You can respond to the email with the standard `Acked-by: NAME <email>` and that should be good enough.
Or if you have 'lab' set up and want to approve the MR then: $ lab mr approve 738
kernel@lists.fedoraproject.org