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 DB955EE3F01 for ; Fri, 15 Sep 2023 05:47:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 321506B02E9; Fri, 15 Sep 2023 01:47:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2AA796B02EB; Fri, 15 Sep 2023 01:47:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 172596B02ED; Fri, 15 Sep 2023 01:47:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 03D4B6B02E9 for ; Fri, 15 Sep 2023 01:47:17 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id C4956C090B for ; Fri, 15 Sep 2023 05:47:16 +0000 (UTC) X-FDA: 81237748872.01.09BF49D Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) by imf16.hostedemail.com (Postfix) with ESMTP id F347A180022 for ; Fri, 15 Sep 2023 05:47:14 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=EDF6o5S4; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf16.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.208.182 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694756835; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=a5dc0RapsJHRQN53o8cJrIr79i5yRR+ziDw1tWj/hHA=; b=hv/zysOEIzj8gXVKPwjzeyYYbiZxmsHUZNJqXIBzIWU3g3nysIj+ZiSBnVuLmPmIv+9UkU n6hfz/8OAl746Q4cjHQyhm3+YCAdu1fpWLLKyR3L6MEvYDd8SxbvT1rFMpBZelPdvZdvFD 0bdS/US/KGPTM0Z2bt+CqmJ0OPKCfLw= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=EDF6o5S4; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf16.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.208.182 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694756835; a=rsa-sha256; cv=none; b=au3TQb0B1KhcurVPAulGRJcIMHI5DIWrcSuhwcrhptjBmHrK238I7J3/0iNcv37zJdFa7v 7G2m/U1ZpZht4kcpNRHQv8oVKIAmffhuTfwKDThqaCQpvNcNoHf88DblP2HB+7vbYi74L5 Y/lvoNgP0O1YrREG/3ZT6xtMRlBsI1U= Received: by mail-lj1-f182.google.com with SMTP id 38308e7fff4ca-2b962c226ceso27342921fa.3 for ; Thu, 14 Sep 2023 22:47:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1694756833; x=1695361633; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=a5dc0RapsJHRQN53o8cJrIr79i5yRR+ziDw1tWj/hHA=; b=EDF6o5S4XoU7LSNQf8+WQLFfW9RMM2IUeImKedzjBjt45jb8bArWQ0J856XzLvyLNC P6k7V3A3PAqTZJ2HmGEXFs+3u3vJWHyy3Rw7GgiKu1t2fLn4QUdoCwsT3PoFplFBR56U M1uhlZ2Ce7T/It0P96NYnntm8o/vcyy/XlPoqPLy4GMNcxfDBf1RfnGg3ytOiazfgPnW qXLPoZyOZ5U6RDLHUL3C50jxpPgud2c8XlcB6kG8y+vKTMJPNuvtX20n1FTxnE6LJYaQ sO1wBVtgz8zrUZnEixYOmBEFzswE/0AbZeyqAGA3iQ/5kQWcd2+3h96EUT3AJbLbgpoH 4BVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694756833; x=1695361633; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=a5dc0RapsJHRQN53o8cJrIr79i5yRR+ziDw1tWj/hHA=; b=AKFVMC2SF7gADZ/boRiNhmqPB5gdDW+rFixOVflTeo7OleTzNETOWurbZiLCiHcG2R /KPkNzzHbjyBjNHvE785WoL0WQ5Cw8TkLqN4fwhEEish7RJnvrqTPT76NEhjlYkDmNmJ LIKRTnvJp3R3XSt7B71dGDBjkOYbQYkdci0CeFGN8rBen8IZ2PsAjnExEDjS7WM7J8dm 9kaIJxPd3NXbzFgbF5sQ5RAD4IjWOLtZWjukz7QpCtqUyqsvL5PnHdZ7pynFYBvKe1cO lRzyOOJ+3quJYV2TRX4AJcoSmSM/oNqfWlb6/tZg9NC6Usu9GJAcCpgtMnlt8n9/ZECN +xFw== X-Gm-Message-State: AOJu0YxAP467Lz4utNrQBnBtxt2unl6tBZn95ImrjAOQ3SyApLnataFE ZOTY6Gq7X4D7V/wBOehHIwDl1OHBWQbZNnVSwpk= X-Google-Smtp-Source: AGHT+IHvdaJpFwbo/Bxy9YcFi/E9XHr2+yJoPfdexlwLicIjMp5w2xNyBGPYT2kgxQDJpBlowPT54BifZOgYPFqahto= X-Received: by 2002:a2e:494a:0:b0:2bc:d634:2210 with SMTP id b10-20020a2e494a000000b002bcd6342210mr623143ljd.16.1694756832856; Thu, 14 Sep 2023 22:47:12 -0700 (PDT) MIME-Version: 1.0 References: <20230912103334.2074140-1-zhaoyang.huang@unisoc.com> In-Reply-To: From: Zhaoyang Huang Date: Fri, 15 Sep 2023 13:47:01 +0800 Message-ID: Subject: Re: [PATCH] arch: arm: remove redundant clear_page when CONFIG_INIT_ON_ALLOC_DEFAULT_ON is on To: "Russell King (Oracle)" 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: F347A180022 X-Stat-Signature: 3m9xwt6aahubk9kg3eumki9nmfusbzqe X-Rspam-User: X-HE-Tag: 1694756834-351009 X-HE-Meta: U2FsdGVkX1+aKD8d3btzDrv75gwtNov3K9vr5FBm0hLcodVRiOe2cJR//IrRkdhMDz3QB+QYCGoZfEa/wGhKJc5sbwWMGiO8TDREKnJv5317vAkPadQx6unMe0M+boU/i9KVWGab+Kpbj73nmMTgRb6/CjbCEnP23XIro2Z2hiektmfpGJIjN06SbZM2moHPg1bZ+Dtd6Qc8Sk1HNBdNE2Cgml4amfPhhODKDvmTYwxVUZJqYQWX7UHZp2r7TKHtttucdkhr1aeV6BaF8N9VKZ/VbpsZBT4M/oQraHYXANFAmw7jNC4JIUK/BF7TQ9lnTft9YGXaO2D6F6xFCfRKuMHFF7Gs/W8vLRZ3tg78/nkDvaHArVzqm7QdV7iXVazFDW92G2k3DJ8Bwws8kfn+/fbsUfV0xVeDlpFiMdNBVBr/4IU239M4vojaYrIDJnmzKYRWK5vzTh8z1O7NklSp+GzWvqg1VQ9MqCeFJyz+u43G7jO0XoVR9P7oDV/T1corgwKMWSWEzewL6xzgOnpA8bSE0I691EObQ3LelgL/QhapvPXTMI9qiXMrg/KHHom/92W9INP2IILjjroFi7q22pL85+DsOxprWfDOHZB2igdG3afxozO3EQJW0XhGvctzI4Kh4PpBqzRfVxNDZkMyZtTAlc2j/2+3yAV5Wk1iNRs+bf6rSqjTA5agGDjN4R+aEjwepkM6ECkXQrRV4NlENRy+eIWZ76t2NW3j6enLAtHcF9iUEnbphoKrDZ0dZhCxpmmW+VzkpS6FLnOm6jTlT1C0us6hmTGe4bijQT388esv+jqz9V0jnca+baqYiRB9AQ5Y6kHO8IV1thNo1Y7Ewad3mWXpuyBopfQjp2nESVS4D95yqAqBGHy33/Yb6o9zU5hb9iLtUzO/sJHAMtwDhAT1YJy9SUGt1317RKAIBThKIEm72Xug5uUUEYE4ZG4aOLwoUXNXN6kRMQ1ADFs 2b/TQqqF Hu9iClO0+GJZCebZ2fYd7tbFqvwNDI3fq0JMbZMUzeYlbTHcHjvZiW5GXXA+UbPlwFw4enbajtpVgmtmNvKyfUT3DxIrMxj6bqCB0PfFRC2Smd2K+EBVHyIjLRnU5qEfX4BQnmGG1v/s8DScWHCv0//OfY9KkcHRqOGfk7/Bh+oOzi7Z0Mhop75SA5wMzryXENaGP+7hLNz0zgJ5VB/8gAinYRyUAS7vMjb+qvlcnZXLe3gqb9a90dBIBZ4WwKC9zax9sIJK4nCBaWuKvJfbz9Z1afiZO+YdpOH/HE2PyE2E81LrdzSMCdUmWosN+E7gMiDMVRs99rqZ8CRvO4RPGCO0iMarzI2h4QJmYTW0uDptqjBbquMjYFGvIlk0BB3unFIrUKwYzPhXpKoDHiVyDnIXTxdjcpj90eRVtp1du3Uw34PKLoWmbJkF0CCO/r7iNn1kWrbMPVivTMQaMS1h0vWpUZeKyfQGPugKIZN9/9ugV1ynJy+AVDE+Ts5lgSY4Vi7JvMwTQ/j64fpITV6CHPnCKntaXq/XwpfOKL2Jc/NlLOtQCm1+cy9lPOJ+7nifuAw/c+ZP8HGHOJJfxKFqARQR5ujdVaqfIJCmL 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: any further comments, it is arised from a real performance issue observed double times of memset in ARM A55 which should be waste. What this patch suggest is to remove the latter one while ensure the page will be cleared under all scenarios On Wed, Sep 13, 2023 at 4:53=E2=80=AFPM Zhaoyang Huang wrote: > > On Wed, Sep 13, 2023 at 4:17=E2=80=AFPM Russell King (Oracle) > wrote: > > > > On Wed, Sep 13, 2023 at 09:13:14AM +0800, Zhaoyang Huang wrote: > > > On Tue, Sep 12, 2023 at 8:18=E2=80=AFPM 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_highpa= ge, > > > > > 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_struc= t *vma, > > > > > unsigned long vaddr) > > > > > { > > > > > struct folio *folio; > > > > > > > > > > //first clear_page invoked by vma_alloc_folio=3D=3D>alloc_page=3D= =3D>post_alloc_hook > > > > > folio =3D vma_alloc_folio(GFP_HIGHUSER_MOVABLE, 0, vma, vad= dr, 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 wh= en > > CONFIG_INIT_ON_ALLOC_DEFAULT_ON is not enabled? > when CONFIG_INIT_ON_ALLOC_DEFAULT_ON is off, want_init_on_alloc() will > return false and then clear_user_highpage will be called > > > > > > > > > > This is, of course, not the only place which calls clear_user_highp= age(). > > > > Please explain why this patch is safe for all the _other_ places wh= ich > > > > 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 unde= r > > > 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. > as explained above, clear_user_highpage will be called in this scenario > > > > 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=3D0 passed to the kernel, if we remove the above > > clear_user_highpage(), the kernel then becomes unsafe. > Both of CONFIG_INIT_ON_ALLOC_DEFAULT_ON and cmdline configuration take > effect via the global variable init_on_alloc which is judged within > want_init_on_alloc() > > > > 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. > ok, do you mean you will update v6's clear_user_highpage from memset > to D-cache flush things? > > > > 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. > This patch only suggests making changes on the specific v6 > architecture where clear_user_highpage equal to clear_page so far. > > > > -- > > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > > FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!