[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z3vuBTiQvnRvv9DQ@e133380.arm.com>
Date: Mon, 6 Jan 2025 14:51:49 +0000
From: Dave Martin <Dave.Martin@....com>
To: Akihiko Odaki <akihiko.odaki@...nix.com>
Cc: Eric Biederman <ebiederm@...ssion.com>, Kees Cook <kees@...nel.org>,
Catalin Marinas <catalin.marinas@....com>,
Mark Brown <broonie@...nel.org>, Baoquan He <bhe@...hat.com>,
Vivek Goyal <vgoyal@...hat.com>, Dave Young <dyoung@...hat.com>,
linux-mm@...ck.org, linux-kernel@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, linux-s390@...r.kernel.org,
kexec@...ts.infradead.org, devel@...nix.com
Subject: Re: [PATCH v2 5/5] crash: Remove KEXEC_CORE_NOTE_NAME
Hi,
On Sat, Jan 04, 2025 at 11:38:38PM +0900, Akihiko Odaki wrote:
> Now KEXEC_CORE_NOTE_NAME is only used at one place and it does not seem
> to provide any value anymore. Replace the remaining usage with the
> literal and remove the macro.
>
> Signed-off-by: Akihiko Odaki <akihiko.odaki@...nix.com>
> ---
> arch/s390/kernel/crash_dump.c | 2 +-
> include/linux/kexec.h | 2 --
> include/linux/vmcore_info.h | 1 -
> 3 files changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/arch/s390/kernel/crash_dump.c b/arch/s390/kernel/crash_dump.c
> index cd0c93a8fb8b..4a9817489e35 100644
> --- a/arch/s390/kernel/crash_dump.c
> +++ b/arch/s390/kernel/crash_dump.c
> @@ -253,7 +253,7 @@ static const char *nt_name(Elf64_Word type)
> const char *name = "LINUX";
>
> if (type == NT_PRPSINFO || type == NT_PRSTATUS || type == NT_PRFPREG)
> - name = KEXEC_CORE_NOTE_NAME;
> + name = "CORE";
If I've understood the code here correctly, the note type is supplied
at all the nt_init() and nt_size() call sites, so instead of this hack
can we wrap those in macros that get the formal name from elf.h rather
than guessing it here? e.g.:
#define nt_size(..., note, ...) \
__nt_size(..., NT ## _ ## note, NN ## _ ## note, ...)
etc.
The compiler is quite likely to fold away most of the implied
duplication of code (it would be interesting to look at the compiler
output) -- but anyway, this is super-slow-path: nobody expects realtime
response when the kernel has crashed.
[...]
Cheers
---Dave
Powered by blists - more mailing lists