summaryrefslogtreecommitdiffstats
path: root/Documentation/leds/leds-mlxcpld.rst
diff options
context:
space:
mode:
authorDarrick J. Wong <djwong@kernel.org>2023-07-17 18:00:09 +0200
committerDarrick J. Wong <djwong@kernel.org>2023-07-17 18:00:09 +0200
commit880b9577855edddda1e732748e849c63199d489b (patch)
tree8864baba5793708725a2c440be96c218846eeaef /Documentation/leds/leds-mlxcpld.rst
parentLinux 6.5-rc2 (diff)
downloadlinux-880b9577855edddda1e732748e849c63199d489b.tar.xz
linux-880b9577855edddda1e732748e849c63199d489b.zip
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>
Diffstat (limited to 'Documentation/leds/leds-mlxcpld.rst')
0 files changed, 0 insertions, 0 deletions