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 A7631C4167B for ; Thu, 30 Nov 2023 13:32:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=s+OwrQre2Kxj7pUguhbWfNzVVUsD3OB3DFHFqUiezdg=; b=oTsGpGd+HIO7sY KJ4MpT4//Vkl+af4jm/7nfcgwxHA0bmMoaluk4AESjrRv0Nvo9TfNKcLS0P7kG90eyXmma0VZkGqC pbiAT1kuVLNX8zq7B3/aYqa5V6Bdnd7aZzGM124cQDBkdTSUX5pboYl4wgomMLIUZsgVt5+7ctgVs LrgpamXNs5mjA3fwrn94lPGoPFgEZp91lHfFbc32LIelkMoL68SgOhbTRSwYq7wcZIeFk+x2R8ScT sInksNbHXUNkK1ZiqkEll+K6PnvTBTScY+T/iiDa2Mq3paLRCMGfWVAnLmMENVlQRMyrVWuyXxSUK a96FIRiKU6EjBxLuzpOQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1r8h9Y-00AyAp-2m; Thu, 30 Nov 2023 13:32:28 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1r8h9W-00Ay9q-14 for linux-arm-kernel@lists.infradead.org; Thu, 30 Nov 2023 13:32:27 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CA30DC15; Thu, 30 Nov 2023 05:33:10 -0800 (PST) Received: from raptor (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 415D63F5A1; Thu, 30 Nov 2023 05:32:19 -0800 (PST) Date: Thu, 30 Nov 2023 13:32:16 +0000 From: Alexandru Elisei To: David Hildenbrand Cc: Hyesoo Yu , catalin.marinas@arm.com, will@kernel.org, oliver.upton@linux.dev, maz@kernel.org, james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, arnd@arndb.de, akpm@linux-foundation.org, mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, bristot@redhat.com, vschneid@redhat.com, mhiramat@kernel.org, rppt@kernel.org, hughd@google.com, pcc@google.com, steven.price@arm.com, anshuman.khandual@arm.com, vincenzo.frascino@arm.com, eugenis@google.com, kcc@google.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org Subject: Re: [PATCH RFC v2 19/27] mm: mprotect: Introduce PAGE_FAULT_ON_ACCESS for mprotect(PROT_MTE) Message-ID: References: <20231119165721.9849-1-alexandru.elisei@arm.com> <20231119165721.9849-20-alexandru.elisei@arm.com> <20231129092725.GD2988384@tiffany> <4e7a4054-092c-4e34-ae00-0105d7c9343c@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4e7a4054-092c-4e34-ae00-0105d7c9343c@redhat.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231130_053226_422159_A27B07D7 X-CRM114-Status: GOOD ( 24.46 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, On Thu, Nov 30, 2023 at 01:49:34PM +0100, David Hildenbrand wrote: > > > > + > > > > +out_retry: > > > > + put_page(page); > > > > + if (vmf->flags & FAULT_FLAG_VMA_LOCK) > > > > + vma_end_read(vma); > > > > + if (fault_flag_allow_retry_first(vmf->flags)) { > > > > + err = VM_FAULT_RETRY; > > > > + } else { > > > > + /* Replay the fault. */ > > > > + err = 0; > > > > > > Hello! > > > > > > Unfortunately, if the page continues to be pinned, it seems like fault will continue to occur. > > > I guess it makes system stability issue. (but I'm not familiar with that, so please let me know if I'm mistaken!) > > > > > > How about migrating the page when migration problem repeats. > > > > Yes, I had the same though in the previous iteration of the series, the > > page was migrated out of the VMA if tag storage couldn't be reserved. > > > > Only short term pins are allowed on MIGRATE_CMA pages, so I expect that the > > pin will be released before the fault is replayed. Because of this, and > > because it makes the code simpler, I chose not to migrate the page if tag > > storage couldn't be reserved. > > There are still some cases that are theoretically problematic: vmsplice() > can pin pages forever and doesn't use FOLL_LONGTERM yet. > > All these things also affect other users that rely on movability (e.g., CMA, > memory hotunplug). I wasn't aware of that, thank you for the information. Then to ensure that the process doesn't hang by replying the loop indefinitely, I'll migrate the page if tag storage cannot be reserved. Looking over the code again, I think I can reuse the same function that migrates tag storage pages out of the MTE VMA (added in patch #21), so no major changes needed. Thanks, Alex > > -- > Cheers, > > David / dhildenb > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel