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 EDC17CA5505 for ; Wed, 13 Sep 2023 08:17:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 558F06B014D; Wed, 13 Sep 2023 04:17:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4E23C6B015B; Wed, 13 Sep 2023 04:17:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 382BB6B0164; Wed, 13 Sep 2023 04:17:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 223DD6B014D for ; Wed, 13 Sep 2023 04:17:17 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 300781CAA30 for ; Wed, 13 Sep 2023 08:17:16 +0000 (UTC) X-FDA: 81230869272.26.B0A5578 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [78.32.30.218]) by imf16.hostedemail.com (Postfix) with ESMTP id 462AB180029 for ; Wed, 13 Sep 2023 08:17:13 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=armlinux.org.uk header.s=pandora-2019 header.b=sNsEsHkn; dmarc=pass (policy=none) header.from=armlinux.org.uk; spf=none (imf16.hostedemail.com: domain of "linux+linux-mm=kvack.org@armlinux.org.uk" has no SPF policy when checking 78.32.30.218) smtp.mailfrom="linux+linux-mm=kvack.org@armlinux.org.uk" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694593033; h=from:from:sender: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=XR3dh35/QhQEf+862guB3I5IbCeKyOZ1Ck8CZrTaQWs=; b=1FFcY1Y8I2prRbExv3p7wAt2fDZ/Z6A3LhhogJIq3Oq2kUYhOvGlsvrR/i+x7ntUFW2edt XTTsBaAB1RwgvdvMX8Uu/Yt/UZNCtyqS60fzkeJ1of/qoCBs+S4SRRYX06oXo53ceAt1XG kDzUA3/4nhSDwFjFrZ6BF+6gqkjD8Uc= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=armlinux.org.uk header.s=pandora-2019 header.b=sNsEsHkn; dmarc=pass (policy=none) header.from=armlinux.org.uk; spf=none (imf16.hostedemail.com: domain of "linux+linux-mm=kvack.org@armlinux.org.uk" has no SPF policy when checking 78.32.30.218) smtp.mailfrom="linux+linux-mm=kvack.org@armlinux.org.uk" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694593033; a=rsa-sha256; cv=none; b=B4mT9W+k+rOt0KnuWRRrSssbxpCnGAEwyO9i541mEEt1kfmG31THE9nMBZDIGZ1h29v88y Q11wVZ9TzBK56c7Tw1KSEJ/3OkW7FzfDH3ekycu+j7X5DwMs4Mly6CmJzvbE0GPpncDV1x 48LX4qZCCibHL1f38qkSAoJqlp0+Y4k= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To: Content-Transfer-Encoding:Content-Type: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-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=XR3dh35/QhQEf+862guB3I5IbCeKyOZ1Ck8CZrTaQWs=; b=sNsEsHkn+tRAnBd8vQ4F3MyjfW YjdQwu6IW7FMpBKjwmcukhcpSlB7x6XF12uorKvvFex3T5Bkh1cq7uhcStvxSCkAHXr3Tkcp1q2bX AOGrEQ0UC8UG1SRXoEj/IkQ4rRNSipNkr/FuvqzJZeDiVHTZW/37aWVL3N1CbtpAVIRDxZGB4BG85 R1/YTVKgG7IG6SLyerkyLay/in0KEt3utgTJxNp1R5UKTiQ6dXccZAjjB/3yB1fzMfbyXtRkwZN0C x7e0g6PpKiCh0DzAzigUsikVFdNERxsBxHPQWRsICeRTlT1CldSrmfZ/5TB21zJkhdurPJWVuSYRM d7VXL3uQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:54172) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1qgL3Q-000284-1y; Wed, 13 Sep 2023 09:16:56 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1qgL3L-0003aA-TC; Wed, 13 Sep 2023 09:16:51 +0100 Date: Wed, 13 Sep 2023 09:16:51 +0100 From: "Russell King (Oracle)" To: Zhaoyang Huang Cc: Matthew Wilcox , "zhaoyang.huang" , Andrew Morton , Mike Rapoport , linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, ke.wang@unisoc.com Subject: Re: [PATCH] arch: arm: remove redundant clear_page when CONFIG_INIT_ON_ALLOC_DEFAULT_ON is on Message-ID: References: <20230912103334.2074140-1-zhaoyang.huang@unisoc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 462AB180029 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: cn7go8bakjcdkdiapb4owfyx4fe5ucqa X-HE-Tag: 1694593033-457940 X-HE-Meta: U2FsdGVkX1/Hmvx67YG01jh4mxvpMccyfCZZNAvTbBpCxkepNdEiz2K30CDrEZ/UkPh0lZvgS9V6N9MDT5Zf8Vx3HbEhPIwp6DMio/HN/0En3PV2UXKVKyvwhuMC5IzmGXVUiiWwqRYiuBKpB35EYzidZ+N5ccat5D0oZiOHXn36jH44DTZo7p+jdfKYl6Z0P8Y9ByU4XN0vIGUgZQaoEPnNcwFKqYxK8/74ZRrfBAISjEmJqyd4ywjRF0XLxzcT8kJdAu58C6NcVf0Hwz0gZtaX3alKW795ckQ78VtBB/5WVuvcOEQ2d7YJY0XCXH7+MgteO/tFoLaGpTdDpOnfPBNIaMK5aQLJNIhZXhZfX6aB3pM9OmGah9RA6IIPV7CrEr5ZwqGqb7PVj6bsBkh3bz65cmvX2u+vk3mY6bnG7WPOqWqeSHXY1aUuVye8u3FSgvhQx6DgIWbZ8N7JM9SdbY46dHRRzF1MRJC2O/Vp8oPTVQb6BhVrTf0AWeRTSFpvg9o4GXnqrhDRqHm+NriJ/s1sxd1+vfKZBcll56RK4CDqm5Ad9wSOSVai1KWNfwdC7brmi0GmE+f6Tef4FL8Td8j7Fh8k6qmSdW96Rxp/a7mOEvOsIPGvjE+YIeez1huXxzVosn1JYASWwV4Wsi9VRjFBM014t1zyD+Vh2mVXtyjpyql0qtYJHjhwU5VoRfzr+noouYDRhPZdi0xrmyhC8yQRGYjPk3xkp7WKMXBm7rz7iSsdnspwOj3Vtii3LyCALyrR6E2HY4m2KkYpLGK1gCNIMDxIfvO4ArxGLv0DbY5U5VYumIeBOazEHCIkdEtmUUs5Y3zTi3J2OJnu5IcBFpmkl2dkf6ZXX05nrVJZXctXFFWjjzvGIIFd8bq2ltd4m1yzdr9P0Hcv2E+2DFFqPDqf3lMhNJOHrzt6voNao0R1nRvRx7AUBnM7G8zpRrKihDSJeYPqqqpeGQyXPM1 NeB6nkxr aohkV6OQFK5SoKgsMmUP0r5OrJYWjoLe18uPkPdqrg6kSnirAqwo/0Lwc64LWL62Pdcj1UenUG6hP80xme0QU3cZ57eVvMCK0Vtf194JrpMwXc77R94MOp6h6N9YSbb9QVOmovFWMfo9CwtuDC3WcLlrGHwcQPwAXAdIMCpGIdw0av/G0XoPnfcKrAdOun6RTonuFUEWzeTgaMkkhiU0j2NQA08E3Aoth/WIC+6uJkR4dXQHs9pHyAX/pZsEbroMm9wLO8fcwLyIo8RNXAmcSCmej98e2zXntEjxXB/EOyis5+czxIbGb3OWWYGXLWY3r2qkgazC8Rij5xNnaZUTQpN40KLe53Am2YNfhNS5GTiTtFfByP1IVG8y6r41AKxCO220CyGZhnaYTUmfLnHE/RzHsQswA5RDElippJpu21DADd2zHrct87BTNvtcX5ObTDV9nV8Qq57xlAjmzqYMF2J1pLdd/OP2hWNxSlsMYyFX2yICwdX7LDXE9v07rEMbHk4q/OXdmRpXJQCqSlwQPtZ4CTXA37GJugikK9JdqlYY8wcW7vI2lTj9dDa3jq7GoNGjlAi+d3QfzQK20NJ1H8jUw0yZmE3xRt+OWhN5Hm2zMMCC93N80q/V6Ad+qxlWswhD3LTx+p3bSR+l6Fevp9EmtxtdF/VBKuvHU+bRnfSYTSAjdk9pn/FN4XA== 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: On Wed, Sep 13, 2023 at 09:13:14AM +0800, Zhaoyang Huang wrote: > On Tue, Sep 12, 2023 at 8:18 PM Matthew Wilcox wrote: > > > > On Tue, Sep 12, 2023 at 06:33:34PM +0800, zhaoyang.huang wrote: > > > From: Zhaoyang Huang > > > > > > Double times of clear_page observed in an arm SOC(A55) when > > > CONFIG_INIT_ON_ALLOC_DEFAULT_ON is on, which introduced by > > > vma_alloc_zeroed_movable_folio within do_anonymous_pages. > > > Since there is no D-cache operation within v6's clear_user_highpage, > > > I would like to suggest to remove the redundant clear_page. So if CONFIG_INIT_ON_ALLOC_DEFAULT_ON is not enabled, then what ensures that the page is cleared? > > > > > > struct folio *vma_alloc_zeroed_movable_folio(struct vm_area_struct *vma, > > > unsigned long vaddr) > > > { > > > struct folio *folio; > > > > > > //first clear_page invoked by vma_alloc_folio==>alloc_page==>post_alloc_hook > > > folio = vma_alloc_folio(GFP_HIGHUSER_MOVABLE, 0, vma, vaddr, false); > > > if (folio) > > > //second clear_page which is meaningless since it do nothing to D-cache in armv6 > > > clear_user_highpage(&folio->page, vaddr); If this clear_user_highpage() is removed, how is this code then safe when CONFIG_INIT_ON_ALLOC_DEFAULT_ON is not enabled? > > > > This is, of course, not the only place which calls clear_user_highpage(). > > Please explain why this patch is safe for all the _other_ places which > > call clear_user_highpage(). > Here are all positions called clear_user_highpage which are paired > with alloc_pages. IMO, it is safe to skip the second clear_page under > armv6. No. Looking at, for example, the v4l case... This allocates a page and provides it to userspace. The page is allocated using GFP_USER | __GFP_DMA32. This does not set __GFP_ZERO. If CONFIG_INIT_ON_ALLOC_DEFAULT_ON is not enabled, the page will not be initialised, and thus we will leak any data in that page to userspace. Now, it's not just about whether that configuration symbol is enabled in the kernel configuration - there is a command line argument to consider as well. CONFIG_INIT_ON_ALLOC_DEFAULT_ON can be y, but with init_on_alloc=0 passed to the kernel, if we remove the above clear_user_highpage(), the kernel then becomes unsafe. However, it's more than that. The kernel allocator has no idea that the page will be mapped to userspace, so it can't do the "clear the page at the user cache colour" trick for VIPT aliasing caches, which ensures that we hit cache lines that the user will see. So, I think we would then have to add arch specific cache operations to write-back the zeroing of the kernel mapping, _and_ cache operations to discard any data in the user cache colour. So, essentially, I don't think that _even_ when init_on_alloc is enabled, we can skip calling clear_user_highpage() as that would lead to data exposure to userspace. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!