From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=209.127.230.111 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792857664; b=u0uCvVlPYra49rbWDfErvz2FCzBwsYD5dPyoJtUsW0GpwaZZua8HLkfyb0XuUciNMKaV pg+t5PsNdQKK0ybVl+2YdBLohQAlQnFc0FD0IWb7755roDyW8/i3ErRyK8kYmpPAUuMhz jgD+Rq0X/OqEvLglr0l02KUvJB/JUzNLgBhT6udUmWieJpV/4CxlD/w0uXOX6EeUKpkS9 E+Za2nzZkW3IEIpTbZfV+tDeDzOHqp1+2hjIYtF4LY5ctTPrjgZ9knxAAQP+OZ/4lnHzS o04Vp7dzhQ2weqHcr2y/KFrfuGfc1jhirvQdgrl3j7WDBwuVpqEcC86cQ8RQGsWbENA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792857664; h=DMARC-Filter:DKIM-Signature:Message-Id:In-Reply-To:Subject:Date: Content-Transfer-Encoding:Content-Type:User-Agent:To: X-Lms-Return-Path:References:Cc:Mime-Version:X-Original-From:From; bh=vSkKqqPrcRVk3BVNulEaeACxkD/BbD3EQ9kOWBnKbIk=; b=fUbQ6US8QTmWZiN5sZ8cGAGznVOKkv+5GOW6CyVvTaoWRu+zOVnlW9e1pd4FjSNhp++d w6CKenoXpTwBRlT5K4Cb1aL3U1LCwUKKUbIGxmluLOkk3TSggD6Id85yWbXdl01ude0Ro NPhiWca/dpCjvek1QC50QsQKfzT4XQU6DuTHVAW74KtrrIThiTsSYcWm4dVqQX2mRTp2d tHFAPY3RRpG9zA974V+MURvams6HnORvKkcI7NwNyNR2Ky6kqGJe8NEW6CRD9r/ijGVrz 95KB6hui44YtLZ+boZTydbUFVV3aI10hwLl4ZPWDKXc00dvhIJHGEjaAniZHZWmpiKw== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass header.d=bytedance.com header.i=@bytedance.com header.a=rsa-sha256 header.s=2212171451 header.b=Y8nqlMG6; arc=none smtp.remote-ip=209.127.230.111 Received: from va-1-111.ptr.blmpb.com (va-1-111.ptr.blmpb.com [209.127.230.111]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ED2F6606A31B for ; Sat, 24 Oct 2026 16:01:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org ED2F6606A31B Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=bytedance.com header.i=@bytedance.com header.a=rsa-sha256 header.s=2212171451 header.b=Y8nqlMG6 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=2212171451; d=bytedance.com; t=1792857657; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=vSkKqqPrcRVk3BVNulEaeACxkD/BbD3EQ9kOWBnKbIk=; b=Y8nqlMG6xNk4CE50/o38uj+s9sIqVf8QCKM01PwMWpWmoxt9f3f48NdTZ8IhCJaMhNe0yI Degyuq0fWnZ+aqXwVdYnczcV/8uG34ZMqBkG7uLfASajhr2bQEvwkS9XRyp0Crpnnki6fq zXYlmXEDd9+zSfLSQ7X36bf3kBOk1CNP6agH4tIF0NPwBslNf1wpC22S2ySwuHDBmv7NTv KCkkEWXtHtomxwyFrZonIdeTUH2gVaD7AMmrED3Jl+Pn1Yoe397kVdoFYXfRTSEy96L4o+ k2/SRf5q5nIew3oI1ciQp3CGUYNJ9AYgrx0JLQK5XWc1KYZq+IT/BBtaffFS5Q== Message-Id: <3b57c214-6a43-4fc7-a531-fb5eac196465@bytedance.com> In-Reply-To: Subject: Re: [PATCH] arm64/mm: restrict transparent contpte mappings to valid PTEs Date: Sun, 25 Oct 2026 00:00:33 +0800 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 User-Agent: Mozilla Thunderbird To: "David Hildenbrand (Arm)" , , , "Ryan Roberts" X-Lms-Return-Path: References: <20261013093600.54995-1-zhaogongyi@bytedance.com> Cc: , , , , , , , , , , , , , , X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list Mime-Version: 1.0 X-Original-From: Zhao Gongyi From: "Zhao Gongyi" On 10/24/26 4:55 AM, David Hildenbrand (Arm) wrote: > > Hi, > > sorry for the late reply. > > If we have the spare PTE bit, why shouldn't we just use it? > > It will make batching over PTEs faster. And we care about that for present PTEs. > > So I don't quite see why the stable fix couldn't just do it right away? Do you > have a prototype that shows that it would require significant code changes? > Hi David, I tried a small prototype that keeps PTE_CONT on present-invalid PTEs. It leaves contpte_set_ptes() unchanged and makes contpte_try_unfold() recognize pte_present(pte) && pte_cont(pte), instead of checking only pte_valid_cont(pte). With this change, the guard-marker reproducer passed 100 iterations in an arm64 QEMU/KVM guest running a KASAN-enabled kernel. The fork and PMD-split probes passed five runs each, with no warnings or KASAN reports. In the earlier A/B test, the unmodified kernel failed on the first guard-marker iteration. The prototype makes the reported reproducer pass with a small change while retaining PTE_CONT. I therefore cannot point to evidence that fixing this failure requires significant code changes. Thanks, Gongyi