summaryrefslogtreecommitdiff
path: root/scripts/gdb/linux/proc.py
diff options
context:
space:
mode:
authorChristian Brauner <brauner@kernel.org>2025-03-31 14:47:40 +0200
committerChristian Brauner <brauner@kernel.org>2025-05-09 12:41:23 +0200
commit0de4c4065cad198fe44405d0eac7bc043f5ee2f1 (patch)
tree9aa599a87ba8833f4240b96cc010947762eb9221 /scripts/gdb/linux/proc.py
parent6e5af8e3ca5f397c8c90c12613863a664e38b158 (diff)
parent0e4f9483959b785f65a36120bb0e4cf1407e492c (diff)
Merge patch series "efivarfs: support freeze/thaw"
Christian Brauner <brauner@kernel.org> says: Allow efivarfs to partake to resync variable state during system hibernation and suspend. Add freeze/thaw support. This is a pretty straightforward implementation. We simply add regular freeze/thaw support for both userspace and the kernel. This works without any big issues and congrats afaict efivars is the first pseudofilesystem that adds support for filesystem freezing and thawing. The simplicity comes from the fact that we simply always resync variable state after efivarfs has been frozen. It doesn't matter whether that's because of suspend, userspace initiated freeze or hibernation. Efivars is simple enough that it doesn't matter that we walk all dentries. There are no directories and there aren't insane amounts of entries and both freeze/thaw are already heavy-handed operations. If userspace initiated a freeze/thaw cycle they would need CAP_SYS_ADMIN in the initial user namespace (as that's where efivarfs is mounted) so it can't be triggered by random userspace. IOW, we really really don't care. * patches from https://lore.kernel.org/r/20250331-work-freeze-v1-0-6dfbe8253b9f@kernel.org: efivarfs: support freeze/thaw libfs: export find_next_child() Link: https://lore.kernel.org/r/20250331-work-freeze-v1-0-6dfbe8253b9f@kernel.org Signed-off-by: Christian Brauner <brauner@kernel.org>
Diffstat (limited to 'scripts/gdb/linux/proc.py')
0 files changed, 0 insertions, 0 deletions