linux-kernel - Re: [PATCH] irqchip: let the probe of APLIC be earlier than IMSIC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87sevj5r45.ffs@tglx>
Date: Mon, 05 Aug 2024 10:08:26 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Vincent Chen <vincent.chen@...ive.com>, Anup Patel <anup@...infault.org>
Cc: paul.walmsley@...ive.com, palmer@...belt.com, aou@...s.berkeley.edu,
 linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org
Subject: Re: [PATCH] irqchip: let the probe of APLIC be earlier than IMSIC

On Mon, Aug 05 2024 at 10:43, Vincent Chen wrote:
> On Fri, Aug 2, 2024 at 7:03 PM Anup Patel <anup@...infault.org> wrote:
>> Secondly, changing compilation order in Makefile to influence
>> the probe order will not help in any way.
>>
> I was confused here. If possible, hope you can help me clarify it.
> The following is the backtrace of really_porbe() dumped by GDB.
> #0  0xffffffff8092318a in really_probe ()
> #1  0xffffffff80923516 in __driver_probe_device.part.0 ()
> #2  0xffffffff8057c856 in driver_probe_device ()
> #3  0xffffffff8057c9ba in __driver_attach ()
> #4  0xffffffff8057aaa4 in bus_for_each_dev ()
> #5  0xffffffff8057c3ea in driver_attach ()
> #6  0xffffffff8057bc4a in bus_add_driver ()
> #7  0xffffffff8057d75a in driver_register ()
> #8  0xffffffff8057e83c in __platform_driver_register ()
> #9  0xffffffff80a2455e in imsic_platform_driver_init ()
> #10 0xffffffff8000212c in do_one_initcall ()
> #11 0xffffffff80a01188 in kernel_init_freeable ()
> #12 0xffffffff80928d80 in kernel_init ()
>
> According to this result, the source to call really_probe is
> do_one_initcall(), regardless of whether it is APLIC or IMSIC. The
> do_one_initcall() function follows the placed order of the
> initialization functions in the __initcall6 section to invoke them.
> The compile order determines the order of the __initcall6 section.
> Therefore, I try to adjust the compile order to influence the probe
> order between IMSIC and APLIC. Do I misunderstand something?

There is no guarantee that this order is retained. The linker can freely
reorg the section. That's why we have deferred probing. It's neither a
bug nor a problem, so what are you trying to solve?

Thanks,

        tglx