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]
Date: Tue, 19 Mar 2024 10:01:11 -0700
From: Bart Van Assche <bvanassche@....org>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Mike Christie <michael.christie@...cle.com>,
 "James E . J . Bottomley" <jejb@...ux.ibm.com>,
 "Martin K . Petersen" <martin.petersen@...cle.com>,
 Lukas Bulwahn <lukas.bulwahn@...il.com>, linux-scsi@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] scsi: core: Make scsi_lib KUnit tests modular for real

On 3/19/24 09:10, Geert Uytterhoeven wrote:
> On Tue, Mar 19, 2024 at 5:03 PM Bart Van Assche <bvanassche@...org> wrote:
>> On 3/19/24 05:02, Geert Uytterhoeven wrote:
>> kernel module? What are the advantages compared to the current approach?
>> That information is missing from the patch description.
> 
> SCSI_LIB_KUNIT_TEST is already tristate, so the original author must
> have meant it to be modular.  Or perhaps he just copied it from
> (most/all) other tests ;-)
> 
> Anyway, I find it very useful to be able to do "modprobe kunit" and
> "modprobe <test>" to run a test when I feel the need to do so.

Hi Geert,

Why to run hardware-independent kunit tests on the target system instead
of on the host? Isn't it much more convenient when developing embedded
software to run kunit tests on the host using UML? The script I use to
run SCSI kunit tests is available below. And if there is a desire to run
SCSI tests on the target system, how about adding triggers in sysfs for
running kunit tests? The (GPL v2) Samsung smartphone kernel supports
this but I have not yet checked whether their implementation is
appropriate for the upstream kernel.

Thanks,

Bart.


#!/bin/sh

set -e

mkdir -p .kunit
if [ -e .config ]; then
     rm -f .config
     make ARCH=um mrproper
fi
if [ ! -e .kunit/.kunitconfig ] || [ "$0" -nt .kunit/.kunitconfig ]; then
     echo "Regenerating .kunit/.kunitconfig"
     cat <<EOF >.kunit/.kunitconfig
CONFIG_BLK_DEV_SD=y
CONFIG_BLK_DEV_ZONED=y
CONFIG_MQ_IOSCHED_DEADLINE=y
CONFIG_BLOCK=y
CONFIG_EISA=n
CONFIG_KUNIT=y
CONFIG_SCSI_PROCFS=n
#CONFIG_PROVE_LOCKING=y
CONFIG_SCSI=y
#CONFIG_SYSFS=y
CONFIG_UBSAN=y
CONFIG_KASAN=y
CONFIG_RUNTIME_TESTING_MENU=n
CONFIG_WERROR=y
EOF
     syms=(
	CONFIG_SCSI_ERROR_TEST
	CONFIG_SCSI_PROTO_TEST
	CONFIG_SCSI_SD_TEST
     )
     for s in "${syms[@]}"; do
     if git grep -qw "${s#CONFIG_}" block/Kconfig* drivers/scsi/Kconfig; 
then
	echo "$s=y" >> .kunit/.kunitconfig
     fi
     done
     cp .kunit/.kunitconfig .kunit/.config
fi
/tools/testing/kunit/kunit.py run

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ