All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.com>
To: Andreas Gruenbacher <agruenba@redhat.com>, cluster-devel@redhat.com
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Thomas Graf <tgraf@suug.ch>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Tom Herbert <tom@quantonium.net>
Subject: Re: [PATCH] gfs2: Stop using rhashtable_walk_peek
Date: Thu, 29 Mar 2018 08:53:19 +1100	[thread overview]
Message-ID: <87woxv3m0g.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <20180328160009.29633-1-agruenba@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2913 bytes --]

On Wed, Mar 28 2018, Andreas Gruenbacher wrote:

> Function rhashtable_walk_peek is problematic because there is no
> guarantee that the glock previously returned still exists; when that key
> is deleted, rhashtable_walk_peek can end up returning a different key,
> which would cause an inconsistent glock dump.  So instead of using
> rhashtable_walk_peek, keep track of the current glock in the seq file
> iterator functions.
>
> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
> ---
>  fs/gfs2/glock.c | 18 +++++++++++++-----
>  1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c
> index 82fb5583445c..f1fc353875d3 100644
> --- a/fs/gfs2/glock.c
> +++ b/fs/gfs2/glock.c
> @@ -55,6 +55,7 @@ struct gfs2_glock_iter {
>  	struct gfs2_sbd *sdp;		/* incore superblock           */
>  	struct rhashtable_iter hti;	/* rhashtable iterator         */
>  	struct gfs2_glock *gl;		/* current glock struct        */
> +	bool gl_held;
>  	loff_t last_pos;		/* last position               */
>  };
>  
> @@ -1923,9 +1924,11 @@ void gfs2_glock_exit(void)
>  
>  static void gfs2_glock_iter_next(struct gfs2_glock_iter *gi, loff_t n)
>  {
> -	if (n == 0)
> -		gi->gl = rhashtable_walk_peek(&gi->hti);
> -	else {
> +	if (n != 0 || !gi->gl) {
> +		if (gi->gl_held) {
> +			gfs2_glock_queue_put(gi->gl);
> +			gi->gl_held = false;
> +		}
>  		gi->gl = rhashtable_walk_next(&gi->hti);
>  		n--;
>  	}

Thank for this patch!
The above looks a bit fragile to me.
gfs2_glock_iter_next() (And hence gfs2_glock_seq_start()) will sometimes
exit with gl_held true, and sometimes with it false.
gfs2_glock_seq_stop() assumes that it is false.
Normally gfs2_glock_seq_next() will normally be called between these
two and will clear gl_held, but I don't think there is a hard guarantee
of that.
Maybe we should always 'put' gi->gl in iter_next if gl_held??

Thanks,
NeilBrown



> @@ -1988,7 +1991,10 @@ static void gfs2_glock_seq_stop(struct seq_file *seq, void *iter_ptr)
>  {
>  	struct gfs2_glock_iter *gi = seq->private;
>  
> -	gi->gl = NULL;
> +	if (gi->gl) {
> +		lockref_get(&gi->gl->gl_lockref);
> +		gi->gl_held = true;
> +	}
>  	rhashtable_walk_stop(&gi->hti);
>  }
>  
> @@ -2061,6 +2067,7 @@ static int __gfs2_glocks_open(struct inode *inode, struct file *file,
>  		 */
>  		gi->last_pos = -1;
>  		gi->gl = NULL;
> +		gi->gl_held = false;
>  		rhashtable_walk_enter(&gl_hash_table, &gi->hti);
>  	}
>  	return ret;
> @@ -2076,7 +2083,8 @@ static int gfs2_glocks_release(struct inode *inode, struct file *file)
>  	struct seq_file *seq = file->private_data;
>  	struct gfs2_glock_iter *gi = seq->private;
>  
> -	gi->gl = NULL;
> +	if (gi->gl_held)
> +		gfs2_glock_put(gi->gl);
>  	rhashtable_walk_exit(&gi->hti);
>  	return seq_release_private(inode, file);
>  }
> -- 
> 2.14.3

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: NeilBrown <neilb@suse.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH] gfs2: Stop using rhashtable_walk_peek
Date: Thu, 29 Mar 2018 08:53:19 +1100	[thread overview]
Message-ID: <87woxv3m0g.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <20180328160009.29633-1-agruenba@redhat.com>

On Wed, Mar 28 2018, Andreas Gruenbacher wrote:

> Function rhashtable_walk_peek is problematic because there is no
> guarantee that the glock previously returned still exists; when that key
> is deleted, rhashtable_walk_peek can end up returning a different key,
> which would cause an inconsistent glock dump.  So instead of using
> rhashtable_walk_peek, keep track of the current glock in the seq file
> iterator functions.
>
> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
> ---
>  fs/gfs2/glock.c | 18 +++++++++++++-----
>  1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c
> index 82fb5583445c..f1fc353875d3 100644
> --- a/fs/gfs2/glock.c
> +++ b/fs/gfs2/glock.c
> @@ -55,6 +55,7 @@ struct gfs2_glock_iter {
>  	struct gfs2_sbd *sdp;		/* incore superblock           */
>  	struct rhashtable_iter hti;	/* rhashtable iterator         */
>  	struct gfs2_glock *gl;		/* current glock struct        */
> +	bool gl_held;
>  	loff_t last_pos;		/* last position               */
>  };
>  
> @@ -1923,9 +1924,11 @@ void gfs2_glock_exit(void)
>  
>  static void gfs2_glock_iter_next(struct gfs2_glock_iter *gi, loff_t n)
>  {
> -	if (n == 0)
> -		gi->gl = rhashtable_walk_peek(&gi->hti);
> -	else {
> +	if (n != 0 || !gi->gl) {
> +		if (gi->gl_held) {
> +			gfs2_glock_queue_put(gi->gl);
> +			gi->gl_held = false;
> +		}
>  		gi->gl = rhashtable_walk_next(&gi->hti);
>  		n--;
>  	}

Thank for this patch!
The above looks a bit fragile to me.
gfs2_glock_iter_next() (And hence gfs2_glock_seq_start()) will sometimes
exit with gl_held true, and sometimes with it false.
gfs2_glock_seq_stop() assumes that it is false.
Normally gfs2_glock_seq_next() will normally be called between these
two and will clear gl_held, but I don't think there is a hard guarantee
of that.
Maybe we should always 'put' gi->gl in iter_next if gl_held??

Thanks,
NeilBrown



> @@ -1988,7 +1991,10 @@ static void gfs2_glock_seq_stop(struct seq_file *seq, void *iter_ptr)
>  {
>  	struct gfs2_glock_iter *gi = seq->private;
>  
> -	gi->gl = NULL;
> +	if (gi->gl) {
> +		lockref_get(&gi->gl->gl_lockref);
> +		gi->gl_held = true;
> +	}
>  	rhashtable_walk_stop(&gi->hti);
>  }
>  
> @@ -2061,6 +2067,7 @@ static int __gfs2_glocks_open(struct inode *inode, struct file *file,
>  		 */
>  		gi->last_pos = -1;
>  		gi->gl = NULL;
> +		gi->gl_held = false;
>  		rhashtable_walk_enter(&gl_hash_table, &gi->hti);
>  	}
>  	return ret;
> @@ -2076,7 +2083,8 @@ static int gfs2_glocks_release(struct inode *inode, struct file *file)
>  	struct seq_file *seq = file->private_data;
>  	struct gfs2_glock_iter *gi = seq->private;
>  
> -	gi->gl = NULL;
> +	if (gi->gl_held)
> +		gfs2_glock_put(gi->gl);
>  	rhashtable_walk_exit(&gi->hti);
>  	return seq_release_private(inode, file);
>  }
> -- 
> 2.14.3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/cluster-devel/attachments/20180329/cd2b1142/attachment.sig>

  reply	other threads:[~2018-03-28 21:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-28 16:00 [PATCH] gfs2: Stop using rhashtable_walk_peek Andreas Gruenbacher
2018-03-28 16:00 ` [Cluster-devel] " Andreas Gruenbacher
2018-03-28 21:53 ` NeilBrown [this message]
2018-03-28 21:53   ` NeilBrown
2018-03-28 22:58   ` Andreas Gruenbacher
2018-03-28 22:58     ` [Cluster-devel] " Andreas Gruenbacher

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=87woxv3m0g.fsf@notabene.neil.brown.name \
    --to=neilb@suse.com \
    --cc=agruenba@redhat.com \
    --cc=cluster-devel@redhat.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=tgraf@suug.ch \
    --cc=tom@quantonium.net \
    /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.