linux-kernel - Re: [PATCH v4 3/3] configfs: Add unit tests

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: <9b1e5c35-1d11-0afa-d382-6f5dc0b14a23@acm.org>
Date:   Tue, 10 Aug 2021 11:45:32 -0700
From:   Bart Van Assche <bvanassche@....org>
To:     Christoph Hellwig <hch@....de>
Cc:     Joel Becker <jlbec@...lplan.org>, linux-kernel@...r.kernel.org,
        Bodo Stroesser <bostroesser@...il.com>,
        "Martin K . Petersen" <martin.petersen@...cle.com>,
        Brendan Higgins <brendanhiggins@...gle.com>,
        Yanko Kaneti <yaneti@...lera.com>,
        Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: [PATCH v4 3/3] configfs: Add unit tests

On 8/10/21 9:50 AM, Christoph Hellwig wrote:
> On Mon, Aug 09, 2021 at 11:31:23AM -0700, Bart Van Assche wrote:
>>>> +config CONFIGFS_KUNIT_TEST
>>>> +	bool "Configfs Kunit test" if !KUNIT_ALL_TESTS
>>>> +	depends on CONFIGFS_FS && KUNIT=y
>>>> +	default KUNIT_ALL_TESTS
>>>
>>> Why does it depend on KUNIT=y?  What is the issue with a modular KUNIT
>>> build?
>>
>> The unit tests calls do_mount(). do_mount() has not been exported and
>> hence is not available to kernel modules. Hence the exclusion of KUNIT=m.
> 
> You should probably document that.  But then again this is another
> big red flag that this code should live in userspace.
> 
>>> To me this sounds like userspace would be a better place for these
>>> kinds of tests.
>>
>> Splitting the code that can only be run from inside the kernel (creation
>> of configfs attributes) and the code that can be run from user space and
>> making sure that the two run in a coordinated fashion would involve a
>> significant amount of work. I prefer to keep the current approach.
> 
> But userspace is the right place to do this kind of pathname
> based file system I/O.

Shuah, as selftest maintainer, can you recommend an approach? How about 
splitting patch 3/3 from this series into a kernel module (the code that 
creates the configfs test attributes) and user space code (the code that 
reads and writes the configfs attributes) and adding the user space code 
in a subdirectory of tools/testing/selftests/?

Thanks,

Bart.