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

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

[kernel test robot]

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)
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]

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

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]

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?

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

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

[Philip Li]

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.

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

[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
> 

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]

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
> >