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

[Eryu Guan <guaneryu@gmail.com>]

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).

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?

Thanks,
Eryu