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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8E5F4C3065A for ; Fri, 28 Jun 2024 17:24:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=f9YtjpFEGW/1s+7CB5DWKbgdGekMYXycALoSWbxwKs0=; b=o/rJ7lY7g13rJCctBQJ1+Xv0ab 2Sj0yyKsIYtXIqjfPCgnWuH8J+HetZwXohwjf7BtU/+/dkJXfCQADmKaw+GScpZJ0CdqzfvjC9P5+ d5MZGUOHpdkGML6WRKAd1seqlQIaV+mFzrjzCuLtqFvc7e1m7nOmUgLPwRmRSEX8fi98psX+SMA9m /Q6TuiVGw57GuQ6WRBtEP0xq0NT4Cqi+gUoqSMhM/9m4kUZu+CgRl1YhvZWseRCD5i9fbq9tRuMXS r4AiOhi8zQpO8zQfpgu1Ysw8cmouRZ6mA078bS6zq2G3M+fn3fckQvVnPy4DqqmftMWQ9SXg+Ep+O y5HjL+/A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sNFKg-0000000EUf4-0L3V; Fri, 28 Jun 2024 17:24:22 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sNFKV-0000000EUcl-2iqi for linux-arm-kernel@lists.infradead.org; Fri, 28 Jun 2024 17:24:13 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 859BECE4220; Fri, 28 Jun 2024 17:24:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4A82BC116B1; Fri, 28 Jun 2024 17:24:06 +0000 (UTC) Date: Fri, 28 Jun 2024 18:24:03 +0100 From: Catalin Marinas To: "Christoph Lameter (Ampere)" Cc: Yang Shi , will@kernel.org, anshuman.khandual@arm.com, david@redhat.com, scott@os.amperecomputing.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [v5 PATCH] arm64: mm: force write fault for atomic RMW instructions Message-ID: References: <20240626191830.3819324-1-yang@os.amperecomputing.com> <773c8be7-eb73-010c-acea-1c2fefd65b84@gentwo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <773c8be7-eb73-010c-acea-1c2fefd65b84@gentwo.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240628_102411_892019_3F7D09F6 X-CRM114-Status: GOOD ( 20.33 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Jun 28, 2024 at 09:57:37AM -0700, Christoph Lameter (Ampere) wrote: > On Fri, 28 Jun 2024, Catalin Marinas wrote: > > On Wed, Jun 26, 2024 at 12:18:30PM -0700, Yang Shi wrote: > > > @@ -568,6 +596,12 @@ static int __kprobes do_page_fault(unsigned long far, unsigned long esr, > > > if (!vma) > > > goto lock_mmap; > > > > > > + if ((vm_flags & VM_READ) && (vma->vm_flags & VM_WRITE) && > > > + is_el0_atomic_instr(regs)) { > > > + vm_flags = VM_WRITE; > > > + mm_flags |= FAULT_FLAG_WRITE; > > > + } > > > > The patch looks fine now and AFAICT there's no ABI change. > > > > However, before deciding whether to merge this patch, I'd like to > > understand why OpenJDK cannot use madvise(MADV_POPULATE_WRITE). This > > would be the portable (Linux) solution that works better on > > architectures without such atomic instructions (e.g. arm64 without LSE > > atomics). So fixing user-space would be my preferred solution. > > Doing so would be requesting application code changes that are linux and > ARM64 specific from applications running on Linux. Linux-specific (e.g. madvise()), I agree, but arm64-specific definitely not. I'd argue that expecting the atomic_add(0) to only trigger a single write fault is arch specific. You can't do this on arm32 or arm64 pre-LSE (I haven't checked other architectures). IIUC, OpenJDK added this feature about two years ago but the arm64 behaviour hasn't changed in the meantime. So it's not like we broke the ABI and forcing user space to update. This patch does feel a bit like working around a non-optimal user choice in kernel space. Who knows, madvise() may even be quicker if you do a single call for a larger VA vs touching each page. > A lot of these are proprietary. Are you aware of other (proprietary) software relying on such pattern to fault pages in as writeable? -- Catalin