Re: [PATCH v10 2/8] powerpc: Move delete_fdt_mem_rsv() to drivers/of/kexec.c

[Lakshmi Ramasubramanian <nramas@linux.microsoft.com>]

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