linux-kernel - Re: [PATCH] irqchip/qcom-irq-combiner: Rename driver struct to end in

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: <877c0smgip.ffs@tglx>
Date: Tue, 01 Jul 2025 11:01:18 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Uwe Kleine-König <u.kleine-koenig@...libre.com>
Cc: Agustin Vega-Frias <agustinv@...eaurora.org>, Marc Zyngier
 <maz@...nel.org>, linux-arm-msm@...r.kernel.org,
 linux-kernel@...r.kernel.org, Markus Schneider-Pargmann
 <msp@...libre.com>, Masahiro Yamada <masahiroy@...nel.org>, Nathan
 Chancellor <nathan@...nel.org>, Nicolas Schier <nicolas.schier@...ux.dev>,
 linux-kbuild@...r.kernel.org
Subject: Re: [PATCH] irqchip/qcom-irq-combiner: Rename driver struct to end
 in _driver

On Mon, Jun 30 2025 at 21:40, Uwe Kleine-König wrote:
> On Mon, Jun 30, 2025 at 08:01:53PM +0200, Thomas Gleixner wrote:
>> On Mon, Jun 30 2025 at 19:23, Uwe Kleine-König wrote:
>> > The modpost section mismatch checks are more lax for objects that have a
>> > name that ends in "_probe". This is not justified here though, so rename
>> 
>> That's a truly bad design or lack of such.
>> 
>> Why can't this muck use foo_driver(name) foo_probe(name) annotations to
>> make it entirely clear what is tested for instead of oracling it out of
>> the name itself. That would make it too easy to understand and analyse.
>
> I don't understand what you're suggesting here. Either I got it wrong or
> it is insufficient because every object is checked, not only the driver
> structs. That would result in more exceptions/special cases than we have
> now.
>
> Anyhow, I agree that depending on the name is unfortunate, maybe we can
> come up with something more clever?

That's what I was referring to. Doing checks based on struct names is a
bad idea. Having distinct '...driver_probe(name)' and ...driver(name)'
macros to distinguish the functionality is the proper thing to do and
way simpler to analyse than names.