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

[Thiago Jung Bauermann]

Lakshmi Ramasubramanian <nramas@xxxxxxxxxxxxxxxxxxx> writes:

> On 12/11/20 10:19 AM, Thiago Jung Bauermann wrote:
>> Hi Lakshmi,
>> Lakshmi Ramasubramanian <nramas@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx>
>>>>>> Signed-off-by: Prakhar Srivastava <prsriva@xxxxxxxxxxxxxxxxxxx>
>>>>>> Signed-off-by: Lakshmi Ramasubramanian <nramas@xxxxxxxxxxxxxxxxxxx>
>>>>>> ---
>>>>>>    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")?

Like I said above, my impression is that you don't need any ifdefs since
my understanding is that all funcitons in the C file are only used when
CONFIG_KEXEC_FILE is set. Do you anticipate (or have found) problems
with that?

-- 
Thiago Jung Bauermann
IBM Linux Technology Center