Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp4379419pxu; Wed, 9 Dec 2020 16:00:39 -0800 (PST) X-Google-Smtp-Source: ABdhPJw0teshQ6hU0eX931jbJ2pm0jRSF+xS+7REhVSQE2MNwNtHW5ZILCW1gw5n5FJpULYaWZM+ X-Received: by 2002:a17:907:4332:: with SMTP id ni2mr4158216ejb.422.1607558439144; Wed, 09 Dec 2020 16:00:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607558439; cv=none; d=google.com; s=arc-20160816; b=roYMV2u0nBtfzHgaK3ggP/X82NmI1UHO0cpHpkQr8K/aq6PrnuvkbtHY8Otul1r7W4 ei/1meQdn6nARfz8E4hLhDkv85uKRDIzaMND4f1frq6SX22AbagLJ2c9rm36Wll9ZhRJ oD1etHqQiJW6ihBBCJUvM6teEqAQFwS/wXzOZWLmCCEPhnd6sqgyX8USD6MvFxDGztGu KoOwiPAilSaqVfhLdk0izQ1Qm+05KANkZLBpoSgrw3QZbuG+ISV5BOL31ScYNKd9L7wY siSGJKQC/p8tkfemGQvKx4iRKNnCZjs3x7FSfTZuOL1/z69VdfxSzfeQsaWSkRhPAXfr MsZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:reply-to:message-id:subject:cc:to:from :dkim-signature:date; bh=+HC4xJMKh3TEAa2lizLm6nxDso3nbE2D+/6iynhmRAs=; b=KgiFEiD3Nxa4LsfYpT8zshnVjCX1ZfALvxJhmQtICVAy0ayaGt0bzR8ikcop9dGeyT R2MMnptZMq374mNYIzaFXf7eMJ2sxNo3UpyttOB2Tmj+jj0YUO1RVdMqx8cr+k62RS2X /qV0l+b/o5CIbgTKSjTSDhp3EPTNwUUoIP3UNii3PXx125wLoRrYxIdLG0EqSxuTlJ+x 12G1L1jy1hYHDZvt2qqdGnRCd4IIq7V9Ohp2NvEcxgjWqhXjqH1hU7yFdWeI0A9pzjf0 D5iOnpJivS8aKXpCxhFXt86LTEFomy+SfR63kKBsuLN/fFkWc876xLOkbG4v81kFKIx8 96xA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=kC4FMinc; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k7si1546993ejg.677.2020.12.09.16.00.16; Wed, 09 Dec 2020 16:00:39 -0800 (PST) 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=@kernel.org header.s=k20201202 header.b=kC4FMinc; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732688AbgLIXXv (ORCPT + 99 others); Wed, 9 Dec 2020 18:23:51 -0500 Received: from mail.kernel.org ([198.145.29.99]:54976 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725885AbgLIXXv (ORCPT ); Wed, 9 Dec 2020 18:23:51 -0500 Date: Wed, 9 Dec 2020 15:23:10 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1607556190; bh=FNkanjJRiKGUHvoOf8PjH4Glcl/rM8Sr+vJWnZnM2Fg=; h=From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=kC4FMincGXAIuGjcw2vg52OYrjhASaFkyzOXsRBrhaJdTJT66PVkMuv2nu2Yp8ly1 Q9YR+F5unST9t6G3aED6/FvHgh0Kmel47VDVjb2nczzFdtmXyR8P+DutyqNUuBThbc Hnkx9jnkwLCGh6qsqD4HGxBShJzfHoSdjqY/v/q7TrAtkxwG15emUkUxm+vGZkgC28 tvv2C0esuULdSJw/RgJ/M/j0SeqD6PPZ/qEirWuncC+c1QjW0kStX3yQzRpH/yEXY1 9/kyRHeux2lmkFLAQ19PROIKgRDJY/CuGsr4ukiEzU/Hg9r6xRyq7T7pwpMo04Tkuk y7ChaDCe7CeqA== From: "Paul E. McKenney" To: Vlastimil Babka Cc: rcu@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com, mingo@kernel.org, jiangshanlai@gmail.com, akpm@linux-foundation.org, mathieu.desnoyers@efficios.com, josh@joshtriplett.org, tglx@linutronix.de, peterz@infradead.org, rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com, fweisbec@gmail.com, oleg@redhat.com, joel@joelfernandes.org, iamjoonsoo.kim@lge.com, andrii@kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2 sl-b 3/5] mm: Make mem_dump_obj() handle vmalloc() memory Message-ID: <20201209232310.GI2657@paulmck-ThinkPad-P72> Reply-To: paulmck@kernel.org References: <20201209011124.GA31164@paulmck-ThinkPad-P72> <20201209011303.32737-3-paulmck@kernel.org> <1c25ca09-ec43-df31-a5ba-476397637a53@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1c25ca09-ec43-df31-a5ba-476397637a53@suse.cz> User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 09, 2020 at 06:51:20PM +0100, Vlastimil Babka wrote: > On 12/9/20 2:13 AM, paulmck@kernel.org wrote: > > From: "Paul E. McKenney" > > > > This commit adds vmalloc() support to mem_dump_obj(). Note that the > > vmalloc_dump_obj() function combines the checking and dumping, in > > contrast with the split between kmem_valid_obj() and kmem_dump_obj(). > > The reason for the difference is that the checking in the vmalloc() > > case involves acquiring a global lock, and redundant acquisitions of > > global locks should be avoided, even on not-so-fast paths. > > > > Note that this change causes on-stack variables to be reported as > > vmalloc() storage from kernel_clone() or similar, depending on the degree > > of inlining that your compiler does. This is likely more helpful than > > the earlier "non-paged (local) memory". > > > > Cc: Andrew Morton > > Cc: Joonsoo Kim > > Cc: > > Reported-by: Andrii Nakryiko > > Signed-off-by: Paul E. McKenney > > ... > > > --- a/mm/vmalloc.c > > +++ b/mm/vmalloc.c > > @@ -3431,6 +3431,18 @@ void pcpu_free_vm_areas(struct vm_struct **vms, int nr_vms) > > } > > #endif /* CONFIG_SMP */ > > > > +bool vmalloc_dump_obj(void *object) > > +{ > > + struct vm_struct *vm; > > + void *objp = (void *)PAGE_ALIGN((unsigned long)object); > > + > > + vm = find_vm_area(objp); > > + if (!vm) > > + return false; > > + pr_cont(" vmalloc allocated at %pS\n", vm->caller); > > Would it be useful to print the vm area boundaries too? Like this? I also considered instead using vm->size, but that always seems to include an extra page, so a 4-page span is listed as having 20480 bytes and a one-page span is 8192 bytes. This might be more accurate in some sense, but would be quite confusing to someone trying to compare this size with that requested in the vmalloc() call. Thanx, Paul ------------------------------------------------------------------------ commit 33e0469c289c2f78e5f0d0c463c8ee3357d273c0 Author: Paul E. McKenney Date: Wed Dec 9 15:15:27 2020 -0800 mm: Make mem_obj_dump() vmalloc() dumps include start and length This commit adds the starting address and number of pages to the vmalloc() information dumped by way of vmalloc_dump_obj(). Cc: Andrew Morton Cc: Joonsoo Kim Cc: Reported-by: Andrii Nakryiko Suggested-by: Vlastimil Babka Signed-off-by: Paul E. McKenney diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 7421719..77b1100 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -3439,7 +3439,8 @@ bool vmalloc_dump_obj(void *object) vm = find_vm_area(objp); if (!vm) return false; - pr_cont(" vmalloc allocated at %pS\n", vm->caller); + pr_cont(" %u-page vmalloc region starting at %#lx allocated at %pS\n", + vm->nr_pages, (unsigned long)vm->addr, vm->caller); return true; }