Hi Dan,
On 07/25/23 at 08:03pm, Dan Carpenter wrote:
> The bug is the error handling:
>
> if (tmp < nr_bytes) {
>
> "tmp" can hold negative error codes but because "nr_bytes" is type
> size_t the negative error codes are treated as very high positive
> values (success). Fix this by
On Tue, Jul 25, 2023 at 08:03:16PM +0300, Dan Carpenter wrote:
> The bug is the error handling:
>
> if (tmp < nr_bytes) {
>
> "tmp" can hold negative error codes but because "nr_bytes" is type
> size_t the negative error codes are treated as very high positive
> values (success). Fix this
On 2023/7/26 5:48, Conor Dooley wrote:
Hey,
Your $subject says -next, but the patch failed to apply to
riscv/for-next. What was the base for this patchset?
Thanks,
Conor.
Hi,
My patchset was tested on current linux-next HEAD
(commit ID: 1e25dd777248, tag: next-20230725) and
it seems all
The bug is the error handling:
if (tmp < nr_bytes) {
"tmp" can hold negative error codes but because "nr_bytes" is type
size_t the negative error codes are treated as very high positive
values (success). Fix this by changing "nr_bytes" to type ssize_t. The
"nr_bytes" variable is used
On riscv, the current crash kernel allocation logic is trying to
allocate within 32bit addressible memory region by default, if
failed, try to allocate without 4G restriction.
In need of saving DMA zone memory while allocating a relatively large
crash kernel region, allocating the reserved memory
Now "crashkernel=" parameter on riscv has been updated to support
crashkernel=X,[high,low]. Through which we can reserve memory region
above/within 32bit addressible DMA zone.
Here update the parameter description accordingly.
Signed-off-by: Chen Jiahao
Reviewed-by: Guo Ren
Reviewed-by: Simon
On riscv, the current crash kernel allocation logic is trying to
allocate within 32bit addressible memory region by default, if
failed, try to allocate without 4G restriction.
In need of saving DMA zone memory while allocating a relatively large
crash kernel region, allocating the reserved memory
From: Petr Tesarik
16-bit add and subtract relocation types are used by the purgatory code
when the kernel is built with CONFIG_RISCV_ALTERNATIVES. If they are not
handled, kexec_file_load(2) fails with:
Unknown rela relocation: 34
kexec_image: Error loading purgatory ret=-8
or later with:
Hi,
oops. I wanted to _add_ the kexec ML to all other recipients, but I
somehow screwed up, so this version is sent _only_ to the kexec ML. If
you reply here, the other recipients will not see your reply. The real
thread is here:
From: Petr Tesarik
The kexec_file_load(2) syscall does not work at least in some kernel
builds. For details see the relevant section in this blog post:
https://sigillatum.tesarici.cz/2023-07-21-state-of-riscv64-kdump.html
This patch series handles additional relocation types and removes the
From: Torsten Duwe
R_RISCV_CALL has been deprecated and replaced by R_RISCV_CALL_PLT. See Enum
18-19 in Table 3. Relocation types here:
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-elf.adoc
It was deprecated in ("Deprecated R_RISCV_CALL, prefer R_RISCV_CALL_PLT"):
From: Petr Tesarik
Linking with this object file it makes kexec_file_load(2) fail with:
kexec_image: Unknown rela relocation: 20
kexec_image: Error loading purgatory ret=-8
This is R_RISCV_GOT_HI20, generated by the linker to handle references to
the global variable _ctype from strcasecmp()
On 24/07/2023 12:09, Song Shuai wrote:
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")
Hi Song,
On 24/07/2023 12:09, Song Shuai wrote:
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
On 2023/7/24 21:34, Baoquan He wrote:
> 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
>>
15 matches
Mail list logo
