From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id BC9DD50A68; Wed, 1 May 2024 10:13:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714558423; cv=none; b=B1wOz6hkvlvZ7q+XuVvtwzuVig4ShH+2E9v3MRtCp2iLiBfl5EGKCOLYI8iRORhry4pLX9OXXHyMkdy4MU9MFpABNNslWri6Ww31VUaipnpCJCEm3iwhLmA5lojWrpnFQa4wUXZxhuXn+xhzhd2RT7E9yjCSmByr9neycZ6nMyU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714558423; c=relaxed/simple; bh=LwgA5tUBh5T6l1zxzQp/kd1I2Hf2cwtWXTWzbe9e+BU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=WoNEQB3qaKD0cI5am5pGNVUZspfrFCQNi2+5YE5SvaS3MssfRTwyPPl5b7fhNT/1jpQaEWPbtsgQys8Cxgo+xl5wLX+FkCfHaf9DTAuQwYk8KQmb3iWo5hWsEtaPvJYJt+JpRbBoaTMqkcAI4XQ7KhoiyDvj7D2QbYmvzOOzQ2A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 49E292F4; Wed, 1 May 2024 03:14:07 -0700 (PDT) Received: from [10.57.65.146] (unknown [10.57.65.146]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A2F2E3F793; Wed, 1 May 2024 03:13:39 -0700 (PDT) Message-ID: Date: Wed, 1 May 2024 11:13:38 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] arm64/mm: pmd_mkinvalid() must handle swap pmds Content-Language: en-GB To: Catalin Marinas Cc: Will Deacon , Mark Rutland , Anshuman Khandual , Andrew Morton , Zi Yan , "Aneesh Kumar K.V" , linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org References: <20240430133138.732088-1-ryan.roberts@arm.com> <171449974870.639201.3165060270571039049.b4-ty@arm.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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.