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

[Fengguang Wu]

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