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] [day] [month] [year] [list]

Message-Id: <804B47DC-1A68-4219-8411-B3F7AF1B2D97@jrtc27.com>
Date: Tue, 6 Aug 2024 04:14:40 +0100
From: Jessica Clarke <jrtc27@...c27.com>
To: Vincent Chen <vincent.chen@...ive.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
 Anup Patel <anup@...infault.org>,
 Paul Walmsley <paul.walmsley@...ive.com>,
 Palmer Dabbelt <palmer@...belt.com>,
 Albert Ou <aou@...s.berkeley.edu>,
 LKML <linux-kernel@...r.kernel.org>,
 linux-riscv <linux-riscv@...ts.infradead.org>
Subject: Re: [PATCH] irqchip: let the probe of APLIC be earlier than IMSIC

On 6 Aug 2024, at 02:56, Vincent Chen <vincent.chen@...ive.com> wrote:
> 
> On Mon, Aug 5, 2024 at 4:08 PM Thomas Gleixner <tglx@...utronix.de> wrote:
>> 
>> 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?
>> 
> 
> Hi Thomas,
> I understand now. I didn't realize that the linker could freely
> reorganize this section. This patch won’t actually adjust the probe
> order. Thank you very much for the explanation

Also FYI your patch subject is backwards, which initially confused me.

Jess