linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
To: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Cc: zohar@linux.ibm.com, robh@kernel.org, gregkh@linuxfoundation.org,
	james.morse@arm.com, catalin.marinas@arm.com, sashal@kernel.org,
	will@kernel.org, mpe@ellerman.id.au, benh@kernel.crashing.org,
	paulus@samba.org, robh+dt@kernel.org, frowand.list@gmail.com,
	vincenzo.frascino@arm.com, mark.rutland@arm.com,
	dmitry.kasatkin@gmail.com, jmorris@namei.org, serge@hallyn.com,
	pasha.tatashin@soleen.com, allison@lohutok.net,
	kstewart@linuxfoundation.org, takahiro.akashi@linaro.org,
	tglx@linutronix.de, masahiroy@kernel.org, bhsharma@redhat.com,
	mbrugger@suse.com, hsinyi@chromium.org, tao.li@vivo.com,
	christophe.leroy@c-s.fr, linux-integrity@vger.kernel.org,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	prsriva@linux.microsoft.com, balajib@linux.microsoft.com
Subject: Re: [PATCH v10 2/8] powerpc: Move delete_fdt_mem_rsv() to drivers/of/kexec.c
Date: Fri, 11 Dec 2020 11:25:18 -0800	[thread overview]
Message-ID: <f52375a3-c817-25ef-13b2-8b5ee6a528c1@linux.microsoft.com> (raw)
In-Reply-To: <878sa49pdv.fsf@manicouagan.localdomain>

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



  reply	other threads:[~2020-12-11 21:00 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-04 19:51 [PATCH v10 0/8] Carry forward IMA measurement log on kexec on ARM64 Lakshmi Ramasubramanian
2020-12-04 19:51 ` [PATCH v10 1/8] powerpc: fix compiler warnings and errors Lakshmi Ramasubramanian
2020-12-05  1:20   ` Thiago Jung Bauermann
2020-12-04 19:51 ` [PATCH v10 2/8] powerpc: Move delete_fdt_mem_rsv() to drivers/of/kexec.c Lakshmi Ramasubramanian
2020-12-05  2:22   ` Thiago Jung Bauermann
2020-12-07  1:50     ` Lakshmi Ramasubramanian
2020-12-11 16:37       ` Lakshmi Ramasubramanian
2020-12-11 18:19         ` Thiago Jung Bauermann
2020-12-11 19:25           ` Lakshmi Ramasubramanian [this message]
2020-12-12  1:14             ` Thiago Jung Bauermann
2020-12-04 19:51 ` [PATCH v10 3/8] powerpc: Move ima buffer functions " Lakshmi Ramasubramanian
2020-12-05 19:48   ` Thiago Jung Bauermann
2020-12-07  1:53     ` Lakshmi Ramasubramanian
2020-12-04 19:51 ` [PATCH v10 4/8] powerpc: Use ima kexec node functions Lakshmi Ramasubramanian
2020-12-05 19:51   ` Thiago Jung Bauermann
2020-12-07  1:54     ` Lakshmi Ramasubramanian
2020-12-04 19:51 ` [PATCH v10 5/8] powerpc: Move remove_ima_buffer() to drivers/of/kexec.c Lakshmi Ramasubramanian
2020-12-05 20:14   ` Thiago Jung Bauermann
2020-12-07  1:57     ` Lakshmi Ramasubramanian
2020-12-04 19:51 ` [PATCH v10 6/8] powerpc: Move ima_get_kexec_buffer() and ima_free_kexec_buffer() to ima Lakshmi Ramasubramanian
2020-12-05 21:02   ` Thiago Jung Bauermann
2020-12-07  1:58     ` Lakshmi Ramasubramanian
2020-12-04 19:51 ` [PATCH v10 7/8] powerpc: Move arch_ima_add_kexec_buffer " Lakshmi Ramasubramanian
2020-12-05 21:36   ` Thiago Jung Bauermann
2020-12-07  2:03     ` Lakshmi Ramasubramanian
2020-12-07 14:57       ` Mimi Zohar
2020-12-04 19:51 ` [PATCH v10 8/8] arm64: Add IMA log information in kimage used for kexec Lakshmi Ramasubramanian
2020-12-05 21:44   ` Thiago Jung Bauermann
2020-12-07  2:05     ` 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=f52375a3-c817-25ef-13b2-8b5ee6a528c1@linux.microsoft.com \
    --to=nramas@linux.microsoft.com \
    --cc=allison@lohutok.net \
    --cc=balajib@linux.microsoft.com \
    --cc=bauerman@linux.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=bhsharma@redhat.com \
    --cc=catalin.marinas@arm.com \
    --cc=christophe.leroy@c-s.fr \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=frowand.list@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hsinyi@chromium.org \
    --cc=james.morse@arm.com \
    --cc=jmorris@namei.org \
    --cc=kstewart@linuxfoundation.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=masahiroy@kernel.org \
    --cc=mbrugger@suse.com \
    --cc=mpe@ellerman.id.au \
    --cc=pasha.tatashin@soleen.com \
    --cc=paulus@samba.org \
    --cc=prsriva@linux.microsoft.com \
    --cc=robh+dt@kernel.org \
    --cc=robh@kernel.org \
    --cc=sashal@kernel.org \
    --cc=serge@hallyn.com \
    --cc=takahiro.akashi@linaro.org \
    --cc=tao.li@vivo.com \
    --cc=tglx@linutronix.de \
    --cc=vincenzo.frascino@arm.com \
    --cc=will@kernel.org \
    --cc=zohar@linux.ibm.com \
    --subject='Re: [PATCH v10 2/8] powerpc: Move delete_fdt_mem_rsv() to drivers/of/kexec.c' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).