gfs2: fix race between gfs2_freeze_func and unmount
authorAbhi Das <adas@redhat.com>
Tue, 30 Apr 2019 21:53:47 +0000 (16:53 -0500)
committerAndreas Gruenbacher <agruenba@redhat.com>
Tue, 7 May 2019 21:39:14 +0000 (23:39 +0200)
commit8f91821990fd6f170a5dca79697a441181a41b16
tree6efd729419e769c9a86681b5a8aca56e6c3e5995
parentfbb27873f21d5fb9bf556edcaa67e9891636e5d4
gfs2: fix race between gfs2_freeze_func and unmount

As part of the freeze operation, gfs2_freeze_func() is left blocking
on a request to hold the sd_freeze_gl in SH. This glock is held in EX
by the gfs2_freeze() code.

A subsequent call to gfs2_unfreeze() releases the EXclusively held
sd_freeze_gl, which allows gfs2_freeze_func() to acquire it in SH and
resume its operation.

gfs2_unfreeze(), however, doesn't wait for gfs2_freeze_func() to complete.
If a umount is issued right after unfreeze, it could result in an
inconsistent filesystem because some journal data (statfs update) isn't
written out.

Refer to commit 24972557b12c for a more detailed explanation of how
freeze/unfreeze work.

This patch causes gfs2_unfreeze() to wait for gfs2_freeze_func() to
complete before returning to the user.

Signed-off-by: Abhi Das <adas@redhat.com>
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
fs/gfs2/incore.h
fs/gfs2/super.c