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 310F5C6FA8F for ; Wed, 30 Aug 2023 12:08:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BCBCF440147; Wed, 30 Aug 2023 08:08:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B7BCE440009; Wed, 30 Aug 2023 08:08:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A91BE440147; Wed, 30 Aug 2023 08:08:25 -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 9A7E9440009 for ; Wed, 30 Aug 2023 08:08:25 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 3CA00B2CED for ; Wed, 30 Aug 2023 12:08:24 +0000 (UTC) X-FDA: 81180648528.22.2A6786A Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf04.hostedemail.com (Postfix) with ESMTP id 5AA644003E for ; Wed, 30 Aug 2023 12:08:18 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Hs41N30K; dmarc=none; spf=none (imf04.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693397300; a=rsa-sha256; cv=none; b=l03+MYUZPvFcqiBZ63535xGgTloqoxao6N29piKzo382XJO3a6SQ4MUvCPNfqs4qJfSGaY 0+E29zckK5zkazJpjPBi5IlS/s/q77VqJSvkI6P1+z+NptdAVdjKU8cK/oE2kMHTli0kjz bGRn4GC44jKe6xLUZQYRmmQ4umE7JUw= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Hs41N30K; dmarc=none; spf=none (imf04.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693397300; 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=/gWxFPnB15/xfwVvJEhax18cVn+NYcCgEBxnuE+iV9g=; b=tT+8ZfvkxxInOgSZqM5PVQHeKeTn/XpLojsDSOEFwp1DRMDarPf3Khz4oYrUrHQPsWnEIp j2Oor8F1RnB1T+jLbV3JSytSBh6Cb+0cu0CPW65VBjREo8KxfHyw5QgOKH3i0FaDa38vg7 c/6AEda7etXqKKg3sqnlLRVPwBq8wpM= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=/gWxFPnB15/xfwVvJEhax18cVn+NYcCgEBxnuE+iV9g=; b=Hs41N30Kv8sSbfJi+YT0uWbRj5 F11cs93nDxxSZLeXUJhh5W+KgL/ashc3+bTesuZuTvCOTj92JWV3CGQZPX4Nfbq3pcXlmse63pZQT jbKI9xAFE8xZO/Zm9SlaCxSgrFDgXbQ0UWbLhof3JiOzDLvJaB3wwPr/yOCizWVmJ/pvT2auXLVjJ cy9UUhu/MwQ63b/EVnmEFp7NpdSEpEImV6mz2Tra85/P+wmmFX4C1985DcQ0LBO9lNekpScz8cSsN tabnVcb2EGsxCgpB1gBruRBM5EKsDqF6q+Z1aVocbKRvcWiRgfUzE/Meab5ivwHto0jWqPc5ePWQH 6x6+b0eA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qbJzJ-00Cebn-Eb; Wed, 30 Aug 2023 12:07:57 +0000 Date: Wed, 30 Aug 2023 13:07:57 +0100 From: Matthew Wilcox To: "Joel Fernandes (Google)" Cc: linux-kernel@vger.kernel.org, Andrew Morton , Uladzislau Rezki , Christoph Hellwig , Lorenzo Stoakes , Zhen Lei , "Paul E . McKenney" , rcu@vger.kernel.org, Zqiang , linux-mm@kvack.org Subject: Re: [PATCH 1/2] mm/vmalloc: Add a safer version of find_vm_area() for debug Message-ID: References: <20230830110402.386898-1-joel@joelfernandes.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230830110402.386898-1-joel@joelfernandes.org> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 5AA644003E X-Stat-Signature: dm6xg8ifron9fwsu5tbk8jxihisrr5m5 X-HE-Tag: 1693397298-281745 X-HE-Meta: U2FsdGVkX19/bJKOO4gepLAJQ/r9l71d8hp0qS/2XE+KDvPlqtrOIgVwMfLf/7VpF6/1K1HF0M9lI7vLowyG7ofFjS0dKshlO/HwiNMcZalFIWGyYaZLLZbDyRHq2/d1ln3rAa0vBSlX72VXO3c+HkPzm+szvU8Y1C/FbVQJFa9E0VKh7xjA6y7rAwgYH0yhlSjTq2uDwZqiBJ1x3tE3eJdF/6ThrpnpC8+t+Bqmwxz/U57EdVqC3nT+0smDaSUZ0vIrNYxP0TbZLfUofeV0ZTd9+x4kNOfmlOofc9B8+tj8/uaoCQSFzoF5ftPFyAzu2Pn12vXE2ISHytrwDUwDb5twAlr396rU4kYXIoXG6YiTugeN14nkSUDRiztc4kg4wzJ8dDfmssnhmPeL2kDC/PVyeNjaJm3v4483k3tAcWXGpBzKXP60SxW6qI27kHwJ1GFgrcKNab47KcDA3uag2D5Gk5CNB7y1cXFyeiMagkKqkZEQTtQY9wPfyqYMZC8B3PzznyUmbyOpy/z+PkpiKgSytp2NQsbRLZ5dMIMXyTxgKL9o0cflO1eieJVHyKjG9b9Kuf7FnEE25/qfKPejKonMshPDvqyAqhLRYfMZNWFQQy/GhA5EyhoV1gCCdq7exqZjxUGfZ7KVwSsCjBUPUbfIM4x+cfrV7S1bAu4kNMapo94WtwKISIpTSSSRci+cZYvok+gfhXzD1ZqG/AOGWV7ZiThjFP4xid492NWvgAStu9SyXkUQkQXlPzsFAKSDQCkg8SYug8QD6RtHIgAl1IklvkmN0sI/I3aaNvrbWI9MKcYccnODGgb5sBIqHPuBgk5EKM2SqGIyZMWvnCoJ67sASgyL3Com7AkpMLRQa003r6+vqZq5luW3FOEHfqFDIblXRGfoqtCtMg/Ue0JPvTSNlT1psNkzEJ15ljOPsmQ+v02AuXLQJJ+DAQwu6/C5Ytc4jVyEieL5S8BiCN+ CRDdMcnn iG4SlxAo8xxGPRfyKa4FSPd2vvoM0PqzzES3YmLYF1rsPdTOVzswGlbXuF+lFlNYoLYDuNxgrojY+L1bGQrKy5Ned6jw16JzoVft+pOtZsdvanD7N4Z29W5TMpsuvE8qAB5lxXKsBLG4gkb8DBX+TLrJNmdoFbzl2ZRigadwR79kMpYrh7mKgaUnIdHYdLCWT0rcb8q9wKjbjbRIcafq9JN6unhDG0V3B64mjoWu6vEmO+NrwBLgW41/m5Y1IFeJr4lckshlMiaclNb9w2Mh5lpQrDdKys3m6ilaEodoOgSbzn03AHYcjiJLDI5jk5n6QagN8hIYqxDIKF8hbABi07a21sPubYzLP5ofuwjBFs9M6fhEXQP3EAGOt9K/aG5nQX4Bk+wVRe7+yRMw6Rumi7EVJTdUl02My8Z6azCUe704IJtf+xzqt04MyrItPu7pHAtfsfjsO7EBEVnRWbcU16PidvMvU/FUPPK0eyr7uk0B6syIU+9LpNNHBrzO9rNAAhgxo 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 Wed, Aug 30, 2023 at 11:03:59AM +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(). > > Reported-by: Zhen Lei > Cc: Paul E. McKenney > Cc: rcu@vger.kernel.org > Cc: Zqiang > Signed-off-by: Joel Fernandes (Google) Reviewed-by: Matthew Wilcox (Oracle) I once started writing something similar, but got distracted and the immediate problem got solved a different way. It does make me wonder if we couldn't make this tree RCU-safe, but that's obviously a much larger job.