From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A496740D56A for ; Mon, 22 Jun 2026 23:45:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782171922; cv=none; b=Z/oO5yFDfc3vaoLy3p/bEjhvStAjUW+yfYbQ81vlrLG1Qo7Y/ZqNT8XZ8qmq9YidIORm0y5GiM9bWLTQj0BmEFdHj135QWRtNPKm7tQCXJlGrdASipOt2+oHMHmi3QlbktTrxDnAu2ofgwFyIMvWl4dL3rFFQUH757E68SUyu/g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782171922; c=relaxed/simple; bh=J+2kftuOdC/Mvf2hM+A9T1xf1SRv9jCakY5GvO7YLS8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Ez9N0G/nGttGZwiysW2NTsg9v2nX1G5/218xq/LuAfhMl+UW8YJYSt6GIENs3z25r9P6R+oj11yytD6NSoaX7B4vT0AY5Dmq5UBg3fTnNWJ4Fqk9j+857uwLGm2xkA5iO2gs6u0nqNOBJ27Lzt7s45n+LRWv/khxV68uA7kBJBQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=n1ytCcfT; arc=none smtp.client-ip=209.85.218.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="n1ytCcfT" Received: by mail-ej1-f45.google.com with SMTP id a640c23a62f3a-c0c5d170ad4so329294866b.3 for ; Mon, 22 Jun 2026 16:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782171920; x=1782776720; darn=vger.kernel.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=rqciz2qlJ5KO2k38VZg83p2ecH48DGVORpzo6dgPKlM=; b=n1ytCcfTygDga4B9/Q+Dns9omZKDweYaz8N4aL6TYjqtfp9zqlV8FuvG9WVCIspo6I 2N6T8US5krP2Avt+G4JwrskevjAT/xq6Ae+KoD8cI3gvaqrkCis0paCRLXEq//EW4ePk JsGmtaUjxUPNI0/5JWdp5qVi4eZbZIWbk/p0uZ3LPwVT/yuSJc2NREEEoBCShZ6kO3ot Ytn0u/V6DPysoYCL5YMgVCSOtTM08JK6GBFQSu5bOQ8CuO9njWE5OExYGMj1+ma/BwGY JJ3xeJNFPAZf78KOi8ZRkQmNVV/wzQVMebG7G/UVJDfqOgrc9mMGwegeiGymMhFA2hph xY0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782171920; x=1782776720; h=user-agent:in-reply-to:content-disposition:mime-version:references :reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=rqciz2qlJ5KO2k38VZg83p2ecH48DGVORpzo6dgPKlM=; b=FwVnWgQO9ueTlHqYE+ZyGw4I5i1WoB76QAIQMBDZxdETI8H558CcHUAonOT3buMbff +fUddIjdXOSeROVXQzCzOOQgm/HUo2Dcx/MY5HWA0FlnWd17UFCk2DQjsAs4E5QuBnsq E5Xkfv8ScsyvfSv0RfH0m3pia3psM/FvYp6EWF9fqh1LRqFSe9I79UJu0qkAt1PJw+Ia EzU+gAfwF+tu5DW1gb7YLvm6DqEaOzuYQ8GFWxt3Oloub+LjpbA6ErW5TikjzDGNcBHB CoTO5dea6oNTfI3QW1TtwXFqdLKesm67i1MNhcpRBnfoGYQL0wlcJjbyGBfmWCD+mOno xM8w== X-Forwarded-Encrypted: i=1; AFNElJ+sO0xZXY7kQD7Q++vVuVfYha+ayIUp69oyUwNhObzHU+abmlU8RA5rTBL+0Es9RbzZ9nbZvQnYj6NW4Ag=@vger.kernel.org X-Gm-Message-State: AOJu0YxWhTVWr9KJcvl5FBvgYixRmFbGaeFektA28fqnb/IAm+FcRYOT SwwwFY8RSQd4y6UpLFrnqncnooy7ty0ppaCpMAXiblqIfNJlzkt4QuOo X-Gm-Gg: AfdE7cmcccatLdULfFamvqG8Bn8btji3xbUKUI9kfbcswzzSX4Awr7eeSuLI4ixbOku uLd1QNgC8zUMTEUbteA0nTLF4A48NU5f49uRmjal9noZVhl0S5FZLsEEQNgXWDi0YylUl8ZQrl7 kLtDtD4Rk569nqiK10C5Tgh3dQLsHu4F1gncMEBqdX7LEwTuaZ3EWPANZjYm4ghC2HEXJfunTGq XLV4ZYpy2LK0OKyejS64++bg91EVaYmzJq9MZyKIgz2T9afWWHvd0oYTRB6o78KLgM5A2MefBvZ ubTtj02Ec2TPcUqRa7aWlvogoHTrb2p6TYeclwaa8ZV/95q12Y2n/iEwJms4DTvBO+Ckw5TIeJL zDreHKKRhELB0nwZ7xu7mi7nUNvpAmfva6DxOyzsdO35KWyIvz62R0Ot3R5QKLb0KJEneH7bbU9 L1ehUsws8m2iU= X-Received: by 2002:a17:906:eec1:b0:bfe:ed06:5a16 with SMTP id a640c23a62f3a-c108f60a8f7mr5710866b.52.1782171919729; Mon, 22 Jun 2026 16:45:19 -0700 (PDT) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c0c5e998decsm422908266b.22.2026.06.22.16.45.19 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 22 Jun 2026 16:45:19 -0700 (PDT) Date: Mon, 22 Jun 2026 23:45:18 +0000 From: Wei Yang To: Lorenzo Stoakes Cc: Wei Yang , akpm@linux-foundation.org, david@kernel.org, riel@surriel.com, liam@infradead.org, vbabka@kernel.org, harry@kernel.org, jannh@google.com, sj@kernel.org, ziy@nvidia.com, balbirs@nvidia.com, linux-mm@kvack.org, stable@vger.kernel.org, Lance Yang , linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/page_vma_mapped: revalidate and do proper check before return device-private pmd Message-ID: <20260622234518.nnx3r7ckphlxn5vm@master> Reply-To: Wei Yang References: <20260622130651.23359-1-richard.weiyang@gmail.com> <20260622142102.pcmr5pftshj5lvju@master> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) On Mon, Jun 22, 2026 at 05:11:02PM +0100, Lorenzo Stoakes wrote: >On Mon, Jun 22, 2026 at 02:21:02PM +0000, Wei Yang wrote: >> On Mon, Jun 22, 2026 at 02:46:40PM +0100, Lorenzo Stoakes wrote: >> >+cc Lance, linux-kernel >> > >> >Your subject line is 83 characters long and is way too detailed how about 'fix >> >device-private PMD handling'? >> > >> >> Got it. >> >> >You forgot to include linux-kernel@vger.kernel.org on the mail, lore seems to be >> >a bit broken atm but in general it's helpful to include that. >> >> Got it. >> >> So usually we send a patch to both linux-mm and linux-kernel? If so, I >> remember is later actions. > >Yeah it's better for dealing with kvack going wrong etc. :) > >> >> > >> >Also is useful to make this [PATCH mm-hotfixes] to make it really clear it's >> >intended as a hotfix. >> > >> >> Got it. >> >> >Some commit msg language nits: >> > >> >On Mon, Jun 22, 2026 at 01:06:51PM +0000, Wei Yang wrote: >> >> For pmd_trans_huge() and pmd_is_migration_entry(), we does following >> >> before return the pmd entry: >> > >> >Sounds better as: >> > >> > For PMD entries that satisfy pmd_trans_huge() or pmd_is_migration_entry(), we >> > perform the following actions: >> > >> >> Sure. >> >> >> >> >> * re-validate pmd entry after PTL >> >> * check PVMW_MIGRATION >> >> * check_pmd() >> >> * handle on pte level if split under us >> >> >> >> But for device-private pmd, we just return after pmd_lock(). >> > >> >-> >> > >> > However, for device-private PMD entries, we simply acquire the PMD lock >> > and return. >> > >> >> Sure. >> >> >Also can you please give some justification here as to why all this also applies >> >to device-private PMD? Right now it sounds hand wavey. >> > >> >> I thought below paragraph explain it. Not sure what justification is preferred. > >Something about device private PMDs splitting the same way THP ones do, in the >pmd_is_device_private_entry() branch of __split_huge_pmd_locked(). > Hi, Lorenzo Thanks for your detailed suggestions. I tried to add the justification here, and the following is the commit log after consolidate your suggestions. For PMD entries that satisfy pmd_trans_huge() or pmd_is_migration_entry(), we perform the following actions: * re-validate pmd entry after PTL * check PVMW_MIGRATION * check_pmd() * handle on pte level if split under us However, for device-private PMD entries, we simply acquire the PMD lock and return. This is not enough, as __split_huge_pmd_locked() would split a pmd device-private PMD under us just as it does for THP PMD. This is particularly problematic when PVMW_MIGRATION is set (meaning a migration entry is sought), as it causes a device-private PMD entry to be returned with a different data layout, causing memory corruption. Just feel this is not that smooth. Would you mind taking another look to see if I get your point correctly? -- Wei Yang Help you, Help me