summaryrefslogtreecommitdiff
path: root/scripts/lib/kdoc/kdoc_output.py
diff options
context:
space:
mode:
authorDavid Hildenbrand <david@redhat.com>2024-12-04 13:54:34 +0100
committerMichael S. Tsirkin <mst@redhat.com>2025-01-27 09:38:57 -0500
commit0f3b1c40c65262a216fb459fd375f39442a5138b (patch)
tree81d63519f3914c24b77a4d26d6dfabfa8a1f6fee /scripts/lib/kdoc/kdoc_output.py
parent2083dfe45e83336fafb92f689d6d4b873ad9872d (diff)
fs/proc/vmcore: disallow vmcore modifications while the vmcore is open
The vmcoredd_update_size() call and its effects (size/offset changes) are currently completely unsynchronized, and will cause trouble when performed concurrently, or when done while someone is already reading the vmcore. Let's protect all vmcore modifications by the vmcore_mutex, disallow vmcore modifications while the vmcore is open, and warn on vmcore modifications after the vmcore was already opened once: modifications while the vmcore is open are unsafe, and modifications after the vmcore was opened indicates trouble. Properly synchronize against concurrent opening of the vmcore. No need to grab the mutex during mmap()/read(): after we opened the vmcore, modifications are impossible. It's worth noting that modifications after the vmcore was opened are completely unexpected, so failing if open, and warning if already opened (+closed again) is good enough. This change not only handles concurrent adding of device dumps + concurrent reading of the vmcore properly, it also prepares for other mechanisms that will modify the vmcore. Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20241204125444.1734652-4-david@redhat.com> Acked-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Diffstat (limited to 'scripts/lib/kdoc/kdoc_output.py')
0 files changed, 0 insertions, 0 deletions