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 BEE32C83F33 for ; Tue, 5 Sep 2023 07:09:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2D51E900009; Tue, 5 Sep 2023 03:09:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2608B8E001A; Tue, 5 Sep 2023 03:09:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0D896900009; Tue, 5 Sep 2023 03:09:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id ED5658E001A for ; Tue, 5 Sep 2023 03:09:21 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 9650F140A82 for ; Tue, 5 Sep 2023 07:09:21 +0000 (UTC) X-FDA: 81201667722.07.5E7F94B Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) by imf20.hostedemail.com (Postfix) with ESMTP id BFE4D1C000D for ; Tue, 5 Sep 2023 07:09:19 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=KgrzdaMM; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.42 as permitted sender) smtp.mailfrom=lstoakes@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693897759; 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=9EkFXVhb7l8seeMvEs227a8hKeXNE+yg3rnGUe+wdzY=; b=QvmxyhrrVkRVqlfnilne5Gyn21p/Gv8ZcNLHcqQayef8FCGafT0GxUPMQg+0ItcEQIimjw 2wUS9AmgLl53tMsTIlEseLDkvEwnpa9VUnkzDhkprehVUQ6tbXOxcqQH6He4g5+EoLGKqs +KPwg7alkbPKI5bRWB6InyUarGwhPbg= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=KgrzdaMM; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.42 as permitted sender) smtp.mailfrom=lstoakes@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693897759; a=rsa-sha256; cv=none; b=46Qx/38fmJWGFJbBe5K4zxeyNMVO/yEZaK2p7D3YzAk0WtlToPRJ0l2HTpqkpN5flR1JQU 7ufEfA3WrF2wbogyIlRgnP9dE6LMo6T3GnIZJpP/edcr0V+BFBhsDYoNOxSYUQcGXy+htL olMpeUwlJXfLKNLBC/gJfZW6v3CihSs= Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-402be83929eso21683985e9.3 for ; Tue, 05 Sep 2023 00:09:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693897758; x=1694502558; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=9EkFXVhb7l8seeMvEs227a8hKeXNE+yg3rnGUe+wdzY=; b=KgrzdaMMo126Dp2AQ4AYUzMeHHKypBShtl6QUij79H8Fn3054wMr/5g0tOR/9G2fcM iIr3wfxS/GysMkUKjeDYUz/hbnYxv9eRgNXzyNwkGuQ29m0yXVpl+bI9uqpBDQxOHGyZ kQiQkX9yJ7KR5rnFKZ+XobPOVz3QfwEjxrlIjWBOOpwX71KTVnnZnI2+ylWaX3+76afz VPMMElhGsJ73Hwqbc45z8XoNv6w16Qv30JdBfNDvffoyfdRbGAptI6ENrCSlk8rKrZ6F qoNPRbrnuqscyn5vU6OPBsK03b/4Qxlv3jB0beuMF4WjBbTpLbasIAccytfIK+gpYAHD EgLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693897758; x=1694502558; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=9EkFXVhb7l8seeMvEs227a8hKeXNE+yg3rnGUe+wdzY=; b=f2nLXlTyeTOSvaquiVC4wNcFqYMOShskNvV2nwPxHE51pzKeyqGTtvwnzNt82EWQfn pTAnnqftvEHmvMEw92Q0bMuV8IwVEMDTFxT/SIinVHn3efvtvBBFAOjEJzAoA8i3hKSG j2Jc9nYTvXLLq+nvLFiGpDFkOanxF0McSF/+hfFZLsFvP5ninpKfVm6SZxd9Oj+uxoo+ vz6nAjsmfuaMAAarWOftQpXpu0PsyY7wKdoqy1g8WKCO7OwTxm8hi1fguMi7bEo9RZ+T 8gc+04Klacjy/OPLK1ouOlIW7fBo/2cUS6PdL5fbK1Lbhk9E67ERYAUhHVqq1qClEXOp qI9A== X-Gm-Message-State: AOJu0Yw3i1GV4WoEAn3IPb9N9p3zQMF+UbarGAZgl5JH6IvPWmG4BLKU 5txTm+83tpc3s8nSuEGCm/Cek2E/WFo= X-Google-Smtp-Source: AGHT+IEfTqNOZjPICJomY8nLIu9YJ5nBcAfu1xIgEX8N4KNWkLjQi/7KkTSjdA9RqJI3eLIva8UBaw== X-Received: by 2002:a1c:6a19:0:b0:401:bf56:8bb2 with SMTP id f25-20020a1c6a19000000b00401bf568bb2mr8200417wmc.10.1693897758167; Tue, 05 Sep 2023 00:09:18 -0700 (PDT) Received: from localhost ([2a00:23c5:dc8c:8701:1663:9a35:5a7b:1d76]) by smtp.gmail.com with ESMTPSA id l3-20020a1ced03000000b003feae747ff2sm19385673wmh.35.2023.09.05.00.09.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Sep 2023 00:09:16 -0700 (PDT) Date: Tue, 5 Sep 2023 08:09:16 +0100 From: Lorenzo Stoakes To: "Joel Fernandes (Google)" Cc: linux-kernel@vger.kernel.org, Andrew Morton , Uladzislau Rezki , Christoph Hellwig , "Paul E. McKenney" , Vlastimil Babka , Zhen Lei , rcu@vger.kernel.org, Zqiang , stable@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v3 1/2] mm/vmalloc: Add a safer version of find_vm_area() for debug Message-ID: <571d4a4a-0674-4c84-b714-8e7582699e30@lucifer.local> References: <20230904180806.1002832-1-joel@joelfernandes.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230904180806.1002832-1-joel@joelfernandes.org> X-Rspam-User: X-Stat-Signature: pbmk6ng5xdbgurp8yoa9kg3foqxcqm71 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: BFE4D1C000D X-HE-Tag: 1693897759-150223 X-HE-Meta: U2FsdGVkX1/XJSf2I902BEklq5EI/LeEdGH0Av6i3l1S5gRn/2q2R+3hrcr2R6RoYYeTX2YPGA0tTt1Jmv/nqwdG0ZwKYWYvUG/sYOF4ZwkdAkajeUYL9BqIib10/0DkpZP4bwnSKPzzmdLhLcDm379wBb2wVDp8rBuOZ7dqWCX+JltCxS7rlEJXDr9JMq6VwJ0r2JSixB5q/1kly7tir7VZzixp/2y4VF4S6Ca36Sg+ix9Wo9vfd19PUksobDp0sWfYYWYCXQIHFiEg0LyAaYcJSTbXXlgjczpeBsa3BXGPruPYIS/kor1Dro2MNHBRQCSxp+ZHLuAX/3AHqH/vvbE4YJLwdVr9Qu/+z59Gfi67qgFPVxecQCWbe7slPMK7/Funayg6KeojsCpeYH2hMO5HHZ4yI5Ikj0aJ3EJtJLwAwCkPIbwKIL5tMjZZaFRFwv8EqvhOhj0C3ZmxZtAL72GYkaMrOk0GigQMsTPdtd3eZFl2vkb8dO7EGPltLfIayjLjNc8cz8sbfwd6CFQwnxZawmAo1VUT03Zxlmn1SxVnr89LNTI1/JnanVsVGP9NUlxltZQ5ISmc7kFgydi/bbJeHYtfhzagXDPmqJ232hea9ROcMVJIkJF9OEW2/W8U1RxFtTGR6nssmFlljyJxDxnZpGtasLCi2EIJF32uffZlGgzPdDfIl+/o5ucJh6ugkUwNOvNhQCEPROOzpWvlaw2wPH6DJT0bswAsn2hgzoNXxUbUGsgSuAg+ZtZ1iVtsuRluQC5jhUzwaIf9cnviful+UkW9deExzTmGelEERq5zGOP6um/Ii/5RTyqnQOjhQQyuBxM2wFWbuX4b9hRk3uVyUphUUkLIykX7NwEsYuaF7KPKTDCud3/MHQmRi7vE0cGMAjERmfdyXewP/JXIaEu5XmSje8uV2q+0sRqcj5RrU6d5FzTGwXTIucl1pVUI7CVK7+nWh+nhNm5N4AA tD5vIyHw +qtzCDRZyP4Nq8Vspqz279XMF4Y6MRItuJaXHYlQEbpjxP8clAedc799YINyVJrh+m3PAbLemVLPrxM32+t/wX6c6/DZsCzpbvCCLVzfhVF58Fnyjt1MfiA0OOcoHYotsQMxDE3Dp++/V9Du4F9y/nYdIE6p0t1g/+4WdzKjolXvbYE/qDrY7j9/9bEYnEIpvahTXSU3r3FRoqTAeP7r1rK0hxSNcKowo9EWO/U4cOmG2tC0Z12ppy0ld8O9oPG8YLdMcFql67+RHTuOadhIXeC13IltoQriaSDSOapYhYIzsiAYWV/oeWrCptWqgmHouOONqm/bJPRuRidyz8WNSBHTzZMlFT57BXVBA2K5PiQC0MbkSyc00jPSiL0sTfLM3z1hYtgofd0TjoT6fm5rPCAvaMhAcGWls2gxa36IsczcuunRQHQ6caWuBshwaYn2lmoPZbhvwiZF/jpK/WUjwu6ztx0UgmVnLJArnregVXdz8CYfZsxRxrViB/so4usPXtmU2rdWr84mbVN+AkfvFqPBHEbm6PFj5KNG2o7htwPJg/AQWP3DCpn1ZYuMuzV2zrqNyO83f3jKUGyfLxtnAz6vza12b114PcbxPq2thVlRmL/rFPpYt8jKbTJ8HDHjOmVJMcjTeWbdEJT8byUUfxbtDPD+lPmavr+KDF5aKxXWZr828QQ1FtLCB9QlQOONncL9xFg5gEHyLy9sH7K1GOS31VA== 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 Mon, Sep 04, 2023 at 06:08:04PM +0000, Joel Fernandes (Google) wrote: > It is unsafe to dump vmalloc area information when trying to do so from > some contexts. Add a safer trylock version of the same function to do a > best-effort VMA finding and use it from vmalloc_dump_obj(). It'd be nice to have more details as to precisely which contexts and what this resolves. > > [applied test robot feedback on unused function fix.] > [applied Uladzislau feedback on locking.] > > Reported-by: Zhen Lei > Cc: Paul E. McKenney > Cc: rcu@vger.kernel.org > Cc: Zqiang > Reviewed-by: Uladzislau Rezki (Sony) > Fixes: 98f180837a89 ("mm: Make mem_dump_obj() handle vmalloc() memory") > Cc: stable@vger.kernel.org > Signed-off-by: Joel Fernandes (Google) > --- > mm/vmalloc.c | 26 ++++++++++++++++++++++---- > 1 file changed, 22 insertions(+), 4 deletions(-) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index 93cf99aba335..2c6a0e2ff404 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -4274,14 +4274,32 @@ void pcpu_free_vm_areas(struct vm_struct **vms, int nr_vms) > #ifdef CONFIG_PRINTK > bool vmalloc_dump_obj(void *object) > { > - struct vm_struct *vm; > void *objp = (void *)PAGE_ALIGN((unsigned long)object); > + const void *caller; > + struct vm_struct *vm; > + struct vmap_area *va; > + unsigned long addr; > + unsigned int nr_pages; > > - vm = find_vm_area(objp); > - if (!vm) > + if (!spin_trylock(&vmap_area_lock)) > + return false; It'd be good to have a comment here explaining why we must trylock here. I am also concerned that in the past this function would return false only if the address was not a vmalloc one, but now it might just return false due to lock contention and the user has no idea which it is? I'd want to at least output "vmalloc region cannot lookup lock contention" vs. the below cannot find case. Under heavy lock contention aren't you potentially breaking the ability to introspect vmalloc addresses? Wouldn't it be better to explicitly detect the contexts under which acquiring this spinlock is not appropriate? > + va = __find_vmap_area((unsigned long)objp, &vmap_area_root); > + if (!va) { > + spin_unlock(&vmap_area_lock); > return false; > + } > + > + vm = va->vm; > + if (!vm) { > + spin_unlock(&vmap_area_lock); > + return false; > + } > + addr = (unsigned long)vm->addr; > + caller = vm->caller; > + nr_pages = vm->nr_pages; > + spin_unlock(&vmap_area_lock); > pr_cont(" %u-page vmalloc region starting at %#lx allocated at %pS\n", > - vm->nr_pages, (unsigned long)vm->addr, vm->caller); > + nr_pages, addr, caller); > return true; > } > #endif > -- > 2.42.0.283.g2d96d420d3-goog >