linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thiago Jung Bauermann <bauerman@linux.ibm.com>
To: Lakshmi Ramasubramanian <nramas@linux.microsoft.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 22:14:55 -0300	[thread overview]
Message-ID: <875z57akq8.fsf@manicouagan.localdomain> (raw)
In-Reply-To: <f52375a3-c817-25ef-13b2-8b5ee6a528c1@linux.microsoft.com>


Lakshmi Ramasubramanian <nramas@linux.microsoft.com> writes:

> 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")?

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

  reply	other threads:[~2020-12-12  1:22 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
2020-12-12  1:14             ` Thiago Jung Bauermann [this message]
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=875z57akq8.fsf@manicouagan.localdomain \
    --to=bauerman@linux.ibm.com \
    --cc=allison@lohutok.net \
    --cc=balajib@linux.microsoft.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=nramas@linux.microsoft.com \
    --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 \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).