linux-kernel - Re: Looking for help with Kconfig dependencies

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: <YNJ3EBDSbqfT/sAk@google.com>
Date:   Tue, 22 Jun 2021 16:49:36 -0700
From:   Matthias Kaehlcke <mka@...omium.org>
To:     Masahiro Yamada <masahiroy@...nel.org>
Cc:     Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Douglas Anderson <dianders@...omium.org>
Subject: Re: Looking for help with Kconfig dependencies

On Mon, Jun 21, 2021 at 07:55:30AM -0700, Matthias Kaehlcke wrote:
> On Sat, Jun 19, 2021 at 10:30:22AM +0900, Masahiro Yamada wrote:
> > On Sat, Jun 19, 2021 at 2:05 AM Matthias Kaehlcke <mka@...omium.org> wrote:
> > >
> > > Hi,
> > >
> > > I'm adding a new driver and have an issue with Kconfig dependencies
> > > that I coulnd't sort out so far.
> > >
> > > Patch https://lore.kernel.org/patchwork/patch/1444212/ adds the new
> > > onboard_usb_hub driver which exports two functions,
> > > onboard_hub_create_pdevs() and onboard_hub_destroy_pdevs(). It also
> > > provides stubs for these functions which are used when the driver
> > > is not selected (CONFIG_USB_ONBOARD_HUB=n).
> > >
> > > The new exported functions are called by the xhci-plat driver
> > > (https://lore.kernel.org/patchwork/patch/1444215/). Since xhci-plat
> > > now depends on symbols from the onboard_hub_driver the following
> > > dependency was added to its Kconfig entry:
> > >
> > >   config USB_XHCI_PLATFORM
> > >     tristate "Generic xHCI driver for a platform device"
> > >     select USB_XHCI_RCAR if ARCH_RENESAS
> > >  +  depends on USB_ONBOARD_HUB || !USB_ONBOARD_HUB
> > >
> > > This generally seems to work, however when USB_XHCI_PLATFORM is
> > > forced to be builtin by another driver that depends on it (e.g.
> > > USB_DWC3) it is still possible to build the onboard_hub driver
> > > as a module, which results in unresolved symbols:
> > >
> > > aarch64-linux-gnu-ld: drivers/usb/host/xhci-plat.o: in function
> > > `xhci_plat_remove':
> > > drivers/usb/host/xhci-plat.c:427: undefined reference to
> > > `onboard_hub_destroy_pdevs'
> > > drivers/usb/host/xhci-plat.c:427:(.text+0x82c): relocation truncated
> > > to fit: R_AARCH64_CALL26 against undefined symbol
> > > `onboard_hub_destroy_pdevs'
> > > aarch64-linux-gnu-ld: drivers/usb/host/xhci-plat.o: in function
> > > `xhci_plat_probe':
> > > drivers/usb/host/xhci-plat.c:379: undefined reference to
> > > `onboard_hub_create_pdevs'
> > > drivers/usb/host/xhci-plat.c:379:(.text+0x131c): relocation truncated
> > > to fit: R_AARCH64_CALL26 against undefined symbol
> > > `onboard_hub_create_pdevs'
> > >
> > > Kconfig generates the following warning with this configuration:
> > >
> > > WARNING: unmet direct dependencies detected for USB_XHCI_PLATFORM
> > >   Depends on [m]: USB_SUPPORT [=y] && USB [=y] && USB_XHCI_HCD [=y] && (USB_ONBOARD_HUB [=m] || !USB_ONBOARD_HUB [=m])
> > >   Selected by [y]:
> > >   - USB_DWC3 [=y] && USB_SUPPORT [=y] && (USB [=y] || USB_GADGET [=y]) && HAS_DMA [=y] && USB_XHCI_HCD [=y]
> > >   Selected by [m]:
> > >   - USB_CDNS_SUPPORT [=m] && USB_SUPPORT [=y] && (USB [=y] || USB_GADGET [=y]) && HAS_DMA [=y] && USB_XHCI_HCD [=y]
> > >   - USB_BRCMSTB [=m] && USB_SUPPORT [=y] && USB [=y] && (ARCH_BRCMSTB [=y] && PHY_BRCM_USB [=m] || COMPILE_TEST [=y]) && USB_XHCI_HCD [=y]
> > >   - USB_XHCI_MVEBU [=m] && USB_SUPPORT [=y] && USB [=y] && USB_XHCI_HCD [=y] && HAS_IOMEM [=y] && (ARCH_MVEBU [=y] || COMPILE_TEST [=y])
> > >
> > > I read through kconfig-language.rst and experimented a fair bit,
> > > but haven't found a working solution. Any advice would be
> > > appreciated.
> > >
> > > Thanks
> > >
> > > Matthias
> > 
> > 
> > 
> > This issue should be discussed in the USB ML,
> 
> That's where it was initially brought up, but it didn't get the attention
> of anyone in the position to give advice. Since the issue is more about
> kbuild dependencies than USB specifically I brought it up here. The driver
> already landed in the USB tree but was reverted due to this issue, I'm
> stuck on this problem and really don't want the driver to die on the
> finish line.
> 
> A workaround could be to make the driver 'bool' rather than 'tristate',
> but I'm not sure if that would be acceptable.
> 
> > but probably 'depends on USB_XHCI_PLATFORM' should be used everywhere instead of
> > 'depends on USB_XHCI_PLATFORM'.
> 
> Did you mean 'select USB_XHCI_PLATFORM' rather than 'depends on
> USB_XHCI_PLATFORM'? In general that sounds reasonable, since the drivers don't
> actually depend on USB_XHCI_PLATFORM from a build perspective, and it's what
> some drivers actually do. However it doesn't fix the problem, apparently a
> 'select X' from CONFIG_Y still results in CONFIG_X being 'y' if CONFIG_Y is
> 'y' (see the USB_DWC3 case above).

After some more experimentation it looks like the opposite fixes the conflict,
i.e. changing all instances of 'select USB_XHCI_PLATFORM' to 'depends on
USB_XHCI_PLATFORM'.

That's also in line with the recommendation to limit the use of 'select' to
certain use cases:

  select should be used with care. select will force a symbol to a value without
  visiting the dependencies. By abusing select you are able to select a symbol
  FOO even if FOO depends on BAR that is not set. In general use select only
  for non-visible symbols (no prompts anywhere) and for symbols with no
  dependencies. That will limit the usefulness but on the other hand avoid the
  illegal configurations all over.

  https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html