Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1700043pxj; Fri, 18 Jun 2021 13:03:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyyodQ+SCTwcv9XNbkxPD+16KKgTxs8aK0KVBcifxEhF4uFpQCu5jXq8YgJVruFbL3ckybs X-Received: by 2002:a17:907:1b02:: with SMTP id mp2mr12334679ejc.196.1624046596977; Fri, 18 Jun 2021 13:03:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624046596; cv=none; d=google.com; s=arc-20160816; b=cQvHJK5IMdynuJu0/dHnURbSItcII1HuEuAdG6IMCmjv/O3dWsLBe7UhFihTf+0KwN aZsvxNNeRL1AwRrWKh5DxnqmcgOvll2bsyh5YNP/W5G69bbDUPKKnJ6ZUqlqAbPkaBQs NxBnlZfBTn89QgVLIl9+ag/V8TlRvu85vxeP9eMMLUnRtKA6XzDJ1Hs4E752hJjSI9QI D4xEEdQg85Ilt4CY1U5VKMcaEPvsyEzLEsgL5GOHedg/BMZNGUPwbYAu4hszI9bjEzFK 4XX47bFgfPt6MS82b01RfW4nYNBuahJmf0u+u6B2CJliuScIMoL1q8PIuf+D0/wFBubn IcfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:message-id:in-reply-to :subject:cc:to:from:date:dkim-signature; bh=eq0N34Elw7O9e3nBxwSL+pENedj11Jkr0/H5vmh3pBo=; b=GVVXPFjCjWaFInw7kVLComETuxv0jeH7gmdz/rdzIip9eFOcZH5D3M0UDVkvSHnNRs gZdIwLC6P1VOas8PkvGNbXpqzMULlGowsRx1r1i3BVgStMEqNJm6qc8EUfE57bc5lqXT HhLlCJ12R3pXwN58vWCfyXsd5WTH3ZLTU4Ih/kQL3Vl+PY0GNHynIgqGgD335v6awRQA DwwzllDdZ4+fwthv0T14TgOESVwAHcLaLQkKGnwc16KB9lAAcgGOqmBYVK/Km1WuWs17 R36+fAG0MiEbaLJxGqdaJqrsAojfbJcQlMwBwLkqn6KA1+cJW++FTK2GPRF55d0DEBOk LnbA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=md5MeIpF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id de14si3183641ejc.521.2021.06.18.13.02.54; Fri, 18 Jun 2021 13:03:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=md5MeIpF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231876AbhFRTt2 (ORCPT + 99 others); Fri, 18 Jun 2021 15:49:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60946 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229591AbhFRTt0 (ORCPT ); Fri, 18 Jun 2021 15:49:26 -0400 Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 36B88C06175F for ; Fri, 18 Jun 2021 12:47:16 -0700 (PDT) Received: by mail-pl1-x62e.google.com with SMTP id m17so2045496plx.7 for ; Fri, 18 Jun 2021 12:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=eq0N34Elw7O9e3nBxwSL+pENedj11Jkr0/H5vmh3pBo=; b=md5MeIpFhcK2iIApQdDDALKT7hCraWLPVY3CbjtqgJicSzCUh6v5whBrWKvYm9kZPx +vweAivEg59pZRNL+Q6LtzJ8V4rmZjLZJC/dM7v5zPpBbsQg0nMqVD3JnIhd6yklk6Y5 tnWZHSnsL1jw07DChiw4RbShzbMsPc3ybynFJLdK1PVN6tCOofoqrefLlTPQGy1NLtYR ddrwoLzLdY1oQ/QgAm+fd0mQI6wqGZTlQvuIzY7Olj2hCF8CPtqeyQGtx+b2z5NmE74i pWI39ae7i843LtjLzOWU/eneQaxPNAGa0NRPyJS0NFJu0mkBHzglNAawqyENDad+LzyE nkNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=eq0N34Elw7O9e3nBxwSL+pENedj11Jkr0/H5vmh3pBo=; b=bYcCbGyaVY4Zo3msgBAS4JQCw5/iim2nhcuhi+J7n4iQradN4tPm3EjKWPJ/BRKJIQ hgAB6khh57Bj0PRet6+UDBeI2tTtZmwTgmMUceY3BK2ZX/hc/9VtiyYlFf1MjaH1DuxZ ecuGMx37JTNgLE2r7p5H+S7XXTSEKRMqd6VXrJ3f+1FDSPSjQVF53lOHmc6upC0whIB7 CmW9YLGZRTNp7xZ05IDeh8Z/VYzNmAl8Ba3kCoRCA6ADWWfU7+7xW8k6lbUu0rzquzKB W8lLYpU4bioR5fE3FwfdgiD/n5/Qoc2McpivFn6sOn1RyWI9vdjiJLbDnDVjZSDSJ7At ES0Q== X-Gm-Message-State: AOAM532ZEdgew4sr6vr2QRjQSogdL18RmeQifLJQkKr/Ja24uv2uQPZ4 Ct2kfY/ALRJOIb2Ml2Yjvsb9+rg1JgCCew== X-Received: by 2002:a17:902:c1cc:b029:122:52b4:3855 with SMTP id c12-20020a170902c1ccb029012252b43855mr1621009plc.10.1624045635401; Fri, 18 Jun 2021 12:47:15 -0700 (PDT) Received: from [2620:15c:17:3:3a6:a5d0:1984:a150] ([2620:15c:17:3:3a6:a5d0:1984:a150]) by smtp.gmail.com with ESMTPSA id s1sm9601820pgg.49.2021.06.18.12.47.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Jun 2021 12:47:14 -0700 (PDT) Date: Fri, 18 Jun 2021 12:47:13 -0700 (PDT) From: David Rientjes To: Claudio Imbrenda cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-s390@vger.kernel.org, frankja@linux.ibm.com, borntraeger@de.ibm.com, cohuck@redhat.com, david@redhat.com, linux-mm@kvack.org, Uladzislau Rezki , Nicholas Piggin , Andrew Morton , Catalin Marinas , Thomas Gleixner , Ingo Molnar , Christoph Hellwig Subject: Re: [PATCH v4 1/2] mm/vmalloc: add vmalloc_no_huge In-Reply-To: <20210614132357.10202-2-imbrenda@linux.ibm.com> Message-ID: <1ab3bba4-dc91-4f8-ecd5-b18b17ec6d8@google.com> References: <20210614132357.10202-1-imbrenda@linux.ibm.com> <20210614132357.10202-2-imbrenda@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 14 Jun 2021, Claudio Imbrenda wrote: > Commit 121e6f3258fe3 ("mm/vmalloc: hugepage vmalloc mappings") added > support for hugepage vmalloc mappings, it also added the flag > VM_NO_HUGE_VMAP for __vmalloc_node_range to request the allocation to > be performed with 0-order non-huge pages. This flag is not accessible > when calling vmalloc, the only option is to call directly > __vmalloc_node_range, which is not exported. > > This means that a module can't vmalloc memory with small pages. > > Case in point: KVM on s390x needs to vmalloc a large area, and it needs > to be mapped with non-huge pages, because of a hardware limitation. > > This patch adds the function vmalloc_no_huge, which works like vmalloc, > but it is guaranteed to always back the mapping using small pages. This > new function is exported, therefore it is usable by modules. > > Signed-off-by: Claudio Imbrenda > Reviewed-by: Uladzislau Rezki (Sony) > Acked-by: Nicholas Piggin > Cc: Andrew Morton > Cc: Nicholas Piggin > Cc: Uladzislau Rezki (Sony) > Cc: Catalin Marinas > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: David Rientjes > Cc: Christoph Hellwig Acked-by: David Rientjes