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 910C0C27C5E for ; Tue, 11 Jun 2024 10:09:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 269706B00A2; Tue, 11 Jun 2024 06:09:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1F21C6B00A3; Tue, 11 Jun 2024 06:09:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 044796B00A4; Tue, 11 Jun 2024 06:09:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id D6DFC6B00A2 for ; Tue, 11 Jun 2024 06:09:10 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 8DDF0121322 for ; Tue, 11 Jun 2024 10:09:10 +0000 (UTC) X-FDA: 82218184860.18.9A5C606 Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) by imf30.hostedemail.com (Postfix) with ESMTP id 9638080008 for ; Tue, 11 Jun 2024 10:09:07 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=A2X5usnl; spf=pass (imf30.hostedemail.com: domain of urezki@gmail.com designates 209.85.208.173 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718100547; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=SAheL3Pbpy7JA5UqcNyCOEP7IV/L7OYe1Dlbh7jegN0=; b=8JyfXdfAAtv7WJW45LE4iud4PSnmqnYCpebjHvRlnYeCmoEJgeI+HBVsHDgbfSP22mpvr5 oXgNsM7HhlUQ+u6VLrghgEIB8IjsVe/UxanW9JtPVX05NLhNQcNhf1ZEUgFHiQagi/6OSn NoBWAFrebpiFfuj8mKK1HQT4j8jHlyE= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=A2X5usnl; spf=pass (imf30.hostedemail.com: domain of urezki@gmail.com designates 209.85.208.173 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718100547; a=rsa-sha256; cv=none; b=GADIJ0d0NPTAGDduV9MPm2/kih5vHVbeawqyRZjjxGdQtUg0tXAGTxoW5fqsMgSnocS0ZM ZU1FHwE/qFPQqiiTym/ddktikR7lg5AdX3oZs2AJLudpFhB49K4FDhBtpEXx71Ee5sdUY0 FCzHCTFMvWc0O30Z4cG0aHViNtcc/qg= Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-2eaae2a6dc1so106994431fa.0 for ; Tue, 11 Jun 2024 03:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718100546; x=1718705346; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=SAheL3Pbpy7JA5UqcNyCOEP7IV/L7OYe1Dlbh7jegN0=; b=A2X5usnlWRmswgQJdDNzrr2U+QujEGc0PpLOkqP3nb1xWCXh/HossVc5Cx5q/f6bO9 rCV8cNf/TGo8405W9ZDRIc969mACMdkmolO79WB18njrUG8A4L3R7gPqd7AIdLbqwPHs GVXFLMWYw9+ugWLQoQqJnGZlL39kis0cgmQ8UmjGM91UVghjSMhCxmFXOGusWO723AEy kwyk3vxfydSUuPrlj1NK6CGh6tiaJn3gPgKQdiF4wUiV/Tm5oULpJzu5Z7/VcX1zZSeJ yrN60zU2X9Qhlpo+TmZ4QmMifkGNUFWo1NUbg+01IatAbxLpDCg8VEtf6ehG+u2s+gJF /zSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718100546; x=1718705346; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=SAheL3Pbpy7JA5UqcNyCOEP7IV/L7OYe1Dlbh7jegN0=; b=m+NEPwjTlhvFxiUFKoKwMwVQ5sE6JKYHmzd4kZ50Ptau8t+z78K9nfKC86gh0JeELv JP77/kuCNz3Ap3cCXBmtoYvefMS16sMjoJVo2IC37OWEYDfnTRmnFMFJcHZ5Qj90TDza JGN/ZfaAhvlyH3qBviT1JatFPuD3iiY3Vhy8HL5mIVTLlZ3mCdO+7L8XhwvvLqcwsgZN HI9gUYGiuPcvn29yjkIFH6oYQGZxccYUQcSxMTRT0xzAlpwFcCxB/dtVFH9G8VvpTv1h 4UcFWcS8L97bluz59wjIooOTjvfE4+S6AHeShJowZQ/RnHBUvMEPQYCLBv/5NqjIOq0I tS1Q== X-Forwarded-Encrypted: i=1; AJvYcCV7KLqIAoN+mGG19Tp6fGIwJo8tno4XVcA6cBifEC74cTK+RfqvHVePLsXzd85c+ria51QInDNrqlW2ti10zkv0cSM= X-Gm-Message-State: AOJu0YwEvgkoautRLGRUMp7AdddmDFMGo+YlDoQXY8aHtKRV0Mf/yCgK AvXusAT+hAX1pggsa5+WfqUWGJutCoy9biwEkQJ5kiiXss0BVLI6 X-Google-Smtp-Source: AGHT+IH0PjLhxIMcOmVEi1E/G0UDxaUaRfwrRjmV1duTjWtdEeQo18W5dDAK7YmkOyj35USGDzY0NA== X-Received: by 2002:a2e:9b57:0:b0:2eb:d963:d8cc with SMTP id 38308e7fff4ca-2ebd963dbffmr57469111fa.49.1718100545408; Tue, 11 Jun 2024 03:09:05 -0700 (PDT) Received: from pc636 (host-90-233-193-23.mobileonline.telia.com. [90.233.193.23]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-2ead4131387sm21465021fa.51.2024.06.11.03.09.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Jun 2024 03:09:05 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Tue, 11 Jun 2024 12:09:01 +0200 To: Shubhang Kaushik OS Cc: "ampere-linux-kernel@lists.amperecomputing.com" , "linux-arm-kernel@lists.infradead.org" , "cl@linux.com" , "corbet@lwn.net" , "akpm@linux-foundation.org" , "urezki@gmail.com" , "linux-mm@kvack.org" , "guoren@kernel.org" , "linux-doc@vger.kernel.org" , "xiongwei.song@windriver.com" , "linux-riscv@lists.infradead.org" , "linux-csky@vger.kernel.org" , "willy@infradead.org" Subject: Re: [PATCH v4] vmalloc: Modify the alloc_vmap_area() error message for better diagnostics Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 9638080008 X-Rspam-User: X-Rspamd-Server: rspam09 X-Stat-Signature: hbsgs6zder4xmopcrftxc3cxwiafj7iy X-HE-Tag: 1718100547-455797 X-HE-Meta: U2FsdGVkX18Htyr6HW8y4KIv7tZQRZkRFETfnaGSWCJecJPS6kO7ZV8K8SgHlXXCtKzHlf/zkcUufzwkR8tqPi+NKJzyhzN0pVV5PrwBTaa6NBNLP2X/wOfwvg/x4Yo2ZZZXi6NPXii8ADPHm3pSADGH52NVKol6cRC1uOHZmkq5Z5rNIjx2SZuc5E2vs0F4b4qnHaCtAOqhB0yfj56HJ+ZviBBU4zctuxuT7xn00oRoJ4abHJZk6k05hzjJIwGiQL78f6p6B94YGEfWzaVAgKP28yYHpIP3Dnn8AM2RmJTd7vKyXXd5gWSasmhZ0669TocAhGeX/Z5IcaK8FTXmEj10+qmZyrQ1hdwdgw14C/EH0KojsF+i0QL+wStNoOzbL5en42+ASzaJ4kRQ42tc6cZY1WQjf4Dv6U5j89sQkojV/77zD5OMZcOJXN3p+tyzsY6nN9RSM+sZuhY10hnhcLHk0hmnGPpJtqUwSd/W1d42F8iFkqDVJyUIME7n5sa+l1XEXoiuoUnmxWSr0hPk1GZJM+Vup+9CLeykIAIBOKqMwYiah9YSnJmJLVS+L9Fc+r/NOCYG+7YkicAiw2Oc2xJ3ainjVGFw+PkXCQSo1+eaGByu1T6Gf8CjjlHkoPnCPojRT5FbIyKHYLMF/542uu+PkIWin1ygTHadZF3bTCE+TI7CkZoAUe/smYYRbck9zDznjAxwHBKQsFqtvc2+mrifc5Gw8T1n3xghNuaFtzg5SI/NxytWO3xhDoQa7xMn3jH9VmPcFFXN+F/FIzx0V04iVGKVfiFXlrhxOeAwEc6MWLnHubINzpoxnDw+Q51DIiRdiD76F9u7/S8EqRWqBn3I+lKxg65ZH3ACI6OtGJ38BmTTO7p1XPwVSsGs1G67g/AKYOXoqEypQOkB3ZKK+GTNp4C3ZlrJCjuKdGRETuiYCDpBJmg/CqeK3BCPsm7nqD6OscnKwWsoAfLSPc0 odSq6cNO AJ6xAuvHYs94XXn7AEJjp0o7ZAHFRP6/5MeJO10tP/22gfIXhNdDpmcR0xN1Nf8S5KDgxnvy8dKbA+lryMmlsOpFd/2bZRJCysupNCzoPa18IKDzeFW/KmCSJ450OyWW9+KcgubrbdA+wtHPGE4xefDCehktReVVDP4CATka0UyUgYOS7Vz5JOpgcRMx9BSpUrbhLIaBm1NEFuNW/X5f0MPKnwdk8MAOEGnlqKG4vrJjmcN53MOjDRtiCatFwgh15vO2njRcdgMu5X0a+cfdkIHluxTtlOXBLMQPEbVtV1sRcsZBldnBn41dcCNpqn7ZFXiVhwL+4ybAOq2J2Kb6zYwDvVp0PoTuGEOKDcuKHOyYZghqit6kvFffH7I0l5JnJ6DREPCmsCWSuRdykoKLz3JmjcChN2P4Vk7QDdR3nf8bSVLnc2rxx/lynltmEbx2yMRYvMh+DRuvmMoSj+axDxEOhj3P+z/lzyE+cNR2r9TIMZx0GZMTl7QprTW0hXcvfCTzvmZzYljO2z1kQc353xwb0i0bCMm+9Uku85SStPWwJmgg= 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: List-Subscribe: List-Unsubscribe: On Mon, Jun 10, 2024 at 05:22:58PM +0000, Shubhang Kaushik OS wrote: > 'vmap allocation for size %lu failed: use vmalloc= to increase size' > The above warning is seen in the kernel functionality for allocation of the restricted virtual memory range till exhaustion. > > This message is misleading because 'vmalloc=' is supported on arm32, x86 platforms and is not a valid kernel parameter on a number of other platforms (in particular its not supported on arm64, alpha, loongarch, arc, csky, hexagon, microblaze, mips, nios2, openrisc, parisc, m64k, powerpc, riscv, sh, um, xtensa, s390, sparc). With the update, the output gets modified to include the function parameters along with the start and end of the virtual memory range allowed. > > The warning message after fix on kernel version 6.10.0-rc1+: > > vmalloc_node_range for size 33619968 failed: Address range restricted between 0xffff800082640000 - 0xffff800084650000 > > Backtrace with the misleading error message: > > vmap allocation for size 33619968 failed: use vmalloc= to increase size > insmod: vmalloc error: size 33554432, vm_struct allocation failed, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0 > CPU: 46 PID: 1977 Comm: insmod Tainted: G E 6.10.0-rc1+ #79 > Hardware name: INGRASYS Yushan Server iSystem TEMP-S000141176+10/Yushan Motherboard, BIOS 2.10.20230517 (SCP: xxx) yyyy/mm/dd > Call trace: > dump_backtrace+0xa0/0x128 > show_stack+0x20/0x38 > dump_stack_lvl+0x78/0x90 > dump_stack+0x18/0x28 > warn_alloc+0x12c/0x1b8 > __vmalloc_node_range_noprof+0x28c/0x7e0 > custom_init+0xb4/0xfff8 [test_driver] > do_one_initcall+0x60/0x290 > do_init_module+0x68/0x250 > load_module+0x236c/0x2428 > init_module_from_file+0x8c/0xd8 > __arm64_sys_finit_module+0x1b4/0x388 > invoke_syscall+0x78/0x108 > el0_svc_common.constprop.0+0x48/0xf0 > do_el0_svc+0x24/0x38 > el0_svc+0x3c/0x130 > el0t_64_sync_handler+0x100/0x130 > el0t_64_sync+0x190/0x198 > > Reviewed-by: Christoph Lameter (Ampere) > Signed-off-by: Shubhang Kaushik > --- > Documentation/admin-guide/kernel-parameters.txt | 9 ++++++--- > mm/vmalloc.c | 4 ++-- > 2 files changed, 8 insertions(+), 5 deletions(-) > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt > index b600df82669d..9b8f8ab90284 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -7245,9 +7245,12 @@ > > vmalloc=nn[KMG] [KNL,BOOT,EARLY] Forces the vmalloc area to have an > exact size of . This can be used to increase > - the minimum size (128MB on x86). It can also be > - used to decrease the size and leave more room > - for directly mapped kernel RAM. > + the minimum size (128MB on x86, arm32 platforms). > + It can also be used to decrease the size and leave more room > + for directly mapped kernel RAM. Note that this parameter does > + not exist on many other platforms (including arm64, alpha, > + loongarch, arc, csky, hexagon, microblaze, mips, nios2, openrisc, > + parisc, m64k, powerpc, riscv, sh, um, xtensa, s390, sparc). > > vmcp_cma=nn[MG] [KNL,S390,EARLY] > Sets the memory size reserved for contiguous memory > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index 5d3aa2dc88a8..75ad551e90ba 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -2055,8 +2055,8 @@ static struct vmap_area *alloc_vmap_area(unsigned long size, > } > > if (!(gfp_mask & __GFP_NOWARN) && printk_ratelimit()) > - pr_warn("vmap allocation for size %lu failed: use vmalloc= to increase size\n", > - size); > + pr_warn("vmalloc_node_range for size %lu failed: Address range restricted to %#lx - %#lx\n", > + size, addr, addr+size); > One question. I see that you would like to see the range, i.e. its "start" and "end" addresses for failure case. For such purpose, why do not you use "vstart" and "vend" variables which specify a range? An "addr" points here on "vend". Or is this intentional? Sorry for late looking at this. I was on a vacation last week. -- Uladzislau Rezki