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 32CF0C83F2C for ; Mon, 4 Sep 2023 18:22:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B3AB18E000A; Mon, 4 Sep 2023 14:22:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AEB7F8E0009; Mon, 4 Sep 2023 14:22:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9B2D88E000A; Mon, 4 Sep 2023 14:22:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 8C7B38E0009 for ; Mon, 4 Sep 2023 14:22:40 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 503DE1A07C3 for ; Mon, 4 Sep 2023 18:22:40 +0000 (UTC) X-FDA: 81199735680.26.E827DD1 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf21.hostedemail.com (Postfix) with ESMTP id 9E6311C0016 for ; Mon, 4 Sep 2023 18:22:37 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=AS8b2VTu; spf=pass (imf21.hostedemail.com: domain of ebiggers@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ebiggers@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693851757; 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=O8BeYj9B0PIcsKjPSsv3IHIjCjB1iQCxHiPL3YgLFn4=; b=Z4tHiHmw303QkP2FmTOm7Moe2QmoV2EtTQAYkgSszCswKsKifwZI2uMYB2rQup/I+oJ4iC TFzVTryEGiIwArFb0yL3DPWCPomodu7YeuEwZyPSsIcQ4VZhjiiFWqfxNFT4UQAJaVhEy7 uDdWq4eHdEtl4hJ25t/RCpfJ9q0sDS0= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=AS8b2VTu; spf=pass (imf21.hostedemail.com: domain of ebiggers@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ebiggers@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693851757; a=rsa-sha256; cv=none; b=jiHpOSikK917THb+XTSM4EWos0izkYRiD6F34D9szampDUGSC2UODU1PAfXbh2tDgTmEIG rifp8gByWAGeW15Jymv0LPqxhXCPaTbgNeZPuVLJB8VzpHUPd/E+qXvRJPrz474BpIB76x LeBdLYYLJk4Ko3em655SNSWtIJb72hE= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id A99A960A6B; Mon, 4 Sep 2023 18:22:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A23D0C433C7; Mon, 4 Sep 2023 18:22:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1693851756; bh=plSadGikF5SVB6fcGNEoFCniaaqZVESV2r2w8EO8OLY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=AS8b2VTuL1498D+vCpK6FGEStRPcO0ZZGAldikbShf2FjQodPosI8qTcReUdxEqo9 vpnBmg1fcoKlXEjpNhe+lKB0Y7XISjNs0vd+I7UWq4WgOUdvIVg7WqKFC4E0llbCso v26MxNCM+R/WC0VxyiAxOyMsmAbaZAJYG0zFGoL6B5GvTgybZ26fPQabTbplckcpVs mC7IOobtcb1u0jbZZulbQqU5evOVbl2x+VBsaMhioEH7gAuqmt0NqS+aJg2JjyRzwe h3jg5neiEN3VVWh6V87hYYdnN1nguT/cJPed0O0U5WFXQouFhsSSCg1XSkMysGQV33 4M9X0m/xSsF1g== Date: Mon, 4 Sep 2023 11:22:34 -0700 From: Eric Biggers To: Linus Torvalds Cc: Michal Hocko , Alexander Potapenko , Zhaoyang Huang , Matthew Wilcox , "zhaoyang.huang" , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, ke.wang@unisoc.com, Marco Elver , Dmitry Vyukov , Dave Hansen , Kees Cook , Mateusz Guzik , Al Viro Subject: Re: [PATCH] mm: make __GFP_SKIP_ZERO visible to skip zero operation Message-ID: <20230904182234.GB30774@sol.localdomain> References: <20230831105252.1385911-1-zhaoyang.huang@unisoc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 9E6311C0016 X-Rspam-User: X-Stat-Signature: fjsecscxywtmj7hu1o49sy8y7bg6jk6w X-Rspamd-Server: rspam01 X-HE-Tag: 1693851757-167453 X-HE-Meta: U2FsdGVkX1+XYICdyARAiF30iQ+G0OdshkiX6QApwZpwq7s8gF/kV5wsZNC7F4MiABOrdOM+4QxtfYHh0PmzWKfh1SUdIykIoyK5D54XsK7SM7T9FRhMn3ueo0eE725zsUuxSF/MEj1uK6JX98rZ9zOO/qyhAqzl4xNupUjv7ADmLv9whQDWELixNL+X1xjmrlO2vvr2MrpwcUF9BXps4sZBuzEmGE9cPh+7W7o1BzFYdTiAXgxcluOB7C0u/fBsItvXM916GlIsxYXWwzXduxJC92oZKsmb0xxOS5cdCeWkagMZh7YG4VCS8wROpweK0PhfDbFWd+kWV2pXpxe2cYadBcoYx0xhXuEDLRCEIYan4ZujWLY35FIhIU+Y9V+iQJfJy/QFteEuLBKMK3IwOj3uD1bwDsigsXwTYrJWSiqTeDgo6CRaDyjvIv+mK4OOVavufJ+wMY0v2YDRalr1sdiFxd5U8WLJpnGoZru9xY63AkBtZajGA5V09iHeM4tgYOFPWjbwyLvGMkrLtPCDVAuHIxDkrA5msqVkGMApuN4089huyyUGHpZHcolxJN06W5QXUHfrGFwYwFIb60Q4afhmKTCnynO3uyHnmBshCLLldHlREcK5gYTXHdB/iYlizOzPWCpk5rQujrzVyPIQcsP1uIXC+MZ2vLfw86Y4A9ab9yz5eMvywk5O1wryov1nigO4VaaGe2y+ORyM3SgSlKqFdL5aMofheMNDPvMEJcdgWm7n0Bfo4d8UsZ/xXSWnL1OsnI0aqHLmGg985Om53QY9zlZa1SCZhQsXQYVpPXc+6KTJ8+QnpmTVONSfyciuuNDOZbu/NCYlR4qhEfNOTDkc61kY9Nlwhd/ccgyop177jdvulX5iYWmQfrnGiFzg86XktSshViURgnC5Vs1X/p8cqZh6+3TXGHBMmy5WQTLxrkuBDfqni0Px3z0iknmnxCjAkpMLtRJVzsQ2CXF U3lWwa3R DLBYFLMBfNExNzlAiXCEgs0wcE0/xaaOK5OX7mFfR68SpGlMGyvojDDYrHZHwhfgnNIcxzlG68faFRkrZ1Nep3USknqXXPdY1GPRaI1vruns2Pvjg6Rk/XRrKb9FZYaNVEhZ1doDmwqCw9JXHIwwjiA8+oIuMge5Bwejsc4bcV8v7g2GMo/lThGfg8UUo7k/x6bsG+XZi/8wpE0dhXWIf8vOERKGt0COfcCeNUFud8agFC2KaBXQC6P1AzWuVFuacQTvJ71UwVzgeH3PPajZ4gD6x/O3g/bIJDu9DFMLSre6Ps+WnywfYrAbeR2g5kT3Mqoh/Gc1iNDozy7hnkoo+2rHW3GOCviACrCyQLMybZOBkGzHAr3uMc0lwsjGD9DWE56c2l470QAsbVVa3CFPdD8hZO02I6imJt7bcVSNzUoWz4txJLKzfegXRUA== 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 Mon, Sep 04, 2023 at 10:34:25AM -0700, Linus Torvalds wrote: > On Mon, 4 Sept 2023 at 00:55, Michal Hocko wrote: > > > > Sooner or later this will become an > > unreviewable mess so the value of init_on_alloc will become very > > dubious. > > The value of init_on_alloc is *already* very dubious. > > Exactly because people will turn it off, because it hurts performance > so much - and in pointless ways. > > You do realize that distributions - well, at least Fedora - simply > don't turn INIT_ON_ALLOC_DEFAULT_ON on at all? > > So the current state of init_on_alloc is that nobody sane uses it. You > have to think you're special to enable it, because it is *so* bad. > > Security people need to realize that the primary point of computing is > NEVER EVER security. Security is entirely pointless without a usable > system. > > Unless security people realize that they are always secondary, they > aren't security people, they are just random wankers. > > And people who state this truism had better not get shamed for > standing up to stupidity. > Android and Ubuntu both set CONFIG_INIT_ON_ALLOC_DEFAULT_ON. I think this makes it clear that the init-on-alloc feature is useful for a substantial amount of users even in its current form. I would caution against checking the kernel config for the distro you happen to be using and extrapolating that to all Linux systems. Regardless, I'm in favor of a per allocation opt-out flag like GFP_SKIP_ZERO. There are clear cases where it makes sense, for example some places in the VFS where the performance impact is large and the code has been carefully reviewed. I don't really like the idea (https://lore.kernel.org/lkml/CAG_fn=UQEuvJ9WXou_sW3moHcVQZJ9NvJ5McNcsYE8xw_WEYGw@mail.gmail.com/) of making the system administrator have to opt out allocation sites individually via a kernel command-line parameter. Yes, it makes the opt out less likely to be abused as two parties (developer and system administrator) have to consent to each individual opt out. So it theory it sounds good. But I feel that doesn't outweigh the fact that it would be complicated and hard to use. How about just having two options: one to always honor GFP_SKIP_ZERO in the code and one to always ignore it. - Eric