Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 11 Jul 2023 15:58:23 -0700 (PDT)
Subject:     Re: [PATCH V2] riscv: Add BUG_ON() for no cpu nodes in devicetree
In-Reply-To: <20230630-blasphemy-tapestry-85755d24cbc3@spud>
CC:     suagrfillet@gmail.com, Paul Walmsley <paul.walmsley@sifive.com>,
        aou@eecs.berkeley.edu, Conor Dooley <conor.dooley@microchip.com>,
        ajones@ventanamicro.com, sunilvl@ventanamicro.com,
        heiko.stuebner@vrull.eu, apatel@ventanamicro.com,
        Evan Green <evan@rivosinc.com>, greentime.hu@sifive.com,
        leyfoon.tan@starfivetech.com, linux-riscv@lists.infradead.org,
        linux-kernel@vger.kernel.org
From:   Palmer Dabbelt <palmer@dabbelt.com>
To:     Conor Dooley <conor@kernel.org>
Message-ID: <mhng-e321737a-1406-4d22-b93b-6baa1b900461@palmer-ri-x1c9a>
Mime-Version: 1.0 (MHng)
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On Fri, 30 Jun 2023 11:39:24 PDT (-0700), Conor Dooley wrote:
> On Fri, Jun 30, 2023 at 06:59:38PM +0800, Song Shuai wrote:
>> When only the ACPI tables are passed to kernel, the tiny devictree created
>> by EFI Stub doesn't provide cpu nodes.
>> 
>> While if append the "acpi=off" to kernel cmdline to disable ACPI for kernel
>> the BUG_ON() in of_parse_and_init_cpus() indicates there's no boot cpu
>> found in the devicetree, not there're no cpu nodes in the devicetree.
>> 
>> Add BUG_ON() in the first place of of_parse_and_init_cpus() to make it clear.
>> 
>> Signed-off-by: Song Shuai <suagrfillet@gmail.com>
>
> I'm still not really convinced that this is needed - not finding the
> boot CPU is a strong a hint as any that your DT is completely broken.
> Especially if you intentionally go out of your way to disable ACPI on a
> system that requires it to boot.
>
> I'll leave it up to Palmer or whoever to determine whether this is a
> valuable change. Code change itself much improved though, thanks - I'd
> give an R-b/A-b other than that I question whether there's any value in
> adding another BUG_ON(). You could've kept the part of the comment that
> explained what the error meant though, but that's not a big deal.

IIUC this is just reduntant: if the BUG_ON triggers then there's no 
CPUs, so we'll end up with no iterations of the loop and thus no found 
CPU and thus a BUG_ON.  The only difference is the SBI probing, but 
that's just poking SBI to turn off spinwait.

So I think we already crash sufficiently on systems with an empty DT.  
Sorry if I'm missing something, though?

> Thanks,
> Conor.
>
>> ---
>> Changes since V1:
>> https://lore.kernel.org/linux-riscv/20230629105839.1160895-1-suagrfillet@gmail.com/
>> - revise the commit-msg and move the BUG_ON into of_parse_and_init_cpus() as Conor suggests
>> 
>> ---
>>  arch/riscv/kernel/smpboot.c | 2 ++
>>  1 file changed, 2 insertions(+)
>> 
>> diff --git a/arch/riscv/kernel/smpboot.c b/arch/riscv/kernel/smpboot.c
>> index 6ca2b5309aab..04d33afbdf55 100644
>> --- a/arch/riscv/kernel/smpboot.c
>> +++ b/arch/riscv/kernel/smpboot.c
>> @@ -147,6 +147,8 @@ static void __init of_parse_and_init_cpus(void)
>>  	int cpuid = 1;
>>  	int rc;
>>  
>> +	BUG_ON(!of_get_next_cpu_node(NULL));
>> +
>>  	cpu_set_ops(0);
>>  
>>  	for_each_of_cpu_node(dn) {
>> -- 
>> 2.20.1
>> 
>> 
>> _______________________________________________
>> linux-riscv mailing list
>> linux-riscv@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-riscv