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]
Date:   Tue, 26 Sep 2023 11:27:49 -0500
From:   Lijun Pan <lijun.pan@...el.com>
To:     Fenghua Yu <fenghua.yu@...el.com>, Vinod Koul <vkoul@...nel.org>,
        "Dave Jiang" <dave.jiang@...el.com>
CC:     <dmaengine@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Michael Prinke <michael.prinke@...el.com>
Subject: Re: [PATCH] dmaengine: idxd: Register dsa_bus_type before registering
 idxd sub-drivers



On 9/24/2023 11:22 AM, Fenghua Yu wrote:
> idxd sub-drivers belong to bus dsa_bus_type. Thus, dsa_bus_type must be
> registered in dsa bus init before idxd drivers can be registered.
> 
> But the order is wrong when both idxd and idxd_bus are builtin drivers.
> In this case, idxd driver is compiled and linked before idxd_bus driver.
> Since the initcall order is determined by the link order, idxd sub-drivers
> are registered in idxd initcall before dsa_bus_type is registered
> in idxd_bus initcall. idxd initcall fails:
> 
> [   21.562803] calling  idxd_init_module+0x0/0x110 @ 1
> [   21.570761] Driver 'idxd' was unable to register with bus_type 'dsa' because the bus was not initialized.
> [   21.586475] initcall idxd_init_module+0x0/0x110 returned -22 after 15717 usecs
> [   21.597178] calling  dsa_bus_init+0x0/0x20 @ 1
> 
> To fix the issue, compile and link idxd_bus driver before idxd driver
> to ensure the right registration order.
> 
> Fixes: d9e5481fca74 ("dmaengine: dsa: move dsa_bus_type out of idxd driver to standalone")
> Reported-by: Michael Prinke <michael.prinke@...el.com>
> Signed-off-by: Fenghua Yu <fenghua.yu@...el.com>
> ---

I guess it was always configured as CONFIG_INTEL_IDXD=m.
Good catch on =y scenario.

Reviewed-by: Lijun Pan <lijun.pan@...el.com>
Tested-by: Lijun Pan <lijun.pan@...el.com>


>   drivers/dma/idxd/Makefile | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/dma/idxd/Makefile b/drivers/dma/idxd/Makefile
> index dc096839ac63..c5e679070e46 100644
> --- a/drivers/dma/idxd/Makefile
> +++ b/drivers/dma/idxd/Makefile
> @@ -1,12 +1,12 @@
>   ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE=IDXD
>   
> +obj-$(CONFIG_INTEL_IDXD_BUS) += idxd_bus.o
> +idxd_bus-y := bus.o
> +
>   obj-$(CONFIG_INTEL_IDXD) += idxd.o
>   idxd-y := init.o irq.o device.o sysfs.o submit.o dma.o cdev.o debugfs.o
>   
>   idxd-$(CONFIG_INTEL_IDXD_PERFMON) += perfmon.o
>   
> -obj-$(CONFIG_INTEL_IDXD_BUS) += idxd_bus.o
> -idxd_bus-y := bus.o
> -
>   obj-$(CONFIG_INTEL_IDXD_COMPAT) += idxd_compat.o
>   idxd_compat-y := compat.o

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ