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: <6hjoiumgl3sljhjtmgvsifgu2kdmydlykib3ejlm5pui6zjla4@u7g2bjk4kcau>
Date: Mon, 7 Oct 2024 15:59:17 -0400
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: "Jason A. Donenfeld" <Jason@...c4.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, 
	Theodore Ts'o <tytso@....edu>, linux-bcachefs@...r.kernel.org, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] bcachefs fixes for 6.12-rc2

On Mon, Oct 07, 2024 at 05:01:55PM GMT, Jason A. Donenfeld wrote:
> On Sun, Oct 06, 2024 at 03:29:51PM -0400, Kent Overstreet wrote:
> > But - a big gap right now is endian /portability/, and that one is a
> > pain to cover with automated tests because you either need access to
> > both big and little endian hardware (at a minumm for creating test
> > images), or you need to run qemu in full-emulation mode, which is pretty
> > unbearably slow.
> 
> It's really not that bad, at least for my use cases:
> 
>     https://www.wireguard.com/build-status/
> 
> This thing sends pings to my cellphone too. You can poke around in
> tools/testing/selftests/wireguard/qemu/ if you're curious. It's kinda
> gnarly but has proven very very flexible to hack up for whatever
> additional testing I need. For example, I've been using it for some of
> my recent non-wireguard work here: https://git.zx2c4.com/linux-rng/commit/?h=jd/vdso-test-harness
> 
> Taking this straight-up probably won't fit for your filesystem work, but
> maybe it can act as a bit of motivation that automated qemu'ing can
> generally work. It has definitely caught a lot of silly bugs during
> development time.

I have all the qemu automation:
https://evilpiepirate.org/git/ktest.git/

That's what I use for normal interactive development, i.e. I run
something like

build-test-kernel -I ~/ktest/tests/fs/bcachefs/replication.ktest rereplicate

which builds a kernel, launches a VM and starts running a test; test
output on stdout, I can ssh in, ctrl-c kills it like any other test.

And those same tests are run automatically by my CI, which watches
various git branches and produces results here:
https://evilpiepirate.org/~testdashboard/ci?user=kmo&branch=bcachefs-testing

(Why yes, thas is a lot of failing tests still.)

I'm giving out accounts on this to anyone in the community doing kernel
development, we've got fstests wrappers for every local filesystem, plus
nfs, plus assorted other tests. Can always use more hardware if anyone
wants to provide more machines.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ