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 936A2C433EF for ; Thu, 21 Apr 2022 05:48:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 25E886B0071; Thu, 21 Apr 2022 01:48:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1E67E6B0073; Thu, 21 Apr 2022 01:48:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0607A6B0074; Thu, 21 Apr 2022 01:48:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id E9E586B0071 for ; Thu, 21 Apr 2022 01:48:42 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id C6CBF1223FB for ; Thu, 21 Apr 2022 05:48:42 +0000 (UTC) X-FDA: 79379806884.02.2591E8C Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) by imf28.hostedemail.com (Postfix) with ESMTP id 0658EC001C for ; Thu, 21 Apr 2022 05:48:39 +0000 (UTC) Received: by mail-lf1-f43.google.com with SMTP id bq30so6775959lfb.3 for ; Wed, 20 Apr 2022 22:48:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b9b5jBflzggfzAqpilsQ3cgeetEBu+zmZUTEStBQLTg=; b=aJVQF93EoxUgAr6y80PEHphqgGX/lXqnHarYrsjx2H1pDtSf32ATDs9IspUDQm7j9b mW2JllHJRcsWjDZyLKdMEiYWo0UOYgul/fPhHOyGjZuz4YXgf1s6cxBXngG6CTkZyfar 5p8zDSWMN7hmx4Z8y61hjflCRv3P8+r05YOQg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b9b5jBflzggfzAqpilsQ3cgeetEBu+zmZUTEStBQLTg=; b=DR2PRoVX4t3m3m6Lyv+wT95Pd5NDT5v33IitXBHs42x5Kd0+acUsbR1wP5jme/wNo8 wX7SDDqDEga/bAF+tfUvVLwt3tcaZgq3rRDyvUCR32zA16swYdqXDtDhwKjUVrgDzD50 avaRZs5bC87+9NlqRf472hJ38KypsJuG4B7a3pcmjKmV2+qogobKydHIYyBamu8br2Tr W0ssJSd2Bo30Y0109ejC4JdLFQSn7SFQsYnd8qbifA0XDuOULRXsGKLK/JdxVQyXJ4pl uLwvXVOTINBhStC4+/FJLOSt5M81ZxOKhCsWwPFJtWRtET3EL95kCr+02dALIS5PsZnn YsSw== X-Gm-Message-State: AOAM533VCovfi41T3iYlx9FjwGLur6ibwfPXCyhpfI7m+l4H3VgqHuK7 bjD8vucnpdurZgnQQ+4BzsTZJZZp1FYtuF41lnQ= X-Google-Smtp-Source: ABdhPJwK7ythnmOlGuDkDKYYEYchvmQRQCYYp5radXx05u9BxAOepJxNvD/vv9nTv4+plV6H5me6Vg== X-Received: by 2002:a05:6512:4001:b0:44a:c386:aac9 with SMTP id br1-20020a056512400100b0044ac386aac9mr16915381lfb.12.1650520120350; Wed, 20 Apr 2022 22:48:40 -0700 (PDT) Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com. [209.85.208.179]) by smtp.gmail.com with ESMTPSA id e9-20020a195009000000b00471948d48c7sm1130464lfb.259.2022.04.20.22.48.37 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 Apr 2022 22:48:37 -0700 (PDT) Received: by mail-lj1-f179.google.com with SMTP id q14so4422492ljc.12 for ; Wed, 20 Apr 2022 22:48:37 -0700 (PDT) X-Received: by 2002:a2e:8245:0:b0:24b:48b1:a1ab with SMTP id j5-20020a2e8245000000b0024b48b1a1abmr14909260ljh.152.1650520116613; Wed, 20 Apr 2022 22:48:36 -0700 (PDT) MIME-Version: 1.0 References: <20220415164413.2727220-1-song@kernel.org> <4AD023F9-FBCE-4C7C-A049-9292491408AA@fb.com> <88eafc9220d134d72db9eb381114432e71903022.camel@intel.com> <1650511496.iys9nxdueb.astroid@bobo.none> In-Reply-To: <1650511496.iys9nxdueb.astroid@bobo.none> From: Linus Torvalds Date: Wed, 20 Apr 2022 22:48:20 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 bpf 0/4] vmalloc: bpf: introduce VM_ALLOW_HUGE_VMAP To: Nicholas Piggin Cc: Mike Rapoport , "akpm@linux-foundation.org" , "ast@kernel.org" , "bp@alien8.de" , "bpf@vger.kernel.org" , "daniel@iogearbox.net" , "dborkman@redhat.com" , "edumazet@google.com" , "hch@infradead.org" , "hpa@zytor.com" , "imbrenda@linux.ibm.com" , Kernel Team , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "mbenes@suse.cz" , "mcgrof@kernel.org" , "pmladek@suse.com" , "Edgecombe, Rick P" , "song@kernel.org" , Song Liu Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 0658EC001C X-Stat-Signature: aopjqx3ets6ybif4j37pyb5ffrpfq6dd Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=aJVQF93E; dmarc=none; spf=pass (imf28.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.43 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org X-HE-Tag: 1650520119-880383 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, Apr 20, 2022 at 8:25 PM Nicholas Piggin wrote: > > Why not just revert fac54e2bfb5b ? That would be stupid, with no sane way forward. The fact is, HUGE_VMALLOC was badly misdesigned, and enabling it on x86 only ended up showing the problems. It wasn't fac54e2bfb5b that was the fundamental issue. It was the whole "oh, we should never have done it that way to begin with". The whole initial notion that HAVE_ARCH_HUGE_VMALLOC means that there must be no PAGE_SIZE pte assumptions was simply broken. There were actual real cases that had those assumptions, and the whole "let's just change vmalloc behavior by default and then people who don't like it can opt out" was just fundamentally a really bad idea. Power had that random "oh, we don't want to do this for module_alloc", which you had a comment about "more testing" for. And s390 had a case of hardware limitations where it didn't work for some cases. And then enabling it on x86 turned up more issues. So yes, commit fac54e2bfb5b _exposed_ things to a much larger audience. But all it just made clear was that your original notion of "let's change behavior and randomly disable it as things turn up" was just broken. Including "small" details like the fact that apparently VM_FLUSH_RESET_PERMS didn't work correctly any more for this, which caused issues for bpf, and that [PATCH 4/4]. And yes, there was a half-arsed comment ("may require extra work") to that effect in the powerpc __module_alloc() function, but it had been left to others to notice separately. So no. We're not going back to that completely broken model. The lagepage thing needs to be opt-in, and needs a lot more care. Linus