[3/2] check: filter lockdep bugs when scanning dmesg

Commit Message

Darrick J. Wong April 17, 2019, 1:19 a.m. UTC

From: Darrick J. Wong <[e-mail]>

Ignore lockdep complaining about its own bugginess when scanning dmesg
output, because we shouldn't be failing filesystem tests on account of
lockdep.

Signed-off-by: Darrick J. Wong <[e-mail]>
---
 common/rc |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

Patch

diff --git a/common/rc b/common/rc
index e0dd3797..b2287766 100644
--- a/common/rc
+++ b/common/rc
@@ -3511,6 +3511,13 @@  _check_dmesg_for()
 	_dmesg_since_test_start | egrep -q "$1"
 }
 
+# Default filter for dmesg scanning
+_check_dmesg_filter()
+{
+	egrep -v -e "BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low" \
+		-e "BUG: MAX_STACK_TRACE_ENTRIES too low"
+}
+
 # check dmesg log for WARNING/Oops/etc.
 _check_dmesg()
 {
@@ -3522,7 +3529,7 @@  _check_dmesg()
 	# default filter is a simple cat command, caller could provide a
 	# customized filter and pass the name through the first argument, to
 	# filter out intentional WARNINGs or Oopses
-	local filter=${1:-cat}
+	local filter=${1:-_check_dmesg_filter}
 
 	_dmesg_since_test_start | $filter >$seqres.dmesg
 	egrep -q -e "kernel BUG at" \