From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta0.migadu.com (out-174.mta0.migadu.com [91.218.175.174]) (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 7487B3CF1ED for ; Sun, 18 Oct 2026 07:11:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792307487; cv=none; b=SMURLUul086ZgkENJ9VY62v8Tk6K4bCBhw8EVU5+wq8gGDSQBAk91ZFjj7RXntXXQb872FmIuJUbEYUZ5/UP4FRzRF0XhnXQRNMcXma6rKzIKTzeyKBNIKe/+b394pq+UuyQP+hnJaxIaGuD3YWvbzcck0zCr5sFuv9cQA6Kge8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792307487; c=relaxed/simple; bh=lGb4nruPMj51RONlIa9w9I0Qf0y/WffyQUyIb347g3E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=bavI/JHMHUmHakMFHh2D6Ug2r/TH1w/69C2i0UNvFxkYoS6bjzZXOJdusklgOLAPDRgA0vzjrviaClP7r3kcIXfRhxRoWLB99H1IV4m9gGNenmKhJ9HEJA+X0iOdLj+qcJ1PdRyh03XSaVxVeWupXdF4NdWRvE+k39i08J3xFYY= 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=LYLyWErn; arc=none smtp.client-ip=91.218.175.174 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="LYLyWErn" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=lGb4nruPMj51RONlIa9w9I0Qf0y/WffyQUyIb347g3E=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1792307482; v=1; x=1792912282; b=LYLyWErn9bNn7Rpo0VTkVWYu5HqNGmQcbWSCIkdQcW1Fvf+nsoVuPXLgsHzTboBz1CrxwP4t NDNbcI+x667eJ2oEKWBRpdkMQid6XUTidBtv6oazh34rbCJt0m64LbbyC/rxy2jh2aQ5INlJ2aO Lv34iDGRXXdh/ZG9rWUhCe8U= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id 970df750e1cbd372; Sun, 18 Oct 2026 07:11:21 +0000 X-Mizu-Trace-ID: 970df750e1cbd372 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, mason@kernel.org, stable@vger.kernel.org Subject: Re: [PATCH 06/10] mm/hugetlb: fix endless write fault on a leftover uffd bit Date: Sun, 18 Oct 2026 15:11:16 +0800 Message-ID: <20261018071116.20342-1-lance.yang@linux.dev> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20261015-urgent_fixes-v1-6-42796911043b@kernel.org> References: <20261015-urgent_fixes-v1-6-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:12PM +0200, David Hildenbrand (Arm) wrote: >From: Josef Bacik > >hugetlb_fault() resolves the uffd bit on a write fault only if the VMA is >registered for userfaultfd write protection, and hugetlb_wp() bails out >for any entry with the uffd bit set assuming hugetlb_fault() has already >resolved it. > >When a read-only hugetlb entry with the uffd bit set is mapped in a VMA >that is not registered for uffd-wp, a write fault to it never makes >progress. If the access comes from the kernel, e.g. read(2) from >/dev/zero into such page, the task spins in the page fault handler, >ignores SIGKILL and keeps holding the locks taken by the system call. > >Such entries should not exist, but an unprivileged user can create them, >for example with MADV_DONTNEED of a page protected with UFFDIO_RWPROTECT >or with UFFDIO_COPY in MODE_WP racing with UFFDIO_UNREGISTER. > >Clear the uffd bit when the VMA is not registered for uffd-wp and let the >fault proceed to hugetlb_wp(), like do_wp_page() does for regular pages. > >Note that a FOLL_FORCE write to a page protected with UFFDIO_RWPROTECT in >a private VMA that was made PROT_NONE now drops the RWP protection of >that page. > >Original fix generated by an LLM and sent in private by Josef. > >Fixes: 60d5b473d61b ("mm/hugetlb: fix uffd wr-protection for CoW optimization path") >Reported-by: Chris Mason >Cc: stable@vger.kernel.org >Signed-off-by: Josef Bacik >[rppt: massage commit message] >Signed-off-by: Mike Rapoport (Microsoft) >[ david: convert comment into a TODO ] >Signed-off-by: David Hildenbrand (Arm) >--- LGTM! Reviewed-by: Lance Yang