linux-kernel - Re: [GIT PULL] bcachefs fixes for 6.12-rc2

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.