Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 11 Jul 2023 16:34:59 +0100
From:   Mark Brown <broonie@kernel.org>
To:     Hugh Dickins <hughd@google.com>
Cc:     Lorenzo Stoakes <lstoakes@gmail.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Mike Kravetz <mike.kravetz@oracle.com>,
        Mike Rapoport <rppt@kernel.org>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Matthew Wilcox <willy@infradead.org>,
        David Hildenbrand <david@redhat.com>,
        Suren Baghdasaryan <surenb@google.com>,
        Qi Zheng <zhengqi.arch@bytedance.com>,
        Yang Shi <shy828301@gmail.com>,
        Mel Gorman <mgorman@techsingularity.net>,
        Peter Xu <peterx@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Will Deacon <will@kernel.org>, Yu Zhao <yuzhao@google.com>,
        Alistair Popple <apopple@nvidia.com>,
        Ralph Campbell <rcampbell@nvidia.com>,
        Ira Weiny <ira.weiny@intel.com>,
        Steven Price <steven.price@arm.com>,
        SeongJae Park <sj@kernel.org>,
        Huang Ying <ying.huang@intel.com>,
        Naoya Horiguchi <naoya.horiguchi@nec.com>,
        Christophe Leroy <christophe.leroy@csgroup.eu>,
        Zack Rusin <zackr@vmware.com>, Jason Gunthorpe <jgg@ziepe.ca>,
        Axel Rasmussen <axelrasmussen@google.com>,
        Anshuman Khandual <anshuman.khandual@arm.com>,
        Pasha Tatashin <pasha.tatashin@soleen.com>,
        Miaohe Lin <linmiaohe@huawei.com>,
        Minchan Kim <minchan@kernel.org>,
        Christoph Hellwig <hch@infradead.org>,
        Song Liu <song@kernel.org>,
        Thomas Hellstrom <thomas.hellstrom@linux.intel.com>,
        Ryan Roberts <ryan.roberts@arm.com>,
        linux-kernel@vger.kernel.org, linux-mm@kvack.org,
        regressions@leemhuis.info, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 12/32] mm/vmalloc: vmalloc_to_page() use
 pte_offset_kernel()
Message-ID: <fbb2b76c-bc5c-4d75-b8cd-37479de688d4@sirena.org.uk>
References: <c1c9a74a-bc5b-15ea-e5d2-8ec34bc921d@google.com>
 <696386a-84f8-b33c-82e5-f865ed6eb39@google.com>
 <42279f1f-7b82-40dc-8546-86171018729c@sirena.org.uk>
 <901ae88d-ad0c-4e9d-b199-f1566cc62a00@lucifer.local>
 <c2358f37-ebaa-44d1-b443-ff91bdedc00b@sirena.org.uk>
 <977ddee4-35f0-fcd1-2fd-1c3057e7ea2a@google.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="w4g5Ya+dx+5ErXu8"
Content-Disposition: inline
In-Reply-To: <977ddee4-35f0-fcd1-2fd-1c3057e7ea2a@google.com>
Precedence: bulk


--w4g5Ya+dx+5ErXu8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Jul 10, 2023 at 09:34:42PM -0700, Hugh Dickins wrote:

> This feels like one of those bugs which depends on the code size in
> some way (a bit like those bugs we used to have, where a function was
> mistakenly marked __init, then in some configs its code landed on a
> page which got freed at startup - I'm not saying this is that at all,
> just saying it feels weird in that way).

> Yet your bisection converges convincingly, which I wouldn't expect
> in that case.

Yes, it smells like code size or something other than the commit
itself, I have seen this sort of behaviour before where something nearby
in history introduced something which was then triggered by whatever the
bisect points at.

> I suppose I should ask you to try reverting this 0d1c81edc61e alone
> from 6.5-rc1: the consistency of your bisection implies that it will
> "fix" the issues, and it is a commit which we could drop.  It makes
> me a little nervous, applying userspace-pagetable validation to kernel
> pagetables, so I don't want to drop it; and it would really be cargo-
> culting to drop it without understanding.  But we could drop it.

I did look at that, it doesn't revert cleanly by itself.  Your other
suggestions are all good - I'll poke at them.  My suspicion is that
there's some longer standing breakage elsewhere and your series (or even
just this patch) just happens to push into happening reliably, had it
not been a mm change and a memory related bug I'd probably have just
discounted the bisect result.

--w4g5Ya+dx+5ErXu8
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEyBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmStdqMACgkQJNaLcl1U
h9B2ygf3WcoveZBcNCDFtF0/hH7JWuCVAeL856Ci/azCtT0y2w6cpUP3VO1xTxDr
m8YfCM2mWlg/iKZ6yC1FkJvgr1m2ZjGA+Q2awiZUiZt/htJOgDnQ3KMRt8jGvSs3
ctdg8gdYBz4LK9TOz5LPKX5UsjiDBcebYEWqAkgvy3ZSGdubnQ8WqlEmDXT/dlOL
3xE4fyDXFPMtZThRYoE0wrN5EwVLJTaE7O/8TpLhPxK2iXbQCgASZhSfe23CCKKF
k5C2XwR97eTiT/uwJtN2aYy/y+ay7+8Do7JEGu2hMJBm8/X7ZUrLtms8MaKNvTGJ
83r2M8FrNLXbhVdHNQJ249P5rF99
=ztfN
-----END PGP SIGNATURE-----

--w4g5Ya+dx+5ErXu8--