linux-kernel - Re: [btrfs] WARNING: CPU: 0 PID: 6379 at fs/direct-io.c:293 dio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 31 Oct 2017 08:10:57 +0100
From:   Fengguang Wu <fengguang.wu@...el.com>
To:     Eryu Guan <guaneryu@...il.com>
Cc:     Lukas Czerner <lczerner@...hat.com>, Jan Kara <jack@...e.cz>,
        "Darrick J. Wong" <darrick.wong@...cle.com>,
        Jeff Moyer <jmoyer@...hat.com>, Jens Axboe <axboe@...nel.dk>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [btrfs] WARNING: CPU: 0 PID: 6379 at fs/direct-io.c:293
 dio_complete+0x1d4/0x220

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