All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] generic/310: make ext[2-4] error patterns more specific
@ 2015-11-12  0:36 Tahsin Erdogan
  2015-11-12 16:15 ` Theodore Ts'o
  0 siblings, 1 reply; 3+ messages in thread
From: Tahsin Erdogan @ 2015-11-12  0:36 UTC (permalink / raw)
  To: fstests; +Cc: Zhao Hongjiang, Theodore Ts'o, Tahsin Erdogan

This test watches for ext[2-4] filesystem errors in kernel messages but it
incorrectly identifies unrelated messages that contain string "error" as
a failure condition.

Make grep pattern more specific to catch only relevant messages.

Signed-off-by: Tahsin Erdogan <tahsin@google.com>
---
 tests/generic/310 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/generic/310 b/tests/generic/310
index c0a8645..9173fb9 100755
--- a/tests/generic/310
+++ b/tests/generic/310
@@ -62,7 +62,7 @@ _require_test
 dmesg -c > /dev/null
 
 nr_bug=`dmesg | grep -c "kernel BUG"`
-nr_error=`dmesg | grep -c "error"`
+nr_error=`dmesg | grep -c "EXT[234]-fs .*error"`
 nr_null=`dmesg | grep -c "kernel NULL pointer dereference"`
 nr_warning=`dmesg | grep -c "^WARNING"`
 nr_lockdep=`dmesg | grep -c "possible recursive locking detected"`
@@ -71,7 +71,7 @@ nr_lockdep=`dmesg | grep -c "possible recursive locking detected"`
 check_kernel_bug()
 {
 	new_bug=`dmesg | grep -c "kernel BUG"`
-	new_error=`dmesg | grep -c "error"`
+	new_error=`dmesg | grep -c "EXT[234]-fs .*error"`
 	new_null=`dmesg | grep -c "kernel NULL pointer dereference"`
 	new_warning=`dmesg | grep -c "^WARNING"`
 	new_lockdep=`dmesg | grep -c "possible recursive locking detected"`
-- 
2.6.0.rc2.230.g3dd15c0


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] generic/310: make ext[2-4] error patterns more specific
  2015-11-12  0:36 [PATCH] generic/310: make ext[2-4] error patterns more specific Tahsin Erdogan
@ 2015-11-12 16:15 ` Theodore Ts'o
  2015-11-12 20:28   ` Dave Chinner
  0 siblings, 1 reply; 3+ messages in thread
From: Theodore Ts'o @ 2015-11-12 16:15 UTC (permalink / raw)
  To: Tahsin Erdogan; +Cc: fstests, Zhao Hongjiang

On Wed, Nov 11, 2015 at 04:36:30PM -0800, Tahsin Erdogan wrote:
> This test watches for ext[2-4] filesystem errors in kernel messages but it
> incorrectly identifies unrelated messages that contain string "error" as
> a failure condition.
> 
> Make grep pattern more specific to catch only relevant messages.
> 
> Signed-off-by: Tahsin Erdogan <tahsin@google.com>

The problem is this is a "generic" test, so it will be run on file
systems other than just ext[234].  So making the regexp's specific to
just ext[234] is probably going to be something acceptable for
xfstests upstream.

(For context, the problem was that there were some kernel messages
coming fom an i2c device driver that happened to be spit out while
generic/310 was running, this was causing a false test failure.)

Alternate possible fixes:

(1) we could make an ext4 version of this test, and then make
generic/310 not run for ext4.  In that case we can use the EXT[234]-fs
specific error.

(2) we can fiter out the i2c error in generic/310

(3) we can figure out why the i2c device driver is randomly spitting
out errors and ask the team responsible for that driver to fix _that_
bug

(4) we can try to enumerate the file system specific error messages
instead of assuming that any random kernel message that happens to
contain the string "error" automatically means that there is a file
system problem.

We should probably do (3) no matter what, and arguably generic/310 is
a badly written test and if there is some way we can do (4), that
would be desirable.  As a fall back, we could do (2), and see if that
is acceptable for xfstests upstream.

Cheers,

						- Ted

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] generic/310: make ext[2-4] error patterns more specific
  2015-11-12 16:15 ` Theodore Ts'o
@ 2015-11-12 20:28   ` Dave Chinner
  0 siblings, 0 replies; 3+ messages in thread
From: Dave Chinner @ 2015-11-12 20:28 UTC (permalink / raw)
  To: Theodore Ts'o; +Cc: Tahsin Erdogan, fstests, Zhao Hongjiang

On Thu, Nov 12, 2015 at 11:15:50AM -0500, Theodore Ts'o wrote:
> On Wed, Nov 11, 2015 at 04:36:30PM -0800, Tahsin Erdogan wrote:
> > This test watches for ext[2-4] filesystem errors in kernel messages but it
> > incorrectly identifies unrelated messages that contain string "error" as
> > a failure condition.
> > 
> > Make grep pattern more specific to catch only relevant messages.
> > 
> > Signed-off-by: Tahsin Erdogan <tahsin@google.com>
> 
> The problem is this is a "generic" test, so it will be run on file
> systems other than just ext[234].  So making the regexp's specific to
> just ext[234] is probably going to be something acceptable for
> xfstests upstream.
> 
> (For context, the problem was that there were some kernel messages
> coming fom an i2c device driver that happened to be spit out while
> generic/310 was running, this was causing a false test failure.)
> 
> Alternate possible fixes:
> 
> (1) we could make an ext4 version of this test, and then make
> generic/310 not run for ext4.  In that case we can use the EXT[234]-fs
> specific error.
> 
> (2) we can fiter out the i2c error in generic/310
> 
> (3) we can figure out why the i2c device driver is randomly spitting
> out errors and ask the team responsible for that driver to fix _that_
> bug
> 
> (4) we can try to enumerate the file system specific error messages
> instead of assuming that any random kernel message that happens to
> contain the string "error" automatically means that there is a file
> system problem.
> 
> We should probably do (3) no matter what,

Yes.

> and arguably generic/310 is
> a badly written test and if there is some way we can do (4), that
> would be desirable.

Well, it should really just use the test harness' dmesg checking.
i.e. all that explicit reading and checking for error types can just
go away completely, as the test harness with capture
errors/warnings/bugs that are emitted to dmesg during the test run
and fail the test.

> As a fall back, we could do (2), and see if that
> is acceptable for xfstests upstream.

No. filtering dmesg errors from random drivers/subsystems on random
kernels is a path we are not going to walk down.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2015-11-12 20:29 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-12  0:36 [PATCH] generic/310: make ext[2-4] error patterns more specific Tahsin Erdogan
2015-11-12 16:15 ` Theodore Ts'o
2015-11-12 20:28   ` Dave Chinner

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.