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 E14E1CA550A for ; Wed, 13 Sep 2023 08:53:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4B20B6B016D; Wed, 13 Sep 2023 04:53:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 462A26B016E; Wed, 13 Sep 2023 04:53:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 329146B016F; Wed, 13 Sep 2023 04:53:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 245A66B016D for ; Wed, 13 Sep 2023 04:53:38 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id F3C78B40EC for ; Wed, 13 Sep 2023 08:53:37 +0000 (UTC) X-FDA: 81230960874.05.1334611 Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) by imf03.hostedemail.com (Postfix) with ESMTP id 21FE020018 for ; Wed, 13 Sep 2023 08:53:35 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=Jwf5rL1z; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf03.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.208.176 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=1694595216; 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=irghFXOamQQNX5fLcZk2WyGaYH9G0dtDSaP941nBse4=; b=vOdNk0ZuUPf/o4Lr2h2IFBZmko/5ay55kcmcEtJLlCfO673Z7U/OERzR/qhkima6sg0kI5 hcE+OlKS0RF5lqtGvp8S+/F7u3ouvjtPZRUB8wiJaAJNmxJBNaNFTW6m6San5+9Z3KXaBE Q648noTi8ITeVdTkxrgM2o3/LzXL2AU= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=Jwf5rL1z; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf03.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.208.176 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694595216; a=rsa-sha256; cv=none; b=ZEWxYHCcrDRC4hPK/JxgNbr22Ugd8SGWAC+QokK5BaZF1JpQ6S4ckMQnkovrmwS8ZSoCLW L4duSXGjv1bc4G3Hu4vPB+cQfzTSRQ2pXYDE/XRhV6ZnVeG8YmNWyDSF/SWCgqlVrPJ+lI vaD+A/ehPNiXySBUErRNY6p1RU2ha/I= Received: by mail-lj1-f176.google.com with SMTP id 38308e7fff4ca-2b95d5ee18dso113723101fa.1 for ; Wed, 13 Sep 2023 01:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694595214; x=1695200014; 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=irghFXOamQQNX5fLcZk2WyGaYH9G0dtDSaP941nBse4=; b=Jwf5rL1zk16svj/QG6mksDZf2uFtERbtG4SX/ktYeBDyV2kc3+VirfFApCQJ9ymPwB zX9rmoQ9JBUGU9eZHZSFCVo44xbRl68KWGUzdDiaPVVW1T7G+G/lx2h7ML1MuxRGxLxD NTCBXUQNyuyTUUjhxz02RK7sAFM/Jhf8Ey4N+YC4cT1Yv/M+I58+b3Qu3zBk/y+uniLZ yrkocOPlJLUt7DVUIvRB84WlD9t9qull70yZGPpf3yUzTsfFLBOhfOlrFppZQla4Aczo VoDxtjHQufUqX6qB/fMcCKdNMHX9W47fKEr9KaqxcYgsEvwhHM5Tmqq00odgzyS/F01O 104w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694595214; x=1695200014; 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=irghFXOamQQNX5fLcZk2WyGaYH9G0dtDSaP941nBse4=; b=xHOZkuJTKLRN+3zKAITjzjHpqCyFZxDJ9x3zorfWVL0+vV28+yTp947xT/OySp/SQh LQSaaVAFQqDuL2zNEkJ3lEC6LU1tbwHxkIldyTIPGweNtPibYRdZcfJ9YnsrzfIj4MVE bi4jVAzuk/uxlRY0/0hn+Z/Y0Xjq69pl/BU8BhDsZ0LC4Jq56VCrNtSGmxx4jvms6CcC 5Sqq4yki56nbEvVFijtj9/qLgZW/QJUJHTP8GeKvEaGxj73o/SYUa1B4W3eXd7wT7NPB v5iMMQiiZJBBqFFU9AdZ+xCeWLx5r0QEf1p8kx0FDxVxdOSNA9lBMMpVH8yiAcBHbBlR HkPw== X-Gm-Message-State: AOJu0Yy51wJPSeo3+bHEyjCZdiqFi+z1Pe6c2A9AqbccTeHopGGuChzS eHQe8cZywNbrES18utAD97Vw+Fk7PdAk9WbdWZc= X-Google-Smtp-Source: AGHT+IGEza02q48TZ+A5LodeGs2jBxD5vU/PGp/0pfGmoly0eyFqGF1Z2ksRNmX1d1xISZ/D1LqVEz8cVJ/HFZvS7+0= X-Received: by 2002:a2e:a282:0:b0:2bd:16e6:e34e with SMTP id k2-20020a2ea282000000b002bd16e6e34emr1549825lja.1.1694595213868; Wed, 13 Sep 2023 01:53:33 -0700 (PDT) MIME-Version: 1.0 References: <20230912103334.2074140-1-zhaoyang.huang@unisoc.com> In-Reply-To: From: Zhaoyang Huang Date: Wed, 13 Sep 2023 16:53:22 +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-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 21FE020018 X-Stat-Signature: xjajzgwzz7rfr7w6qcin838gsbe4xxos X-HE-Tag: 1694595215-534493 X-HE-Meta: U2FsdGVkX18ibQEm3jyRiFs9xp0vshSxo7xqaw13HIpVFFTjo3Dt1EembOApKz+JNTcTKrkDjjPKMismsFMwbq8mMijO8BR94JPj149wKD6GRFMLzPLU8WMiDtT/FoyNl7iiejfS49L+pz96lzpbGhv0mX9x6OYcc0SO11KxAQRrfV5FeicpFzJoUUAEIBmFwS84wY4q0vKXZRLRwv5W61EDYSceXO1Q1oBGlsOc8XpEqrrct2UfbSSRsXOYA3blDhyaz0KkiD0wero8C37aFVEkkW6jf7UAeLajnKQK8tWLIxMEJXeg7xwoU9mIrsB/YNj/OarvsvA4Zps+A09Tr2SR+eNNZ/UVFjqnPNajIVs4dKzrTe2fgBFxgF0VqwCCl1RjMHGzQsvJbas+J1j1cP4NgVXSMoT/zTTMnNj974LbvkXhZl2KLE/U1kqiqZZOVJYQtyO2cIWAUBT4khC+wRH0OaGpvR1SfFSoFwmUG+qyG5iuENyt4Xo9DY6XG4///s9gPHJYVm/BqpEvT8AyuUaj3rKhD7Dm1pdcLNUY2oMosDzVTUNqW80f5/79V9JMPs3JLpLABHiF3P74cxeliapUEdJQ/hysfZ4XNgVCnPmQWLgW61c+s0i3wZRUUCxNB+62USgo+CdnBA937NU0mSDVEXhy+3tR+XhgUyLuVp++xKwpjVGnSxhKNms/IYJSNU5eaRAknp9vQfo0rHiIPgpbzIwIL53FoJzC7bKvH+RCwsJWa3VxpYL2zm0OEx9ueQngt9uqUj9X3zHUcu0mGr0U3ddsIBj49MFHVLJaXEIWroOvwJXPVu/CmT+Cq3k1Tsenpzyr/fZqQLVZuKTReABwNK9HPUTkbBvxOawBiaTXu9mEIwm1BKJ/vifzyyQ7SL1Q0/zPBwP/t24KiXDQNxeyReaevYBvVHTnHchsYLGvOr1DgkGqn+PtyS9J4XX84rNaCBk8wt9IrfHvxFL QzjKrSgs ye4+R6tRKOY8oVXUierSl5mM1Ta6Kr8RRyRP/HnMmaPMhN51dM6GkjOFu8c9Ldx3xdy8rZUMoACPh5H9ipZTRlxc32EnhIsNsTPhis7ZrkGI2qZTtCDF17RlYsmdJiuMqCtnlY/9q8H6suaa0SuYUGPjrywoGg84ITf/7Ub22yPd8e5TFBekABmp8WE5EiR4nJKq6ACKc7vtD1KI6QICFCZKJJzGVAo6HxtU1CmB4WcWmKsZa9PWO+NqRpFQyezZDU5qYnBZFUdY5tF8Adccr+DVbEt/fIEafP+4/Tm8Xk5pPKttj6s8MGIHCXnVtGORc2yU6WHPF9xmV2hrJDJ7kPW1Tm5FXdhedQvB0WhrVFPESMDI75Mt49N1DXAJBxXqQYwjaZcZ91XazBdFB+hahkxbslZXB6/aRlgLfvwnuZ050E4XmcVU/kY7MJxUjqIJpSz7AnfSREYKtONpgQpQ8IM/i/b8jUj0n/sokmIQ+uQCBzmsQN9JvmIdqE1xGMh6Yqdaxh3Z7rS46S8BQjpBqAj+E6Dczc0DBHYaqasXLPQPqujrXZWF9cxhosMB+yaWATwK9GUqt0CLtmOg= 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 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_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=3D=3D>alloc_page=3D= =3D>post_alloc_hook > > > > folio =3D vma_alloc_folio(GFP_HIGHUSER_MOVABLE, 0, vma, vaddr= , false); > > > > if (folio) > > > > //second clear_page which is meaningless since it do nothing to D-c= ache 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? 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_highpag= e(). > > > Please explain why this patch is safe for all the _other_ places whic= h > > > 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. 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!