On 01/05/2024 11:04, Catalin Marinas wrote: > On Wed, May 01, 2024 at 09:05:17AM +0100, Ryan Roberts wrote: >> On 30/04/2024 18:57, Catalin Marinas wrote: >>> On Tue, 30 Apr 2024 14:31:38 +0100, Ryan Roberts wrote: >>>> __split_huge_pmd_locked() can be called for a present THP, devmap or >>>> (non-present) migration entry. It calls pmdp_invalidate() >>>> unconditionally on the pmdp and only determines if it is present or not >>>> based on the returned old pmd. >>>> >>>> But arm64's pmd_mkinvalid(), called by pmdp_invalidate(), >>>> unconditionally sets the PMD_PRESENT_INVALID flag, which causes future >>>> pmd_present() calls to return true - even for a swap pmd. Therefore any >>>> lockless pgtable walker could see the migration entry pmd in this state >>>> and start interpretting the fields (e.g. pmd_pfn()) as if it were >>>> present, leading to BadThings (TM). GUP-fast appears to be one such >>>> lockless pgtable walker. >>>> >>>> [...] >>> >>> Applied to arm64 (for-next/fixes), thanks! It should land in 6.9-rc7. I >>> removed the debug/test code, please send it as a separate patch for >>> 6.10. >> >> Thanks Catalin! I'm guessing this will turn up in today's linux-next, so if I >> send the tests today and Andrew puts them straight in mm-unstable (which will >> goto linux-next) there is no risk that the tests are there without the fix? Or >> do I need to hold off until the fix is in v6.9-rc7? > > It looks like we don't push for-next/fixes to linux-next, it's > short-lived usually, it ends up upstream quickly. I can send the pull > request later today, should turn up in mainline by tomorrow. You can add > a note to your patch for Andrew that it will fail on arm64 until the fix > ends up upstream. It's a matter of a couple of days anyway. OK, I just didn't want to send it only for our CI to start failing. I'll do as you suggest.
