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: <20210810165029.GA20722@lst.de>
Date:   Tue, 10 Aug 2021 18:50:29 +0200
From:   Christoph Hellwig <hch@....de>
To:     Bart Van Assche <bvanassche@....org>
Cc:     Christoph Hellwig <hch@....de>, 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>
Subject: Re: [PATCH v4 3/3] configfs: Add unit tests

On Mon, Aug 09, 2021 at 11:31:23AM -0700, Bart Van Assche wrote:
> I can store this documentation in a new README, but isn't this something
> that has already been explained in
> Documentation/dev-tools/kunit/kunit-tool.rst?

So reference that.

> 
> >> +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.

So for the current in-kernel approach:

Nacked-by: Christoph Hellwig <hch@....de>