linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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



  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