All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Eryu Guan <eguan@redhat.com>
Cc: linux-xfs@vger.kernel.org, fstests@vger.kernel.org
Subject: Re: [PATCH 1/8] common/rc: report kmemleak errors
Date: Thu, 14 Dec 2017 10:15:08 -0800	[thread overview]
Message-ID: <20171214181508.GJ6896@magnolia> (raw)
In-Reply-To: <20171214093718.GH2749@eguan.usersys.redhat.com>

On Thu, Dec 14, 2017 at 05:37:18PM +0800, Eryu Guan wrote:
> On Tue, Dec 12, 2017 at 10:03:18PM -0800, Darrick J. Wong wrote:
> > From: Darrick J. Wong <darrick.wong@oracle.com>
> > 
> > If kmemleak is enabled, scan and report memory leaks after every test.
> > 
> > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> > ---
> >  check     |    2 ++
> >  common/rc |   52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 54 insertions(+)
> > 
> > 
> > diff --git a/check b/check
> > index b2d251a..469188e 100755
> > --- a/check
> > +++ b/check
> > @@ -497,6 +497,7 @@ _check_filesystems()
> >  	fi
> >  }
> >  
> > +_init_kmemleak
> >  _prepare_test_list
> >  
> >  if $OPTIONS_HAVE_SECTIONS; then
> > @@ -793,6 +794,7 @@ for section in $HOST_OPTIONS_SECTIONS; do
> >  		    n_try=`expr $n_try + 1`
> >  		    _check_filesystems
> >  		    _check_dmesg || err=true
> > +		    _check_kmemleak || err=true
> >  		fi
> >  
> >  	    fi
> > diff --git a/common/rc b/common/rc
> > index cb83918..a2bed36 100644
> > --- a/common/rc
> > +++ b/common/rc
> > @@ -3339,6 +3339,58 @@ _check_dmesg()
> >  	fi
> >  }
> >  
> > +# capture the kmemleak report
> > +_capture_kmemleak()
> > +{
> > +	local _kern_knob="${DEBUGFS_MNT}/kmemleak"
> > +	local _leak_file="$1"
> > +
> > +	# Tell the kernel to scan for memory leaks.  Apparently the write
> > +	# returns before the scan is complete, so do it twice in the hopes
> > +	# that twice is enough to capture all the leaks.
> > +	echo "scan" > "${_kern_knob}"
> > +	cat "${_kern_knob}" > /dev/null
> > +	echo "scan" > "${_kern_knob}"
> > +	cat "${_kern_knob}" > "${_leak_file}"
> > +	echo "clear" > "${_kern_knob}"
> 
> Hmm, two scans seem not enough either, I could see false positive easily
> in a 'quick' group run, because some leaks are not reported immediately
> after the test but after next test or next few tests. e.g. I saw
> generic/008 (tested on XFS) being reported as leaking memory, and from
> 008.kmemleak I saw:
> 
> unreferenced object 0xffff880277679800 (size 512):
>   comm "nametest", pid 25007, jiffies 4300176958 (age 9.854s)
> ...
> 
> But "nametest" is only used in generic/007, the leak should be triggered
> by generic/007 too, but 007 was reported as PASS in my case.
> 
> Not sure what's the best way to deal with these false positive, adding
> more scans seem to work, but that's ugly and requires more test time..
> What do you think?

I'm not sure either -- the brief scan I made of mm/kmemleak.c didn't
reveal anything obvious that would explain the behavior we see.  It
might just take a while for determine positively that an item isn't
gray.

We could change the message to state that found leaks might have
resulted from the previous test?  That's rather unsatisfying, but I
don't know what else to do.

Or maybe a sleep 1 in between scans to see if that makes it more likely
to attribute a leak to the correct test?  I don't anticipate running
xfstests with kmemleak=on too terribly often, so the extra ~700s won't
bother me too much.

--D

> Otherwise the whole check kmemleak framework looks fine to me.
> 
> Thanks,
> Eryu
> 
> > +}
> > +
> > +# set up kmemleak
> > +_init_kmemleak()
> > +{
> > +	local _kern_knob="${DEBUGFS_MNT}/kmemleak"
> > +
> > +	if [ ! -w "${_kern_knob}" ]; then
> > +		return 0
> > +	fi
> > +
> > +	# Disable the automatic scan so that we can control it completely,
> > +	# then dump all the leaks recorded so far.
> > +	echo "scan=off" > "${_kern_knob}"
> > +	_capture_kmemleak /dev/null
> > +}
> > +
> > +# check kmemleak log
> > +_check_kmemleak()
> > +{
> > +	local _kern_knob="${DEBUGFS_MNT}/kmemleak"
> > +	local _leak_file="${seqres}.kmemleak"
> > +
> > +	if [ ! -w "${_kern_knob}" ]; then
> > +		return 0
> > +	fi
> > +
> > +	# Capture and report any leaks
> > +	_capture_kmemleak "${_leak_file}"
> > +	if [ -s "${_leak_file}" ]; then
> > +		_dump_err "_check_kmemleak: something found in kmemleak (see ${_leak_file})"
> > +		return 1
> > +	else
> > +		rm -f "${_leak_file}"
> > +		return 0
> > +	fi
> > +}
> > +
> >  # don't check dmesg log after test
> >  _disable_dmesg_check()
> >  {
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe fstests" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2017-12-14 18:15 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-13  6:03 [PATCH 0/8] weekly fstests changes Darrick J. Wong
2017-12-13  6:03 ` [PATCH 1/8] common/rc: report kmemleak errors Darrick J. Wong
2017-12-14  9:37   ` Eryu Guan
2017-12-14 18:15     ` Darrick J. Wong [this message]
2018-01-05  8:02       ` Eryu Guan
2018-01-05 17:02         ` Darrick J. Wong
2018-01-07 15:25           ` Eryu Guan
2017-12-13  6:03 ` [PATCH 2/8] common/xfs: fix scrub support probing again Darrick J. Wong
2017-12-13  6:03 ` [PATCH 3/8] generic/45[34]: test line draw characters in file/attr names Darrick J. Wong
2017-12-13  6:03 ` [PATCH 4/8] xfs: fix tests to handle removal of no-alloc create nonfeature Darrick J. Wong
2017-12-13 22:12   ` Dave Chinner
2017-12-13 22:45   ` [PATCH v2 " Darrick J. Wong
2017-12-13  6:03 ` [PATCH 5/8] generic: test error shutdown while stressing filesystem Darrick J. Wong
2017-12-13  6:03 ` [PATCH 6/8] fsstress: implement the clonerange/deduperange ioctls Darrick J. Wong
2017-12-14  6:39   ` Amir Goldstein
2017-12-14  7:32     ` Eryu Guan
2017-12-14 20:20       ` Darrick J. Wong
2017-12-15  2:07   ` [PATCH v2 " Darrick J. Wong
2018-01-03  8:48     ` Eryu Guan
2018-01-03 17:12       ` Darrick J. Wong
2018-01-05  4:35         ` Eryu Guan
2018-01-05  4:54           ` Darrick J. Wong
2018-01-06  1:46             ` Darrick J. Wong
2018-01-09  7:09               ` Darrick J. Wong
2018-02-22 16:06     ` Luis Henriques
2018-02-22 17:27       ` Darrick J. Wong
2018-02-22 18:17         ` Luis Henriques
2018-02-22 18:34           ` Darrick J. Wong
2018-02-23 10:17             ` Luis Henriques
2017-12-13  6:04 ` [PATCH 7/8] generic: run a long-soak write-only fsstress test Darrick J. Wong
2018-01-07 15:34   ` Eryu Guan
2017-12-13  6:04 ` [PATCH 8/8] xfs/068: fix variability problems in file/dir count output Darrick J. Wong
2017-12-13 22:20   ` Dave Chinner
2017-12-13 22:23     ` Darrick J. Wong
2017-12-13 22:45       ` Dave Chinner
2017-12-13 23:17         ` Darrick J. Wong
2017-12-13 23:42           ` Dave Chinner
2017-12-13 23:28   ` [PATCH v2 8/8] xfs/068: fix clonerange " Darrick J. Wong
2017-12-13 23:44     ` Dave Chinner
2017-12-14  6:52       ` Amir Goldstein
2017-12-14  7:37         ` Amir Goldstein
2017-12-14  7:49         ` Eryu Guan
2017-12-14  8:15           ` Amir Goldstein
2017-12-14 21:35           ` Dave Chinner
2017-12-15  2:04             ` Darrick J. Wong
2017-12-15  4:37               ` Dave Chinner
2017-12-15  7:06                 ` Amir Goldstein
2017-12-15  2:08   ` [PATCH v3 8/8] xfs/068: fix variability " Darrick J. Wong
2017-12-15  2:16     ` Darrick J. Wong
2017-12-15  2:17   ` [PATCH v4 " Darrick J. Wong
2017-12-15  8:55 ` [PATCH 0/8] weekly fstests changes Eryu Guan
2018-01-03 19:22 ` [PATCH 9/8] xfs: find libxfs api violations Darrick J. Wong
2018-01-03 19:26 ` [PATCH 10/8] xfs: check that fs freeze minimizes required recovery Darrick J. Wong
2018-01-09 11:33   ` Eryu Guan
2018-01-10  0:03     ` Darrick J. Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171214181508.GJ6896@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=eguan@redhat.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.