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 C52E7EB8FD2 for ; Wed, 6 Sep 2023 14:17:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 02F36440169; Wed, 6 Sep 2023 10:17:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F213C440151; Wed, 6 Sep 2023 10:17:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DC26B440169; Wed, 6 Sep 2023 10:17:51 -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 CB1DB440151 for ; Wed, 6 Sep 2023 10:17:51 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 084CBC06A9 for ; Wed, 6 Sep 2023 14:17:51 +0000 (UTC) X-FDA: 81206376342.01.BFDA38E Received: from mail-io1-f49.google.com (mail-io1-f49.google.com [209.85.166.49]) by imf24.hostedemail.com (Postfix) with ESMTP id 2A9BF180025 for ; Wed, 6 Sep 2023 14:17:48 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=cu7wWAgc; spf=pass (imf24.hostedemail.com: domain of glider@google.com designates 209.85.166.49 as permitted sender) smtp.mailfrom=glider@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694009869; 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=Iu7OT2bcEXCIdHfig8w+3vXulx2YiGto+l76rBqKbA0=; b=bFwFSt4q2fdk97hxAZhCuEIWMNR/0e+6JWg+yI+84/04QDF9lstMIELnY80eheBHKL1FDL P/DUD8llIo3KX2dPfr1VSptoijlSlstpt1sEHVXUL5FfJTwLQSHxCIpWlLvg61lTQ7P81y HHKf/NkIhCHq3ca29s9kFvMwHXi6UYs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694009869; a=rsa-sha256; cv=none; b=1JnKKtN3YJPUBNk5RIwPXkqwyR8iqcCIcFCWgCxcmebiqix5GqNoOFq1li0nzqgOa+xoy+ dYll3/oeUHzYDMAqA7uYOzf4L7YeTzGfBwMidj2qCec2Njzp1aiwTjYtMba0j+4v5zWcXP m+kSvVzuaOQs2XkMJNX4PJPYniZHfVE= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=cu7wWAgc; spf=pass (imf24.hostedemail.com: domain of glider@google.com designates 209.85.166.49 as permitted sender) smtp.mailfrom=glider@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-io1-f49.google.com with SMTP id ca18e2360f4ac-7951f0e02ecso155958239f.0 for ; Wed, 06 Sep 2023 07:17:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1694009868; x=1694614668; 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=Iu7OT2bcEXCIdHfig8w+3vXulx2YiGto+l76rBqKbA0=; b=cu7wWAgc4TGDkZeKb4sdFjmWv56HaGQsMvhTy3Xlf9oZiqvXhp92LKkventAF4HvmE OFFvCg09lxI+ODCSjDxbvk0pnNG3MWZmrGNzEkxRvhdvBbdcIh4u9MZltKzecsDT36Ci R6fUvrdtJZroSSGcvwizSh5TuYWmD4R2Nwnu4rutmM0WEKu+ySzHOgkp1FkHkRUdDegS nVso/f+2lpkXeaKGs/qIO0q75gzD2ruYHk3MUkAoCL7usw6iVrcd59A8wURor9ERNZbf MhCQZ3oLiFBZ1KE7d+xL1TSSEsgxze2D+YV4/ZEEm2IS3HijV1qffIoHadh2dPnSGBgR i1iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1694009868; x=1694614668; 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=Iu7OT2bcEXCIdHfig8w+3vXulx2YiGto+l76rBqKbA0=; b=VwicHFZ82pZFMGFq8mk7BetqB0IGqS3qoKnvbxPx/ziJn5d04B9vGo1LJeEPZ3OEcs JV6gIyHiI6Tbm5PgzVfn6qVO81R7b9gjF7kXR+MHCL6Gvj3JjJ8v46VxaZVLTB6B2oUV AgbPmvHvR0cCGS8lWS8lw4qdjrDoWTkVSnm5dvuQodSM9juHG680FpfmTkqxmwANw+mq 0RhKqJSI0faGbuiFa+IphY9mskrcKXaiIVvdyj8WGp8xAlfi0IpvCIKN7N+RWqKiEixi ZsbWA2UxUErUXQzLD1zSj8eItoKFCpkj0jDRcidHUb1Y5f4PI7mz73cOQ2vRaJi+2lA7 HWFw== X-Gm-Message-State: AOJu0YzTCdPDibBt3so2YF6xYpn/L7kKGCv3P8Lxr1qP1aX3MCQELCUg FIgfisB1wQx+CCiz9t8a0zwmx2gZ9rSfZLkd5PGFdQ== X-Google-Smtp-Source: AGHT+IHQkboujHrOaSmdEGFmIRBPqspCZbW38QdHA2LAPUgocyuSTB4VDQ7FGTDlp2rZC7IOFjMfKv+zIM8qBv3LsDw= X-Received: by 2002:a6b:4904:0:b0:787:4b5f:b6cf with SMTP id u4-20020a6b4904000000b007874b5fb6cfmr17444605iob.5.1694009868214; Wed, 06 Sep 2023 07:17:48 -0700 (PDT) MIME-Version: 1.0 References: <20230831105252.1385911-1-zhaoyang.huang@unisoc.com> <20230904182234.GB30774@sol.localdomain> In-Reply-To: <20230904182234.GB30774@sol.localdomain> From: Alexander Potapenko Date: Wed, 6 Sep 2023 16:17:07 +0200 Message-ID: Subject: Re: [PATCH] mm: make __GFP_SKIP_ZERO visible to skip zero operation To: Eric Biggers Cc: Linus Torvalds , Michal Hocko , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 2A9BF180025 X-Rspam-User: X-Stat-Signature: c39tg3hinjoahbicdkt4dekhnatmot68 X-Rspamd-Server: rspam03 X-HE-Tag: 1694009868-369981 X-HE-Meta: U2FsdGVkX1+8U1AF1/VRdFXvD716ENz+OvXA92Q34yJioUQqL8iaOMxCdfCEBiqy2PhsP7ogMZ/xDYszoPTWVezTSyESHXp4kLtX+0gymE328QJ8XcjVfUXOihYjRp9lBYCP94vEfq+BZ2rg9/mUmptnPVeByp8ksd+z1SS7dlKPg8yBVqSlHFJt3XPGz6keZDqHx3JwvtFE/7HzK0l313iKilm47VdQgM39UqBijGGGf8VCpD6VIZvLBYLLBeqkCZpKrz4QRhnrKhcfu58xpDVLLMHE52r1jjJB7v1NBc6MWLeQ/Wd1NrsCKYy9NpD6kUG3ldGgK63qVZ1i8/MWoE5jTeD5eQKyNVNQeKMcAlA9IQ9KgSXJnBEAdxA2xLN0Om0lMqy25Ip2Me4KRd13bogXC33gfC0d8EBo7Fx23SVF2HevxN3AEqA1H4ee0NyW6vSOLhRJ/OlTkeFspPpuPczASXDY7oWhOv/NZlDw0K1+sJpDkdOQEegJ+pzd1o75h0IRPlgqMP4LRy1obe8aoKHFWTZpP2WB5oI738oYQZQTBqyB5i0he/clewfBh5x7mm5lV75GrlvslG3ymxNeIv2cG/b9zP7DpphrDM5kvVwWFmob6/Zg5riQeGhz/dho4chMK419u0YxnFOXLwwQDL4vs/4vYwT1OzYlKcGbILf02GO0N9V8jcuYFS4HQWJG2SkABt52gsYkgQA4N0syLwozI1XUrf6FOZI+SF4y0kv0HXZU3T03EbkmcAyO3jLh65GkANBM9NMvU5QS1e7KocQIXfVOJBkvzUkZL1W8AbSbL0L7FnUmSTDCPAbRAyv9GG9Qnlv5wniP5L1MGsbiLeT6nLRoWQAoasQ+3GLNTRPao1Gw/STUJ/FuU38qKdQTmxEBk5qlzNe/2LEXYNjBmV83F1dJOqYN4MW6IIUgjjXokyFsSVSPkEmwTTqcLj3S6Qa6B2HxAulsjRD3yWk zASnvGIR d/E7dJ+d9XCKKS5nxQmZ9dg2JsX0ZodpywL2Al/oUxMKI2OTg8VRZgtUfxVHk2c59xaxBWr1LEROIw11W0FI4ztjO26b9LcdpcGKEG5xfNawCJGQZsYISOqrxpGmxM9Qgg02PZBb8JjAU69wDFY5k9+AxObinWQHxhtlgG1MWQlf/bTeb+xH3E7IMKDhGIxYBOhou0ruK9r4UCkBQpuPYt3PdRIQ1wPqXbsiZndNJJt9dCWeLzWpI0kFb09uAeHcTySFU9dXqSRa2r94s1ITMgtC6r1Q2cWkrMj54lOchunvdVAM9/arOVaG5lv6Ev/g5L7apFsSeH3tRO6YnnI7l1ovctmYh8Yf9vgxez1iV0J7sdqiHpJnuAjyzbrAcX5hsHRyj/nHgSqX68ArEAQT4E0+Xu2yiyhzEndPs 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 4, 2023 at 8:22=E2=80=AFPM Eric Biggers w= rote: > > 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 thi= s makes > it clear that the init-on-alloc feature is useful for a substantial amoun= t of > users even in its current form. > > I would caution against checking the kernel config for the distro you hap= pen 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_Z= ERO. > There are clear cases where it makes sense, for example some places in th= e VFS > where the performance impact is large and the code has been carefully rev= iewed. What are our options to prevent this flag from spreading uncontrollably? Would it make sense to still provide a separate API for such allocations, so that the flag doesn't get added into some module-level `gfp` variable? > > I don't really like the idea > (https://lore.kernel.org/lkml/CAG_fn=3DUQEuvJ9WXou_sW3moHcVQZJ9NvJ5McNcsY= E8xw_WEYGw@mail.gmail.com/) > of making the system administrator have to opt out allocation sites indiv= idually > via a kernel command-line parameter. Yes, it makes the opt out less like= ly to > be abused as two parties (developer and system administrator) have to con= sent to > each individual opt out. So it theory it sounds good. But I feel that d= oesn't > outweigh the fact that it would be complicated and hard to use. How abou= t just > having two options: one to always honor GFP_SKIP_ZERO in the code and one= to > always ignore it. I am afraid we still need some level of granularity here. E.g. we definitely want to skip initialization for kstrdup(), kmemdup() and friends, some would say even on the systems running with init_on_alloc=3D1. For e.g. 3rd party driver allocations we also need an opt-out flag, but the need for a kill switch to disable that flag is higher. On the other hand, that kill switch does not have to disable the carefully reviewed opt-outs in the upstream code. Assuming that OS vendors usually control their kernel source, we can probably distinguish between opting out the allocations done within statically linked code and the modules, introducing the following levels of initialization that could be controlled by init_on_alloc: - init_on_alloc=3D1 - initialize all allocations, like it's done currently - init_on_alloc=3Dexcept_static_optouts - initialize all allocations, allow GFP_SKIP_ZERO in the statically linked code - init_on_alloc=3Dexcept_optouts - initialize all allocations, allow GFP_SKIP_ZERO in the kernel and the modules - init_on_alloc=3D0 - do not initialize allocations by default In this scheme, the system administrator may choose to either be paranoid, or choose to trust just their OS vendor, or trust the driver vendors as well. In any case, it will be possible to dynamically pull the plug on the opt-ou= ts. > > - Eric -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Stra=C3=9Fe, 33 80636 M=C3=BCnchen Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Liana Sebastian Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg