Re: [RESEND PATCH -fixes 1/2] riscv: Export va_kernel_pa_offset in vmcoreinfo
在 2023/7/24 下午6:09, Song Shuai 写道:
Since RISC-V Linux v6.4, the commit 3335068f8721 ("riscv: Use
PUD/P4D/PGD pages for the linear mapping") changes phys_ram_base
from the physical start of the kernel to the actual start of the DRAM.
The Crash-utility's VTOP() still uses phys_ram_base and kernel_map.virt_addr
to translate kernel virtual address, that failed the Crash with Linux v6.4 [1].
Export kernel_map.va_kernel_pa_offset in vmcoreinfo to help Crash translate
the kernel virtual address correctly.
Fixes: 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear mapping")
Link:
https://lore.kernel.org/linux-riscv/20230724040649.220279-1-suagrfil...@gmail.com/
[1]
Signed-off-by: Song Shuai
---
arch/riscv/kernel/crash_core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/riscv/kernel/crash_core.c b/arch/riscv/kernel/crash_core.c
index b351a3c01355..55f1d7856b54 100644
--- a/arch/riscv/kernel/crash_core.c
+++ b/arch/riscv/kernel/crash_core.c
@@ -18,4 +18,6 @@ void arch_crash_save_vmcoreinfo(void)
vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
#endif
vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n",
KERNEL_LINK_ADDR);
+ vmcoreinfo_append_str("NUMBER(va_kernel_pa_offset)=0x%lx\n",
+ kernel_map.va_kernel_pa_offset);
}
Reviewed-by: Xianting Tian
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 1/3] arm64: kdump: Allocate crash low memory in the bottom-up direction
On 2023/7/22 5:22, kernel test robot wrote: > Hi, > > kernel test robot noticed the following build errors: > > [auto build test ERROR on arm64/for-next/core] > [also build test ERROR on linus/master v6.5-rc2 next-20230721] > [If your patch is applied to the wrong git tree, kindly drop us a note. > And when submitting patch, we suggest to use '--base' as documented in > https://git-scm.com/docs/git-format-patch#_base_tree_information] > > url: > https://github.com/intel-lab-lkp/linux/commits/thunder-leizhen-huaweicloud-com/arm64-kdump-Allocate-crash-low-memory-in-the-bottom-up-direction/20230721-162312 > base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git > for-next/core > patch link: > https://lore.kernel.org/r/20230721081726.882-2-thunder.leizhen%40huaweicloud.com > patch subject: [PATCH 1/3] arm64: kdump: Allocate crash low memory in the > bottom-up direction > config: arm64-allnoconfig > (https://download.01.org/0day-ci/archive/20230722/202307220500.1i73fz5z-...@intel.com/config) > compiler: aarch64-linux-gcc (GCC) 12.3.0 > reproduce: > (https://download.01.org/0day-ci/archive/20230722/202307220500.1i73fz5z-...@intel.com/reproduce) > > If you fix the issue in a separate patch/commit (i.e. not just a new version > of > the same patch/commit), kindly add following tags > | Reported-by: kernel test robot > | Closes: > https://lore.kernel.org/oe-kbuild-all/202307220500.1i73fz5z-...@intel.com/ > > All errors (new ones prefixed by >>): Oh, thanks. I got it. The CONFIG_KEXEC_CORE build control is move into reserve_crashkernel(). Function late_reserve_crashkernel() needs to do the same. I forgot to test turning off options like CONFIG_KEXEC_CORE. I will do it tomorrow. Sorry. diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index b544ed0ab04193d..d444721011d0b2f 100644 --- a/arch/arm64/mm/init.c +++ b/arch/arm64/mm/init.c @@ -122,6 +122,9 @@ static void __init late_reserve_crashkernel(void) unsigned long long low_base, low_size; unsigned long long crash_base, crash_size; + if (!IS_ENABLED(CONFIG_KEXEC_CORE)) + return; > >aarch64-linux-ld: arch/arm64/mm/init.o: in function > `late_reserve_crashkernel': >>> init.c:(.init.text+0x58): undefined reference to `crashk_res' >aarch64-linux-ld: arch/arm64/mm/init.o: relocation > R_AARCH64_ADR_PREL_PG_HI21 against symbol `crashk_res' which may bind > externally can not be used when making a shared object; recompile with -fPIC >init.c:(.init.text+0x58): dangerous relocation: unsupported relocation >>> aarch64-linux-ld: init.c:(.init.text+0x5c): undefined reference to >>> `crashk_res' >>> aarch64-linux-ld: init.c:(.init.text+0x88): undefined reference to >>> `crashk_low_res' >aarch64-linux-ld: arch/arm64/mm/init.o: relocation > R_AARCH64_ADR_PREL_PG_HI21 against symbol `crashk_low_res' which may bind > externally can not be used when making a shared object; recompile with -fPIC >init.c:(.init.text+0x88): dangerous relocation: unsupported relocation >aarch64-linux-ld: init.c:(.init.text+0x90): undefined reference to > `crashk_res' >aarch64-linux-ld: init.c:(.init.text+0x9c): undefined reference to > `crashk_low_res' >aarch64-linux-ld: init.c:(.init.text+0xd0): undefined reference to > `crashk_res' >aarch64-linux-ld: init.c:(.init.text+0x13c): undefined reference to > `crashk_res' >aarch64-linux-ld: init.c:(.init.text+0x150): undefined reference to > `crashk_res' >aarch64-linux-ld: init.c:(.init.text+0x18c): undefined reference to > `crashk_low_res' >aarch64-linux-ld: init.c:(.init.text+0x1b0): undefined reference to > `crashk_low_res' >aarch64-linux-ld: init.c:(.init.text+0x204): undefined reference to > `crashk_low_res' >aarch64-linux-ld: init.c:(.init.text+0x234): undefined reference to > `crashk_low_res' >aarch64-linux-ld: init.c:(.init.text+0x248): undefined reference to > `crashk_low_res' >aarch64-linux-ld: arch/arm64/mm/init.o:init.c:(.init.text+0x25c): more > undefined references to `crashk_low_res' follow > -- Regards, Zhen Lei ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 0/3] arm64: kdump: Restore the write protection for the crashkernel memory region
Hi, On 07/21/23 at 04:17pm, thunder.leiz...@huaweicloud.com wrote: > From: Zhen Lei > > Unlike in the past, the low memory allocation direction of the crashkernel is > changed from top-down to bottom-up. As long as the DMA zone has sufficient > continuous free memory, the allocated crashkernel low memory must meet the > requirements. The allocation direction of crashkernel high memory remains > unchanged, that is, top-down. As long as the high memory(above DMA zone) has > sufficient continuous free memory, the allocated crashkernel high memory must > meet the requirements. In this way, with the restoration of the original > page-level mapping and the implementation of the > arch_kexec_protect_crashkres() > function, write protection for the crashkernel memory region can be supported. > > Of course, if the high memory or low memory cannot meet the initial > requirements, > that is, fall back is required. In this case, write protection is not > supported > because the newly allocated memory is not page-level mapped. > > Because the original retry process is eliminated, the new process looks > clearer > and is a simple sequential flow. Thanks, but no. The pure semantics and the corresponding implementation have been complicated, it's not worth adding so much more complication to it just because of one inessential feature. If stomp really happened and destroy the loaded kdump kernel, the write protection truly can save kdump to make vmcore dumping succeed. While without write protection, we at least know that stomp happened by the later checksum verifycation. That's an advantage over write protection which silently ignores the stomp, right? So, due to the low cost performance, from people maintaining and understanding the code point of view, I would like to NACK this series. BUT since all these code changes are added into arm64 arch, I won't object if arm64 maintainers wants to pikc them up. By the way, as we have talked before, arm64 lacks the loaded kernel checksum storing and verifying, would you like to add that? Thanks Baoquan ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[RESEND PATCH -fixes 1/2] riscv: Export va_kernel_pa_offset in vmcoreinfo
Since RISC-V Linux v6.4, the commit 3335068f8721 ("riscv: Use
PUD/P4D/PGD pages for the linear mapping") changes phys_ram_base
from the physical start of the kernel to the actual start of the DRAM.
The Crash-utility's VTOP() still uses phys_ram_base and kernel_map.virt_addr
to translate kernel virtual address, that failed the Crash with Linux v6.4 [1].
Export kernel_map.va_kernel_pa_offset in vmcoreinfo to help Crash translate
the kernel virtual address correctly.
Fixes: 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear mapping")
Link:
https://lore.kernel.org/linux-riscv/20230724040649.220279-1-suagrfil...@gmail.com/
[1]
Signed-off-by: Song Shuai
---
arch/riscv/kernel/crash_core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/riscv/kernel/crash_core.c b/arch/riscv/kernel/crash_core.c
index b351a3c01355..55f1d7856b54 100644
--- a/arch/riscv/kernel/crash_core.c
+++ b/arch/riscv/kernel/crash_core.c
@@ -18,4 +18,6 @@ void arch_crash_save_vmcoreinfo(void)
vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
#endif
vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n",
KERNEL_LINK_ADDR);
+ vmcoreinfo_append_str("NUMBER(va_kernel_pa_offset)=0x%lx\n",
+ kernel_map.va_kernel_pa_offset);
}
--
2.20.1
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[RESEND PATCH -fixes 2/2] Documentation: kdump: Add va_kernel_pa_offset for RISCV64
RISC-V Linux exports "va_kernel_pa_offset" in vmcoreinfo to help
Crash-utility translate the kernel virtual address correctly.
Here adds the definition of "va_kernel_pa_offset".
Fixes: 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear mapping")
Link:
https://lore.kernel.org/linux-riscv/20230724040649.220279-1-suagrfil...@gmail.com/
Signed-off-by: Song Shuai
---
Documentation/admin-guide/kdump/vmcoreinfo.rst | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst
b/Documentation/admin-guide/kdump/vmcoreinfo.rst
index c18d94fa6470..f8ebb63b6c5d 100644
--- a/Documentation/admin-guide/kdump/vmcoreinfo.rst
+++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst
@@ -624,3 +624,9 @@ Used to get the correct ranges:
* VMALLOC_START ~ VMALLOC_END : vmalloc() / ioremap() space.
* VMEMMAP_START ~ VMEMMAP_END : vmemmap space, used for struct page array.
* KERNEL_LINK_ADDR : start address of Kernel link and BPF
+
+va_kernel_pa_offset
+---
+
+Indicates the offset between the kernel virtual and physical mappings.
+Used to translate virtual to physical addresses.
--
2.20.1
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH v2] kexec_lock: Replace kexec_mutex() by kexec_lock() in two comments
kexec_mutex is replaced by an atomic variable
in 05c6257433b (panic, kexec: make __crash_kexec() NMI safe).
But there are still two comments that for kexec_add_buffer()
and ima_add_kexec_buffer() using kexec_mutex, replace them by kexec_lock.
Signed-off-by: Wenyu Liu
Acked-by: Baoquan He
Acked-by: Paul Menzel
---
v1 -> v2
- fixed some mistakes in the submission information
kernel/kexec_file.c| 2 +-
security/integrity/ima/ima_kexec.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index 881ba0d1714c..b5bbb2fe0668 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -624,7 +624,7 @@ int kexec_locate_mem_hole(struct kexec_buf *kbuf)
* kexec_add_buffer - place a buffer in a kexec segment
* @kbuf: Buffer contents and memory parameters.
*
- * This function assumes that kexec_mutex is held.
+ * This function assumes that kexec_lock is held.
* On successful return, @kbuf->mem will have the physical address of
* the buffer in memory.
*
diff --git a/security/integrity/ima/ima_kexec.c
b/security/integrity/ima/ima_kexec.c
index 419dc405c831..ad133fe120db 100644
--- a/security/integrity/ima/ima_kexec.c
+++ b/security/integrity/ima/ima_kexec.c
@@ -77,7 +77,7 @@ static int ima_dump_measurement_list(unsigned long
*buffer_size, void **buffer,
* Called during kexec_file_load so that IMA can add a segment to the kexec
* image for the measurement list for the next kernel.
*
- * This function assumes that kexec_mutex is held.
+ * This function assumes that kexec_lock is held.
*/
void ima_add_kexec_buffer(struct kimage *image)
{
--
2.33.0
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH -fixes 1/2] riscv: Export va_kernel_pa_offset in vmcoreinfo
Since RISC-V Linux v6.4, the commit 3335068f8721 ("riscv: Use
PUD/P4D/PGD pages for the linear mapping") changes phys_ram_base
from the physical start of the kernel to the actual start of the DRAM.
The Crash-utility's VTOP() still uses phys_ram_base and kernel_map.virt_addr
to translate kernel virtual address, that failed the Crash with Linux v6.4 [1].
Export kernel_map.va_kernel_pa_offset in vmcoreinfo to help Crash translate
the kernel virtual address correctly.
Fixes: 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear mapping")
Link:
https://lore.kernel.org/linux-riscv/20230724040649.220279-1-suagrfil...@gmail.com/
[1]
Signed-off-by: Song Shuai
---
arch/riscv/kernel/crash_core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/riscv/kernel/crash_core.c b/arch/riscv/kernel/crash_core.c
index b351a3c01355..55f1d7856b54 100644
--- a/arch/riscv/kernel/crash_core.c
+++ b/arch/riscv/kernel/crash_core.c
@@ -18,4 +18,6 @@ void arch_crash_save_vmcoreinfo(void)
vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
#endif
vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n",
KERNEL_LINK_ADDR);
+ vmcoreinfo_append_str("NUMBER(va_kernel_pa_offset)=0x%lx\n",
+ kernel_map.va_kernel_pa_offset);
}
--
2.20.1
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [Crash-utility] RISCV64: Use va_kernel_pa_offset in VTOP()
On 2023/07/24 17:44, Song Shuai wrote:
> 在 2023/7/24 15:41, Conor Dooley 写道:
>> Hey,
>>
>> On Mon, Jul 24, 2023 at 12:06:49PM +0800, Song Shuai wrote:
>>> Since RISC-V Linux v6.4, the commit 3335068f8721 ("riscv: Use
>>> PUD/P4D/PGD pages for the linear mapping") changes the
>>> phys_ram_base from the kernel_map.phys_addr to the start of DRAM.
>>>
>>> The Crash's VTOP() still uses phys_ram_base and kernel_map.virt_addr
>>> to translate kernel virtual address, that made Crash boot failed with
>>> Linux v6.4 and later version.
>>>
>>> Let Linux export kernel_map.va_kernel_pa_offset in v6.5 and Crash can
>>> use "va_kernel_pa_offset" to translate the kernel virtual address in
>>> VTOP() correctly.
>>>
>>> Signed-off-by: Song Shuai
>>> ---
>>> You can check/test the Linux changes from this link:
>>> https://github.com/sugarfillet/linux/commits/6.5-rc3-crash
>>>
>>> And I'll send the Linux changes to riscv/for-next If you're ok with
>>> this patch.
>>
>> If you want this to go into 6.5, you'll need to send it for riscv/fixes
>> instead. It sounds like a fix for this would need to go into 6.4 too,
>> no?
> You're right, that should be riscv/fixes for 6.5 and this issue also
> need to be fixed in 6.4 stable.
>
> How about waiting for Crash guys' comments on the introduction of the
> "va_kernel_pa_offset" in vmcoreinfo
> and then determine which stable version should be taken in the first
> "if" of kernel_version.
I don't have any specific comment on this, it looks necessary and if
it's accepted in vmcoreinfo, then we can accept a crash patch for it.
Thanks,
Kazu
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] kexec_lock:Fix comment for kexec_lock
Thanks for the tips, I'll make a double-checkpost and post a new one later
在 2023/7/24 16:49, Paul Menzel 写道:
> Dear Wenyu,
>
>
> Thank you for your patch. Some minor comments, you can ignore.
>
> Am 24.07.23 um 05:45 schrieb Wenyu Liu(D):
>
> The (D) looks strange. At least a space should be added before the (.
>
>> kexec_mutex is replaced by an atomic variable in
>> 56314b90fd43bd2444 (panic, kexec: make __crash_kexec() NMI safe).
>>
>> Fix some comment that still using kexec_mutex.
>
> comment*s*
>
>>
>> Signed-off-by: Wenyu Liu
>
> Due to the (D) this doesn’t exactly match with the Author field. You also
> have two spaces before < instead of one.
>
> Also for the commit message summary you could be more specific:
>
>> kexec_lock: Replace kexec_mutex() by kexec_lock() in two comments
>
> At least, please add a space after the colon (:).
>
>> ---
>> kernel/kexec_file.c | 2 +-
>> security/integrity/ima/ima_kexec.c | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
>> index 881ba0d1714c..b5bbb2fe0668 100644
>> --- a/kernel/kexec_file.c
>> +++ b/kernel/kexec_file.c
>> @@ -624,7 +624,7 @@ int kexec_locate_mem_hole(struct kexec_buf *kbuf)
>> * kexec_add_buffer - place a buffer in a kexec segment
>> * @kbuf: Buffer contents and memory parameters.
>> *
>> - * This function assumes that kexec_mutex is held.
>> + * This function assumes that kexec_lock is held.
>> * On successful return, @kbuf->mem will have the physical address of
>> * the buffer in memory.
>> *
>> diff --git a/security/integrity/ima/ima_kexec.c
>> b/security/integrity/ima/ima_kexec.c
>> index 419dc405c831..ad133fe120db 100644
>> --- a/security/integrity/ima/ima_kexec.c
>> +++ b/security/integrity/ima/ima_kexec.c
>> @@ -77,7 +77,7 @@ static int ima_dump_measurement_list(unsigned long
>> *buffer_size, void **buffer,
>> * Called during kexec_file_load so that IMA can add a segment to the kexec
>> * image for the measurement list for the next kernel.
>> *
>> - * This function assumes that kexec_mutex is held.
>> + * This function assumes that kexec_lock is held.
>> */
>> void ima_add_kexec_buffer(struct kimage *image)
>> {
>> --
>> 2.33.0
>
>
> Kind regards,
>
> Paul
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] kexec_lock:Fix comment for kexec_lock
Thanks for the tips, I will post a new one later
在 2023/7/24 16:23, Baoquan He 写道:
> On 07/24/23 at 11:45am, Wenyu Liu(D) wrote:
>> kexec_mutex is replaced by an atomic variable in
>> 56314b90fd43bd2444 (panic, kexec: make __crash_kexec() NMI safe).
>
> You could use a distros kernel or customized kernel and made change
> based on that. The commit id isn't correct. I pasted the right one
> at below.
>
> commit 05c6257433b ("panic, kexec: make __crash_kexec() NMI safe")
>
> Other than this, this looks good. You can post a new one with my ack.
>
> Acked-by: Baoquan He
>
>>
>> Fix some comment that still using kexec_mutex.
>>
>> Signed-off-by: Wenyu Liu
>> ---
>> kernel/kexec_file.c| 2 +-
>> security/integrity/ima/ima_kexec.c | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
>> index 881ba0d1714c..b5bbb2fe0668 100644
>> --- a/kernel/kexec_file.c
>> +++ b/kernel/kexec_file.c
>> @@ -624,7 +624,7 @@ int kexec_locate_mem_hole(struct kexec_buf *kbuf)
>> * kexec_add_buffer - place a buffer in a kexec segment
>> * @kbuf: Buffer contents and memory parameters.
>> *
>> - * This function assumes that kexec_mutex is held.
>> + * This function assumes that kexec_lock is held.
>> * On successful return, @kbuf->mem will have the physical address of
>> * the buffer in memory.
>> *
>> diff --git a/security/integrity/ima/ima_kexec.c
>> b/security/integrity/ima/ima_kexec.c
>> index 419dc405c831..ad133fe120db 100644
>> --- a/security/integrity/ima/ima_kexec.c
>> +++ b/security/integrity/ima/ima_kexec.c
>> @@ -77,7 +77,7 @@ static int ima_dump_measurement_list(unsigned long
>> *buffer_size, void **buffer,
>> * Called during kexec_file_load so that IMA can add a segment to the kexec
>> * image for the measurement list for the next kernel.
>> *
>> - * This function assumes that kexec_mutex is held.
>> + * This function assumes that kexec_lock is held.
>> */
>> void ima_add_kexec_buffer(struct kimage *image)
>> {
>> --
>> 2.33.0
>>
>> ___
>> kexec mailing list
>> kexec@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec
>>
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] kexec_lock:Fix comment for kexec_lock
Dear Wenyu,
Thank you for your patch. Some minor comments, you can ignore.
Am 24.07.23 um 05:45 schrieb Wenyu Liu(D):
The (D) looks strange. At least a space should be added before the (.
kexec_mutex is replaced by an atomic variable in
56314b90fd43bd2444 (panic, kexec: make __crash_kexec() NMI safe).
Fix some comment that still using kexec_mutex.
comment*s*
Signed-off-by: Wenyu Liu
Due to the (D) this doesn’t exactly match with the Author field. You
also have two spaces before < instead of one.
Also for the commit message summary you could be more specific:
> kexec_lock: Replace kexec_mutex() by kexec_lock() in two comments
At least, please add a space after the colon (:).
---
kernel/kexec_file.c| 2 +-
security/integrity/ima/ima_kexec.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index 881ba0d1714c..b5bbb2fe0668 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -624,7 +624,7 @@ int kexec_locate_mem_hole(struct kexec_buf *kbuf)
* kexec_add_buffer - place a buffer in a kexec segment
* @kbuf: Buffer contents and memory parameters.
*
- * This function assumes that kexec_mutex is held.
+ * This function assumes that kexec_lock is held.
* On successful return, @kbuf->mem will have the physical address of
* the buffer in memory.
*
diff --git a/security/integrity/ima/ima_kexec.c
b/security/integrity/ima/ima_kexec.c
index 419dc405c831..ad133fe120db 100644
--- a/security/integrity/ima/ima_kexec.c
+++ b/security/integrity/ima/ima_kexec.c
@@ -77,7 +77,7 @@ static int ima_dump_measurement_list(unsigned long
*buffer_size, void **buffer,
* Called during kexec_file_load so that IMA can add a segment to the kexec
* image for the measurement list for the next kernel.
*
- * This function assumes that kexec_mutex is held.
+ * This function assumes that kexec_lock is held.
*/
void ima_add_kexec_buffer(struct kimage *image)
{
--
2.33.0
Kind regards,
Paul
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [Crash-utility] RISCV64: Use va_kernel_pa_offset in VTOP()
在 2023/7/24 16:13, Alexandre Ghiti 写道:
Hi Song,
On 24/07/2023 06:06, Song Shuai wrote:
Since RISC-V Linux v6.4, the commit 3335068f8721 ("riscv: Use
PUD/P4D/PGD pages for the linear mapping") changes the
phys_ram_base from the kernel_map.phys_addr to the start of DRAM.
Maybe we could be more explicit here, kernel_map.phys_addr actually
points to the physical start of the kernel so maybe something like that:
"changes phys_ram_base from the physical start of the kernel to the
actual start of the DRAM."
ok,
The Crash's VTOP() still uses phys_ram_base and kernel_map.virt_addr
to translate kernel virtual address, that made Crash boot failed with
Linux v6.4 and later version.
Let Linux export kernel_map.va_kernel_pa_offset in v6.5 and Crash can
use "va_kernel_pa_offset" to translate the kernel virtual address in
VTOP() correctly.
Signed-off-by: Song Shuai
---
You can check/test the Linux changes from this link:
https://github.com/sugarfillet/linux/commits/6.5-rc3-crash
And I'll send the Linux changes to riscv/for-next If you're ok with
this patch.
---
defs.h | 4 ++--
riscv64.c | 22 ++
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/defs.h b/defs.h
index 358f365..46b9857 100644
--- a/defs.h
+++ b/defs.h
@@ -3662,8 +3662,7 @@ typedef signed int s32;
ulong _X = X; \
(THIS_KERNEL_VERSION >= LINUX(5,13,0) && \
(_X) >= machdep->machspec->kernel_link_addr) ? \
- (((unsigned long)(_X)-(machdep->machspec->kernel_link_addr))
+ \
- machdep->machspec->phys_base): \
+ ((unsigned
long)(_X)-(machdep->machspec->va_kernel_pa_offset)): \
(((unsigned long)(_X)-(machdep->kvbase)) + \
machdep->machspec->phys_base); \
})
@@ -7021,6 +7020,7 @@ struct machine_specific {
ulong modules_vaddr;
ulong modules_end;
ulong kernel_link_addr;
+ ulong va_kernel_pa_offset;
ulong _page_present;
ulong _page_read;
diff --git a/riscv64.c b/riscv64.c
index 6b9a688..b9e50b4 100644
--- a/riscv64.c
+++ b/riscv64.c
@@ -418,6 +418,27 @@ error:
error(FATAL, "cannot get vm layout\n");
}
+static void
+riscv64_get_va_kernel_pa_offset(struct machine_specific *ms)
+{
+ unsigned long kernel_version = riscv64_get_kernel_version();
+
+ /*
+ * va_kernel_pa_offset is defined in Linux kernel since 6.5.
+ */
+ if (kernel_version >= LINUX(6,5,0)) {
+ char *string;
+ if ((string =
pc->read_vmcoreinfo("NUMBER(va_kernel_pa_offset)"))) {
+ ms->va_kernel_pa_offset = htol(string, QUIET, NULL);
+ free(string);
+ } else
+ error(FATAL, "cannot read va_kernel_pa_offset\n");
+ } else if (kernel_version >= LINUX(6,4,0))
+ error(FATAL, "cannot determine va_kernel_pa_offset since
Linux 6.4\n");
+ else
+ ms->va_kernel_pa_offset = ms->kernel_link_addr - ms->phys_base;
+}
+
static int
riscv64_is_kvaddr(ulong vaddr)
{
@@ -1352,6 +1373,7 @@ riscv64_init(int when)
riscv64_get_struct_page_size(machdep->machspec);
riscv64_get_va_bits(machdep->machspec);
riscv64_get_va_range(machdep->machspec);
+ riscv64_get_va_kernel_pa_offset(machdep->machspec);
pt_level_alloc(&machdep->pgd, "cannot malloc pgd space.");
pt_level_alloc(&machdep->machspec->p4d, "cannot malloc p4d
space.");
Would you mind giving me the instructions on how to reproduce the issue
please? So that I can add that to our internal CI and avoid this type of
breakage in the future.
You can reproduce this issue via :
1. compile the Linux v6.4 or later version with Kdump support
2. generate the vmcore file via sysrq-trigger
3. start the Crash (crash-utility/crash:master) with namelist(vmlinux)
and vmcore with optional "-d" option
Crash would boot failed with some incorrect infos (like: empty
cpu_*_mask,utsname ) and some error like:
`crash: read error: kernel virtual address: 80ecb498 type:
"linux_banner"`
Thanks,
Alex
--
Thanks
Song Shuai
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [Crash-utility] RISCV64: Use va_kernel_pa_offset in VTOP()
在 2023/7/24 15:41, Conor Dooley 写道:
Hey,
On Mon, Jul 24, 2023 at 12:06:49PM +0800, Song Shuai wrote:
Since RISC-V Linux v6.4, the commit 3335068f8721 ("riscv: Use
PUD/P4D/PGD pages for the linear mapping") changes the
phys_ram_base from the kernel_map.phys_addr to the start of DRAM.
The Crash's VTOP() still uses phys_ram_base and kernel_map.virt_addr
to translate kernel virtual address, that made Crash boot failed with
Linux v6.4 and later version.
Let Linux export kernel_map.va_kernel_pa_offset in v6.5 and Crash can
use "va_kernel_pa_offset" to translate the kernel virtual address in
VTOP() correctly.
Signed-off-by: Song Shuai
---
You can check/test the Linux changes from this link:
https://github.com/sugarfillet/linux/commits/6.5-rc3-crash
And I'll send the Linux changes to riscv/for-next If you're ok with this patch.
If you want this to go into 6.5, you'll need to send it for riscv/fixes
instead. It sounds like a fix for this would need to go into 6.4 too,
no?
You're right, that should be riscv/fixes for 6.5 and this issue also
need to be fixed in 6.4 stable.
How about waiting for Crash guys' comments on the introduction of the
"va_kernel_pa_offset" in vmcoreinfo
and then determine which stable version should be taken in the first
"if" of kernel_version.
--
Thanks
Song Shuai
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] kexec_lock:Fix comment for kexec_lock
On 07/24/23 at 11:45am, Wenyu Liu(D) wrote:
> kexec_mutex is replaced by an atomic variable in
> 56314b90fd43bd2444 (panic, kexec: make __crash_kexec() NMI safe).
You could use a distros kernel or customized kernel and made change
based on that. The commit id isn't correct. I pasted the right one
at below.
commit 05c6257433b ("panic, kexec: make __crash_kexec() NMI safe")
Other than this, this looks good. You can post a new one with my ack.
Acked-by: Baoquan He
>
> Fix some comment that still using kexec_mutex.
>
> Signed-off-by: Wenyu Liu
> ---
> kernel/kexec_file.c| 2 +-
> security/integrity/ima/ima_kexec.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index 881ba0d1714c..b5bbb2fe0668 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -624,7 +624,7 @@ int kexec_locate_mem_hole(struct kexec_buf *kbuf)
> * kexec_add_buffer - place a buffer in a kexec segment
> * @kbuf: Buffer contents and memory parameters.
> *
> - * This function assumes that kexec_mutex is held.
> + * This function assumes that kexec_lock is held.
> * On successful return, @kbuf->mem will have the physical address of
> * the buffer in memory.
> *
> diff --git a/security/integrity/ima/ima_kexec.c
> b/security/integrity/ima/ima_kexec.c
> index 419dc405c831..ad133fe120db 100644
> --- a/security/integrity/ima/ima_kexec.c
> +++ b/security/integrity/ima/ima_kexec.c
> @@ -77,7 +77,7 @@ static int ima_dump_measurement_list(unsigned long
> *buffer_size, void **buffer,
> * Called during kexec_file_load so that IMA can add a segment to the kexec
> * image for the measurement list for the next kernel.
> *
> - * This function assumes that kexec_mutex is held.
> + * This function assumes that kexec_lock is held.
> */
> void ima_add_kexec_buffer(struct kimage *image)
> {
> --
> 2.33.0
>
> ___
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [Crash-utility] RISCV64: Use va_kernel_pa_offset in VTOP()
Hi Song,
On 24/07/2023 06:06, Song Shuai wrote:
Since RISC-V Linux v6.4, the commit 3335068f8721 ("riscv: Use
PUD/P4D/PGD pages for the linear mapping") changes the
phys_ram_base from the kernel_map.phys_addr to the start of DRAM.
Maybe we could be more explicit here, kernel_map.phys_addr actually
points to the physical start of the kernel so maybe something like that:
"changes phys_ram_base from the physical start of the kernel to the
actual start of the DRAM."
The Crash's VTOP() still uses phys_ram_base and kernel_map.virt_addr
to translate kernel virtual address, that made Crash boot failed with
Linux v6.4 and later version.
Let Linux export kernel_map.va_kernel_pa_offset in v6.5 and Crash can
use "va_kernel_pa_offset" to translate the kernel virtual address in
VTOP() correctly.
Signed-off-by: Song Shuai
---
You can check/test the Linux changes from this link:
https://github.com/sugarfillet/linux/commits/6.5-rc3-crash
And I'll send the Linux changes to riscv/for-next If you're ok with this patch.
---
defs.h| 4 ++--
riscv64.c | 22 ++
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/defs.h b/defs.h
index 358f365..46b9857 100644
--- a/defs.h
+++ b/defs.h
@@ -3662,8 +3662,7 @@ typedef signed int s32;
ulong _X = X;
\
(THIS_KERNEL_VERSION >= LINUX(5,13,0) &&
\
(_X) >= machdep->machspec->kernel_link_addr) ?
\
- (((unsigned long)(_X)-(machdep->machspec->kernel_link_addr)) +
\
-machdep->machspec->phys_base):
\
+ ((unsigned long)(_X)-(machdep->machspec->va_kernel_pa_offset)):
\
(((unsigned long)(_X)-(machdep->kvbase)) +
\
machdep->machspec->phys_base);
\
})
@@ -7021,6 +7020,7 @@ struct machine_specific {
ulong modules_vaddr;
ulong modules_end;
ulong kernel_link_addr;
+ ulong va_kernel_pa_offset;
ulong _page_present;
ulong _page_read;
diff --git a/riscv64.c b/riscv64.c
index 6b9a688..b9e50b4 100644
--- a/riscv64.c
+++ b/riscv64.c
@@ -418,6 +418,27 @@ error:
error(FATAL, "cannot get vm layout\n");
}
+static void
+riscv64_get_va_kernel_pa_offset(struct machine_specific *ms)
+{
+ unsigned long kernel_version = riscv64_get_kernel_version();
+
+ /*
+* va_kernel_pa_offset is defined in Linux kernel since 6.5.
+*/
+ if (kernel_version >= LINUX(6,5,0)) {
+ char *string;
+ if ((string =
pc->read_vmcoreinfo("NUMBER(va_kernel_pa_offset)"))) {
+ ms->va_kernel_pa_offset = htol(string, QUIET, NULL);
+ free(string);
+ } else
+ error(FATAL, "cannot read va_kernel_pa_offset\n");
+ } else if (kernel_version >= LINUX(6,4,0))
+ error(FATAL, "cannot determine va_kernel_pa_offset since Linux
6.4\n");
+ else
+ ms->va_kernel_pa_offset = ms->kernel_link_addr - ms->phys_base;
+}
+
static int
riscv64_is_kvaddr(ulong vaddr)
{
@@ -1352,6 +1373,7 @@ riscv64_init(int when)
riscv64_get_struct_page_size(machdep->machspec);
riscv64_get_va_bits(machdep->machspec);
riscv64_get_va_range(machdep->machspec);
+ riscv64_get_va_kernel_pa_offset(machdep->machspec);
pt_level_alloc(&machdep->pgd, "cannot malloc pgd space.");
pt_level_alloc(&machdep->machspec->p4d, "cannot malloc p4d
space.");
Would you mind giving me the instructions on how to reproduce the issue
please? So that I can add that to our internal CI and avoid this type of
breakage in the future.
Thanks,
Alex
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
