Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Low] mm: DEVICE_MIGRATION selects HMM_MIRROR without depends on MMU constraint --
commit d98d7483ad3c2031ffcf056a41d08580cd84769d Author: Mika Penttilä <[email protected]> mm/Kconfig: changes for migrate on fault for device pages This commit modifies the memory management Kconfig to have DEVICE_MIGRATION explicitly select HMM_MIRROR. This ensures HMM is enabled for the unified HMM and migrate_device page table walks. > diff --git a/mm/Kconfig b/mm/Kconfig > index 604c58199acbf..b7a485beb9a78 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -687,6 +687,7 @@ config MIGRATION > > config DEVICE_MIGRATION > def_bool MIGRATION && ZONE_DEVICE > + select HMM_MIRROR [Severity: Low] Does selecting HMM_MIRROR under DEVICE_MIGRATION require an explicit dependency on MMU? When a Kconfig symbol uses select, it is expected to have dependencies compatible with the selected symbol's dependencies. HMM_MIRROR explicitly depends on MMU, but DEVICE_MIGRATION lacks an explicit depends on MMU or depends on MIGRATION constraint. While DEVICE_MIGRATION is currently only enabled via its default expression which transitively requires MMU, a default value expression does not act as a dependency constraint against a select operation. If a future patch were to forcefully select DEVICE_MIGRATION on a non-MMU architecture, it would bypass the def_bool and enable HMM_MIRROR without its required MMU dependency. Could this structural risk be avoided by adding an explicit depends on MMU to DEVICE_MIGRATION? > config ARCH_ENABLE_HUGEPAGE_MIGRATION > bool -- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
