All of lore.kernel.org
 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 [linux-next:master 7646/8170] arch/powerpc/kexec/crash.c:488:2-8: WARNING: NULL check before some freeing functions is not needed 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.