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 07C67C46467 for ; Mon, 16 Jan 2023 11:50:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9E4206B0073; Mon, 16 Jan 2023 06:50:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9948C6B0074; Mon, 16 Jan 2023 06:50:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8837D6B0075; Mon, 16 Jan 2023 06:50:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 750476B0073 for ; Mon, 16 Jan 2023 06:50:56 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 3E6D01406BA for ; Mon, 16 Jan 2023 11:50:56 +0000 (UTC) X-FDA: 80360495712.29.99DCF57 Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com [209.85.167.50]) by imf12.hostedemail.com (Postfix) with ESMTP id 70B8440005 for ; Mon, 16 Jan 2023 11:50:54 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=ALG6KyeB; spf=pass (imf12.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.50 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=1673869854; a=rsa-sha256; cv=none; b=wISKYvDRZCsk8dIEEfpqzOVprKaqNpz4Y1DXkIYAtte1VTUgzU/bDWGV4bZY3u49ncZ2b1 agEwSVujAz6yIaoa89Xcdh/ppXrvl5JKaDhel62ru6Q2GNIfRjEuwdMqJZrzuUcKUjuVgO pvuKues1jMSexZQGZM4mRA9lLZpUCG8= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=ALG6KyeB; spf=pass (imf12.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.50 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=1673869854; 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=WW+GdQuvnNnKm/U4vO+vCnOCQLrE79/XGPwNYhmpQik=; b=vigQ1FkxRlrk0Gc1hABspF1HZpqVrORf6oo/Ynd0jwbqvfGMYv4B2B5trIlQx37q2BxuFS nqZY9+EOb9bTbY3OEI0JRO6zC6Y1YaQQENjO6x9pE6E+qnUCslZy/y0SUr6EZmtkUqWS+L 5aT6NKzmDWZuFPHE3Zbmu7ycD0fw6DY= Received: by mail-lf1-f50.google.com with SMTP id cf42so42392139lfb.1 for ; Mon, 16 Jan 2023 03:50:54 -0800 (PST) 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=WW+GdQuvnNnKm/U4vO+vCnOCQLrE79/XGPwNYhmpQik=; b=ALG6KyeBBO+EAxG/y7g2nLAT+M09WHeqe4zvSaVz94dDYLHEb5YV7JFHVdh14ziGnG Kmk9HvT6NUsvly3g2fRh5XmvRo5AXIvfzKJRiAMnyWXpsCDkVlT79pkW9F3cKR/++ZyW Z/XKUJxpjhgzlF4i/UfE1PP7Hpn/jRfLg1Lyn90fRLoU9392Hh8Mad5hEe8p0RNBAM2g ZrWIg+XHaEnnSMPXib/OHoRqsRvcqVTa2julJdMtb4SWsgsd9FoyxlwLVQ8Ey0rJn+0/ uSjpsdf3a5op1vYjxfa6O3OuWriDDpn2ptqhjeo7pGEm6x7WgOs9cLePCrUFBWXcHwYu VGVw== 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=WW+GdQuvnNnKm/U4vO+vCnOCQLrE79/XGPwNYhmpQik=; b=3tCDJ+RtB83hovGid61hEdoMoJq8r1mVjBxY+fwGkuOR4bFDtETDU8doeL6av0ykZN up1wE7qL6bE+REfMd8fN5crnBgvqrH/Oo8IAjUm89sr8Ix5URr45fxDO+inlil5/sQ9/ 9WN61hHEa9wzr5a4a/HsdTdnRfHRbk7ueK8p8xhgtQYt6eNe3kXS841OyguOrFF3EFLL /G835jEmuTJU8V1zmGeUVp82iK94Jtfm2uWQU2SPlV1GIfGu5CznJ+DtA0IgSoQG+JFP nwpblSGML2tnip6kq4TWw/4EtjhD0g/5LZxinCmeDXy+WCfYwE/sxVaCkfEVm77H1btK fz5w== X-Gm-Message-State: AFqh2kqv0ENsP/6MRPBCr3+rgvxvOuwHhPJYFuWhJws5lXJolR7t8dUH KwR7ehIPqcnCfeiimSViD5Q= X-Google-Smtp-Source: AMrXdXsUqBX9MpqEpNTkbgkGeZyCBItYVHh0hP1RaL6GrvfEmE14vHDxbdPBFdb3EgNVUjIvoDbhbg== X-Received: by 2002:ac2:42c4:0:b0:4a4:68b7:d645 with SMTP id n4-20020ac242c4000000b004a468b7d645mr20859265lfl.44.1673869852773; Mon, 16 Jan 2023 03:50:52 -0800 (PST) Received: from pc636 (host-90-235-24-7.mobileonline.telia.com. [90.235.24.7]) by smtp.gmail.com with ESMTPSA id c15-20020a056512238f00b004cb3fbc7925sm4967081lfv.77.2023.01.16.03.50.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Jan 2023 03:50:52 -0800 (PST) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Mon, 16 Jan 2023 12:50:50 +0100 To: Baoquan He Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, urezki@gmail.com, lstoakes@gmail.com, stephen.s.brennan@oracle.com, willy@infradead.org, akpm@linux-foundation.org, hch@infradead.org Subject: Re: [PATCH v3 3/7] mm/vmalloc.c: allow vread() to read out vm_map_ram areas Message-ID: References: <20230113031921.64716-1-bhe@redhat.com> <20230113031921.64716-4-bhe@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230113031921.64716-4-bhe@redhat.com> X-Rspam-User: X-Rspamd-Queue-Id: 70B8440005 X-Rspamd-Server: rspam01 X-Stat-Signature: xmcapz4m5i8ns94trt5zjocca63dkgtt X-HE-Tag: 1673869854-991431 X-HE-Meta: U2FsdGVkX1/0sWZN6IIE17aFho05+IaB7FDODTp2O3WsV+ljy0nYrosgKVahzFQ3zEGNpneDT6+/yNICWB+gm3eF4P23MkvxV5xn2NIuGSCw9r3uCQMawbhPuYlHyRpfyhOUPMU6H80JIYSqZ4q8SkgGifkJaKrU9GlUbYsHaDDy9kZoPmscG6wbC8oWWu4iCCwQ04t0wIZmDcKd2UZr5fqLhq2LRcii4Oc2sWzywm7FxotB8QUVF9S064r5NFvNQQPWJO3f1+f+9Y5/9kqbgwaTzpz7upCZQ1EA7qeNtpO5gQjDrKOSoP2GuLVg3TvmWQhp1U7Jku9Hkf+fApEAtkT9TVEmikmtn8zHjA3+Gss4nvcszzpDL3jN5J3lLwkUziSWG6Pe6ty8bg3TeAPNOm9ze1NTURfCddc/uXAAkDWNeZAhCW9G6lU+qVkg1ychW370iamNUiaoQ9UcS+jXDvShjiLi2/LjqWNTXvdM9xg6VPxQkhhH2Pzxi759FZlaJP2wmtb3Ba4Qswgw7MpEsK8q/vZjEKklXfT7iH5FCC2A73DlT0t0MIUBjsH5eYFljYWuO9VrIIzK0vSQiNMpwFxFhEAz0vPI1U8OiUyAB2jGUFnoArbzWrVvD708LMbaJRSqdWkNQV5J++DHIgUq0zPhiRcQV+N5kHv7HmteLE6MyDCMJZ5bjyYV42ABjE0vM4fMflYAYPatA9oBom2NyzNrJiav8j+vBN33jd38FOj+eWhgKktR48LAY3i5i0KLdOZ1Y0cHqXyOnkaFDvj7vJ2uuHAGKq/tLJjeDfTqGeVmRoqfBgyKLwEMTWut1EE9cunT5lDtwgM3r3it6vMjVqU6r2B/5UeCBDaonn7aUodxLaRO6vNFWYxvT9otj8A6l8KCEqqYbW3aUz0L0ERz8n7m/TAEEXxCrdEWJ04QijHNzkLPHyoc6/XHCC0tWTznGPBLsnJnw7AvUv8387/ BjzR3Jks Ji2KGCxC0n2fmtDeTFBg7KAjmFZhWVB5l2tPqyAW7yOmb7EwszlayeMkPPhwZQli0nSYK8D1Jz9rbw5GUaqFe8mhEqim6eOxesIKXD4vVvlynaq7Qsj/Yq2zav5vC5nzZBIVAk+9TBH3dR/g= 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 Fri, Jan 13, 2023 at 11:19:17AM +0800, Baoquan He wrote: > Currently, vread can read out vmalloc areas which is associated with > a vm_struct. While this doesn't work for areas created by vm_map_ram() > interface because it doesn't have an associated vm_struct. Then in vread(), > these areas are all skipped. > > Here, add a new function vmap_ram_vread() to read out vm_map_ram areas. > The area created with vmap_ram_vread() interface directly can be handled > like the other normal vmap areas with aligned_vread(). While areas > which will be further subdivided and managed with vmap_block need > carefully read out page-aligned small regions and zero fill holes. > > Signed-off-by: Baoquan He > --- > mm/vmalloc.c | 80 +++++++++++++++++++++++++++++++++++++++++++++++----- > 1 file changed, 73 insertions(+), 7 deletions(-) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index ab4825050b5c..13875bc41e27 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -3544,6 +3544,65 @@ static int aligned_vread(char *buf, char *addr, unsigned long count) > return copied; > } > > +static void vmap_ram_vread(char *buf, char *addr, int count, unsigned long flags) > +{ > + char *start; > + struct vmap_block *vb; > + unsigned long offset; > + unsigned int rs, re, n; > + > + /* > + * If it's area created by vm_map_ram() interface directly, but > + * not further subdividing and delegating management to vmap_block, > + * handle it here. > + */ > + if (!(flags & VMAP_BLOCK)) { > + aligned_vread(buf, addr, count); > + return; > + } > + > + /* > + * Area is split into regions and tracked with vmap_block, read out > + * each region and zero fill the hole between regions. > + */ > + vb = xa_load(&vmap_blocks, addr_to_vb_idx((unsigned long)addr)); > + > + spin_lock(&vb->lock); > + if (bitmap_empty(vb->used_map, VMAP_BBMAP_BITS)) { > CPU-X invokes free_vmap_block() whereas we take the vb->lock and do some manipulations with vb that might be already freed over RCU-core. Should we protect it by the rcu_read_lock() also here? -- Uladzislau Rezki