From: Chen Zhongjin <chenzhongjin@huawei.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: <linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-arch@vger.kernel.org>, <stable@vger.kernel.org>,
<peterz@infradead.org>, <tglx@linutronix.de>, <namit@vmware.com>,
<gor@linux.ibm.com>, <rdunlap@infradead.org>, <sashal@kernel.org>
Subject: Re: [PATCH 5.10 v3] locking/csd_lock: fix csdlock_debug cause arm64 boot panic
Date: Mon, 9 May 2022 11:14:12 +0800 [thread overview]
Message-ID: <e8715911-f835-059d-27f8-cc5f5ad30a07@huawei.com> (raw)
In-Reply-To: <YnZAO+3Rhj0gwq38@kroah.com>
Hi Greg,
Since the patch:
https://lore.kernel.org/all/20210420093559.23168-1-catalin.marinas@arm.com/
has forced CONFIG_SPARSEMEM_VMEMMAP=y from 5.12, it's not necessary to include
this patch on master.
However this problem still exist on 5.10 stable, so either we can backport the
above patch to 5.10, or independently apply mine.
I'm not sure if backporting one exist patch is better, but that patch only
changed configs without any fix for old builds.
If you have any advice please tell me.
Thanks!
Chen
On 2022/5/7 17:47, Greg KH wrote:
> On Sat, May 07, 2022 at 04:45:10PM +0800, Chen Zhongjin wrote:
>> csdlock_debug is a early_param to enable csd_lock_wait
>> feature.
>>
>> It uses static_branch_enable in early_param which triggers
>> a panic on arm64 with config:
>> CONFIG_SPARSEMEM=y
>> CONFIG_SPARSEMEM_VMEMMAP=n
>>
>> The log shows:
>> Unable to handle kernel NULL pointer dereference at
>> virtual address ", '0' <repeats 16 times>, "
>> ...
>> Call trace:
>> __aarch64_insn_write+0x9c/0x18c
>> ...
>> static_key_enable+0x1c/0x30
>> csdlock_debug+0x4c/0x78
>> do_early_param+0x9c/0xcc
>> parse_args+0x26c/0x3a8
>> parse_early_options+0x34/0x40
>> parse_early_param+0x80/0xa4
>> setup_arch+0x150/0x6c8
>> start_kernel+0x8c/0x720
>> ...
>> Kernel panic - not syncing: Oops: Fatal exception
>>
>> Call trace inside __aarch64_insn_write:
>> __nr_to_section
>> __pfn_to_page
>> phys_to_page
>> patch_map
>> __aarch64_insn_write
>>
>> Here, with CONFIG_SPARSEMEM_VMEMMAP=n, __nr_to_section returns
>> NULL and makes the NULL dereference because mem_section is
>> initialized in sparse_init after parse_early_param stage.
>>
>> So, static_branch_enable shouldn't be used inside early_param.
>> To avoid this, I changed it to __setup and fixed this.
>>
>> Reported-by: Chen jingwen <chenjingwen6@huawei.com>
>> Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
>> ---
>> Change v2 -> v3:
>> Add module name in title
>>
>> Change v1 -> v2:
>> Fix return 1 for __setup
>> ---
>>
>> kernel/smp.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/kernel/smp.c b/kernel/smp.c
>> index 65a630f62363..381eb15cd28f 100644
>> --- a/kernel/smp.c
>> +++ b/kernel/smp.c
>> @@ -174,9 +174,9 @@ static int __init csdlock_debug(char *str)
>> if (val)
>> static_branch_enable(&csdlock_debug_enabled);
>>
>> - return 0;
>> + return 1;
>> }
>> -early_param("csdlock_debug", csdlock_debug);
>> +__setup("csdlock_debug=", csdlock_debug);
>>
>> static DEFINE_PER_CPU(call_single_data_t *, cur_csd);
>> static DEFINE_PER_CPU(smp_call_func_t, cur_csd_func);
>> --
>> 2.17.1
>>
>
>
> <formletter>
>
> This is not the correct way to submit patches for inclusion in the
> stable kernel tree. Please read:
> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> for how to do this properly.
>
> </formletter>
> .
next prev parent reply other threads:[~2022-05-09 3:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-07 8:45 [PATCH 5.10 v3] locking/csd_lock: fix csdlock_debug cause arm64 boot panic Chen Zhongjin
2022-05-07 9:47 ` Greg KH
2022-05-09 3:14 ` Chen Zhongjin [this message]
2022-05-09 10:14 ` Greg KH
2022-05-10 6:32 ` Chen Zhongjin
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=e8715911-f835-059d-27f8-cc5f5ad30a07@huawei.com \
--to=chenzhongjin@huawei.com \
--cc=gor@linux.ibm.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=namit@vmware.com \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.org \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
/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