lkml.org 
[lkml]   [2020]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v10 2/8] powerpc: Move delete_fdt_mem_rsv() to drivers/of/kexec.c
From
Date
On 12/11/20 10:19 AM, Thiago Jung Bauermann wrote:
>
> Hi Lakshmi,
>
> Lakshmi Ramasubramanian <nramas@linux.microsoft.com> writes:
>
>> On 12/6/20 5:50 PM, Lakshmi Ramasubramanian wrote:
>>
>> Hi Thiago,
>>
>>> On 12/4/20 6:22 PM, Thiago Jung Bauermann wrote
>>>>
>>>> Hello Lakshmi,
>>>>
>>>> Lakshmi Ramasubramanian <nramas@linux.microsoft.com> writes:
>>>>
>>>>> delete_fdt_mem_rsv() retrieves the memory reserve map entry, for
>>>>> the given starting address and size, from the device tree blob, and
>>>>> removes the entry from the device tree blob. This function is called
>>>>> to free the resources reserved for the buffer used for carrying forward
>>>>> the IMA measurement logs on kexec. This function does not have
>>>>> architecture specific code, but is currently limited to powerpc.
>>>>>
>>>>> Move delete_fdt_mem_rsv() to "drivers/of/kexec_fdt.c" so that it is
>>>>
>>>> s/kexec_fdt.c/kexec.c/
>>> Missed that in the patch description. Will fix it. Thanks.
>>>
>>>>> accessible for other architectures as well.
>>>>>
>>>>> Co-developed-by: Prakhar Srivastava <prsriva@linux.microsoft.com>
>>>>> Signed-off-by: Prakhar Srivastava <prsriva@linux.microsoft.com>
>>>>> Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
>>>>> ---
>>>>> arch/powerpc/include/asm/kexec.h | 1 -
>>>>> arch/powerpc/kexec/file_load.c | 32 -----------------
>>>>> drivers/of/Makefile | 1 +
>>>>> drivers/of/kexec.c | 61 ++++++++++++++++++++++++++++++++
>>>>> include/linux/kexec.h | 5 +++
>>>>> 5 files changed, 67 insertions(+), 33 deletions(-)
>>>>> create mode 100644 drivers/of/kexec.c
>>>>>
>>>>> diff --git a/arch/powerpc/include/asm/kexec.h
>>>>> b/arch/powerpc/include/asm/kexec.h
>>>>> index 55d6ede30c19..7c223031ecdd 100644
>>>>> --- a/arch/powerpc/include/asm/kexec.h
>>>>> +++ b/arch/powerpc/include/asm/kexec.h
>>>>> @@ -126,7 +126,6 @@ int setup_purgatory(struct kimage *image, const void
>>>>> *slave_code,
>>>>> int setup_new_fdt(const struct kimage *image, void *fdt,
>>>>> unsigned long initrd_load_addr, unsigned long initrd_len,
>>>>> const char *cmdline);
>>>>> -int delete_fdt_mem_rsv(void *fdt, unsigned long start, unsigned long size);
>>>>> #ifdef CONFIG_PPC64
>>>>> struct kexec_buf;
>>>>> diff --git a/arch/powerpc/kexec/file_load.c b/arch/powerpc/kexec/file_load.c
>>>>> index 9a232bc36c8f..9efc98b1e2ae 100644
>>>>> --- a/arch/powerpc/kexec/file_load.c
>>>>> +++ b/arch/powerpc/kexec/file_load.c
>>>>> @@ -109,38 +109,6 @@ int setup_purgatory(struct kimage *image, const void
>>>>> *slave_code,
>>>>> return 0;
>>>>> }
>>>>> -/**
>>>>> - * delete_fdt_mem_rsv - delete memory reservation with given address and
>>>>> size
>>>>> - *
>>>>> - * Return: 0 on success, or negative errno on error.
>>>>> - */
>>>>> -int delete_fdt_mem_rsv(void *fdt, unsigned long start, unsigned long size)
>>>>> -{
>>>>> - int i, ret, num_rsvs = fdt_num_mem_rsv(fdt);
>>>>> -
>>>>> - for (i = 0; i < num_rsvs; i++) {
>>>>> - uint64_t rsv_start, rsv_size;
>>>>> -
>>>>> - ret = fdt_get_mem_rsv(fdt, i, &rsv_start, &rsv_size);
>>>>> - if (ret) {
>>>>> - pr_err("Malformed device tree.\n");
>>>>> - return -EINVAL;
>>>>> - }
>>>>> -
>>>>> - if (rsv_start == start && rsv_size == size) {
>>>>> - ret = fdt_del_mem_rsv(fdt, i);
>>>>> - if (ret) {
>>>>> - pr_err("Error deleting device tree reservation.\n");
>>>>> - return -EINVAL;
>>>>> - }
>>>>> -
>>>>> - return 0;
>>>>> - }
>>>>> - }
>>>>> -
>>>>> - return -ENOENT;
>>>>> -}
>>>>> -
>>>>> /*
>>>>> * setup_new_fdt - modify /chosen and memory reservation for the next
>>>>> kernel
>>>>> * @image: kexec image being loaded.
>>>>> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
>>>>> index 6e1e5212f058..77d24712c0c8 100644
>>>>> --- a/drivers/of/Makefile
>>>>> +++ b/drivers/of/Makefile
>>>>> @@ -13,5 +13,6 @@ obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
>>>>> obj-$(CONFIG_OF_RESOLVE) += resolver.o
>>>>> obj-$(CONFIG_OF_OVERLAY) += overlay.o
>>>>> obj-$(CONFIG_OF_NUMA) += of_numa.o
>>>>> +obj-$(CONFIG_OF_FLATTREE) += kexec.o
>>>>
>>>> Isn't this too broad? kexec.o will only be useful to kernel configs
>>>> which enable CONFIG_KEXEC_FILE, so perhaps do:
>>>>
>>>> ifdef CONFIG_OF_FLATTREE
>>>> ifdef CONFIG_KEXEC_FILE
>>>> obj-y += kexec.o
>>>> endif
>>>> endif
>>>>
>>>> What do you think?
>>> Per Rob's feedback on v9 patch set, I have moved all the architecture
>>> independent ima kexec functions to a single file "drivers/of/kexec.c"
>>> Since these functions are enabled on different kernel CONFIGs, I have
>>> used IS_ENABLED(CONFIG_XYZ) macro instead of "#ifdef" in the C file to
>>> conditionally compile.
>> Per Rob's feedback on the v9 patch, I'll keep the ima kexec functions in a
>> single file (in "drivers/of/kexec.c") and use IS_ENABLED() macro to handle the
>> function calls.
>>
>> I'll make the other changes you'd suggested on v10 patches and will post v11
>> patch set shortly.
>
>>From a cursory look at the use of functions in this file, I got the
> impression that there wouldn't be any reference to them in kernel
> configs that didn't have CONFIG_KEXEC_FILE enabled, which is why I
> suggested the change above. I think you can make it without any other
> changes to the code.
>
> I could be wrong though, and there could be some config which tried to
> use some of these functions even when CONFIG_KEXEC_FILE is disabled. In
> that case, the customary way to resolve it is to provide static inline
> stub versions in a header file (not in a .c file) of just those
> functions that are needed.
>
> The reason why placing stub functions in header files is better is that
> then the compiler has visibility of the dummy function when compiling
> the source file which uses the function, and is able to eliminate the
> dead code that arises from the function always returning one value.

I agree with you Thiago.

Is there a way to keep all the relevant functions in a single C file,
not use "#ifdef" in C file, and follow the coding pattern you've
described above (i mean, "defining a stub function in a header file when
the config conditions are not met")?

>
> Using IS_ENABLED() to do an early return as the first operation in the
> function in a separate .c file means that the compiler doesn't know
> anything and has to put a jump to the dummy function (only to
> immediately return), and retain the code that deals with the possibility
> of different values being returned.
>
> It's not a big deal in this case because none of these functions is in a
> hot path, but it does make the kernel text a tiny bit bigger than
> necessary.
>

I agree.

thanks,
-lakshmi


\
 
 \ /
  Last update: 2020-12-11 20:27    [W:0.073 / U:0.564 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site