Re: [btrfs] WARNING: CPU: 0 PID: 6379 at fs/direct-io.c:293 dio_complete+0x1d4/0x220

From: Fengguang Wu <fengguang.wu@intel.com>
To: Eryu Guan <guaneryu@gmail.com>
Cc: Lukas Czerner <lczerner@redhat.com>, Jan Kara <jack@suse.cz>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	Jeff Moyer <jmoyer@redhat.com>, Jens Axboe <axboe@kernel.dk>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [btrfs] WARNING: CPU: 0 PID: 6379 at fs/direct-io.c:293 dio_complete+0x1d4/0x220
Date: Tue, 31 Oct 2017 08:10:57 +0100	[thread overview]
Message-ID: <20171031071057.wt24ueykec7bggeg@wfg-t540p.sh.intel.com> (raw)
In-Reply-To: <20171031065417.GD3283@eguan.usersys.redhat.com>

On Tue, Oct 31, 2017 at 02:54:17PM +0800, Eryu Guan wrote:
>On Tue, Oct 31, 2017 at 01:10:41AM +0100, Fengguang Wu wrote:
>> Hi Eryu,
>>
>> On Mon, Oct 30, 2017 at 03:44:29PM +0800, Eryu Guan wrote:
>> > Hi Fengguang,
>> >
>> > On Mon, Oct 30, 2017 at 08:20:21AM +0100, Fengguang Wu wrote:
>> > > CC fsdevel.
>> > >
>> > > On Sun, Oct 29, 2017 at 11:51:55PM +0100, Fengguang Wu wrote:
>> > > > Hi Linus,
>> > > >
>> > > > Up to now we see the below boot error/warnings when testing v4.14-rc6.
>> > > >
>> > > > They hit the RC release mainly due to various imperfections in 0day's
>> > > > auto bisection. So I manually list them here and CC the likely easy to
>> > > > debug ones to the corresponding maintainers in the followup emails.
>> > > >
>> > > > boot_successes: 4700
>> > > > boot_failures: 247
>> > >
>> > > [...]
>> > >
>> > > > WARNING:at_fs/direct-io.c:#dio_complete: 7
>> > > > WARNING:at_fs/iomap.c:#iomap_dio_complete: 3
>> > > > WARNING:at_fs/iomap.c:#iomap_dio_rw: 1
>> > >
>> > > The first warning happens on btrfs and is bisected to this commit.
>> > > The other 2 warnings happen on xfs.
>> >
>> > I noticed that the warnings are triggered by generic/095 and
>> > generic/208, they're known to generate such warnings and I think these
>> > warnings are kind of 'known issue', please see comments above
>> > _filter_aiodio_dmesg() in fstests/common/filter.
>> >
>> > Please make sure your local fstests contains the following 3 commits:
>> >
>> > ca93e26865ab common: move _filter_xfs_dmesg() to common/filter
>> > 5aa662733ab0 common: turn _filter_xfs_dmesg() into _filter_aiodio_dmesg()
>> > 228aee780f13 generic/036,208: whitelist [iomap_]dio_complete() WARNs
>>
>> OK.
>>
>> > we filtered out such warnings in fstests on purpose so the affected
>> > tests won't fail because of such dmesg warnings.
>>
>> We may also teach 0day robot to ignore the warning when running the
>> above 2 fstests.
>>
>> The more generic way of filtering may be to inject a dmesg line like
>>
>>        THIS TEST WILL TRIGGER KERNEL WARNING, PLEASE IGNORE.
>>
>> just before the specific tests startup. Then 3rd party dmesg parsing
>> scripts can handle such purpose-made warnings in a uniform way.
>
>fstests doesn't know, prior to the test, if the warnings the test is
>going to trigger are intentional or real bugs, fstests records the dmesg
>log and analyzes the log after test and reports PASS if all the warnings
>are intentional (based on the whitelist filter).

Ah OK.

>But I think it's possible to insert such a message to dmesg *after* test
>if fstests finds that all the warnings are intentional. Does that work
>for 0day robot?

That should work, too.

Thanks,
Fengguang