From: Santosh Sivaraj <santosh@fossix.org>
To: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>,
robh@kernel.org, dan.carpenter@oracle.com, mpe@ellerman.id.au
Cc: devicetree@vger.kernel.org, kbuild-all@lists.01.org,
lkp@intel.com, linuxppc-dev@lists.ozlabs.org,
bauerman@linux.ibm.com, dja@axtens.net
Subject: Re: [PATCH 1/2] powerpc: Free fdt on error in elf64_load()
Date: Wed, 21 Apr 2021 19:32:42 +0530 [thread overview]
Message-ID: <87pmynybul.fsf@fossix.org> (raw)
In-Reply-To: <407a9f66-8f91-9c6e-9653-738ba79a97b2@linux.microsoft.com>
Lakshmi Ramasubramanian <nramas@linux.microsoft.com> writes:
> On 4/20/21 10:35 PM, Santosh Sivaraj wrote:
> Hi Santosh,
>
>>
>>> There are a few "goto out;" statements before the local variable "fdt"
>>> is initialized through the call to of_kexec_alloc_and_setup_fdt() in
>>> elf64_load(). This will result in an uninitialized "fdt" being passed
>>> to kvfree() in this function if there is an error before the call to
>>> of_kexec_alloc_and_setup_fdt().
>>>
>>> If there is any error after fdt is allocated, but before it is
>>> saved in the arch specific kimage struct, free the fdt.
>>>
>>> Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
>>> Reported-by: kernel test robot <lkp@intel.com>
>>> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
>>> Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
>>> ---
>>> arch/powerpc/kexec/elf_64.c | 16 ++++++----------
>>> 1 file changed, 6 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/arch/powerpc/kexec/elf_64.c b/arch/powerpc/kexec/elf_64.c
>>> index 5a569bb51349..02662e72c53d 100644
>>> --- a/arch/powerpc/kexec/elf_64.c
>>> +++ b/arch/powerpc/kexec/elf_64.c
>>> @@ -114,7 +114,7 @@ static void *elf64_load(struct kimage *image, char *kernel_buf,
>>> ret = setup_new_fdt_ppc64(image, fdt, initrd_load_addr,
>>> initrd_len, cmdline);
>>> if (ret)
>>> - goto out;
>>> + goto out_free_fdt;
>>
>> Shouldn't there be a goto out_free_fdt if fdt_open_into fails?
>
> You are likely looking at elf_64.c in the mainline branch. The patch I
> have submitted is based on Rob's device-tree for-next branch. Please see
> the link below:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git/tree/arch/powerpc/kexec/elf_64.c?h=for-next
That's right, I was indeed looking at the mainline. Sorry for the noise.
Thanks,
Santosh
>
>>
>>>
>>> fdt_pack(fdt);
>>>
>>> @@ -125,7 +125,7 @@ static void *elf64_load(struct kimage *image, char *kernel_buf,
>>> kbuf.mem = KEXEC_BUF_MEM_UNKNOWN;
>>> ret = kexec_add_buffer(&kbuf);
>>> if (ret)
>>> - goto out;
>>> + goto out_free_fdt;
>>>
>>> /* FDT will be freed in arch_kimage_file_post_load_cleanup */
>>> image->arch.fdt = fdt;
>>> @@ -140,18 +140,14 @@ static void *elf64_load(struct kimage *image, char *kernel_buf,
>>> if (ret)
>>> pr_err("Error setting up the purgatory.\n");
>>>
>>> + goto out;
>>> +
>>> +out_free_fdt:
>>> + kvfree(fdt);
>>
>> Can just use kfree here?
> "fdt" is allocated through kvmalloc(). So it is freed using kvfree.
>
> thanks,
> -lakshmi
>
>>> out:
>>> kfree(modified_cmdline);
>>> kexec_free_elf_info(&elf_info);
>>>
>>> - /*
>>> - * Once FDT buffer has been successfully passed to kexec_add_buffer(),
>>> - * the FDT buffer address is saved in image->arch.fdt. In that case,
>>> - * the memory cannot be freed here in case of any other error.
>>> - */
>>> - if (ret && !image->arch.fdt)
>>> - kvfree(fdt);
>>> -
>>> return ret ? ERR_PTR(ret) : NULL;
>>> }
>>>
>>> --
>>> 2.31.0
WARNING: multiple messages have this Message-ID (diff)
From: Santosh Sivaraj <santosh@fossix.org>
To: kbuild-all@lists.01.org
Subject: Re: [PATCH 1/2] powerpc: Free fdt on error in elf64_load()
Date: Wed, 21 Apr 2021 19:32:42 +0530 [thread overview]
Message-ID: <87pmynybul.fsf@fossix.org> (raw)
In-Reply-To: <407a9f66-8f91-9c6e-9653-738ba79a97b2@linux.microsoft.com>
[-- Attachment #1: Type: text/plain, Size: 3122 bytes --]
Lakshmi Ramasubramanian <nramas@linux.microsoft.com> writes:
> On 4/20/21 10:35 PM, Santosh Sivaraj wrote:
> Hi Santosh,
>
>>
>>> There are a few "goto out;" statements before the local variable "fdt"
>>> is initialized through the call to of_kexec_alloc_and_setup_fdt() in
>>> elf64_load(). This will result in an uninitialized "fdt" being passed
>>> to kvfree() in this function if there is an error before the call to
>>> of_kexec_alloc_and_setup_fdt().
>>>
>>> If there is any error after fdt is allocated, but before it is
>>> saved in the arch specific kimage struct, free the fdt.
>>>
>>> Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
>>> Reported-by: kernel test robot <lkp@intel.com>
>>> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
>>> Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
>>> ---
>>> arch/powerpc/kexec/elf_64.c | 16 ++++++----------
>>> 1 file changed, 6 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/arch/powerpc/kexec/elf_64.c b/arch/powerpc/kexec/elf_64.c
>>> index 5a569bb51349..02662e72c53d 100644
>>> --- a/arch/powerpc/kexec/elf_64.c
>>> +++ b/arch/powerpc/kexec/elf_64.c
>>> @@ -114,7 +114,7 @@ static void *elf64_load(struct kimage *image, char *kernel_buf,
>>> ret = setup_new_fdt_ppc64(image, fdt, initrd_load_addr,
>>> initrd_len, cmdline);
>>> if (ret)
>>> - goto out;
>>> + goto out_free_fdt;
>>
>> Shouldn't there be a goto out_free_fdt if fdt_open_into fails?
>
> You are likely looking at elf_64.c in the mainline branch. The patch I
> have submitted is based on Rob's device-tree for-next branch. Please see
> the link below:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git/tree/arch/powerpc/kexec/elf_64.c?h=for-next
That's right, I was indeed looking at the mainline. Sorry for the noise.
Thanks,
Santosh
>
>>
>>>
>>> fdt_pack(fdt);
>>>
>>> @@ -125,7 +125,7 @@ static void *elf64_load(struct kimage *image, char *kernel_buf,
>>> kbuf.mem = KEXEC_BUF_MEM_UNKNOWN;
>>> ret = kexec_add_buffer(&kbuf);
>>> if (ret)
>>> - goto out;
>>> + goto out_free_fdt;
>>>
>>> /* FDT will be freed in arch_kimage_file_post_load_cleanup */
>>> image->arch.fdt = fdt;
>>> @@ -140,18 +140,14 @@ static void *elf64_load(struct kimage *image, char *kernel_buf,
>>> if (ret)
>>> pr_err("Error setting up the purgatory.\n");
>>>
>>> + goto out;
>>> +
>>> +out_free_fdt:
>>> + kvfree(fdt);
>>
>> Can just use kfree here?
> "fdt" is allocated through kvmalloc(). So it is freed using kvfree.
>
> thanks,
> -lakshmi
>
>>> out:
>>> kfree(modified_cmdline);
>>> kexec_free_elf_info(&elf_info);
>>>
>>> - /*
>>> - * Once FDT buffer has been successfully passed to kexec_add_buffer(),
>>> - * the FDT buffer address is saved in image->arch.fdt. In that case,
>>> - * the memory cannot be freed here in case of any other error.
>>> - */
>>> - if (ret && !image->arch.fdt)
>>> - kvfree(fdt);
>>> -
>>> return ret ? ERR_PTR(ret) : NULL;
>>> }
>>>
>>> --
>>> 2.31.0
next prev parent reply other threads:[~2021-04-21 14:03 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-20 19:03 [PATCH 1/2] powerpc: Free fdt on error in elf64_load() Lakshmi Ramasubramanian
2021-04-20 19:03 ` Lakshmi Ramasubramanian
2021-04-20 19:03 ` Lakshmi Ramasubramanian
2021-04-20 19:03 ` [PATCH 2/2] powerpc: If kexec_build_elf_info() fails return immediately from elf64_load() Lakshmi Ramasubramanian
2021-04-20 19:03 ` Lakshmi Ramasubramanian
2021-04-20 19:03 ` Lakshmi Ramasubramanian
2021-04-21 7:21 ` Michael Ellerman
2021-04-21 7:21 ` Michael Ellerman
2021-04-21 7:21 ` Michael Ellerman
2021-04-21 5:35 ` [PATCH 1/2] powerpc: Free fdt on error in elf64_load() Santosh Sivaraj
2021-04-21 5:35 ` Santosh Sivaraj
2021-04-21 13:58 ` Lakshmi Ramasubramanian
2021-04-21 13:58 ` Lakshmi Ramasubramanian
2021-04-21 14:02 ` Santosh Sivaraj [this message]
2021-04-21 14:02 ` Santosh Sivaraj
2021-04-21 7:18 ` Michael Ellerman
2021-04-21 7:18 ` Michael Ellerman
2021-04-21 7:18 ` Michael Ellerman
2021-04-21 14:01 ` Lakshmi Ramasubramanian
2021-04-21 14:01 ` Lakshmi Ramasubramanian
2021-04-21 14:01 ` Lakshmi Ramasubramanian
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=87pmynybul.fsf@fossix.org \
--to=santosh@fossix.org \
--cc=bauerman@linux.ibm.com \
--cc=dan.carpenter@oracle.com \
--cc=devicetree@vger.kernel.org \
--cc=dja@axtens.net \
--cc=kbuild-all@lists.01.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=lkp@intel.com \
--cc=mpe@ellerman.id.au \
--cc=nramas@linux.microsoft.com \
--cc=robh@kernel.org \
/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.