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 E9B5BE77170 for ; Wed, 4 Dec 2024 16:29:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 60CEB6B007B; Wed, 4 Dec 2024 11:29:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5BE306B0083; Wed, 4 Dec 2024 11:29:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 483CD6B0085; Wed, 4 Dec 2024 11:29:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 2230F6B007B for ; Wed, 4 Dec 2024 11:29:43 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id BA0B1A1003 for ; Wed, 4 Dec 2024 16:29:42 +0000 (UTC) X-FDA: 82857812058.25.A7FA60E Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf06.hostedemail.com (Postfix) with ESMTP id 6362B18000C for ; Wed, 4 Dec 2024 16:29:30 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=iVKb33xa; dmarc=none; spf=none (imf06.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733329774; a=rsa-sha256; cv=none; b=NgV8RMmzCKVueeQxHUTM8Ai0+9e9o8LrwBqVOrwCeK8oix+7mlGQr8Rq9FY9H/FofFkjuC hQBUD1asd2n2BXEtbCDQKWYE/RFlTyCi14uI3DBvyoqETFaV+UWjaGSfhCKCV60eLZZLTs 5xWThciHh5oHgajKv9a/GJURR1FGGF4= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=iVKb33xa; dmarc=none; spf=none (imf06.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733329774; 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=TeDvk+DFUy0cyWi8NwkWYJIWousmkq2THX+IF1OUp5Y=; b=JVQtAON4aOWsVeGR4fBVZzKwFXPByGTAk1SPzhyH109MVuxYOrL90DzLjvILfV1qh2lK67 wvoZFUbkF2mwX6B0GF+wMR/eqcMIYIueAAjHdEzSpbAt9kVbjWDnA8DSapRE6oc8mxIno7 vPWs+ACKlC0GSiUXGcQpplkubbbZQTg= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=TeDvk+DFUy0cyWi8NwkWYJIWousmkq2THX+IF1OUp5Y=; b=iVKb33xackS5QtKM5CqC2T8yST 0WrYqXFh2LIaPBX85LUhhkeu39J1TXZE28Kopv72bx3FWJFBaAUa2qZE/hb77BInXLtFliE1NA2nW bo9yugRexcIpD69ONk1atnG5zCZ1rnk2dxWDM4zag5k8kHduNX1j/oHUmnG+iQ+NvjFiZtZJMJAyn r1Hqz0tPa3JmlG8pvinGDKn0+nNmXjebEVV2obmEGOq9Vx/Esh+g8UIml43m1F6CsSPnFHz0fImp2 pQS12O/eLXRwHz4v461dUc1r/uxDzYK4RKP2iuxc4Aif6ZctuO02rBPqgdhyuDRWM8zDC1hjY2cm1 y3sk4z9w==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tIsFq-0000000BeCj-2kGP; Wed, 04 Dec 2024 16:29:34 +0000 Date: Wed, 4 Dec 2024 16:29:34 +0000 From: Matthew Wilcox To: Zi Yan Cc: Vlastimil Babka , Geert Uytterhoeven , linux-mm@kvack.org, Andrew Morton , David Hildenbrand , Miaohe Lin , Kefeng Wang , John Hubbard , "Huang, Ying" , Ryan Roberts , Alexander Potapenko , Kees Cook , linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org Subject: Re: [PATCH] mm: avoid zeroing user movable page twice with init_on_alloc=1 Message-ID: References: <20241011150304.709590-1-ziy@nvidia.com> <9942C08D-C188-461C-B731-F08DE294CD2B@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9942C08D-C188-461C-B731-F08DE294CD2B@nvidia.com> X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 6362B18000C X-Stat-Signature: nebtfgz4bgi791jeip3h17beo58f79cx X-HE-Tag: 1733329770-729835 X-HE-Meta: U2FsdGVkX1+Yj2MGLDHJcJROkzw87mmZZ9j8ALzS/5ehDKq6vx3dc0NSCFqZTQIBBKs33jvFaSCWFIZ3D/L1XEXw1fTj04mFwTEla5zQPxXuD0f+xziSnA74CH41LGQOAAE7jrNFvLOsK2HhDRraxdgPd1u8G9HFoNxIKtv09kCn+U07HIPwwPVvDFs+2a/RplCSuWuC0ZOEoUAydP+K+YwMoN4lgFQON4mNJcrRACw+XbaAr1Rh1EoJrnNsvu8vtXIhJw4Lqq6u8clarTiHkY4KoQsr7pPQi2wJgwn6Vjk7ZSAmeXwtY3PPWmI59HA311EjK1Zlv5MX84BzvEI1xvVshIQOeNM0S+R/h3+AZb+/Kmu0qreysTYj/sVZawPcWygDhfgppqvM7oNuow60nRYkGfJlWI4/N0ZAB5qaH7QRGQCglmAxw9enarWAozuArnsUkFWRSxMNxBzAimVuSndiWC0z8y1gF1dg7tsylhmBQ51sX5ltoECLwdO4gp/XK3ym8dKtDpcYtwrDO5U7XPN+go51ZNscpr6ARej0tMz/nl/de8DSnK9x/CGi7cgrzHomY+7EnjCCCmeD63RwQ+gL7DNNlOUEhSTn9UfLx6SNYvKGL1fk2dM+mjmlxvjB2ZuOpM9+lp9EiOvG9De+G1bYyHCo5HC1YphqpvoIQnXTOLE+6ZPfQkaybYU/zkDt2UU4kMp2TqUfQ9GLO9lvSw3MoEsAj5cLAIn5UpG0mLWe9ZgcjD1LZJLpPT6tzgVnzrS0ctrHxTHU4uyGytw1bX83Qt5Q/HR1dyn+pJ/p/DggTTELpkaD0LsEuqWe/BtnuSetrXPORH8zlg8prQWS7rhyDraE2O3SPqSF2XPHfk8YMh/I9pzoGUoNCGH58SkHaTGmfIwAMuw2A590P32P+igQ/leWEfZXcdAyrlYb6KTyH4ovrNAojBtvgBVELU6FYTQRlBgMbZFNj8CrCPa eaiTg6fj QT9HLSlTd8sUsrNJ7duPGdqIRwBWKv3AoofpHNCSmt/bT3C9z8iWn2ckADXINIEfCR1yUj5OnUpjg/oQxdNjbaRUwrdS50pXq0Zy3etFhN6CCWw/iyfTlMTkRnJaTANmiXtU3OiRI3Wb3EjprnosGPCK13KhO6hZxzAolmi4MIIuzzUBgtVAIfRarIn61JIupgYY+F+/ZU2wCBDKOj+CNtQh8iD6nTRy65mOLV6uTsvUs/PJEkcJ5AKrq8nKsVudrz9zQjiOdJDQ7gv+7V9GwE0fPsg== 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 Wed, Dec 04, 2024 at 11:16:51AM -0500, Zi Yan wrote: > > So maybe the clearing done as part of page allocator isn't enough here. > > > Basically, mips needs to flush data cache if kmap address is aliased to People use "aliased" in contronym ways. Do you mean "has a non-congruent alias" or "has a congruent alias"? > userspace address. This means when mips has THP on, the patch below > is not enough to fix the issue. > > In post_alloc_hook(), it does not make sense to pass userspace address > in to determine whether to flush dcache or not. > > One way to fix it is to add something like arch_userpage_post_alloc() > to flush dcache if kmap address is aliased to userspace address. > But my questions are that > 1) if kmap address will always be the same for two separate kmap_local() calls, No. It just takes the next address in the stack. > 2) how much overheads the additional kmap_local() and kunmap_local() have. That's going to be a per-arch question ...