Darrick J. Wong 880b957785 fs: distinguish between user initiated freeze and kernel initiated freeze
Userspace can freeze a filesystem using the FIFREEZE ioctl or by
suspending the block device; this state persists until userspace thaws
the filesystem with the FITHAW ioctl or resuming the block device.
Since commit 18e9e5104fcd ("Introduce freeze_super and thaw_super for
the fsfreeze ioctl") we only allow the first freeze command to succeed.

The kernel may decide that it is necessary to freeze a filesystem for
its own internal purposes, such as suspends in progress, filesystem fsck
activities, or quiescing a device prior to removal.  Userspace thaw
commands must never break a kernel freeze, and kernel thaw commands
shouldn't undo userspace's freeze command.

Introduce a couple of freeze holder flags and wire it into the
sb_writers state.  One kernel and one userspace freeze are allowed to
coexist at the same time; the filesystem will not thaw until both are
lifted.

I wonder if the f2fs/gfs2 code should be using a kernel freeze here, but
for now we'll use FREEZE_HOLDER_USERSPACE to preserve existing
behaviors.

Cc: mcgrof@kernel.org
Cc: jack@suse.cz
Cc: hch@infradead.org
Cc: ruansy.fnst@fujitsu.com
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Jan Kara <jack@suse.cz>
2023-07-17 09:00:09 -07:00
..
2023-01-19 09:24:28 +01:00
2023-01-19 09:24:27 +01:00
2023-07-04 11:45:16 -07:00
2023-06-06 18:35:06 +02:00
2023-04-18 14:40:12 +02:00
2022-08-06 14:44:49 -07:00
2023-07-04 11:45:16 -07:00
2023-03-27 14:42:16 +02:00
2023-07-04 11:45:16 -07:00
2023-07-03 22:30:48 +02:00
2023-07-03 22:25:02 +02:00
2023-07-03 22:30:48 +02:00
2023-07-03 22:30:26 +02:00
2023-03-06 09:57:12 +01:00