[Cluster-devel] [PATCH 30/32] gfs2: Don't demote a glock until its revokes are written

[Steven Whitehouse]

Hi,

On 13/11/2019 21:30, Bob Peterson wrote:
> Before this patch, run_queue would demote glocks based on whether
> there are any more holders. But if the glock has pending revokes that
> haven't been written to the media, giving up the glock might end in
> file system corruption if the revokes never get written due to
> io errors, node crashes and fences, etc. In that case, another node
> will replay the metadata blocks associated with the glock, but
> because the revoke was never written, it could replay that block
> even though the glock had since been granted to another node who
> might have made changes.
>
> This patch changes the logic in run_queue so that it never demotes
> a glock until its count of pending revokes reaches zero.
>
> Signed-off-by: Bob Peterson <rpeterso at redhat.com>

I'm not sure this makes sense... if we demote the glock then the revokes 
should be written out during that process. So if that is not happening 
it is a bug. I don't think we should need to change the logic for 
deciding what we are going to demote?

Steve.

> ---
>   fs/gfs2/glock.c | 3 +++
>   1 file changed, 3 insertions(+)
>
> diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c
> index ab72797e3ba1..082f70eb96db 100644
> --- a/fs/gfs2/glock.c
> +++ b/fs/gfs2/glock.c
> @@ -712,6 +712,9 @@ __acquires(&gl->gl_lockref.lock)
>   			goto out_unlock;
>   		if (nonblock)
>   			goto out_sched;
> +		smp_mb();
> +		if (atomic_read(&gl->gl_revokes) != 0)
> +			goto out_sched;
>   		set_bit(GLF_DEMOTE_IN_PROGRESS, &gl->gl_flags);
>   		GLOCK_BUG_ON(gl, gl->gl_demote_state == LM_ST_EXCLUSIVE);
>   		gl->gl_target = gl->gl_demote_state;