kernel/linux.git/fs/proc/vmcore.c, branch v6.18.21

fs/proc/vmcore: a few cleanups for vmcore_add_device_dump()

2025-07-10T05:57:56+00:00

There are two cleanups for vmcore_add_device_dump(). Return -ENOMEM directly rather than goto the label to simplify the code and use scoped_guard() to simplify the lock/unlock code. Link: https://lkml.kernel.org/r/20250626105440.1053139-1-suhui@nfschina.com Signed-off-by: Su Hui Reviewed-by: Dan Carpenter Cc: Baoquan He Cc: Dave Young Cc: Suhui Cc: Vivek Goyal Signed-off-by: Andrew Morton

procfs: fix a locking bug in a vmcore_add_device_dump() error path

2025-02-18T06:40:00+00:00

Unlock vmcore_mutex when returning -EBUSY. Link: https://lkml.kernel.org/r/20250129222003.1495713-1-bvanassche@acm.org Fixes: 0f3b1c40c652 ("fs/proc/vmcore: disallow vmcore modifications while the vmcore is open") Signed-off-by: Bart Van Assche Acked-by: Michael S. Tsirkin Acked-by: David Hildenbrand Cc: Baoquan he Signed-off-by: Andrew Morton

Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost

2025-01-27T23:26:06+00:00

Pull virtio updates from Michael Tsirkin: "A small number of improvements all over the place: - vdpa/octeon support for multiple interrupts - virtio-pci support for error recovery - vp_vdpa support for notification with data - vhost/net fix to set num_buffers for spec compliance - virtio-mem now works with kdump on s390 And small cleanups all over the place" * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: (23 commits) virtio_blk: Add support for transport error recovery virtio_pci: Add support for PCIe Function Level Reset vhost/net: Set num_buffers for virtio 1.0 vdpa/octeon_ep: read vendor-specific PCI capability virtio-pci: define type and header for PCI vendor data vdpa/octeon_ep: handle device config change events vdpa/octeon_ep: enable support for multiple interrupts per device vdpa: solidrun: Replace deprecated PCI functions s390/kdump: virtio-mem kdump support (CONFIG_PROC_VMCORE_DEVICE_RAM) virtio-mem: support CONFIG_PROC_VMCORE_DEVICE_RAM virtio-mem: remember usable region size virtio-mem: mark device ready before registering callbacks in kdump mode fs/proc/vmcore: introduce PROC_VMCORE_DEVICE_RAM to detect device RAM ranges in 2nd kernel fs/proc/vmcore: factor out freeing a list of vmcore ranges fs/proc/vmcore: factor out allocating a vmcore range and adding it to a list fs/proc/vmcore: move vmcore definitions out of kcore.h fs/proc/vmcore: prefix all pr_* with "vmcore:" fs/proc/vmcore: disallow vmcore modifications while the vmcore is open fs/proc/vmcore: replace vmcoredd_mutex by vmcore_mutex fs/proc/vmcore: convert vmcore_cb_lock into vmcore_mutex ...

fs/proc/vmcore: introduce PROC_VMCORE_DEVICE_RAM to detect device RAM ranges in 2nd kernel

2025-01-27T14:39:19+00:00

s390 allocates+prepares the elfcore hdr in the dump (2nd) kernel, not in the crashed kernel. RAM provided by memory devices such as virtio-mem can only be detected using the device driver; when vmcore_init() is called, these device drivers are usually not loaded yet, or the devices did not get probed yet. Consequently, on s390 these RAM ranges will not be included in the crash dump, which makes the dump partially corrupt and is unfortunate. Instead of deferring the vmcore_init() call, to an (unclear?) later point, let's reuse the vmcore_cb infrastructure to obtain device RAM ranges as the device drivers probe the device and get access to this information. Then, we'll add these ranges to the vmcore, adding more PT_LOAD entries and updating the offsets+vmcore size. Use a separate Kconfig option to be set by an architecture to include this code only if the arch really needs it. Further, we'll make the config depend on the relevant drivers (i.e., virtio_mem) once they implement support (next). The alternative of having a PROVIDE_PROC_VMCORE_DEVICE_RAM config option was dropped for now for simplicity. The current target use case is s390, which only creates an elf64 elfcore, so focusing on elf64 is sufficient. Signed-off-by: David Hildenbrand Message-Id: <20241204125444.1734652-9-david@redhat.com> Acked-by: Andrew Morton Signed-off-by: Michael S. Tsirkin

fs/proc/vmcore: factor out freeing a list of vmcore ranges

2025-01-27T14:39:16+00:00

Let's factor it out into include/linux/crash_dump.h, from where we can use it also outside of vmcore.c later. Acked-by: Baoquan He Signed-off-by: David Hildenbrand Message-Id: <20241204125444.1734652-8-david@redhat.com> Acked-by: Andrew Morton Signed-off-by: Michael S. Tsirkin

fs/proc/vmcore: factor out allocating a vmcore range and adding it to a list

2025-01-27T14:39:11+00:00

Let's factor it out into include/linux/crash_dump.h, from where we can use it also outside of vmcore.c later. Acked-by: Baoquan He Signed-off-by: David Hildenbrand Message-Id: <20241204125444.1734652-7-david@redhat.com> Acked-by: Andrew Morton Signed-off-by: Michael S. Tsirkin

fs/proc/vmcore: move vmcore definitions out of kcore.h

2025-01-27T14:39:07+00:00

These vmcore defines are not related to /proc/kcore, move them out. We'll move "struct vmcoredd_node" to vmcore.c, because it is only used internally. While "struct vmcore" is only used internally for now, we're planning on using it from inline functions in crash_dump.h next, so move it to crash_dump.h. While at it, rename "struct vmcore" to "struct vmcore_range", which is a more suitable name and will make the usage of it outside of vmcore.c clearer. Signed-off-by: David Hildenbrand Message-Id: <20241204125444.1734652-6-david@redhat.com> Acked-by: Andrew Morton Signed-off-by: Michael S. Tsirkin

fs/proc/vmcore: prefix all pr_* with "vmcore:"

2025-01-27T14:39:02+00:00

Let's use "vmcore: " as a prefix, converting the single "Kdump: vmcore not initialized" one to effectively be "vmcore: not initialized". Signed-off-by: David Hildenbrand Message-Id: <20241204125444.1734652-5-david@redhat.com> Acked-by: Andrew Morton Signed-off-by: Michael S. Tsirkin

fs/proc/vmcore: disallow vmcore modifications while the vmcore is open

2025-01-27T14:38:57+00:00

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 Message-Id: <20241204125444.1734652-4-david@redhat.com> Acked-by: Andrew Morton Signed-off-by: Michael S. Tsirkin

fs/proc/vmcore: replace vmcoredd_mutex by vmcore_mutex

2025-01-27T14:38:52+00:00

Now that we have a mutex that synchronizes against opening of the vmcore, let's use that one to replace vmcoredd_mutex: there is no need to have two separate ones. This is a preparation for properly preventing vmcore modifications after the vmcore was opened. Signed-off-by: David Hildenbrand Message-Id: <20241204125444.1734652-3-david@redhat.com> Acked-by: Andrew Morton Signed-off-by: Michael S. Tsirkin