Re: [linux-next:master 1418/1780] kismet: WARNING: unmet direct dependencies detected for FB_DEFERRED_IO when selected by FB_DMAMEM_HELPERS_DEFERRED

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

On Sat, Feb 08, 2025 at 11:59:53PM +0800, Philip Li wrote:
> On Fri, Feb 07, 2025 at 11:59:58AM +0000, Lorenzo Stoakes wrote:
> > On Fri, Feb 07, 2025 at 03:24:13AM +0800, kernel test robot wrote:
> > > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> > > head:   808eb958781e4ebb6e9c0962af2e856767e20f45
> > > commit: 236ee083f1b9128fd5bd266054c5b8868f803cee [1418/1780] fbdev: have CONFIG_FB_DEFERRED_IO depend on CONFIG_MMU
> > > config: arm-kismet-CONFIG_FB_DEFERRED_IO-CONFIG_FB_DMAMEM_HELPERS_DEFERRED-0-0 (https://download.01.org/0day-ci/archive/20250207/202502070305.1rGTDnW0-lkp@intel.com/config)
> >
> > I'm not really sure what a kismet device is or how it's configured or where
> > on earth this comes from?
> >
> > Could somebody on intel test side please clarify? Because you might just
> > have a broken config here?
>
> Hi Lorenzo, kismet is part of kmax [1] by Paul Gazzillo, which checks for unmet
> dependency bugs in Kconfig specifications due to reverse dependencies overriding
> direct dependencies.
>
> The 0day bot had used it to detect possible dependency issues [2]. And the issue
> can also be reproduced by running "make ARCH=arm olddefconfig" on the attached
> .config.

Thanks for the info.

>
> Would you mind check again whether the generated .config is a valid one that
> exposes potential issue?

I can tell you right now anything that relies on deferred I/O that doesn't have
an MMU is fundamentally broken by design. It just can't work.

Anyway, I've sort of thrown my arms in the air and given up on this, because
there are too many nommu things that seem to one way or another end up selecting
something that relies on an MMU.

If I try to propagate the dependency through I'm going to end up changing an
absolute ton of stuff, not all of which is necessarily tested against requiring
CONFIG_MMU (they may select the defio stuff but not use it for instance).

So I've dropped this dependency, which will eliminate these errors, and
reluctantly put an #ifdef CONFIG_MMU ... #endif block in the driver.

It'd be good if somebody could go through and ensure all the stuff that _needs_
deferred I/O that _relies_ on an MMU triggering write-protection faults to do so
actually explicitly depends on CONFIG_MMU, but that person will have to be a
drm/fbdev person who is sure that the propagation doesn't inavertently break
something.

These error reports correctly highlight that there's an issue however, so thank
you for reporting, but fundamentally underlying are some dusty cobwebs that need
attention _at some point_ :)

Thanks, Lorenzo

>
> [1] https://github.com/paulgazz/kmax#using-kismet
> [2] https://lore.kernel.org/oe-kbuild-all/?q=kismet
> [3] https://download.01.org/0day-ci/archive/20250207/202502070305.1rGTDnW0-lkp@intel.com/reproduce
>
> >
> > Thanks!
> >
> > > reproduce: (https://download.01.org/0day-ci/archive/20250207/202502070305.1rGTDnW0-lkp@intel.com/reproduce)
> > >
> > > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > > the same patch/commit), kindly add following tags
> > > | Reported-by: kernel test robot <lkp@intel.com>
> > > | Closes: https://lore.kernel.org/oe-kbuild-all/202502070305.1rGTDnW0-lkp@intel.com/
> > >
> > > kismet warnings: (new ones prefixed by >>)
> > > >> kismet: WARNING: unmet direct dependencies detected for FB_DEFERRED_IO when selected by FB_DMAMEM_HELPERS_DEFERRED
> > >    WARNING: unmet direct dependencies detected for FB_DEFERRED_IO
> > >      Depends on [n]: HAS_IOMEM [=y] && FB_CORE [=y] && MMU [=n]
> > >      Selected by [y]:
> > >      - FB_DMAMEM_HELPERS_DEFERRED [=y] && HAS_IOMEM [=y] && FB_CORE [=y]
> >
> > This is a nommu device selecting a feature that absolutely requires an
> > mmu. Something's broken here.
> >
> > I'm not sure pretending an mmu-dependent feature is does not rely on the
> > mmu is the way to fix this.
> >
> > I'm VERY reluctant to add a stub for the function that explicitly relies on
> > CONFIG_MMU because it'd be very misleading.
> >
> >
> > >
> > > --
> > > 0-DAY CI Kernel Test Service
> > > https://github.com/intel/lkp-tests/wiki
> >