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 B7419C38A02 for ; Fri, 28 Oct 2022 07:52:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2272C6B0072; Fri, 28 Oct 2022 03:52:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1D7A86B0073; Fri, 28 Oct 2022 03:52:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 09F8C6B0074; Fri, 28 Oct 2022 03:52:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id EBD696B0072 for ; Fri, 28 Oct 2022 03:52:46 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id C35711C6079 for ; Fri, 28 Oct 2022 07:52:46 +0000 (UTC) X-FDA: 80069591532.12.F879CE2 Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com [209.85.218.54]) by imf27.hostedemail.com (Postfix) with ESMTP id 5A8154000C for ; Fri, 28 Oct 2022 07:52:46 +0000 (UTC) Received: by mail-ej1-f54.google.com with SMTP id fy4so11086546ejc.5 for ; Fri, 28 Oct 2022 00:52:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; 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=XwIuMgarBav7+YeP0K9ujVsg3ThrM7RsVGNOUW5uARs=; b=Vd4r0VXfE403xVA3IXR7IPEUVIZRXV2xX/J6FnpT3mYrujTnmjaL1rTvUGhRTeE3Nb 9HTmrhdqcnnWOe56dYwB7U9XjrNqAP7hnQDVPXDlen8mryg9M1mUJbfxDRlQse0cfEqM 2LhtsgdFMIS4IQpkhuhUtkVjr2O8EATiTswvpvmJXZcdiaMTuxJPaS38hxLfywt7LRYW 9nFuu4aOxfbTjv3P2nyBxF5wNxXrSxQ+CKh0Mz3LzFitawvTvnrR6l25MbBPYCI8EoeL BTF2tecPtDPE4aF3YCX3Rd1zoYbL45ZC/D+RhLbM/4T1Q4dnCkEmHFkvUYmQqOxexRaQ j2Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=XwIuMgarBav7+YeP0K9ujVsg3ThrM7RsVGNOUW5uARs=; b=y/q9CSHb/mpzSp5wCK38kUiBcxz7nEt57JyG1h8jZwxrHy5Od6pEamnPcdbcaFHCLJ UQwEVRE4NAjWLw/+yZr/Jhdfii/iPVTNG+EL2wuEVvy4tqY2X64hFzhPl3hLxrxoiqGI T7sOoBeopVAqodo2oYmsRE4jmci1QhfkyfvxdSkJAIU+d4TLyf9bPD5W+rG9RZTP5dLe GnO6Hi4VClqk/9c41vuUoeU05ShynwNyZZH/Gu8gv8WrezE8RJ/rVXTnRmR1w8tfs0+J E7IPXnvxgdPNk8RnFxlmwOXpSP9dimDp4LWVKTJqED8iDvn2ZgzKWBTEiJY63gQ9bWhA 6feA== X-Gm-Message-State: ACrzQf0T4YNy6zo+Bc+8bwN1F7lRp3RjbopxUWPVJMzk1SWaUnDAZO0y C3HB48p8WN1KLYqW5btcxkg= X-Google-Smtp-Source: AMsMyM4WJuQrpK94AxGiTeHkbMZGUl0o5mR2Wibc45qb4ZxQ6Pr8lU8NAyGtAINsZqQLqA4094JxQA== X-Received: by 2002:a17:906:4fcd:b0:78d:8059:17c with SMTP id i13-20020a1709064fcd00b0078d8059017cmr46968635ejw.423.1666943564853; Fri, 28 Oct 2022 00:52:44 -0700 (PDT) Received: from pc636 ([155.137.26.201]) by smtp.gmail.com with ESMTPSA id q17-20020a170906389100b0077a11b79b9bsm1804505ejd.133.2022.10.28.00.52.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Oct 2022 00:52:44 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Fri, 28 Oct 2022 09:52:42 +0200 To: Baoquan He Cc: Stephen Brennan , Andrew Morton , linux-mm@kvack.org, Uladzislau Rezki , Christoph Hellwig , Matthew Wilcox Subject: Re: /proc/kcore reads 0's for vmap_block Message-ID: References: <87ilk6gos2.fsf@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Vd4r0VXf; spf=pass (imf27.hostedemail.com: domain of urezki@gmail.com designates 209.85.218.54 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=1666943566; a=rsa-sha256; cv=none; b=dzwUX+MVUxAbRaWRQy9AOy0cku+vLJBH9zFjOcmUQqsA/SftpdxqMQZZAJ2dBDklHiqXDQ iT/p3Z0fk1Hi4okTZ6iROEJtdFLCD+oCiAOxsTdqBj8J+RSmlArXAjrzHQzx8kW2zLsKQL Fev5qz0s5V0Jn/HqKPOjFMdV5eaeTtQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666943566; 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=XwIuMgarBav7+YeP0K9ujVsg3ThrM7RsVGNOUW5uARs=; b=B9bKOwl9NENZJq1rjIhCtMkc9kYjTWV2KToYS3AdoDzpHmw4Jk7c5sB9tC1ZgyhjiIDCEv lnocKkDrKV0Gvs6LJtr5K5+jVVo2MUJOg7rJZbRldbq+2s/V9v0mmTYThRwJ1wGgEaQNwD xO0Sci2senPPq6uQwA6XHBczTGTn5Fc= X-Rspam-User: X-Rspamd-Queue-Id: 5A8154000C Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Vd4r0VXf; spf=pass (imf27.hostedemail.com: domain of urezki@gmail.com designates 209.85.218.54 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Stat-Signature: kyine41t1zkt8nr3j61stdbyx67acgen X-Rspamd-Server: rspam10 X-HE-Tag: 1666943566-298938 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: On Thu, Oct 27, 2022 at 04:54:38PM +0800, Baoquan He wrote: > On 10/26/22 at 04:15pm, Stephen Brennan wrote: > > Hi all, > > > > The /proc/kcore interface uses vread() to read memory addresses which > > are in the vmalloc region, and it seems that vread() doesn't support > > vmap_areas which are associated with a vmap_block. As far as I can tell, > > those have vmap_area.vm == NULL, and get skipped during vread()'s > > iteration. So the end result is that the read simply returns 0's. > > Hmm, with my understanding, it should be vm_map_ram() which is called > without a struct vm_struct associated, and it's the only interface do > to so. vmap_block is the optimization way based on percpu to reduce vmap > lock race. > > > > > This impacts live debuggers like gdb and drgn, which is how I stumbled > > upon it[1]. It looks like crash avoids the issue by doing a page table > > walk and reading the physical address. > > > > I'm wondering if there's any rationale for this omission from vread(): > > is it a simple oversight, or was it omitted due to the difficulty? Is > > it possible for /proc/kcore to simply take the page faults when it reads > > unmapped memory and handle them? (I'm sure that's already discussed or > > is obviously infeasible for some reason beyond me.) > > From git history, the vmlist iterating was taken in vread() at the > first place. Later, in below commit, when people changed to iterate > vmap_area_list instead, they just inherited the old code logic. I guess > that's why vmap with NULL ->vm is skipped. > > commit e81ce85f960c ("mm, vmalloc: iterate vmap_area_list, instead of vmlist in vread/vwrite()") > > > > > Ideally, I'm just looking for a way forward that allows the debugger to > > *work* as expected, meaning either that /proc/kcore always reads the > > correct data, or that the debugger can know ahead of time that it will > > need to do some processing (like a page table walk) first. > > I think we can adjust vread() to allow those vmap_area with NULL ->vm > being read out? Made a draft patch at below, please feel free to have a > test. Not sure if there's any risk. > > From 9f1b786730f3ee0a8d5b48a94dbefa674102d7b9 Mon Sep 17 00:00:00 2001 > From: Baoquan He > Date: Thu, 27 Oct 2022 16:20:26 +0800 > Subject: [PATCH] mm/vmalloc.c: allow to read out vm_map_ram() areas in vread() > Content-type: text/plain > > Currently, vread can read out vmalloc areas who is associated with > a vm_struct. While this doesn't work for areas created by vm_map_ram() > interface because it doesn't allocate a vm_struct. Then in vread(), > these areas will be skipped. > > Pages are passed into vm_map_ram() and mapped onto frea vmap area, > it should be safe to read them out. Change code to allow to read > out these vm_map_ram() areas in vread(). > > Signed-off-by: Baoquan He > --- > mm/vmalloc.c | 15 +++++++-------- > 1 file changed, 7 insertions(+), 8 deletions(-) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index ccaa461998f3..f899ab784671 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -3526,7 +3526,7 @@ long vread(char *buf, char *addr, unsigned long count) > struct vm_struct *vm; > char *vaddr, *buf_start = buf; > unsigned long buflen = count; > - unsigned long n; > + unsigned long n, size; > > addr = kasan_reset_tag(addr); > > @@ -3547,12 +3547,11 @@ long vread(char *buf, char *addr, unsigned long count) > if (!count) > break; > > - if (!va->vm) > - continue; > - > vm = va->vm; > - vaddr = (char *) vm->addr; > - if (addr >= vaddr + get_vm_area_size(vm)) > + vaddr = (char *) va->va_start; > + size = vm ? get_vm_area_size(vm) : va_size(va); > + > + if (addr >= vaddr + size) > continue; > while (addr < vaddr) { > if (count == 0) > @@ -3562,10 +3561,10 @@ long vread(char *buf, char *addr, unsigned long count) > addr++; > count--; > } > - n = vaddr + get_vm_area_size(vm) - addr; > + n = vaddr + size - addr; > if (n > count) > n = count; > - if (!(vm->flags & VM_IOREMAP)) > + if (!vm || !(vm->flags & VM_IOREMAP)) > aligned_vread(buf, addr, n); > What happens if during the read a page is unmapped by the vm_unamp_ram()? I see that it concurrently can occur. -- Uladzislau Rezki