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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 981F7C433EF for ; Sat, 16 Apr 2022 20:31:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233010AbiDPUdr (ORCPT ); Sat, 16 Apr 2022 16:33:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37370 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232999AbiDPUdm (ORCPT ); Sat, 16 Apr 2022 16:33:42 -0400 Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 54E605BD33 for ; Sat, 16 Apr 2022 13:31:08 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id u19so18883668lff.4 for ; Sat, 16 Apr 2022 13:31:08 -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=YLjXXGPCeZFoo0LSeAoNTeYQmnNJj43S9GqF3x/ym20=; b=SrSlzeiaQpCm4wc0MQ0m37QHAqoK9FT8MbEl9SPGH8rdWqMQedT7lTTS7GcsoBzJnC mwh/ajg/m0eG9+H3NUwn9OLJNGOLmtA5Tot2AAfRENjeYsH57sN9QT0cCZ6etY+bAiY8 POMTsc8VPFSI9b1QmVcOmHGCjJIie+BnfYtvE= 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=YLjXXGPCeZFoo0LSeAoNTeYQmnNJj43S9GqF3x/ym20=; b=BwlDmq/TNEy3IXceUH/aSyqPUw3czZB+lvoM/ZcR5wvyZ0OO2kMr9Z1V99UJij43I9 9FxOm4BSPpWSInE2xdvD0Y96Et5uAhKmkWQ8qtI4/ywdfutgXiixTCgti6W5k8dNfAHt R8VRWJ7wnFKzrABRGokVkcvILZZU0p7WB+0GDjukzvWGZCZK1hU0etycqUjTflyvQKJY NY4eqPTaKIt+HalIbMNj8Hiu7GGHHeiOUPsCSl011c22oEM5bKQfebpN7IzFlJNMgAzK lcf761Yml240j5ADhItQhQ+C0/1iTYakVaH3codakjdyk1titg1FFy0E4u0k/ODT7LAP hqqg== X-Gm-Message-State: AOAM5324lNeWptkLUSsItSJpoLTWIm4rb4+PRpzXJBJXum12Guq0kQd6 ovnWUY3W8xhKbVQxbwQ3mB+/3HHMGFEk6x0o28s= X-Google-Smtp-Source: ABdhPJzD9HwNLlcYCx5Y5bPP7o79l7BxtnCqfgWsVtOTjx6ZrzSe3VUw1hHPejnzsmdc/kYdLS48ow== X-Received: by 2002:a05:6512:945:b0:44a:f03f:e8c9 with SMTP id u5-20020a056512094500b0044af03fe8c9mr3264466lft.163.1650141066390; Sat, 16 Apr 2022 13:31:06 -0700 (PDT) Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com. [209.85.167.48]) by smtp.gmail.com with ESMTPSA id g3-20020a2e9e43000000b00244c60deb14sm664533ljk.15.2022.04.16.13.31.03 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 16 Apr 2022 13:31:03 -0700 (PDT) Received: by mail-lf1-f48.google.com with SMTP id o2so18815542lfu.13 for ; Sat, 16 Apr 2022 13:31:03 -0700 (PDT) X-Received: by 2002:ac2:4203:0:b0:448:8053:d402 with SMTP id y3-20020ac24203000000b004488053d402mr3175652lfh.687.1650141063333; Sat, 16 Apr 2022 13:31:03 -0700 (PDT) MIME-Version: 1.0 References: <20220415164413.2727220-1-song@kernel.org> <4AD023F9-FBCE-4C7C-A049-9292491408AA@fb.com> In-Reply-To: <4AD023F9-FBCE-4C7C-A049-9292491408AA@fb.com> From: Linus Torvalds Date: Sat, 16 Apr 2022 13:30:47 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 bpf 0/4] vmalloc: bpf: introduce VM_ALLOW_HUGE_VMAP To: Song Liu Cc: Christoph Hellwig , Luis Chamberlain , Song Liu , bpf , Linux Memory Management List , open list , Alexei Starovoitov , Daniel Borkmann , Kernel Team , Andrew Morton , "Edgecombe, Rick P" , Claudio Imbrenda Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Apr 16, 2022 at 12:55 PM Song Liu wrote: > > Based on this analysis, I think we should either > 1) ship the whole set with 5.18; or > 2) ship 1/4, 3/4, and 4/4 with 5.18, and 2/4 with 5.19. Honestly, I think the proper thing to do is - apply #1, because yes, that "use huge pages" should be an opt-in. - but just disable hugepages for now. I think those games with set_memory_nx() and friends just show how rough this all is right now. In fact, I personally think that the whole bpf 'prog_pack' stuff should probably be disabled. It looks incredible broken to me right now. Unless I mis-read it, it does a "module_alloc()" to allocate the vmap area, and then just marks it executable without having even initialized the pages. Am I missing something? So now we have random kernel memory that is marked executable. Sure, it's also marked RO, but who cares? It's random data that is now executable. Maybe I am missing something, but I really don't think this is ready for prime-time. We should effectively disable it all, and have people think through it a lot more. Linus