linux-kernel - Re: [PATCH RESEND v11 10/13] um: nommu: a work around for MMU dependency to PCI driver

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: <m25xde80qh.wl-thehajime@gmail.com>
Date: Sat, 20 Sep 2025 08:46:14 +0900
From: Hajime Tazaki <thehajime@...il.com>
To: johannes@...solutions.net
Cc: linux-um@...ts.infradead.org,
	ricarkol@...gle.com,
	Liam.Howlett@...cle.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH RESEND v11 10/13] um: nommu: a work around for MMU dependency to PCI driver


thanks Johannes, I think I got a clearer view than before.

I guess Kconfig does the right thing.
And Kunit does the right too but an additional job which Kunit does
prevents run tests w/ !MMU.

> >  CONIFG_MMU=n
> > 
> > via --kconfig_add CONFIG_MMU=n.
> 
> Sure. But that should disable CONFIG_UML_PCI_OVER_VIRTIO, and it doesn't
> now.

Kconfig (via kunit.py config) disables CONFIG_UML_PCI_OVER_VIRTIO
correctly.

But after that, Kunit does the additional job, validate_config() (in
kunit_kernel.py), which checks the configs (arch_uml.config +
--kconfig_add) is a subset of the final result of .config.

When I applied a patch below:

diff --git a/arch/um/drivers/Kconfig b/arch/um/drivers/Kconfig
index 6a0354ca032f..04025207a077 100644
--- a/arch/um/drivers/Kconfig
+++ b/arch/um/drivers/Kconfig
@@ -159,6 +159,7 @@ config UML_RTC
 
 config UML_PCI
        bool
+       depends on MMU
        select FORCE_PCI
        select IRQ_MSI_LIB
        select UML_IOMEM_EMULATION
@@ -170,6 +171,7 @@ config UML_PCI_OVER_VIRTIO
        bool "Enable PCI over VIRTIO device simulation"
        # in theory, just VIRTIO is enough, but that causes recursion
        depends on VIRTIO_UML
+       depends on MMU
        select UML_PCI

and do
  ./tools/testing/kunit/kunit.py config  --kconfig_add CONFIG_MMU=n

the validation currently gives the following error:

 ERROR:root:Not all Kconfig options selected in kunitconfig were in the generated .config.
 This is probably due to unsatisfied dependencies.
 Missing: CONFIG_UML_PCI_OVER_VIRTIO=y
 Note: many Kconfig options aren't available on UML. You can try
 running on a different architecture with something like
 "--arch=x86_64".

so, if I give an additional --kconfig_add CONFIG_UML_PCI_OVER_VIRTIO=n
to the command line, the validation passes, because the configs
(arch_uml.config + --kconfig_add) becomes the subset of the final
result.

what I can handle this would be either of them:

1) use --kconfig_add CONFIG_UML_PCI_OVER_VIRTIO=n when using kunit w/
  !MMU, and drop this patch from the series (no modification to the tree)
2) prepare a different file for !MMU & ARCH=um testing (e.g.,
  arch_uml_nommu.config), and add an option to kunit.py to switch MMU
  or !MMU
3) implement virtio-pci for !MMU and propose to remove the restriction
  of CONFIG_PCI depends on CONFIG_MMU.

2) will be removed when 3) is done so, I'm hesitating to propose a
patch used by whole tree.

so, I think 1) is (not the best but) a reasonable solution, with a
note in nommu-uml specific document (i.e., [PATCH 12/13]).

Let me know what you think.

-- Hajime

On Fri, 19 Sep 2025 18:38:03 +0900,
Johannes Berg wrote:
> 
> On Fri, 2025-09-19 at 18:32 +0900, Hajime Tazaki wrote:
> > currently, drivers/pci/Kconfig (CONFIG_PCI) marks as depends on MMU,
> 
> Right.
> 
> > so we cannot select it when CONFIG_MMU=n.
> 
> Actually, I believe that's not true, I think it *can* select something
> even if you override the 'depends on' it has, it just causes a warning
> in Kconfig.
> 
> But I don't think PCI is even selected, UML_PCI is selected, and then
> that selects PCI_MSI which should really only be reachable when PCI is
> enabled, so this perhaps does nothing? Not sure ...
> 
> > but it's different with kunit when using them via kunit.py config,
> 
> It really isn't, you just don't see everything because kunit.py hides
> the build from you.
> 
> > it first adds
> > 
> >  CONFIG_VIRTIO_UML=y
> >  CONFIG_UML_PCI_OVER_VIRTIO=y
> > 
> > via tools/testing/kunit/configs/arch_uml.config, and then add
> > 
> >  CONIFG_MMU=n
> > 
> > via --kconfig_add CONFIG_MMU=n.
> 
> Sure. But that should disable CONFIG_UML_PCI_OVER_VIRTIO, and it doesn't
> now.
> 
> > and then execute make ARCH=um olddefconfig, which in turn enables
> > CONFIG_UML_PCI_OVER_VIRTIO.
> 
> Keeps it, let's say.
> 
> > if we append "--kconfig_add CONFIG_UML_PCI_OVER_VIRTIO=n" to kunit.py,
> > it will overwrite the arch_uml.config.
> 
> Yeah but that being required doesn't make sense - the Kconfig should
> express the correct dependencies.
> 
> > # I don't know how kunit handles those appended CONFIG entries, though..
> 
> It just puts them into the file and runs oldconfig, I guess?
> 
> > my goal is simple; to test !MMU code via kunit.
> 
> Sure.
> 
> > my original patch or the additional kconfig argument (--kconfig_add)
> > satisfies this goal.
> 
> Sure. But both are the wrong solution, as I said, the Kconfig should
> express the correct dependencies.
> 
> > > The problem is probably UML_PCI_OVER_VIRTIO selecting UML_PCI selecting
> > > various PCI code, but nothing depends on PCI in the first place. Which
> > > it should, then?
> > 
> > I don't understand the 'nothing depends on PCI...' part.  care to
> > elaborate ?
> 
> See above, I think?
> 
> My gut feeling is that UML_PCI_OVER_VIRTIO should depend on PCI but I
> don't know if that then doesn't end up in some kind of circular
> dependency.
> 
> johannes