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: <gbjim7wxszmwfvm523bgyfxf5mk5773pafdxnf2wf4mgaebsmz@qfeejv4ilwxv>
Date: Mon, 30 Jun 2025 21:40:28 +0200
From: Uwe Kleine-König <u.kleine-koenig@...libre.com>
To: Thomas Gleixner <tglx@...utronix.de>
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

Hello,

[adding the people involved with scripts/mod to Cc:]

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?

There are a few more candidates:

$ git grep -E '_driver\>\s*[a-z_0-9]*_(ops|probe|console)\>' next/master
next/master:Documentation/driver-api/usb/typec_bus.rst:   :functions: typec_altmode_driver typec_altmode_ops
next/master:drivers/char/virtio_console.c:static struct virtio_driver virtio_console = {
next/master:drivers/clocksource/timer-nxp-stm.c:static struct platform_driver nxp_stm_probe = {
next/master:drivers/irqchip/qcom-irq-combiner.c:static struct platform_driver qcom_irq_combiner_probe = {
next/master:drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c:static struct pci_driver aq_pci_ops = {
next/master:drivers/net/ethernet/dec/tulip/xircom_cb.c:static struct pci_driver xircom_ops = {
next/master:drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c:static struct omap_dss_driver panel_dpi_ops = {
next/master:drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c:static struct omap_dss_driver dsicm_ops = {
next/master:drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c:static struct omap_dss_driver lb035q02_ops = {
next/master:drivers/video/fbdev/omap2/omapfb/displays/panel-nec-nl8048hl11.c:static struct omap_dss_driver nec_8048_ops = {
next/master:drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c:static struct omap_dss_driver sharp_ls_ops = {
next/master:drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c:static struct omap_dss_driver acx565akm_ops = {
next/master:drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c:static struct omap_dss_driver td028ttec1_ops = {
next/master:drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.c:static struct omap_dss_driver tpo_td043_ops = {

I already sent patches for the two networking drivers, we're discussing
the irqchip driver here and the omap2 framebuffer drivers are IMHO false
positives. I didn't look into the virtio_console driver, but I guess
that one is ok, too.

The clocksource driver is a bit more difficult, .probe() must be in
__init because it calls sched_clock_register() but using
platform_driver_probe() might not be easy. Markus currently fights with
a similar clocksource driver where the clocksource depends on an mbox
driver that is only probed later. In his case probing the schedclock
returns -EPROBE_DEFER but when the mbox driver is ready the device
cannot be reprobed again as the schedclock driver is already gone. Of
course the error message for -EPROBE_DEFER is suppressed, because that's
what you do for this type of message. So the machine dies with no
explaining output. We seem to have a yak to shave.

Best regards
Uwe

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ