From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.migadu.com (out-106.mta1.migadu.com [95.215.58.106]) (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 672D351588E for ; Wed, 14 Oct 2026 13:19:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.106 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791983998; cv=none; b=RW+G9z7+JPgn009q8OQOQ2DqxgbjEVwAEvgoj/D259L8Muzgli89Ba8M8OH7EZo4WURomhjh9LX9ihbeueA1Ecb0d1ycIeYMmVP14dXdZSFeDOKadi/duAtFwmDAckxRYqxaXruD/f6//UTJhmJHll1nLOAL9t5ViaTMsTf7JjM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791983998; c=relaxed/simple; bh=m7HcPUAMizid1DX3lRG9Tzw1zddlCTzU8zWnOAtnnRg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=nNrC4UxvoDHKGBMZcY5b13kImnWRYDPeZypmiMZlM0ifo+Leg3bHItVAq9b9gT2V43Ixx9UIfGPPX4UXlHgQIzdd9zqdGzwnpdCC2iyKPEfZrjvityfeKUlFuaY/FlOumdEnoEGxsXyCplD63dgb2dd3Rxle0biHPlEoE1TFdNs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=kRRCaIoJ; arc=none smtp.client-ip=95.215.58.106 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="kRRCaIoJ" X-Envelope-To: kvm@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=m7HcPUAMizid1DX3lRG9Tzw1zddlCTzU8zWnOAtnnRg=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1791983994; v=1; x=1792588794; b=kRRCaIoJw0sJTJ/tOBQljz6AT/gufciBi0m1KrH8rJZGBnpa3mkxfjwGQPb+ELUw7hsBdCVU mmxqIxcLYn0+K+Zux9JnBzXzRsy69peQpfNnW2jSJ4q0+GnbK8U14BbNpbbi8550m/0hof2d0ZT ASh7FEPzd7j6QUveg7i6TzX0= X-Envelope-To: kvm@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id b774b44408666da9; Wed, 14 Oct 2026 13:19:54 +0000 X-Mizu-Trace-ID: b774b44408666da9 X-Migadu-Flow: FLOW_OUT Message-ID: <58e8d79b-f7c3-4ded-9272-07c309917055@linux.dev> Date: Wed, 14 Oct 2026 21:19:42 +0800 Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/huge_memory: recheck a special PMD under the lock in copy_huge_pmd() Content-Language: en-US To: Konstantin Khorenko Cc: Alex Williamson , David Hildenbrand , Andrew Morton , Ryan Roberts , kvm@vger.kernel.org, =?UTF-8?Q?Lo=C3=AFc_Molinari?= , Nico Pache , Zi Yan , "Liam R. Howlett" , dri-devel@lists.freedesktop.org, Baolin Wang , Usama Arif , Barry Song , Dev Jain , linux-mm@kvack.org, Peter Xu , linux-kernel@vger.kernel.org, Jason Gunthorpe , stable@vger.kernel.org, Kiryl Shutsemau References: <20261014-b4-prep-vstor-149847-copy_huge_pmd-recheck-special-pmd-v1-1-d225c60bc316@virtuozzo.com> From: Lance Yang In-Reply-To: <20261014-b4-prep-vstor-149847-copy_huge_pmd-recheck-special-pmd-v1-1-d225c60bc316@virtuozzo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2026/10/14 19:57, Konstantin Khorenko wrote: [...] > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index 1e5d68acf62a5..fcea98f0d8865 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -1965,13 +1965,22 @@ int copy_huge_pmd(struct mm_struct *dst_mm, struct mm_struct *src_mm, > src_ptl = pmd_lockptr(src_mm, src_pmd); > spin_lock_nested(src_ptl, SINGLE_DEPTH_NESTING); > /* > - * No need to recheck the pmd, it can't change with write > - * mmap lock held here. > - * > - * Meanwhile, making sure it's not a CoW VMA with writable > - * mapping, otherwise it means either the anon page wrongly > - * applied special bit, or we made the PRIVATE mapping be > - * able to wrongly write to the backend MMIO. > + * The mmap and VMA write locks of the source keep faults > + * out, but unmap_mapping_range() does not take the mmap > + * lock and may have cleared the pmd since the lockless > + * read. Let copy_pmd_range() skip it then. > + */ > + pmd = pmdp_get(src_pmd); > + if (unlikely(!pmd_present(pmd) || !pmd_special(pmd))) { Why not just check pmd_none(pmd) here? We're holding the source mmap/VMA write locks, so the PMD either stays special or gets cleared, right? Cheers, Lance > + spin_unlock(src_ptl); > + spin_unlock(dst_ptl); > + return -EAGAIN; > + } > + /* > + * Make sure it's not a CoW VMA with writable mapping, > + * otherwise it means either the anon page wrongly applied > + * special bit, or we made the PRIVATE mapping be able to > + * wrongly write to the backend MMIO. > */ > VM_WARN_ON_ONCE(vma_is_cow_mapping(src_vma) && pmd_write(pmd)); > goto set_pmd; > > --- > base-commit: 24a19b953e2a3d0ea5a8c4951a0ab8f32720c907 > change-id: 20261014-b4-prep-vstor-149847-copy_huge_pmd-recheck-special-pmd-bdf7efb612c2 > > Best regards, > -- > Konstantin Khorenko >