From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752908AbdJaHLH (ORCPT ); Tue, 31 Oct 2017 03:11:07 -0400 Received: from mga03.intel.com ([134.134.136.65]:42453 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751564AbdJaHLF (ORCPT ); Tue, 31 Oct 2017 03:11:05 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.44,322,1505804400"; d="scan'208";a="915726120" Date: Tue, 31 Oct 2017 08:10:57 +0100 From: Fengguang Wu To: Eryu Guan Cc: Lukas Czerner , Jan Kara , "Darrick J. Wong" , Jeff Moyer , Jens Axboe , Linus Torvalds , Linux Kernel Mailing List , linux-fsdevel Subject: Re: [btrfs] WARNING: CPU: 0 PID: 6379 at fs/direct-io.c:293 dio_complete+0x1d4/0x220 Message-ID: <20171031071057.wt24ueykec7bggeg@wfg-t540p.sh.intel.com> References: <20171029225155.qcum5i75awrt5tzm@wfg-t540p.sh.intel.com> <20171030072021.gcgpaolo5m3myuln@wfg-t540p.sh.intel.com> <20171030074429.GC3283@eguan.usersys.redhat.com> <20171031001041.5qjzn5pjertpdc3e@wfg-t540p.sh.intel.com> <20171031065417.GD3283@eguan.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20171031065417.GD3283@eguan.usersys.redhat.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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