kernel.git/arch/s390/kernel/crash_dump.c, branch linux-5.18.y

s390/crash: fix incorrect number of bytes to copy to user space

2022-08-17T12:42:08Z

[ Upstream commit f6749da17a34eb08c9665f072ce7c812ff68aad2 ] The number of bytes in a chunk is correctly calculated, but instead the total number of bytes is passed to copy_to_user_real() function. Reported-by: Matthew Wilcox Fixes: df9694c7975f ("s390/dump: streamline oldmem copy functions") Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin

s390/crash: make copy_oldmem_page() return number of bytes copied

2022-06-29T07:04:36Z

[ Upstream commit af2debd58bd769e38f538143f0d332e15d753396 ] Callback copy_oldmem_page() returns either error code or zero. Instead, it should return the error code or number of bytes copied. Fixes: df9694c7975f ("s390/dump: streamline oldmem copy functions") Reviewed-by: Alexander Egorenkov Tested-by: Alexander Egorenkov Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

s390/crash: add missing iterator advance in copy_oldmem_page()

2022-06-29T07:04:36Z

[ Upstream commit cc02e6e21aa5f2ac0defe8c15e5a9d024da6e73d ] In case old memory was successfully copied the passed iterator should be advanced as well. Currently copy_oldmem_page() is always called with single-segment iterator. Should that ever change - copy_oldmem_user and copy_oldmem_kernel() functions would need a rework to deal with multi-segment iterators. Fixes: 5d8de293c224 ("vmcore: convert copy_oldmem_page() to take an iov_iter") Reviewed-by: Alexander Egorenkov Tested-by: Alexander Egorenkov Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin

vmcore: convert copy_oldmem_page() to take an iov_iter

2022-06-29T07:04:36Z

[ Upstream commit 5d8de293c224896a4da99763fce4f9794308caf4 ] Patch series "Convert vmcore to use an iov_iter", v5. For some reason several people have been sending bad patches to fix compiler warnings in vmcore recently. Here's how it should be done. Compile-tested only on x86. As noted in the first patch, s390 should take this conversion a bit further, but I'm not inclined to do that work myself. This patch (of 3): Instead of passing in a 'buf' and 'userbuf' argument, pass in an iov_iter. s390 needs more work to pass the iov_iter down further, or refactor, but I'd be more comfortable if someone who can test on s390 did that work. It's more convenient to convert the whole of read_from_oldmem() to take an iov_iter at the same time, so rename it to read_from_oldmem_iter() and add a temporary read_from_oldmem() wrapper that creates an iov_iter. Link: https://lkml.kernel.org/r/20220408090636.560886-1-bhe@redhat.com Link: https://lkml.kernel.org/r/20220408090636.560886-2-bhe@redhat.com Signed-off-by: Matthew Wilcox (Oracle) Signed-off-by: Baoquan He Reviewed-by: Christoph Hellwig Cc: Heiko Carstens Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin

s390/maccess: fix semantics of memcpy_real() and its callers

2022-02-09T21:56:04Z

There is a confusion with regard to the source address of memcpy_real() and calling functions. While the declared type for a source assumes a virtual address, in fact it always called with physical address of the source. This confusion led to bugs in copy_oldmem_kernel() and copy_oldmem_user() functions, where __pa() macro applied mistakenly to physical addresses. It does not lead to a real issue, since virtual and physical addresses are currently the same. Fix both the bugs and memcpy_real() prototype by making type of source address consistent to the function name and the way it actually used. Reviewed-by: Heiko Carstens Signed-off-by: Alexander Gordeev Signed-off-by: Vasily Gorbik

s390/dump: fix old lowcore virtual vs physical address confusion

2022-02-09T21:56:03Z

Virtual addresses of vmcore_info and os_info members are wrongly passed to copy_oldmem_kernel(), while the function expects physical address of the source. Instead, __pa() macro should have been applied. Yet, use of __pa() macro could be somehow confusing, since copy_oldmem_kernel() may treat the source as an offset, not as a direct physical address (that depens from the oldmem availability and location). Fix the virtual vs physical address confusion and make the way the old lowcore is read consistent across all sources. Reviewed-by: Heiko Carstens Signed-off-by: Alexander Gordeev Signed-off-by: Vasily Gorbik

s390/crash_dump: fix virtual vs physical address handling

2021-12-20T09:21:55Z

Signal processor STORE STATUS requires a physical address where register contents are supposed to be written to, however the kernel must read the data via the corresponding virtual address. Also the allocated save_area, where register contents are copied to, resides in virtual address space. Fix this by using proper __pa() conversion, or correct memblock_alloc() invocation. Reviewed-by: Alexander Gordeev Signed-off-by: Heiko Carstens

s390/dump: fix copying to user-space of swapped kdump oldmem

2021-11-18T16:25:34Z

This commit fixes a bug introduced by commit e9e7870f90e3 ("s390/dump: introduce boot data 'oldmem_data'"). OLDMEM_BASE was mistakenly replaced by oldmem_data.size instead of oldmem_data.start. This bug caused the following error during kdump: kdump.sh[878]: No program header covering vaddr 0x3434f5245found kexec bug? Fixes: e9e7870f90e3 ("s390/dump: introduce boot data 'oldmem_data'") Cc: stable@vger.kernel.org # 5.15+ Signed-off-by: Alexander Egorenkov Reviewed-by: Marc Hartmayer Reviewed-by: Heiko Carstens Signed-off-by: Heiko Carstens

s390/dump: introduce boot data 'oldmem_data'

2021-07-27T07:39:16Z

The new boot data struct shall replace global variables OLDMEM_BASE and OLDMEM_SIZE. It is initialized in the decompressor and passed to the decompressed kernel. In comparison to the old solution, this one doesn't access data at fixed physical addresses which will become important when the decompressor becomes relocatable. Signed-off-by: Alexander Egorenkov Acked-by: Heiko Carstens Signed-off-by: Heiko Carstens

elf_prstatus: collect the common part (everything before pr_reg) into a struct

2021-01-06T13:38:29Z

Preparations to doing i386 compat elf_prstatus sanely - rather than duplicating the beginning of compat_elf_prstatus, take these fields into a separate structure (compat_elf_prstatus_common), so that it could be reused. Due to the incestous relationship between binfmt_elf.c and compat_binfmt_elf.c we need the same shape change done to native struct elf_prstatus, gathering the fields prior to pr_reg into a new structure (struct elf_prstatus_common). Fortunately, offset of pr_reg is always a multiple of 16 with no padding right before it, so it's possible to turn all the stuff prior to it into a single member without disturbing the layout. [build fix from Geert Uytterhoeven folded in] Signed-off-by: Al Viro