From: sashiko-bot@kernel.org
To: mpenttil@redhat.com
Cc: intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v15 01/11] mm/Kconfig: changes for migrate on fault for device pages
Date: Thu, 24 Sep 2026 07:11:15 +0000 [thread overview]
Message-ID: <20260924071116.60FA71F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260924065313.899730-2-mpenttil@redhat.com>
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ä <mpenttil@redhat.com>
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/20260924065313.899730-1-mpenttil@redhat.com?part=1
next prev parent reply other threads:[~2026-09-24 7:11 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-24 6:53 [PATCH v15 00/11] migrate on fault for device pages mpenttil
2026-09-24 6:53 ` [PATCH v15 01/11] mm/Kconfig: changes for " mpenttil
2026-09-24 7:11 ` sashiko-bot [this message]
2026-09-24 6:53 ` [PATCH v15 02/11] mm: add helper to convert HMM pfn to migrate pfn mpenttil
2026-09-24 6:53 ` [PATCH v15 03/11] mm/hmm: preparations for HMM to participate in migration mpenttil
2026-09-24 7:09 ` sashiko-bot
2026-09-24 6:53 ` [PATCH v15 04/11] mm/hmm: do the plumbing " mpenttil
2026-09-24 6:53 ` [PATCH v15 05/11] mm/hmm: migrate collection in HMM pagewalk - pte level mpenttil
2026-09-24 7:10 ` sashiko-bot
2026-09-24 6:53 ` [PATCH v15 06/11] mm/hmm: migrate collection in HMM pagewalk - pmd level mpenttil
2026-09-24 7:09 ` sashiko-bot
2026-09-24 6:53 ` [PATCH v15 07/11] mm/hmm: add lazy MMU mode support for migration in HMM pagewalk mpenttil
2026-09-24 6:53 ` [PATCH v15 08/11] mm/hmm: implement rollback for device page " mpenttil
2026-09-24 7:16 ` sashiko-bot
2026-09-24 6:53 ` [PATCH v15 09/11] mm: enable device page migration from " mpenttil
2026-09-24 6:53 ` [PATCH v15 10/11] lib/test_hmm: add a new testcase for the migrate on fault mpenttil
2026-09-24 7:27 ` sashiko-bot
2026-09-24 6:53 ` [PATCH v15 11/11] Documentation/mm/hmm: document migration through hmm_range_fault() mpenttil
2026-09-24 7:28 ` ✗ CI.checkpatch: warning for Migrate on fault for device pages (rev7) Patchwork
2026-09-24 7:30 ` ✓ CI.KUnit: success " Patchwork
2026-09-24 7:46 ` ✗ CI.checksparse: warning " Patchwork
2026-09-24 8:09 ` ✓ Xe.CI.BAT: success " Patchwork
2026-09-24 21:10 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-09-25 9:07 ` [PATCH v15 00/11] migrate on fault for device pages Christoph Hellwig
2026-09-25 10:23 ` Mika Penttilä
2026-09-25 12:47 ` Jason Gunthorpe
2026-09-25 13:22 ` Mika Penttilä
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260924071116.60FA71F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=mpenttil@redhat.com \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.