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

[Thiago Jung Bauermann]

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.

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.

-- 
Thiago Jung Bauermann
IBM Linux Technology Center