From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel DeFreez <dcdefreez@ucdavis.edu>
Date: Thu, 14 Apr 2016 18:44:38 -0700
Subject: [Cluster-devel] GFS2: Always call gfs2_holder_uninit after
	gfs_holder_init?
Message-ID: <20160415014438.GB24605@ceres>
List-Id: <cluster-devel.redhat.com>
To: cluster-devel.redhat.com
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,

I am trying to understand some of the internals of glocks. It looks like the
basic pattern is:

1. Initialize a holder with gfs2_holder_init
2. Enqueue this holder onto the glock
3. Dequeue the holder
4. Uninitialize the holder with gfs2_holder_uninit

My question is this: are there situations where the holder structure does not
need to be uninitialized?  I ask because I have run across a couple of
cases where it is not, such as in gfs2_get_flags:

gfs2_holder_init(ip->i_gl, LM_ST_SHARED, 0, &gh);
error = gfs2_glock_nq(&gh);
if (error)
    return error;
...
gfs2_glock_dq(&gh);
gfs2_holder_uninit(&gh);

Is this correct? Here gh is initialized but never uninitialized on the error
path. It seems like this would cause an inaccurate lockref count. In
many other cases the holder structure is uninitialized, even if lock
acquisition fails.

Thanks,

Daniel