Re: [PATCH] mm/page_vma_mapped: guard check_pmd() with CONFIG_TRANSPARENT_HUGEPAGE

[Lorenzo Stoakes]

+cc Roman for Sashiko discussion

On Thu, Jun 25, 2026 at 06:41:02AM +0000, Wei Yang wrote:
> +cc Balbir
>
> On Wed, Jun 24, 2026 at 09:59:43PM -0700, Andrew Morton wrote:
> >On Thu, 25 Jun 2026 03:46:29 +0000 Wei Yang <richard.weiyang@xxxxxxxxx> wrote:
> >
> >> >Sashiko had an off-topic complaint about the surrounding code:
> >> >	https://lore.kernel.org/oe-kbuild-all/202606240042.ffPsEXVc-lkp@xxxxxxxxx/
> >>
> >> I see this robot reply, but not see the Sashiko comment.
> >>
> >> How can I view Sashiko's commnet?
> >
> >oop sorry.
> >
> >You can go to https://sashiko.dev/ and search for the email subject.
> >
> >Or append your Message-ID to "https://sashiko.dev/#/patchset":
> >
> >	https://sashiko.dev/#/patchset/20260624082359.2869-1-richard.weiyang@xxxxxxxxx
> >
>
> Got it, thansk
>
> This one mentioned two things:
>
>   a. page_vma_mapped_walk() return without check
>   b. whether __split_huge_pmd_locked() would split device-private pmd
>
> For a., it is being fixing at [1].
>
> For b., to be honest I am not 100% for sure. If a device-private pmd could be
> file backed, then this looks like a bug.
>
> Balbir,
>
> Would you mind taking a look at the second comment raised by Sashiko?
>
> [1]: https://lore.kernel.org/linux-mm/20260624065353.1622-1-richard.weiyang@xxxxxxxxx/

I continue to dislike that sashiko does this.

Series with... interesting use of AI :).. are already taking up more of the time
we reviewers don't have... but interrupting existing review to mention random
stuff is unhelpful I feel :)

I think the better use of time here would be for Balbir to perhaps ask AI to
examine all cases where a PMD device private entry might crop up and to check to
see if there's any other bugs similar to the ones we've encountered before?

Given Sashiko is very token-constrained, I also wonder whether this feature
wouldn't be better disabled (or maybe have the ability to turn off
per-subsystem?)

In a couple other cases the 'also consider' stuff actually took a bunch of time
unnecessarily and I felt they interferred with the series landing.

Given the time constraints we all work under, it'd be better not to add to
workload this way (having to figure out if the points are valid are a time drain
in themselves).

Thanks, Lorenzo