Re: [Crash-utility PATCH] RISCV64: Add KASLR support
On Tue, Aug 15, 2023 at 6:50 PM Song Shuai wrote:
>
> From: Song Shuai
>
> This patch adds KASLR support for Crash to analyze KASLR-ed vmcore
> since RISC-V Linux is already sufficiently prepared for KASLR [1].
>
> With this patch, even if the Crash '--kaslr' option is not set or Linux
> CONFIG_RANDOMIZE_BASE is not configured, the 'derive_kaslr_offset()'
> function will always work to calculate 'kt->relocate' which serves to
> update the kernel virtual address.
>
> [1]:
> https://lore.kernel.org/linux-riscv/20230722123850.634544-1-alexgh...@rivosinc.com/
>
> Signed-off-by: Song Shuai
> ---
> main.c| 2 +-
> riscv64.c | 11 +++
> symbols.c | 4 ++--
> 3 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/main.c b/main.c
> index b278c22..0c6e595 100644
> --- a/main.c
> +++ b/main.c
> @@ -228,7 +228,7 @@ main(int argc, char **argv)
> } else if (STREQ(long_options[option_index].name,
> "kaslr")) {
> if (!machine_type("X86_64") &&
> !machine_type("ARM64") &&
> !machine_type("X86") &&
> - !machine_type("S390X"))
> + !machine_type("S390X") &&
> !machine_type("RISCV64"))
> error(INFO, "--kaslr not valid "
> "with this machine type.\n");
> else if (STREQ(optarg, "auto"))
> diff --git a/riscv64.c b/riscv64.c
> index a02f75a..288c7ae 100644
> --- a/riscv64.c
> +++ b/riscv64.c
> @@ -378,6 +378,9 @@ static void riscv64_get_va_range(struct machine_specific
> *ms)
> } else
> goto error;
>
> + if ((kt->flags2 & KASLR) && (kt->flags & RELOC_SET))
> + ms->kernel_link_addr += (kt->relocate * -1);
> +
> /*
> * From Linux 5.13, the kernel mapping is moved to the last 2GB
> * of the address space, modules use the 2GB memory range right
> @@ -1360,6 +1363,14 @@ riscv64_init(int when)
>
> machdep->verify_paddr = generic_verify_paddr;
> machdep->ptrs_per_pgd = PTRS_PER_PGD;
> +
> + /*
> +* Even if CONFIG_RANDOMIZE_BASE is not configured,
> +* derive_kaslr_offset() should work and set
> +* kt->relocate to 0
> +*/
> + if (!kt->relocate && !(kt->flags2 & (RELOC_AUTO|KASLR)))
> + kt->flags2 |= (RELOC_AUTO|KASLR);
> break;
>
> case PRE_GDB:
> diff --git a/symbols.c b/symbols.c
> index 876be7a..8e8b4c3 100644
> --- a/symbols.c
> +++ b/symbols.c
> @@ -629,7 +629,7 @@ kaslr_init(void)
> char *string;
>
> if ((!machine_type("X86_64") && !machine_type("ARM64") &&
> !machine_type("X86") &&
> - !machine_type("S390X")) || (kt->flags & RELOC_SET))
> + !machine_type("S390X") && !machine_type("RISCV64")) || (kt->flags
> & RELOC_SET))
> return;
>
> if (!kt->vmcoreinfo._stext_SYMBOL &&
> @@ -795,7 +795,7 @@ store_symbols(bfd *abfd, int dynamic, void *minisyms,
> long symcount,
> } else if (!(kt->flags & RELOC_SET))
> kt->flags |= RELOC_FORCE;
> } else if (machine_type("X86_64") || machine_type("ARM64") ||
> - machine_type("S390X")) {
> + machine_type("S390X") || machine_type("RISCV64")) {
> if ((kt->flags2 & RELOC_AUTO) && !(kt->flags & RELOC_SET))
> derive_kaslr_offset(abfd, dynamic, from,
> fromend, size, store);
> --
> 2.20.1
>
Reviewed-by: Guo Ren
Could you put some output in the commit log, to let other turst this
patch could work.
--
Best Regards
Guo Ren
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH -next v6 0/2] support allocating crashkernel above 4G explicitly on riscv
On Mon, Jul 3, 2023 at 9:07 PM chenjiahao (C) wrote: > > > On 2023/7/1 21:45, Guo Ren wrote: > > On Sat, Jul 1, 2023 at 5:12 PM Chen Jiahao wrote: > >> 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 top down in > >> high memory, without overlapping the DMA zone, is a mature solution. > >> Hence this patchset introduces the parameter option > >> crashkernel=X,[high,low]. > >> > >> One can reserve the crash kernel from high memory above DMA zone range > >> by explicitly passing "crashkernel=X,high"; or reserve a memory range > >> below 4G with "crashkernel=X,low". Besides, there are few rules need > >> to take notice: > >> 1. "crashkernel=X,[high,low]" will be ignored if "crashkernel=size" > >> is specified. > >> 2. "crashkernel=X,low" is valid only when "crashkernel=X,high" is passed > >> and there is enough memory to be allocated under 4G. > >> 3. When allocating crashkernel above 4G and no "crashkernel=X,low" is > >> specified, a 128M low memory will be allocated automatically for > >> swiotlb bounce buffer. > >> See Documentation/admin-guide/kernel-parameters.txt for more information. > >> > >> To verify loading the crashkernel, adapted kexec-tools is attached below: > >> https://github.com/chenjh005/kexec-tools/tree/build-test-riscv-v2 > >> > >> Following test cases have been performed as expected: > >> 1) crashkernel=256M //low=256M > >> 2) crashkernel=1G//low=1G > > Have you tried 1GB memory? we found a pud mapping problem on Sv39 of kexec, > > See: > > https://lore.kernel.org/linux-riscv/20230629082032.3481237-1-guo...@kernel.org/ > > I have tested on QEMU with sv57 mmu, so it seems the synchronization problem > was not reproduce when reserving 1G memory and loading the capture kernel. Yes, the pud of sv57 is not the pgd entries, so you didn't get problem. > > > Thanks, > Jiahao > > > > >> 3) crashkernel=4G//high=4G, low=128M(default) > >> 4) crashkernel=4G crashkernel=256M,high //high=4G, low=128M(default), > >> high is ignored > >> 5) crashkernel=4G crashkernel=256M,low //high=4G, low=128M(default), > >> low is ignored > >> 6) crashkernel=4G,high //high=4G, low=128M(default) > >> 7) crashkernel=256M,low //low=0M, invalid > >> 8) crashkernel=4G,high crashkernel=256M,low //high=4G, low=256M > >> 9) crashkernel=4G,high crashkernel=4G,low//high=0M, low=0M, invalid > >> 10) crashkernel=512M@0xd000 //low=512M > >> > >> Changes since [v6]: > >> 1. Introduce the "high" flag to mark whether "crashkernel=X,high" > >> is passed. Fix the retrying logic between "crashkernel=X,high" > >> case and others when the first allocation attempt fails. > >> > >> Changes since [v5]: > >> 1. Update the crashkernel allocation logic when crashkernel=X,high > >> is specified. In this case, region above 4G will directly get > >> reserved as crashkernel, rather than trying lower 32bit allocation > >> first. > >> > >> Changes since [v4]: > >> 1. Update some imprecise code comments for cmdline parsing. > >> > >> Changes since [v3]: > >> 1. Update to print warning and return explicitly on failure when > >> crashkernel=size@offset is specified. Not changing the result > >> in this case but making the logic more straightforward. > >> 2. Some minor cleanup. > >> > >> Changes since [v2]: > >> 1. Update the allocation logic to ensure the high crashkernel > >> region is reserved strictly above dma32_phys_limit. > >> 2. Clean up some minor format problems. > >> > >> Chen Jiahao (2): > >>riscv: kdump: Implement crashkernel=X,[high,low] > >>docs: kdump: Update the crashkernel description for riscv > >> > >> .../admin-guide/kernel-parameters.txt | 15 ++-- > >> arch/riscv/kernel/setup.c | 5 ++ > >> arch/riscv/mm/init.c | 84 +-- > >> 3 files changed, 90 insertions(+), 14 deletions(-) > >> > >> -- > >> 2.34.1 > >> > > -- Best Regards Guo Ren ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH -next v6 0/2] support allocating crashkernel above 4G explicitly on riscv
On Sat, Jul 1, 2023 at 5:12 PM Chen Jiahao wrote: > > 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 top down in > high memory, without overlapping the DMA zone, is a mature solution. > Hence this patchset introduces the parameter option crashkernel=X,[high,low]. > > One can reserve the crash kernel from high memory above DMA zone range > by explicitly passing "crashkernel=X,high"; or reserve a memory range > below 4G with "crashkernel=X,low". Besides, there are few rules need > to take notice: > 1. "crashkernel=X,[high,low]" will be ignored if "crashkernel=size" >is specified. > 2. "crashkernel=X,low" is valid only when "crashkernel=X,high" is passed >and there is enough memory to be allocated under 4G. > 3. When allocating crashkernel above 4G and no "crashkernel=X,low" is >specified, a 128M low memory will be allocated automatically for >swiotlb bounce buffer. > See Documentation/admin-guide/kernel-parameters.txt for more information. > > To verify loading the crashkernel, adapted kexec-tools is attached below: > https://github.com/chenjh005/kexec-tools/tree/build-test-riscv-v2 > > Following test cases have been performed as expected: > 1) crashkernel=256M //low=256M > 2) crashkernel=1G//low=1G Have you tried 1GB memory? we found a pud mapping problem on Sv39 of kexec, See: https://lore.kernel.org/linux-riscv/20230629082032.3481237-1-guo...@kernel.org/ > 3) crashkernel=4G//high=4G, low=128M(default) > 4) crashkernel=4G crashkernel=256M,high //high=4G, low=128M(default), > high is ignored > 5) crashkernel=4G crashkernel=256M,low //high=4G, low=128M(default), > low is ignored > 6) crashkernel=4G,high //high=4G, low=128M(default) > 7) crashkernel=256M,low //low=0M, invalid > 8) crashkernel=4G,high crashkernel=256M,low //high=4G, low=256M > 9) crashkernel=4G,high crashkernel=4G,low//high=0M, low=0M, invalid > 10) crashkernel=512M@0xd000 //low=512M > > Changes since [v6]: > 1. Introduce the "high" flag to mark whether "crashkernel=X,high" >is passed. Fix the retrying logic between "crashkernel=X,high" >case and others when the first allocation attempt fails. > > Changes since [v5]: > 1. Update the crashkernel allocation logic when crashkernel=X,high >is specified. In this case, region above 4G will directly get >reserved as crashkernel, rather than trying lower 32bit allocation >first. > > Changes since [v4]: > 1. Update some imprecise code comments for cmdline parsing. > > Changes since [v3]: > 1. Update to print warning and return explicitly on failure when >crashkernel=size@offset is specified. Not changing the result >in this case but making the logic more straightforward. > 2. Some minor cleanup. > > Changes since [v2]: > 1. Update the allocation logic to ensure the high crashkernel >region is reserved strictly above dma32_phys_limit. > 2. Clean up some minor format problems. > > Chen Jiahao (2): > riscv: kdump: Implement crashkernel=X,[high,low] > docs: kdump: Update the crashkernel description for riscv > > .../admin-guide/kernel-parameters.txt | 15 ++-- > arch/riscv/kernel/setup.c | 5 ++ > arch/riscv/mm/init.c | 84 +-- > 3 files changed, 90 insertions(+), 14 deletions(-) > > -- > 2.34.1 > -- Best Regards Guo Ren ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH -next v3 1/2] riscv: kdump: Implement crashkernel=X,[high,low]
On Fri, Apr 7, 2023 at 8:03 PM Simon Horman wrote: > > On Fri, Apr 07, 2023 at 05:06:24PM +0800, Guo Ren wrote: > > On Thu, Apr 6, 2023 at 10:06 PM Chen Jiahao wrote: > > > > > > 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 top down in > > > high memory, without overlapping the DMA zone, is a mature solution. > > > Here introduce the parameter option crashkernel=X,[high,low]. > > > > > > One can reserve the crash kernel from high memory above DMA zone range > > > by explicitly passing "crashkernel=X,high"; or reserve a memory range > > > below 4G with "crashkernel=X,low". > > Asked-by: Guo Ren > > Perhaps 'Acked-by' :) Sorry, my typo. Acked-by: Guo Ren -- Best Regards Guo Ren ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH -next v3 1/2] riscv: kdump: Implement crashkernel=X,[high,low]
On Thu, Apr 6, 2023 at 10:06 PM Chen Jiahao wrote:
>
> 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 top down in
> high memory, without overlapping the DMA zone, is a mature solution.
> Here introduce the parameter option crashkernel=X,[high,low].
>
> One can reserve the crash kernel from high memory above DMA zone range
> by explicitly passing "crashkernel=X,high"; or reserve a memory range
> below 4G with "crashkernel=X,low".
Asked-by: Guo Ren
>
> Signed-off-by: Chen Jiahao
> ---
> arch/riscv/kernel/setup.c | 5 +++
> arch/riscv/mm/init.c | 74 ---
> 2 files changed, 74 insertions(+), 5 deletions(-)
>
> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> index 5d3184cbf518..ea84e5047c23 100644
> --- a/arch/riscv/kernel/setup.c
> +++ b/arch/riscv/kernel/setup.c
> @@ -176,6 +176,11 @@ static void __init init_resources(void)
> if (ret < 0)
> goto error;
> }
> + if (crashk_low_res.start != crashk_low_res.end) {
> + ret = add_resource(&iomem_resource, &crashk_low_res);
> + if (ret < 0)
> + goto error;
> + }
> #endif
>
> #ifdef CONFIG_CRASH_DUMP
> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> index 478d6763a01a..b5b457193423 100644
> --- a/arch/riscv/mm/init.c
> +++ b/arch/riscv/mm/init.c
> @@ -1152,6 +1152,28 @@ static inline void setup_vm_final(void)
> }
> #endif /* CONFIG_MMU */
>
> +/* Reserve 128M low memory by default for swiotlb buffer */
> +#define DEFAULT_CRASH_KERNEL_LOW_SIZE (128UL << 20)
> +
> +static int __init reserve_crashkernel_low(unsigned long long low_size)
> +{
> + unsigned long long low_base;
> +
> + low_base = memblock_phys_alloc_range(low_size, PMD_SIZE, 0,
> dma32_phys_limit);
> + if (!low_base) {
> + pr_err("cannot allocate crashkernel low memory
> (size:0x%llx).\n", low_size);
> + return -ENOMEM;
> + }
> +
> + pr_info("crashkernel low memory reserved: 0x%016llx - 0x%016llx (%lld
> MB)\n",
> + low_base, low_base + low_size, low_size >> 20);
> +
> + crashk_low_res.start = low_base;
> + crashk_low_res.end = low_base + low_size - 1;
> +
> + return 0;
> +}
> +
> /*
> * reserve_crashkernel() - reserves memory for crash kernel
> *
> @@ -1163,8 +1185,12 @@ static void __init reserve_crashkernel(void)
> {
> unsigned long long crash_base = 0;
> unsigned long long crash_size = 0;
> + unsigned long long crash_low_size = 0;
> unsigned long search_start = memblock_start_of_DRAM();
> unsigned long search_end = memblock_end_of_DRAM();
> + unsigned long search_low_max = (unsigned long)dma32_phys_limit;
> + char *cmdline = boot_command_line;
> + bool fixed_base = false;
>
> int ret = 0;
>
> @@ -1180,14 +1206,37 @@ static void __init reserve_crashkernel(void)
> return;
> }
>
> - ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
> + ret = parse_crashkernel(cmdline, memblock_phys_mem_size(),
> &crash_size, &crash_base);
> - if (ret || !crash_size)
> + if (ret == -ENOENT) {
> + /*
> +* crashkernel=X,[high,low] can be specified or not, but
> +* invalid value is not allowed.
> +*/
> + ret = parse_crashkernel_high(cmdline, 0, &crash_size,
> &crash_base);
> + if (ret || !crash_size)
> + return;
> +
> + /*
> +* crashkernel=Y,low is valid only when crashkernel=X,high
> +* is passed and high memory is reserved successful.
> +*/
> + ret = parse_crashkernel_low(cmdline, 0, &crash_low_size,
> &crash_base);
> + if (ret == -ENOENT)
> + crash_low_size = DEFAULT_CRASH_KERNEL_LOW_SIZE;
> + else if (ret)
> + return;
> +
> + search_start = search_low_max;
> + } else if (ret || !crash_size) {
> + /* Invalid argument value specified */
> return;
> + }
Re: [PATCH -next v3 2/2] docs: kdump: Update the crashkernel description for riscv
Reviewed-by: Guo Ren On Thu, Apr 6, 2023 at 10:05 PM Chen Jiahao wrote: > > 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 > --- > Documentation/admin-guide/kernel-parameters.txt | 15 --- > 1 file changed, 8 insertions(+), 7 deletions(-) > > diff --git a/Documentation/admin-guide/kernel-parameters.txt > b/Documentation/admin-guide/kernel-parameters.txt > index 54702bd488eb..41865aae9eaa 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -866,7 +866,7 @@ > memory region [offset, offset + size] for that kernel > image. If '@offset' is omitted, then a suitable offset > is selected automatically. > - [KNL, X86-64, ARM64] Select a region under 4G first, > and > + [KNL, X86-64, ARM64, RISCV] Select a region under 4G > first, and > fall back to reserve region above 4G when '@offset' > hasn't been specified. > See Documentation/admin-guide/kdump/kdump.rst for > further details. > @@ -879,14 +879,14 @@ > Documentation/admin-guide/kdump/kdump.rst for an > example. > > crashkernel=size[KMG],high > - [KNL, X86-64, ARM64] range could be above 4G. Allow > kernel > - to allocate physical memory region from top, so could > - be above 4G if system have more than 4G ram installed. > - Otherwise memory region will be allocated below 4G, if > - available. > + [KNL, X86-64, ARM64, RISCV] range could be above 4G. > + Allow kernel to allocate physical memory region from > top, > + so could be above 4G if system have more than 4G ram > + installed. Otherwise memory region will be allocated > + below 4G, if available. > It will be ignored if crashkernel=X is specified. > crashkernel=size[KMG],low > - [KNL, X86-64, ARM64] range under 4G. When > crashkernel=X,high > + [KNL, X86-64, ARM64, RISCV] range under 4G. When > crashkernel=X,high > is passed, kernel could allocate physical memory > region > above 4G, that cause second kernel crash on system > that require some amount of low memory, e.g. swiotlb > @@ -897,6 +897,7 @@ > size is platform dependent. > --> x86: max(swiotlb_size_or_default() + 8MiB, > 256MiB) > --> arm64: 128MiB > + --> riscv: 128MiB > This one lets the user specify own low range under 4G > for second kernel instead. > 0: to disable low allocation. > -- > 2.31.1 > -- Best Regards Guo Ren ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH V2] RISC-V: Add support for riscv kexec/kdump on kexec-tools
F.Y.I
xianting_...@126.com
On Mon, Mar 27, 2023 at 9:52 AM Baoquan He wrote:
>
> Hi Xianting,
>
> On 10/26/22 at 10:59am, Xianting Tian wrote:
> >
> > 在 2022/10/26 上午10:13, Xianting Tian 写道:
> > > Hi Simon
> > >
> > > thanks for the comments
> > >
> > > 在 2022/10/21 下午11:27, Simon Horman 写道:
> > > > On Thu, Oct 20, 2022 at 11:15:48AM +0800, Xianting Tian wrote:
> > > > > From: Nick Kossifidis
> > > > >
> > > > > This patch adds support for loading the ELF kernel image. It parses
> > > > > the current/provided device tree to determine the system's memory
> > > > > layout, and /proc/iomem for the various kernel segments.
> > > > >
> > > > > This patch was firstly developed by Nick Kossifidis, and two fixes (
> > > > > 1: fail to find free memory area for dtb load when using
> > > > > initrd image,
> > > > > lists.infradead.org/pipermail/linux-riscv/2022-August/018398.html;
> > > > > 2: fix memory range size calculation,
> > > > > kexec/arch/riscv/crashdump-riscv.c:line 85
> > > > > ) are contributed by Yixun Lan, Xianting Tian.
> > > > >
> > > > > Tested on Qemu's rv64 virt machine and SoC of T-Head RISC-V
> > > > > Xuantie 910 CPU.
> > > > Hi,
> > > >
> > > > thanks for some patch.
> > > >
> > > > Some minor feedback follows.
> > > >
> > > > Separately, I'll post a patch to add RISC-V builds to the github
> > > > workflow. If you could include that in V3 I'd be most grateful.
> > > >
> > > > > Tested-by: Yixun Lan
> > > > > Co-developed-by: Xianting Tian
> > > > > Co-developed-by: Yixun Lan
> > > > > Signed-off-by: Nick Kossifidis
> > > > ...
> > > >
> > > > > +ret = mem_regions_alloc_and_add(mem_ranges, start,
> > > > > +end - start, type);
> > > > mem_regions_alloc_and_add isn't always available.
> > > > f.e. on mips this causes a build failure.
> > > >
> > > > Ref:
> > > > https://github.com/horms/kexec-tools/actions/runs/3298491143/jobs/5440677595
> > >
> > > As you know, mem_regions_sort, mem_regions_alloc_and_add are the common
> > > funtions,
> > >
> > > The build error of mips is caused by this riscv patch?
> > >
> > > kexec/mem_regions.c:void mem_regions_sort(struct memory_ranges *ranges)
> > > kexec/mem_regions.h:void mem_regions_sort(struct memory_ranges *ranges);
> > >
> > >
> > > kexec/mem_regions.c:int mem_regions_alloc_and_add(struct memory_ranges
> > > *ranges,
> > > kexec/mem_regions.h:int mem_regions_alloc_and_add(struct memory_ranges
> > > *ranges,
> > >
> > > >
> > > > ...
> > > >
> > > > > +int dtb_get_memory_ranges(char *dtb, struct memory_ranges
> > > > > *mem_ranges, struct memory_ranges *extra_ranges)
> > > > > +{
> > > > ...
> > > >
> > > > > +mem_regions_sort(mem_ranges);
> > > > Likewise, mem_regions_sort isn't always available.
> > > > f.e. on mips this causes a build failure.
> > > >
> > > > ...
> > > >
> > > > > diff --git a/purgatory/arch/riscv/Makefile
> > > > > b/purgatory/arch/riscv/Makefile
> > > > > new file mode 100644
> > > > > index 000..8bded71
> > > > > --- /dev/null
> > > > > +++ b/purgatory/arch/riscv/Makefile
> > > > > @@ -0,0 +1,7 @@
> > > > > +#
> > > > > +# Purgatory riscv
> > > > > +#
> > > > > +
> > > > > +riscv_PURGATORY_SRCS =
> > > > > +
> > > > > +dist += purgatory/arch/sh/Makefile $(riscv_PURGATORY_SRCS)
> > > > s/sh/riscv/
> > > >
> > > > Else the distribution tarball won't include this Makefile
> > > >
> > > > You can exercise this using:
> > > >make distcheck DISTCHECK_CONFIGURE_FLAGS="--host=riscv64-linux-gnu"
> > > thanks, I will fix this.
> >
> > the fix is in my personal gitee
> >
> > https://gitee.com/xianting-tian/kexec-tools/commits/master
>
> Is this patchset reposting still in your working plan? I don't see the
> code in kexe-tools, so ping to ask.
>
> If this is not your work tasks any more, people interested can pick this
> patchset and post after polishing.
>
> Thanks
> Baoquan
>
--
Best Regards
Guo Ren
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH V5 0/2] Support VMCOREINFO export for RISCV64
On Wed, Dec 7, 2022 at 4:08 PM Conor Dooley wrote: > > On Wed, Dec 07, 2022 at 11:34:57AM +0800, Guo Ren wrote: > > On Wed, Dec 7, 2022 at 7:05 AM Conor Dooley wrote: > > > > > > Hey Palmer, Xianting, > > > > > > On Fri, Dec 02, 2022 at 04:49:39PM -0800, Palmer Dabbelt wrote: > > > > On Wed, 26 Oct 2022 22:42:06 +0800, Xianting Tian wrote: > > > > > As disscussed in below patch set, the patch of 'describe VMCOREINFO > > > > > export in Documentation' > > > > > need to update according to Bagas's comments. > > > > > https://lore.kernel.org/linux-riscv/22aaf52e-8cc8-4d11-99cb-88de4d113...@kernel.org/ > > > > > > > > > > As others patches in above patch set already applied, so this patch > > > > > set only contains below two > > > > > patches. > > > > > > > > > > [...] > > > > > > > > Applied, thanks! > > > > > > > > [1/2] RISC-V: Add arch_crash_save_vmcoreinfo support > > > > https://git.kernel.org/palmer/c/649d6b1019a2 > > > > > > So this patch seems to be causing issues for the nommu build: > > > https://lore.kernel.org/oe-kbuild-all/202212062250.tr0othcz-...@intel.com/ > > > > > > I had a bit of a poke at trying to see if there were some headers we > > > could pull in before actually checking the .config only to see: > > > # CONFIG_MMU is not set > > > > > > Do we have to wrap the whole thing in a `#ifdef CONFIG_MMU` to fix > > > compilation here? > > The problem does not belong to the patch. > > > > Could I send a fixup patch? like this? > > That seems like a sane dependancy, but did you build that config? > This doesn't fix the problem for me :/ Sorry, It's the wrong fixup. Here is the new version, and tested. Thx for the report. https://lore.kernel.org/linux-riscv/20221207091112.2258674-1-guo...@kernel.org/ > > > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > > index ef8d66de5f38..d8c07999426c 100644 > > --- a/arch/riscv/Kconfig > > +++ b/arch/riscv/Kconfig > > @@ -512,6 +512,7 @@ config ARCH_HAS_KEXEC_PURGATORY > > > > config CRASH_DUMP > > bool "Build kdump crash kernel" > > + depends on KEXEC > > help > > Generate crash dump after being started by kexec. This should > > be normally only set in special crash dump kernels which are > > > > > > > > Thanks, > > > Conor. > > > > > > > > > -- > > Best Regards > > Guo Ren -- Best Regards Guo Ren ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH V5 0/2] Support VMCOREINFO export for RISCV64
On Wed, Dec 7, 2022 at 7:05 AM Conor Dooley wrote:
>
> Hey Palmer, Xianting,
>
> On Fri, Dec 02, 2022 at 04:49:39PM -0800, Palmer Dabbelt wrote:
> > On Wed, 26 Oct 2022 22:42:06 +0800, Xianting Tian wrote:
> > > As disscussed in below patch set, the patch of 'describe VMCOREINFO
> > > export in Documentation'
> > > need to update according to Bagas's comments.
> > > https://lore.kernel.org/linux-riscv/22aaf52e-8cc8-4d11-99cb-88de4d113...@kernel.org/
> > >
> > > As others patches in above patch set already applied, so this patch set
> > > only contains below two
> > > patches.
> > >
> > > [...]
> >
> > Applied, thanks!
> >
> > [1/2] RISC-V: Add arch_crash_save_vmcoreinfo support
> > https://git.kernel.org/palmer/c/649d6b1019a2
>
> So this patch seems to be causing issues for the nommu build:
> https://lore.kernel.org/oe-kbuild-all/202212062250.tr0othcz-...@intel.com/
>
> I had a bit of a poke at trying to see if there were some headers we
> could pull in before actually checking the .config only to see:
> # CONFIG_MMU is not set
>
> Do we have to wrap the whole thing in a `#ifdef CONFIG_MMU` to fix
> compilation here?
The problem does not belong to the patch.
Could I send a fixup patch? like this?
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index ef8d66de5f38..d8c07999426c 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -512,6 +512,7 @@ config ARCH_HAS_KEXEC_PURGATORY
config CRASH_DUMP
bool "Build kdump crash kernel"
+ depends on KEXEC
help
Generate crash dump after being started by kexec. This should
be normally only set in special crash dump kernels which are
>
> Thanks,
> Conor.
>
--
Best Regards
Guo Ren
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH V5 0/2] Support VMCOREINFO export for RISCV64
Hi Palmer, Here are another two fix-up patches of kdump for the crash tool. https://lore.kernel.org/linux-riscv/20221020141603.2856206-3-guo...@kernel.org/ https://lore.kernel.org/linux-riscv/20221020141603.2856206-2-guo...@kernel.org/ On Sat, Dec 3, 2022 at 8:56 AM Palmer Dabbelt wrote: > > On Wed, 26 Oct 2022 22:42:06 +0800, Xianting Tian wrote: > > As disscussed in below patch set, the patch of 'describe VMCOREINFO export > > in Documentation' > > need to update according to Bagas's comments. > > https://lore.kernel.org/linux-riscv/22aaf52e-8cc8-4d11-99cb-88de4d113...@kernel.org/ > > > > As others patches in above patch set already applied, so this patch set > > only contains below two > > patches. > > > > [...] > > Applied, thanks! > > [1/2] RISC-V: Add arch_crash_save_vmcoreinfo support > https://git.kernel.org/palmer/c/649d6b1019a2 > [2/2] Documentation: kdump: describe VMCOREINFO export for RISCV64 > https://git.kernel.org/palmer/c/c5b4216929eb > > Best regards, > -- > Palmer Dabbelt -- Best Regards Guo Ren ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH V5 1/2] RISC-V: Add arch_crash_save_vmcoreinfo support
Tested-by: Guo Ren
On Wed, Oct 26, 2022 at 10:42 PM Xianting Tian
wrote:
>
> Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC,
> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram base for vmcore.
>
> Default pagetable levels and PAGE_OFFSET aren't same for different kernel
> version as below. For pagetable levels, it sets sv57 by default and falls
> back to setting sv48 at boot time if sv57 is not supported by the hardware.
>
> For ram base, the default value is 0x8020 for qemu riscv64 env and,
> for example, is 0x20 on the XuanTie 910 CPU.
>
> * Linux Kernel 5.18 ~
> * PGTABLE_LEVELS = 5
> * PAGE_OFFSET = 0xff60
> * Linux Kernel 5.17 ~
> * PGTABLE_LEVELS = 4
> * PAGE_OFFSET = 0xaf80
> * Linux Kernel 4.19 ~
> * PGTABLE_LEVELS = 3
> * PAGE_OFFSET = 0xffe0
>
> Since these configurations change from time to time and version to version,
> it is preferable to export them via vmcoreinfo than to change the crash's
> code frequently, it can simplify the development of crash tool.
>
> Signed-off-by: Xianting Tian
> ---
> arch/riscv/kernel/Makefile | 1 +
> arch/riscv/kernel/crash_core.c | 21 +
> 2 files changed, 22 insertions(+)
> create mode 100644 arch/riscv/kernel/crash_core.c
>
> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> index db6e4b1294ba..4cf303a779ab 100644
> --- a/arch/riscv/kernel/Makefile
> +++ b/arch/riscv/kernel/Makefile
> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)+= kgdb.o
> obj-$(CONFIG_KEXEC_CORE) += kexec_relocate.o crash_save_regs.o
> machine_kexec.o
> obj-$(CONFIG_KEXEC_FILE) += elf_kexec.o machine_kexec_file.o
> obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
> +obj-$(CONFIG_CRASH_CORE) += crash_core.o
>
> obj-$(CONFIG_JUMP_LABEL) += jump_label.o
>
> diff --git a/arch/riscv/kernel/crash_core.c b/arch/riscv/kernel/crash_core.c
> new file mode 100644
> index ..b351a3c01355
> --- /dev/null
> +++ b/arch/riscv/kernel/crash_core.c
> @@ -0,0 +1,21 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#include
> +#include
> +
> +void arch_crash_save_vmcoreinfo(void)
> +{
> + VMCOREINFO_NUMBER(VA_BITS);
> + VMCOREINFO_NUMBER(phys_ram_base);
> +
> + vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
> + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
> + vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
> + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
> + vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
> +#ifdef CONFIG_64BIT
> + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
> + 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);
> +}
> --
> 2.17.1
>
--
Best Regards
Guo Ren
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH V4 1/2] RISC-V: Add arch_crash_save_vmcoreinfo support
Tested-by: Guo Ren Don't forget the another two kdump fixups [1] [1] https://lore.kernel.org/all/20221020141603.2856206-3-guo...@kernel.org/ Only the patch without [1]: crash> help -r CPU 0: [OFFLINE] CPU 1: epc : 80009ff0 ra : 800b789a sp : ff201098bb40 gp : 815fca60 tp : ff600468 t0 : 3c5b t1 : t2 : 663c s0 : ff201098bc90 s1 : 81600798 a0 : ff201098bb48 a1 : a2 : a3 : 0001 a4 : a5 : ff6004690800 a6 : a7 : s2 : ff201098bb48 s3 : 81093ec8 s4 : 816004ac s5 : s6 : 0007 s7 : 80e7f720 s8 : 00fff3f0 s9 : 0007 s10: 00b98700 s11: 0001 t3 : 819a8097 t4 : 819a8097 t5 : 819a8098 t6 : ff201098b9a8 CPU 2: [OFFLINE] CPU 3: [OFFLINE] The patch with [1]: crash> help -r CPU 0: epc : 80003f34 ra : 808caa7c sp : 81403eb0 gp : 815fcb48 tp : 81413400 t0 : t1 : t2 : s0 : 81403ec0 s1 : a0 : a1 : a2 : a3 : a4 : a5 : a6 : a7 : s2 : 816001c8 s3 : 81600370 s4 : 80c32e18 s5 : 819d3018 s6 : 810e2110 s7 : s8 : s9 : 80039eac s10: s11: t3 : t4 : t5 : t6 : CPU 1: epc : 80003f34 ra : 808caa7c sp : ff200068bf30 gp : 815fcb48 tp : ff600240d400 t0 : t1 : t2 : s0 : ff200068bf40 s1 : 0001 a0 : a1 : a2 : a3 : a4 : a5 : a6 : a7 : s2 : 816001c8 s3 : 81600370 s4 : 80c32e18 s5 : 819d3018 s6 : 810e2110 s7 : s8 : s9 : 80039ea8 s10: s11: t3 : t4 : t5 : t6 : CPU 2: epc : 80003f34 ra : 808caa7c sp : ff2000693f30 gp : 815fcb48 tp : ff600240e900 t0 : t1 : t2 : s0 : ff2000693f40 s1 : 0002 a0 : a1 : a2 : a3 : a4 : a5 : a6 : a7 : s2 : 816001c8 s3 : 81600370 s4 : 80c32e18 s5 : 819d3018 s6 : 810e2110 s7 : s8 : s9 : 80039eb0 s10: s11: t3 : t4 : t5 : t6 : CPU 3: epc : 8000a1e4 ra : 800b7bba sp : ff20109bbb40 gp : 815fcb48 tp : ff600373aa00 t0 : 3c5b t1 : t2 : 663c s0 : ff20109bbc90 s1 : 816007a0 a0 : ff20109bbb48 a1 : a2 : a3 : 0001 a4 : a5 : ff6002c61c00 a6 : a7 : s2 : ff20109bbb48 s3 : 810941a8 s4 : 816004b4 s5 : s6 : 0007 s7 : 80e7f7a0 s8 : 00fff3f0 s9 : 0007 s10: 00b98700 s11: 0001 t3 : 819a8097 t4 : 819a8097 t5 : 819a8098 t6 : ff20109bb9a8 On Wed, Oct 19, 2022 at 6:36 PM Xianting Tian wrote: > > Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC, > VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram base for vmcore. > > Default pagetable levels and PAGE_OFFSET aren't same for different kernel > version as below. For pagetable levels, it sets sv57 by default and falls > back to setting sv48 at boot time if sv57 is not supported by the hardware. > > For ram base, the default value is 0x8020 for qemu riscv64 env and, > for example, is 0x20 on the XuanTie 910 CPU. > > * Linux Kernel 5.18 ~ > * PGTABLE_LEVELS = 5 > * PAGE_OFFSET = 0xff60 > * Linux Kernel 5.17 ~ > * PGTABLE_LEVELS = 4 > * PAGE_OFFSET = 0xaf80 > *
Re: [PATCH] RISC-V: Add support for riscv kexec/kdump on kexec-tools
F.Y.I Nick Kossifidis The first author should be him. On Wed, Sep 14, 2022 at 3:52 PM Xianting Tian wrote: > > This patch adds support for loading the ELF kernel image. It parses > the current/provided device tree to determine the system's memory > layout, and /proc/iomem for the various kernel segments. > > This patch was firstly developed by Nick Kossifidis, and two fixes ( >1: fail to find free memory area for dtb load when using initrd image, > lists.infradead.org/pipermail/linux-riscv/2022-August/018398.html; >2: fix memory range size calculation, >kexec/arch/riscv/crashdump-riscv.c:line 85 > ) are contributed by Yixun Lan, Xianting Tian. > > Tested on Qemu's rv64 virt machine and SoC of T-Head RISC-V Xuantie 910 CPU. > > Tested-by: Yixun Lan > Signed-off-by: Xianting Tian > Signed-off-by: Yixun Lan > Signed-off-by: Nick Kossifidis > --- > configure.ac| 3 + > include/elf.h | 3 +- > kexec/Makefile | 1 + > kexec/arch/riscv/Makefile | 35 ++ > kexec/arch/riscv/crashdump-riscv.c | 140 > kexec/arch/riscv/include/arch/options.h | 43 +++ > kexec/arch/riscv/kexec-elf-riscv.c | 255 ++ > kexec/arch/riscv/kexec-riscv.c | 365 +++ > kexec/arch/riscv/kexec-riscv.h | 32 ++ > kexec/dt-ops.c | 442 +++- > kexec/dt-ops.h | 7 + > kexec/kexec-syscall.h | 4 + > purgatory/Makefile | 1 + > purgatory/arch/riscv/Makefile | 7 + > 14 files changed, 1336 insertions(+), 2 deletions(-) > create mode 100644 kexec/arch/riscv/Makefile > create mode 100644 kexec/arch/riscv/crashdump-riscv.c > create mode 100644 kexec/arch/riscv/include/arch/options.h > create mode 100644 kexec/arch/riscv/kexec-elf-riscv.c > create mode 100644 kexec/arch/riscv/kexec-riscv.c > create mode 100644 kexec/arch/riscv/kexec-riscv.h > create mode 100644 purgatory/arch/riscv/Makefile > > diff --git a/configure.ac b/configure.ac > index 0d825ef..7cc55b0 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -58,6 +58,9 @@ case $target_cpu in > hppa*) > ARCH="hppa" > ;; > + riscv32|riscv64 ) > + ARCH="riscv" > + ;; > * ) > AC_MSG_ERROR([unsupported architecture $target_cpu]) > ;; > diff --git a/include/elf.h b/include/elf.h > index b7677a2..123f167 100644 > --- a/include/elf.h > +++ b/include/elf.h > @@ -259,7 +259,8 @@ typedef struct > #define EM_ARC_A5 93 /* ARC Cores Tangent-A5 */ > #define EM_XTENSA 94 /* Tensilica Xtensa Architecture */ > #define EM_AARCH64 183 /* ARM AARCH64 */ > -#define EM_NUM 184 > +#define EM_RISCV 243 /* RISC-V */ > +#define EM_NUM 244 > > /* If it is necessary to assign new unofficial EM_* values, please > pick large random numbers (0x8523, 0xa7f2, etc.) to minimize the > diff --git a/kexec/Makefile b/kexec/Makefile > index e69e309..ca17831 100644 > --- a/kexec/Makefile > +++ b/kexec/Makefile > @@ -88,6 +88,7 @@ include $(srcdir)/kexec/arch/mips/Makefile > include $(srcdir)/kexec/arch/cris/Makefile > include $(srcdir)/kexec/arch/ppc/Makefile > include $(srcdir)/kexec/arch/ppc64/Makefile > +include $(srcdir)/kexec/arch/riscv/Makefile > include $(srcdir)/kexec/arch/s390/Makefile > include $(srcdir)/kexec/arch/sh/Makefile > include $(srcdir)/kexec/arch/x86_64/Makefile > diff --git a/kexec/arch/riscv/Makefile b/kexec/arch/riscv/Makefile > new file mode 100644 > index 000..f26cc90 > --- /dev/null > +++ b/kexec/arch/riscv/Makefile > @@ -0,0 +1,35 @@ > +# > +# kexec riscv > +# > +riscv_KEXEC_SRCS = kexec/arch/riscv/kexec-riscv.c > +riscv_KEXEC_SRCS += kexec/arch/riscv/kexec-elf-riscv.c > +riscv_KEXEC_SRCS += kexec/arch/riscv/crashdump-riscv.c > + > +riscv_MEM_REGIONS = kexec/mem_regions.c > + > +riscv_DT_OPS += kexec/dt-ops.c > + > +riscv_ARCH_REUSE_INITRD = > + > +riscv_CPPFLAGS += -I $(srcdir)/kexec/ > + > +dist += kexec/arch/riscv/Makefile $(riscv_KEXEC_SRCS) \ > + kexec/arch/riscv/kexec-riscv.h \ > + kexec/arch/riscv/include/arch/options.h > + > +ifdef HAVE_LIBFDT > + > +LIBS += -lfdt > + > +else > + > +include $(srcdir)/kexec/libfdt/Makefile.libfdt > + > +libfdt_SRCS += $(LIBFDT_SRCS:%=kexec/libfdt/%) > + > +riscv_CPPFLAGS += -I$(srcdir)/kexec/libfdt > + > +riscv_KEXEC_SRCS += $(libfdt_SRCS) > + > +endif > + > diff --git a/kexec/arch/riscv/crashdump-riscv.c > b/kexec/arch/riscv/crashdump-riscv.c > new file mode 100644 > index 000..3ed4fe3 > --- /dev/null > +++ b/kexec/arch/riscv/crashdump-riscv.c > @@ -0,0 +1,140 @@ > +#include > +#include > +#include > + > +#include "kexec.h" > +#include "crashdump.h" > +#include "ke
Re: [PATCH] mm: convert totalram_pages, totalhigh_pages and managed_pages to atomic.
On Mon, Oct 22, 2018 at 10:53:22PM +0530, Arun KS wrote: > Remove managed_page_count_lock spinlock and instead use atomic > variables. > > Suggested-by: Michal Hocko > Suggested-by: Vlastimil Babka > Signed-off-by: Arun KS > > --- > As discussed here, > https://patchwork.kernel.org/patch/10627521/#22261253 > --- > --- > arch/csky/mm/init.c | 4 +- > arch/powerpc/platforms/pseries/cmm.c | 11 ++-- > arch/s390/mm/init.c | 2 +- > arch/um/kernel/mem.c | 4 +- > arch/x86/kernel/cpu/microcode/core.c | 5 +- > drivers/char/agp/backend.c| 4 +- > drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 2 +- > drivers/gpu/drm/i915/i915_gem.c | 2 +- > drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 +- > drivers/hv/hv_balloon.c | 19 +++ > drivers/md/dm-bufio.c | 5 +- > drivers/md/dm-crypt.c | 4 +- > drivers/md/dm-integrity.c | 4 +- > drivers/md/dm-stats.c | 3 +- > drivers/media/platform/mtk-vpu/mtk_vpu.c | 3 +- > drivers/misc/vmw_balloon.c| 2 +- > drivers/parisc/ccio-dma.c | 5 +- > drivers/parisc/sba_iommu.c| 5 +- > drivers/staging/android/ion/ion_system_heap.c | 2 +- > drivers/xen/xen-selfballoon.c | 7 +-- > fs/ceph/super.h | 3 +- > fs/file_table.c | 9 ++-- > fs/fuse/inode.c | 4 +- > fs/nfs/write.c| 3 +- > fs/nfsd/nfscache.c| 3 +- > fs/ntfs/malloc.h | 2 +- > fs/proc/base.c| 3 +- > include/linux/highmem.h | 2 +- > include/linux/mm.h| 2 +- > include/linux/mmzone.h| 10 +--- > include/linux/swap.h | 2 +- > kernel/fork.c | 6 +-- > kernel/kexec_core.c | 5 +- > kernel/power/snapshot.c | 2 +- > lib/show_mem.c| 3 +- > mm/highmem.c | 2 +- > mm/huge_memory.c | 2 +- > mm/kasan/quarantine.c | 4 +- > mm/memblock.c | 6 +-- > mm/memory_hotplug.c | 4 +- > mm/mm_init.c | 3 +- > mm/oom_kill.c | 2 +- > mm/page_alloc.c | 75 > ++- > mm/shmem.c| 12 +++-- > mm/slab.c | 3 +- > mm/swap.c | 3 +- > mm/util.c | 2 +- > mm/vmalloc.c | 4 +- > mm/vmstat.c | 4 +- > mm/workingset.c | 2 +- > mm/zswap.c| 2 +- > net/dccp/proto.c | 6 +-- > net/decnet/dn_route.c | 2 +- > net/ipv4/tcp_metrics.c| 2 +- > net/netfilter/nf_conntrack_core.c | 6 +-- > net/netfilter/xt_hashlimit.c | 4 +- > net/sctp/protocol.c | 6 +-- > security/integrity/ima/ima_kexec.c| 2 +- > 58 files changed, 171 insertions(+), 143 deletions(-) > > diff --git a/arch/csky/mm/init.c b/arch/csky/mm/init.c > index dc07c07..3f4d35e 100644 > --- a/arch/csky/mm/init.c > +++ b/arch/csky/mm/init.c > @@ -71,7 +71,7 @@ void free_initrd_mem(unsigned long start, unsigned long end) > ClearPageReserved(virt_to_page(start)); > init_page_count(virt_to_page(start)); > free_page(start); > - totalram_pages++; > + atomic_long_inc(&totalram_pages); > } > } > #endif > @@ -88,7 +88,7 @@ void free_initmem(void) > ClearPageReserved(virt_to_page(addr)); > init_page_count(virt_to_page(addr)); > free_page(addr); > - totalram_pages++; > + atomic_long_inc(&totalram_pages); > addr += PAGE_SIZE; > } For csky part, it's OK. Guo Ren ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
