Re: btrfs: sleeping function called from invalid context

[Filipe Manana <fdmanana@gmail.com>]

On Mon, Feb 24, 2020 at 9:56 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:
>
> On Mon, Feb 24, 2020 at 10:14:06AM +0000, Filipe Manana wrote:
> > We do have some tests that fail in any kernel release so far. Some
> > because the corresponding fixes are not yet merged or some fail often
> > due to known problems.
> > Looking at your list of failure, I see some that shouldn't be failing
> > like btrfs/053.
>
> I've sent you the compressed tarfile with the test artifacts under
> separate cover.  The files that you'll probably want to look at first
> are ./runtests.log and ./syslog.  The xfstests results artifacts will
> be in ./btrfs/results-default/.
>
> If you have a wiki page or some other pointer of what tests that you
> expect to fail, I can put them into a btrfs-specific or file system
> configuration specific exclude file.  For example, see [1] and [2].

I don't think we do. Usually people keep their own list.
It's also very frequent to have tests fail because the corresponding
patches that fix them were not yet merged, specially for recently
added tests.

>
> [1] https://github.com/tytso/xfstests-bld/blob/master/kvm-xfstests/test-appliance/files/root/fs/ext4/exclude
> [2] https://github.com/tytso/xfstests-bld/blob/master/kvm-xfstests/test-appliance/files/root/fs/ext4/cfg/bigalloc.exclude
>
> I'm planning on running btrfs and xfs tests more frequently to support
> some $WORK initiatives.  So if there are tests which are known
> failures that would be good for me to suppress, and if there are some
> file system configurations that would be useful for me to run, please
> let me know and I'm happy to set them so that gce-xfstests and
> kvm-xfstests can better test btrfs.
>
> Also, I assume you do have some btrfs developers who are regularly
> running xfstests,

I run them daily. And I suppose other developers run them frequently as well.

> so I don't know how helpful this would be to you,
> but given that I'm going to be running the tests *anyway*, if it would
> be helpful for me to forward test results to you, or to only send you
> a note when test regressions show up, I'm happy to do that.

Regarding the failures you got:

btrfs/056 - failure to setup dmflakey, this happens sporadically to me
and others as well, for any test that uses dmflakey and it seems to
happen more often when running dmflakey tests in sequence

btrfs/153 - has been failing for a long time, known issue, just ignore
it for now

btrfs/204 - expected to fail, there's a fix in the mailing list but it
wasn't merged yet (https://patchwork.kernel.org/patch/11357415/)

generic/065 - another failure to create the dmflakey device

generic/260 - expected to fail on btrfs, due to the way space is
allocated and managed in btrfs

generic/475 - this one can fail often for several different reasons.
Some reasons why it can fail are fixed by patches sent to rc3 for
example, other problems like the one you hit (missing file extent
holes) are addressed by a patchset that is in the integration branch
and will likely go into the next merge window

generic/562 - fails with ENOSPC. Doesn't fail for me here, needs to be
investigated.

shared/298 - The test fails with error trying to open a file that
doesn't exists apparently (/root/xfstests/src/parse-extent-tree.awk).
Never seen this failure in my vms, the test always passes for me.
Needs investigation.

Thanks for the report and logs.


>
> Cheers,
>
>                                         - Ted



-- 
Filipe David Manana,

“Whether you think you can, or you think you can't — you're right.”