From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 685C0C369A2 for ; Thu, 10 Apr 2025 16:08:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DBA4E280117; Thu, 10 Apr 2025 12:08:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D4C6428010C; Thu, 10 Apr 2025 12:08:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B9426280117; Thu, 10 Apr 2025 12:08:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 94C9328010C for ; Thu, 10 Apr 2025 12:08:12 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id ECC01120954 for ; Thu, 10 Apr 2025 16:08:13 +0000 (UTC) X-FDA: 83318616066.14.C84E52C Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by imf12.hostedemail.com (Postfix) with ESMTP id CA7C940002 for ; Thu, 10 Apr 2025 16:08:11 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=KeFXTRMr; dmarc=pass (policy=none) header.from=ibm.com; spf=pass (imf12.hostedemail.com: domain of agordeev@linux.ibm.com designates 148.163.158.5 as permitted sender) smtp.mailfrom=agordeev@linux.ibm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744301291; a=rsa-sha256; cv=none; b=PAA9I6K7Kc44eyP5+iU1WWm2BJ4Os9HofL4ylnYsZfYAKVvs7yBgvxDL+Dxih5SqTGhJkU /9+ZxfqO2UNISOwk/1ioZW+I/aoIIT9eobKvZDDK9n2UamgISouJwxAWzea1I1Atz8BWmc hs/vI2hvdzKI4rB4H9zrvxh3kyLRQ+Y= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=KeFXTRMr; dmarc=pass (policy=none) header.from=ibm.com; spf=pass (imf12.hostedemail.com: domain of agordeev@linux.ibm.com designates 148.163.158.5 as permitted sender) smtp.mailfrom=agordeev@linux.ibm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744301291; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Jmp1TuG2rk5K6Ce5PuPbd2zgfuoBese75oMt4oJEqFw=; b=wL5PhbWcfO41+n7jW+5Pw9786ijSPGzohU/jJyNjiuTF5G9Iy9kRpD307dFftKTWQ6kcyV MSsXbAXchgbKc2PMOGn+6n42EwQrbO5+3aHkyPJF2XZB3ja67UyeMctD/+Z0qVuCEdrbSh 4bmF19wNcaFdzbC7ubW/w9huMFz13PI= Received: from pps.filterd (m0360072.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 53A9vhWL025345; Thu, 10 Apr 2025 16:07:54 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=pp1; bh=Jmp1TuG2rk5K6Ce5PuPbd2zgfuoBes e75oMt4oJEqFw=; b=KeFXTRMrvncRLBLOSZihPcfH8PnGHMOqw/mHIMC9+jcV7r 3tbCvVZgLf/TazLxRstYbgeSilvo9dnkQrP8GLZmdCLP7hdgfS+pkqs9INITQDkg T2HE3mA0tY6cCiOjFIeFG4XrbkilmiOfe4bJ2uXJGkSGYpDWZPzJpRf8Q8UfqalD 1CebmuMJfdmCLXHOg3FqkHKYI/Ii9HIld7NTTOecyj72tFJzSX9SlqDWmWk5FBk1 ZqLBZaAIh98rcIrrrmwglOKbYKDbWtxoar9QCagJyJPXCGZkd7ppURgrDNEYz5xA RkTJiRkBoXLMNPSqxBNFta7pxtSKrRmzyuagJ/7g== Received: from ppma21.wdc07v.mail.ibm.com (5b.69.3da9.ip4.static.sl-reverse.com [169.61.105.91]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 45ww2xettf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Apr 2025 16:07:54 +0000 (GMT) Received: from pps.filterd (ppma21.wdc07v.mail.ibm.com [127.0.0.1]) by ppma21.wdc07v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 53ADaw5Y013858; Thu, 10 Apr 2025 16:07:53 GMT Received: from smtprelay01.fra02v.mail.ibm.com ([9.218.2.227]) by ppma21.wdc07v.mail.ibm.com (PPS) with ESMTPS id 45ufunxs3e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Apr 2025 16:07:53 +0000 Received: from smtpav02.fra02v.mail.ibm.com (smtpav02.fra02v.mail.ibm.com [10.20.54.101]) by smtprelay01.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 53AG7p5N34996542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 10 Apr 2025 16:07:51 GMT Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3550B2004B; Thu, 10 Apr 2025 16:07:51 +0000 (GMT) Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A52D020040; Thu, 10 Apr 2025 16:07:50 +0000 (GMT) Received: from tuxmaker.boeblingen.de.ibm.com (unknown [9.152.85.9]) by smtpav02.fra02v.mail.ibm.com (Postfix) with ESMTPS; Thu, 10 Apr 2025 16:07:50 +0000 (GMT) Date: Thu, 10 Apr 2025 18:07:49 +0200 From: Alexander Gordeev To: Ryan Roberts Cc: Andrew Morton , "David S. Miller" , Andreas Larsson , Juergen Gross , Boris Ostrovsky , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , "Matthew Wilcox (Oracle)" , Catalin Marinas , linux-mm@kvack.org, sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 0/5] Fix lazy mmu mode Message-ID: <912c7a32-b39c-494f-a29c-4865cd92aeba@agordeev.local> References: <20250303141542.3371656-1-ryan.roberts@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250303141542.3371656-1-ryan.roberts@arm.com> X-TM-AS-GCONF: 00 X-Proofpoint-GUID: JX9GiUvvsSXRJxqGU54xz_Dphrw8Y78U X-Proofpoint-ORIG-GUID: JX9GiUvvsSXRJxqGU54xz_Dphrw8Y78U X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1095,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2025-04-10_04,2025-04-10_01,2024-11-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=896 bulkscore=0 impostorscore=0 mlxscore=0 suspectscore=0 clxscore=1011 priorityscore=1501 spamscore=0 malwarescore=0 lowpriorityscore=0 adultscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2502280000 definitions=main-2504100116 X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: CA7C940002 X-Stat-Signature: d6x9uif5wpxbikbfowkok9ie98x97ni1 X-HE-Tag: 1744301291-845269 X-HE-Meta: U2FsdGVkX1+Z3DbD80gGhsBL9ZMDGoJjgdY9D4NMg4sYwwlAaKyM7dXoi8srJ7HCGONcD93yuQhlkXWybVC/z23FB40H23DD8Hyl+ypFb5PLhrViEroMXKMVQgJuJ0hYbbucYb3eHGywgXAP+MiltUCJZHlHfKVowIY/Icc1UbkvvUB4EdpWpxFUx9E0Spi26JUDy4TZxMY73imAtZ/xCJyoN1O3vd0Q96q3SLfGoWIIKGzzm3dQsau87q0x10ouGyT0mltafSVyFNS9eXiPzPTn7JHqB1U6vOMQT0+YUgXYK4+9UrLuuCHAIfL8wyH2IjrNCusecQ2qJFjXE+3bArddBdtqIHYpUXzf2EIwGkKRHwi/IEfrVjCkQE1HZIJ6sQIHdiwUJcv0AHiDS/Ei7djaamii9EYXcO8qBJLrSZEU8cH/KCFS4ArQBcdkY3REyDqCKDqp3izxVvPCIz3AFjgvn6h7/G6aYZEfUbqohgHIedin4CzEwZWV8btR85/k6Gvfulq+p4mRqBsxe9N5AJkXYRm6+1MRTi+ffTZexl++dIRcixY2dPPK79yj9mxRk0ySHJ3ydGXv6idNQLz4NGnJfSKY/ZNzoylU437+7JQHGuXsEkGCBc+1Gt/jQ2Dk3O9llaYJDCnoeRZzPV7GPK0doBa+X72EpZaJd7tRdA6gyvWtAKxSGQ5tDFFcBE1fwy5NKONjarDs7Dk5xkLFfsQl0pdBowrUgTZD0TEDsCTN0sL/hXRwC2QPsBGT/LLurt1nIht122IpBWRxB5MOzJwLeXaVqN5ptv5TN/g7bbxdHp+hRWrJXa0fPtDi43Pv1TZyWphSmEPb8cNwiIWSzjIgcpQVDJSU8KLlD36VbYHI3A9K7xv4iUgawwBxcVcPvUMuKF63GepqzG5OtoQrxvFYif3t/DsNnZ39SvbQIuKeBln+E1J/NLNEh4+TY5yNaOEsXlBF3KLwp7AfW2z cEodVmq0 V9+cKPJk4ln/i/M5UrerrHYS8N1r/FTlVz4N0AQZZzUtmr2MJG97K6Rq4GhmmKO/+aD1ckU1a84NV9nfPOPwJCil++yVQNKha9rgCn0wBWo1Z9I9LxjEuBzHXMpeQvCHJvCEqgZhdXiOVl5Kzl8G9kTMU1XW1vF83q1/B7WU/LYD9b2lIs1VcIhmSVw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, Mar 03, 2025 at 02:15:34PM +0000, Ryan Roberts wrote: Hi Ryan, > I'm planning to implement lazy mmu mode for arm64 to optimize vmalloc. As part > of that, I will extend lazy mmu mode to cover kernel mappings in vmalloc table > walkers. While lazy mmu mode is already used for kernel mappings in a few > places, this will extend it's use significantly. > > Having reviewed the existing lazy mmu implementations in powerpc, sparc and x86, > it looks like there are a bunch of bugs, some of which may be more likely to > trigger once I extend the use of lazy mmu. Do you have any idea about generic code issues as result of not adhering to the originally stated requirement: /* ... * the PTE updates which happen during this window. Note that using this * interface requires that read hazards be removed from the code. A read * hazard could result in the direct mode hypervisor case, since the actual * write to the page tables may not yet have taken place, so reads though * a raw PTE pointer after it has been modified are not guaranteed to be * up to date. ... */ I tried to follow few code paths and at least this one does not look so good: copy_pte_range(..., src_pte, ...) ret = copy_nonpresent_pte(..., src_pte, ...) try_restore_exclusive_pte(..., src_pte, ...) // is_device_exclusive_entry(entry) restore_exclusive_pte(..., ptep, ...) set_pte_at(..., ptep, ...) set_pte(ptep, pte); // save in lazy mmu mode // ret == -ENOENT ptent = ptep_get(src_pte); // lazy mmu save is not observed ret = copy_present_ptes(..., ptent, ...); // wrong ptent used I am not aware whether the effort to "read hazards be removed from the code" has ever been made and the generic code is safe in this regard. What is your take on this? Thanks!