From: Sourabh Jain <sourabhjain@linux.ibm.com>
To: kernel test robot <lkp@intel.com>
Cc: oe-kbuild-all@lists.linux.dev,
Linux Memory Management List <linux-mm@kvack.org>,
Michael Ellerman <mpe@ellerman.id.au>
Subject: Re: [linux-next:master 7646/8170] arch/powerpc/kexec/crash.c:488:2-8: WARNING: NULL check before some freeing functions is not needed.
Date: Fri, 26 Apr 2024 10:09:02 +0530 [thread overview]
Message-ID: <4b89fead-5d26-4aa1-b424-8ba4306a0905@linux.ibm.com> (raw)
In-Reply-To: <202404261048.skfV5DDB-lkp@intel.com>
On 26/04/24 07:57, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> head: 5e4f84f18c4ee9b0ccdc19e39b7de41df21699dd
> commit: 849599b702ef8977fcd5b2f27c61ef773c42bb88 [7646/8170] powerpc/crash: add crash memory hotplug support
> config: powerpc-randconfig-r061-20240426 (https://download.01.org/0day-ci/archive/20240426/202404261048.skfV5DDB-lkp@intel.com/config)
> compiler: powerpc-linux-gcc (GCC) 13.2.0
>
> 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 <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202404261048.skfV5DDB-lkp@intel.com/
>
> cocci warnings: (new ones prefixed by >>)
>>> arch/powerpc/kexec/crash.c:488:2-8: WARNING: NULL check before some freeing functions is not needed.
> vim +488 arch/powerpc/kexec/crash.c
>
> 418
> 419 /**
> 420 * update_crash_elfcorehdr() - Recreate the elfcorehdr and replace it with old
> 421 * elfcorehdr in the kexec segment array.
> 422 * @image: the active struct kimage
> 423 * @mn: struct memory_notify data handler
> 424 */
> 425 static void update_crash_elfcorehdr(struct kimage *image, struct memory_notify *mn)
> 426 {
> 427 int ret;
> 428 struct crash_mem *cmem = NULL;
> 429 struct kexec_segment *ksegment;
> 430 void *ptr, *mem, *elfbuf = NULL;
> 431 unsigned long elfsz, memsz, base_addr, size;
> 432
> 433 ksegment = &image->segment[image->elfcorehdr_index];
> 434 mem = (void *) ksegment->mem;
> 435 memsz = ksegment->memsz;
> 436
> 437 ret = get_crash_memory_ranges(&cmem);
> 438 if (ret) {
> 439 pr_err("Failed to get crash mem range\n");
> 440 return;
> 441 }
> 442
> 443 /*
> 444 * The hot unplugged memory is part of crash memory ranges,
> 445 * remove it here.
> 446 */
> 447 if (image->hp_action == KEXEC_CRASH_HP_REMOVE_MEMORY) {
> 448 base_addr = PFN_PHYS(mn->start_pfn);
> 449 size = mn->nr_pages * PAGE_SIZE;
> 450 ret = remove_mem_range(&cmem, base_addr, size);
> 451 if (ret) {
> 452 pr_err("Failed to remove hot-unplugged memory from crash memory ranges\n");
> 453 goto out;
> 454 }
> 455 }
> 456
> 457 ret = crash_prepare_elf64_headers(cmem, false, &elfbuf, &elfsz);
> 458 if (ret) {
> 459 pr_err("Failed to prepare elf header\n");
> 460 goto out;
> 461 }
> 462
> 463 /*
> 464 * It is unlikely that kernel hit this because elfcorehdr kexec
> 465 * segment (memsz) is built with addition space to accommodate growing
> 466 * number of crash memory ranges while loading the kdump kernel. It is
> 467 * Just to avoid any unforeseen case.
> 468 */
> 469 if (elfsz > memsz) {
> 470 pr_err("Updated crash elfcorehdr elfsz %lu > memsz %lu", elfsz, memsz);
> 471 goto out;
> 472 }
> 473
> 474 ptr = __va(mem);
> 475 if (ptr) {
> 476 /* Temporarily invalidate the crash image while it is replaced */
> 477 xchg(&kexec_crash_image, NULL);
> 478
> 479 /* Replace the old elfcorehdr with newly prepared elfcorehdr */
> 480 memcpy((void *)ptr, elfbuf, elfsz);
> 481
> 482 /* The crash image is now valid once again */
> 483 xchg(&kexec_crash_image, image);
> 484 }
> 485 out:
> 486 kvfree(cmem);
> 487 if (elfbuf)
> > 488 kvfree(elfbuf);
> 489 }
> 490
Thanks for the report.
I will fix this and send next version.
- Sourabh Jain
next prev parent reply other threads:[~2024-04-26 4:39 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-26 2:27 kernel test robot
2024-04-26 4:39 ` Sourabh Jain [this message]
2024-04-26 6:29 ` Sourabh Jain
2024-05-02 13:23 ` Michael Ellerman
2024-05-02 18:31 ` Sourabh Jain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4b89fead-5d26-4aa1-b424-8ba4306a0905@linux.ibm.com \
--to=sourabhjain@linux.ibm.com \
--cc=linux-mm@kvack.org \
--cc=lkp@intel.com \
--cc=mpe@ellerman.id.au \
--cc=oe-kbuild-all@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox