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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C0662C433EF for ; Wed, 19 Jan 2022 04:19:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Message-Id:MIME-Version:In-Reply-To: References:Cc:To:Subject:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=49dBvdy6HCXY/6GSyaPoXP8VK10nFzK8G7xBJdSc6Q8=; b=qWkdRpm7/13O3T QeyAOoWdFOdGNRal/wqKzXTUQ2VYPScnYPNXMNq3XtThqt4IVimGGxlGrUVszXK2wzCniigeQOh+I 5MPATL9ay7yB3eyYKRyTjRgfRLRGWu79V0zsD6HeavL88HRz287AqB+rbneNw7MK5ppBVlyHIdt9O 46GVLo5l26Xy9ExdK2r/Q7tVI7udB7zMHg60SjaBQoe/Ru2zdzW70TRqMdCF2bxd/tVjhyJC9V86y azJ6/X1rQFwOKmwHpHLSboIS/EwTRBSQW0vXSQHLcnkbmswzYhCgdjqh3xqgVzPlDvDLxN4lIvj3j w1fd6JVrPC1vSHYLazvg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nA2Ps-003k3p-P4; Wed, 19 Jan 2022 04:17:48 +0000 Received: from mail-pj1-x1032.google.com ([2607:f8b0:4864:20::1032]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nA2Po-003k2p-Hb for linux-arm-kernel@lists.infradead.org; Wed, 19 Jan 2022 04:17:45 +0000 Received: by mail-pj1-x1032.google.com with SMTP id z17-20020a17090ab11100b001b4d8817e04so4169690pjq.2 for ; Tue, 18 Jan 2022 20:17:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:subject:to:cc:references:in-reply-to:mime-version :message-id:content-transfer-encoding; bh=AKF/m4crRjUPKaEVyR47iJWpF9556rhB20qICdT0XMw=; b=gAmqQ4rYYDr653fs21as+JGb8WVc3EmyhbYjx0q2IQ5dWwJZKJ4GnqrquUtrvSB9OB yrB2KyU4M340MMrv250jTVTm9egqTgMtoitKsWrnZig7xF0hOskKydBZPGefcGE0csbP AiWdymunWo98bs9atvLMSPnGTL+cKj+CVfnPBiHWx4Exxb8VTZv3RGeCwPszEkMQiHOl 7RVADXLKYlCe8CIcbja61x2w0JRXJUjn5z1wkaIVivzwlVoMaedV2Yu12vPxNe4yUID6 AI9KiKUKOHS2QOSPlOzLqKoMbfHEMjJecKbks82ZSv6NLKRWAaGowwlsYIP1sXYCr2Nk XDhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:subject:to:cc:references:in-reply-to :mime-version:message-id:content-transfer-encoding; bh=AKF/m4crRjUPKaEVyR47iJWpF9556rhB20qICdT0XMw=; b=rGrfuy6L05WiDCZhuCnhrxMl3PJpLSz6ncc2n0zxZvJDp7L0GWerwNE7lH67Q8wAg2 bwzpPa3eQ9X/zgWXPlAmUASbIsFQx28RtnIlzF2PzwsXf9SC8sH0XHTtt7fWrzntJwgm ZpuvDeSwbPXU8tAZUsYoHRx5SeGluQ0DE09Dvjme5sf4lmU0fF4SgmbrCEjNnedOjTsU j6Kzb5i5IHNf73UVBijhf8ckGB0RNM5uNICtYv7ALwpYVo8uM986JjayRTkLolihLJmN 96pBkdzTLcm3DbvH2Rdf2N7SDGLCN5Z+dj9jw16+LjGvrj82py3FLUgt0i3RYOhYkImu 9zxQ== X-Gm-Message-State: AOAM5328MIa0E940xwWWiastgnUEvzZ8yRH0q5JWVyvsmlglgodaEogK LDv1L3EWy8Lu6QgbPPOXZt4= X-Google-Smtp-Source: ABdhPJx3OvhLmFtcmBgPOWtTOgtFz5eNT+qAc0Hg/uqwpDFNuWOOlw66tKXtoYn5ZRQ3+6wnEZ9b/A== X-Received: by 2002:a17:902:6b89:b0:149:7aa8:d98c with SMTP id p9-20020a1709026b8900b001497aa8d98cmr30797727plk.72.1642565863190; Tue, 18 Jan 2022 20:17:43 -0800 (PST) Received: from localhost (193-116-82-75.tpgi.com.au. [193.116.82.75]) by smtp.gmail.com with ESMTPSA id n5sm18226822pfo.39.2022.01.18.20.17.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Jan 2022 20:17:42 -0800 (PST) Date: Wed, 19 Jan 2022 14:17:37 +1000 From: Nicholas Piggin Subject: Re: [PATCH v2 3/3] x86: Support huge vmalloc mappings To: Andrew Morton , Jonathan Corbet , Dave Hansen , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, Kefeng Wang , x86@kernel.org Cc: Benjamin Herrenschmidt , Borislav Petkov , Catalin Marinas , Christophe Leroy , Dave Hansen , "H. Peter Anvin" , Ingo Molnar , Michael Ellerman , Paul Mackerras , Thomas Gleixner , Will Deacon , Matthew Wilcox References: <20211227145903.187152-1-wangkefeng.wang@huawei.com> <20211227145903.187152-4-wangkefeng.wang@huawei.com> <70ff58bc-3a92-55c2-2da8-c5877af72e44@intel.com> <3858de1f-cdbc-ff52-2890-4254d0f48b0a@huawei.com> <31a75f95-6e6e-b640-2d95-08a95ea8cf51@intel.com> <1642472965.lgfksp6krp.astroid@bobo.none> <4488d39f-0698-7bfd-b81c-1e609821818f@intel.com> In-Reply-To: <4488d39f-0698-7bfd-b81c-1e609821818f@intel.com> MIME-Version: 1.0 Message-Id: <1642565468.c0jax91tvn.astroid@bobo.none> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220118_201744_612471_C117FBF8 X-CRM114-Status: GOOD ( 22.81 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Excerpts from Dave Hansen's message of January 19, 2022 3:28 am: > On 1/17/22 6:46 PM, Nicholas Piggin wrote: >>> This all sounds very fragile to me. Every time a new architecture would >>> get added for huge vmalloc() support, the developer needs to know to go >>> find that architecture's module_alloc() and add this flag. >> This is documented in the Kconfig. >> >> # >> # Archs that select this would be capable of PMD-sized vmaps (i.e., >> # arch_vmap_pmd_supported() returns true), and they must make no assumptions >> # that vmalloc memory is mapped with PAGE_SIZE ptes. The VM_NO_HUGE_VMAP flag >> # can be used to prohibit arch-specific allocations from using hugepages to >> # help with this (e.g., modules may require it). >> # >> config HAVE_ARCH_HUGE_VMALLOC >> depends on HAVE_ARCH_HUGE_VMAP >> bool >> >> Is it really fair to say it's *very* fragile? Surely it's reasonable to >> read the (not very long) documentation ad understand the consequences for >> the arch code before enabling it. > > Very fragile or not, I think folks are likely to get it wrong. It would > be nice to have it default *everyone* to safe and slow and make *sure* It's not safe to enable though. That's the problem. If it was just modules then you'd have a point but it could be anything. > they go look at the architecture modules code itself before enabling > this for modules. This is required not just for modules for the whole arch code, it has to be looked at and decided this will work. > Just from that Kconfig text, I don't think I'd know off the top of my > head what do do for x86, or what code I needed to go touch. You have to make sure arch/x86 makes no assumptions that vmalloc memory is backed by PAGE_SIZE ptes. If you can't do that then you shouldn't enable the option. The option can not explain it any more because any arch could do anything with its mappings. The module code is an example, not the recipe. Thanks, Nick _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel