From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.migadu.com (out-43.mta1.migadu.com [95.215.58.43]) (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 7E70D403E9D for ; Sun, 18 Oct 2026 08:21:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792311691; cv=none; b=EMCB7loP/8JaOh7Rt3O9X83kvUuskNzTkVn23enxNp5KOcazqsV1Z+rZJ5PUEoq5huduki+XAfh/tAdWkThB9R9MEclg3+A6D04QsyU7W3ZaIkj26OKhArvswGr69/CXXpdvF0VKcKNJTNdE+l2tjdM4CwLvsE3b2zhCKVG3tXU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792311691; c=relaxed/simple; bh=sN5FiXCvtsa5hp2sSKXzUhp4xkTvbR9DGPpqAMU5Ii0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=htNRZ7RYXEdwBvgQ2H4Mkjq++T16rNv35l6PVJUWhEUhrJIh1tL85kj2v3blY/MLUlhEPjI0uaE0lrSw50zbb5siTwbXFsWQXLTmiYTUuP4EeWYrjyYz2Qv9Dw+5LUjHw2u/cwDsaOgwtIJMrjqzF/UpDslfbvCUnLbIgj/fEaY= 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=dXWnS8MU; arc=none smtp.client-ip=95.215.58.43 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="dXWnS8MU" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=sN5FiXCvtsa5hp2sSKXzUhp4xkTvbR9DGPpqAMU5Ii0=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1792311687; v=1; x=1792916487; b=dXWnS8MUqti8KJSWxPrn+b7tCzZ5JZrmaPvI8tD3/kvgZ/DOjUrS/DzJZWveUzS5U1qVbJd4 wpVYVUFTdHmkkBxHdg0kqoFiOo4zpkbdau1fgHBzM5cPBwTghff+JDmjhRzEFf0UazP8rs8tb4q cMF9chUoY5ENSeUMCMC1uElA= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id 39d921597cd8dcbf; Sun, 18 Oct 2026 08:21:27 +0000 X-Mizu-Trace-ID: 39d921597cd8dcbf X-Migadu-Flow: FLOW_OUT From: Lance Yang To: david@kernel.org Cc: akpm@linux-foundation.org, liam@infradead.org, ljs@kernel.org, vbabka@kernel.org, jannh@google.com, pfalcato@suse.de, muchun.song@linux.dev, osalvador@suse.de, linmiaohe@huawei.com, nao.horiguchi@gmail.com, agl@us.ibm.com, mel@csn.ul.ie, riel@surriel.com, peterx@redhat.com, kas@kernel.org, rppt@kernel.org, josef@toxicpanda.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, mason@kernel.org Subject: Re: [PATCH 09/10] mm/hugetlb: don't leave a uffd-wp marker when zapping an RWP entry Date: Sun, 18 Oct 2026 16:21:13 +0800 Message-ID: <20261018082113.5548-1-lance.yang@linux.dev> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20261015-urgent_fixes-v1-9-42796911043b@kernel.org> References: <20261015-urgent_fixes-v1-9-42796911043b@kernel.org> 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=UTF-8 Content-Transfer-Encoding: 8bit On Thu, Oct 15, 2026 at 06:07:15PM +0200, David Hildenbrand (Arm) wrote: >From: Josef Bacik > >An entry that is protected with UFFDIO_RWPROTECT is PAGE_NONE with the >uffd bit set, the bit that userfaultfd write protection uses too. When >__unmap_hugepage_range() zaps an entry with that bit it leaves a >PTE_MARKER_UFFD_WP behind, whatever the VMA is registered for. > >In a VMA registered with UFFDIO_REGISTER_MODE_RWP that marker means >nothing. The next fault has hugetlb_no_page() turn it into a present, >read-only entry with the uffd bit. That is not an RWP entry, since it is >not PAGE_NONE, and the VMA has no VM_UFFD_WP (the two modes can not be >registered together). An earlier fix solved some side effects, now just >stop the zap from wrongly installing a marker. > >Leave a marker only if the VMA is registered for write protection, both >for present and for non-present entries. The zap of ordinary page >tables has the same test, in cond_install_uffd_wp_ptes(), and >hugetlb_change_protection() says that "uffd_rwp does not install markers". > >After a zap the range of an RWP VMA is simply empty, as it is for >anonymous memory and shmem. Nothing changes for VMAs with VM_UFFD_WP. In >a VMA that is not registered at all a leftover uffd bit or marker is now >dropped by the zap and no longer kept alive. > >Original fix generated by an LLM and sent in private by Josef. > >Fixes: 2d427bb01639 ("mm/userfaultfd: add RWP fault delivery and expose UFFDIO_REGISTER_MODE_RWP") >Cc: stable@vger.kernel.org >Reported-by: Chris Mason >Signed-off-by: Josef Bacik >[ david: a bit of description overhaul+simplification ] >Signed-off-by: David Hildenbrand (Arm) >--- Reviewed-by: Lance Yang