linux-ext4 - Re: [RFC 4/5] check,common/config: Add support for central fsconfig

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87mse4hd5i.fsf@gmail.com>
Date: Sat, 01 Mar 2025 23:00:17 +0530
From: Ritesh Harjani (IBM) <ritesh.list@...il.com>
To: Anand Jain <anand.jain@...cle.com>, "Nirjhar Roy (IBM)" <nirjhar.roy.lists@...il.com>, fstests@...r.kernel.org
Cc: linux-ext4@...r.kernel.org, linux-xfs@...r.kernel.org, ojaswin@...ux.ibm.com, djwong@...nel.org, zlang@...nel.org
Subject: Re: [RFC 4/5] check,common/config: Add support for central fsconfig

Anand Jain <anand.jain@...cle.com> writes:

> On 10/1/25 17:10, Nirjhar Roy (IBM) wrote:
>> This adds support to pick and use any existing FS config from
>> configs/<fstype>/<config>. e.g.
>> 
>> configs/xfs/1k
>> configs/xfs/4k
>> configs/ext4/4k
>> configs/ext4/64k
>> 
>> This should help us maintain and test different fs test
>> configurations from a central place. We also hope that
>> this will be useful for both developers and testers to
>> look into what is being actively maintained and tested
>> by FS Maintainers.
>> 
>> When we will have fsconfigs set, then will be another subdirectory created
>> in results/<section>. For example let's look at the following:
>> 
>> The directory tree structure on running
>> sudo ./check -q 2 -R xunit-quiet -c xfs/4k,configs/xfs/1k selftest/001 selftest/007
>> 
>
>
> The -c option check makes sense to me. Is it possible to get this
> feature implemented first while the -q option is still under discussion?

Hi Anand, 

Thanks for trying the patches. The design of -c option is still under
discussion [1]. But it will be helpful if you could help us understand
your reasons for finding -c option useful :) 

[1]: https://lore.kernel.org/linux-fsdevel/Z55RXUKB5O5l8QjM@li-dc0c254c-257c-11b2-a85c-98b6c1322444.ibm.com/

>
> That said, I have a suggestion for the -c option—
>   Global config variables should be overridden by file system-specific 
> config files.
>
> For example, if configs/localhost.config contains:
>
> MKFS_OPTIONS="--sectorsize 64K"
>
> but configs/<fstype>/some_config sets:
>
> MKFS_OPTIONS=""
>
> then the value from configs/<fstype>/some_config should take priority.
>
> I ran some tests with btrfs, and I don’t see this behavior happening yet.

I think that was intentional. I guess the reasoning was, we don't want to
break use cases for folks who still wanted to use local.config file
option.

However, in the new proposed design [2] we are thinking of having 1
large config per filesystem. e.g. configs/btrfs/config.btrfs which will
define all of the relevant sections e.g. btrfs_4k, btrfs_64k, ...  Then
on invokking "make", it will generate a single large fs config file i.e.
configs/.all-sections-configs which will club all filesystems section
configs together.

Now when someone invokes check script with different -s options, it will
first look into local.config file, if local.config not found, then it
will look into configs/.all-sections-configs to get the relevant section
defines.

This hopefully should address all the other concerns which were raised
on the current central fs config design.

[2]: https://lore.kernel.org/linux-fsdevel/87plj0hp7e.fsf@gmail.com/

-ritesh

>
> Thanks, Anand