Re: [PATCH v2] Add EXT4_STATE_MAY_INLINE_DATA check in ext4_readdir

"Theodore Tso" <[email protected]>
Newsgroups org.kernel.vger.linux-ext4
Message-ID <[email protected]>
Given the issues that were reported by the Sashiko and Syzbot issues,
I commend that you try using the kvm-xfstests[1] test appliance or the
related gce-xfstests[2] test appliance if you have access to Google
Compute Engine

[1] https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-quickstart.md
[2] https://thunk.org/gce-xfstests

Since you are making changes to inline_data feature, you'd use it
soemthing like this:

% cd /usr/src/linux  # replace with your kernel sources
% install-kconfig
% kbuild
% kvm-xfstests -c ext4/inline -g auto

You can also add some options to install-kconfig to enable extra
debugging, of which the most interesting are --kasan and --lockdep.  I
would recommend doing your initial testing using just the plain
install-kconfig, and then once you are getting clean run, do separate
runs with the Kernel Address Sanitizer and the runtime locking
correctness validator.

The way I do my testing using gce-xfstests is to use a command like
this: "gce-xfstests ltm -c ext4/all -g auto" which will launch 12
VM's, for a variety of ext4 test scenarios (e.g., with bigalloc, fast
commit, 1k block sizes, etc.)  You can of course try running
"kvm-xfstests -c ext4/all -g auto" but this will likely take around
24-36 hours depending on how fast your local storage test devices.
(Using gce-xfstest's lightweight test manager takes around 2 hours of
wall clock time, since the test VM's run in parallel.)

Cheers,

					- Ted
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.