From: Yunfeng Ye <yeyunfeng@huawei.com>
To: Will Deacon <will@kernel.org>
Cc: <catalin.marinas@arm.com>, <will.deacon@arm.com>,
<kstewart@linuxfoundation.org>, <gregkh@linuxfoundation.org>,
<tglx@linutronix.de>, <info@metux.net>,
<linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2] arm64: armv8_deprecated: Checking return value for memory allocation
Date: Tue, 8 Oct 2019 10:33:17 +0800 [thread overview]
Message-ID: <e58c36f6-23e3-12b2-bd9c-1ef731b5f8fd@huawei.com> (raw)
In-Reply-To: <20191007153710.7xpx27kgeewz75kt@willie-the-truck>
On 2019/10/7 23:37, Will Deacon wrote:
> On Mon, Oct 07, 2019 at 06:06:35PM +0800, Yunfeng Ye wrote:
>> There are no return value checking when using kzalloc() and kcalloc() for
>> memory allocation. so add it.
>>
>> Signed-off-by: Yunfeng Ye <yeyunfeng@huawei.com>
>> ---
>> v1 -> v2:
>> - return error code when memory allocation failure
>>
>> arch/arm64/kernel/armv8_deprecated.c | 57 +++++++++++++++++++++++++++---------
>> 1 file changed, 43 insertions(+), 14 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/armv8_deprecated.c b/arch/arm64/kernel/armv8_deprecated.c
>> index 2ec09de..2284fcb 100644
>> --- a/arch/arm64/kernel/armv8_deprecated.c
>> +++ b/arch/arm64/kernel/armv8_deprecated.c
>> @@ -168,12 +168,15 @@ static int update_insn_emulation_mode(struct insn_emulation *insn,
>> return ret;
>> }
>>
>> -static void __init register_insn_emulation(struct insn_emulation_ops *ops)
>> +static int __init register_insn_emulation(struct insn_emulation_ops *ops)
>> {
>> unsigned long flags;
>> struct insn_emulation *insn;
>>
>> insn = kzalloc(sizeof(*insn), GFP_KERNEL);
>> + if (!insn)
>> + return -ENOMEM;
>> +
>> insn->ops = ops;
>> insn->min = INSN_UNDEF;
>>
>> @@ -197,6 +200,7 @@ static void __init register_insn_emulation(struct insn_emulation_ops *ops)
>>
>> /* Register any handlers if required */
>> update_insn_emulation_mode(insn, INSN_UNDEF);
>> + return 0;
>> }
>>
>> static int emulation_proc_handler(struct ctl_table *table, int write,
>> @@ -224,7 +228,7 @@ static int emulation_proc_handler(struct ctl_table *table, int write,
>> return ret;
>> }
>>
>> -static void __init register_insn_emulation_sysctl(void)
>> +static int __init register_insn_emulation_sysctl(void)
>> {
>> unsigned long flags;
>> int i = 0;
>> @@ -233,6 +237,8 @@ static void __init register_insn_emulation_sysctl(void)
>>
>> insns_sysctl = kcalloc(nr_insn_emulated + 1, sizeof(*sysctl),
>> GFP_KERNEL);
>> + if (!insns_sysctl)
>> + return -ENOMEM;
>>
>> raw_spin_lock_irqsave(&insn_emulation_lock, flags);
>> list_for_each_entry(insn, &insn_emulation, node) {
>> @@ -251,6 +257,7 @@ static void __init register_insn_emulation_sysctl(void)
>> raw_spin_unlock_irqrestore(&insn_emulation_lock, flags);
>>
>> register_sysctl("abi", insns_sysctl);
>> + return 0;
>> }
>>
>> /*
>> @@ -617,25 +624,47 @@ static int t16_setend_handler(struct pt_regs *regs, u32 instr)
>> */
>> static int __init armv8_deprecated_init(void)
>> {
>> - if (IS_ENABLED(CONFIG_SWP_EMULATION))
>> - register_insn_emulation(&swp_ops);
>> + int ret = 0;
>> + int err = 0;
>> +
>> + if (IS_ENABLED(CONFIG_SWP_EMULATION)) {
>> + ret = register_insn_emulation(&swp_ops);
>> + if (ret) {
>> + pr_err("register insn emulation swp: fail\n");
>> + err = ret;
>> + }
>> + }
>
> Is there much point in continuing here? May as well just return ret, I
> think. I also don't think you need to print anything, since kmalloc
> should already have shouted.
>
The registration of each instruction simulation is independent. I think
that one failure does not affect the registration of other instructions.
In addition, if return directly, is it need to unregister? Of course,
the first instruction registration can be directly returned, If the
following instruction registration fails, is it need unregister operation?
currently the unregistration of instruction simulation is not be implemented
yet.
The purpose of printing information is to replace the direct return, which
can distinguish which instruction failed to register. There is no need to print
information if it returns directly.
thanks.
>> - if (IS_ENABLED(CONFIG_CP15_BARRIER_EMULATION))
>> - register_insn_emulation(&cp15_barrier_ops);
>> + if (IS_ENABLED(CONFIG_CP15_BARRIER_EMULATION)) {
>> + ret = register_insn_emulation(&cp15_barrier_ops);
>> + if (ret) {
>> + pr_err("register insn emulation cpu15_barrier: fail\n");
>> + err = ret;
>> + }
>> + }
>>
>> if (IS_ENABLED(CONFIG_SETEND_EMULATION)) {
>> - if(system_supports_mixed_endian_el0())
>> - register_insn_emulation(&setend_ops);
>> - else
>> + if (system_supports_mixed_endian_el0()) {
>> + ret = register_insn_emulation(&setend_ops);
>> + if (ret) {
>> + pr_err("register insn emulation setend: fail\n");
>> + err = ret;
>> + }
>> + } else {
>> pr_info("setend instruction emulation is not supported on this system\n");
>> + }
>> }
>>
>> - cpuhp_setup_state_nocalls(CPUHP_AP_ARM64_ISNDEP_STARTING,
>> - "arm64/isndep:starting",
>> - run_all_insn_set_hw_mode, NULL);
>> - register_insn_emulation_sysctl();
>> + if (nr_insn_emulated) {
>> + cpuhp_setup_state_nocalls(CPUHP_AP_ARM64_ISNDEP_STARTING,
>> + "arm64/isndep:starting",
>> + run_all_insn_set_hw_mode, NULL);
>> + ret = register_insn_emulation_sysctl();
>> + if (ret)
>> + err = ret;
>> + }
>
> I'm dubious about leaving the cpuhp notifier registered if we fail here.
> Can we simply reorder the logic so that the notifier is registered after
> successfully calling register_insn_emulation_sysctl()? thanks.
>
ok, I will reorder the logic.
And the same question: is it need to unregister the instruction emulation
if register_insn_emulation_sysctl() invoked fail?
> Will
>
> .
>
next prev parent reply other threads:[~2019-10-08 2:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-07 10:06 Yunfeng Ye
2019-10-07 15:37 ` Will Deacon
2019-10-08 2:33 ` Yunfeng Ye [this message]
2019-10-08 10:25 ` Will Deacon
2019-10-08 11:01 ` Yunfeng Ye
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=e58c36f6-23e3-12b2-bd9c-1ef731b5f8fd@huawei.com \
--to=yeyunfeng@huawei.com \
--cc=catalin.marinas@arm.com \
--cc=gregkh@linuxfoundation.org \
--cc=info@metux.net \
--cc=kstewart@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=will.deacon@arm.com \
--cc=will@kernel.org \
/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
all inboxes | Powered by JetHome®