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: <CABvJ_xhMAU+Ft-Ut2hMapO9dCSkz4M2PqxvdCrJS6eaSz02hLQ@mail.gmail.com>
Date: Tue, 6 Aug 2024 09:56:53 +0800
From: Vincent Chen <vincent.chen@...ive.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Anup Patel <anup@...infault.org>, 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 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

Regards,
Vincent

> Thanks,
>
>         tglx