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 CC644C05027 for ; Fri, 20 Jan 2023 11:55:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0519A6B0072; Fri, 20 Jan 2023 06:55:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 002666B0073; Fri, 20 Jan 2023 06:55:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E0B626B0074; Fri, 20 Jan 2023 06:55:03 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id D11A06B0072 for ; Fri, 20 Jan 2023 06:55:03 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 9E622160ECD for ; Fri, 20 Jan 2023 11:55:03 +0000 (UTC) X-FDA: 80375021286.28.DB4CAF6 Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) by imf04.hostedemail.com (Postfix) with ESMTP id D29734000A for ; Fri, 20 Jan 2023 11:55:00 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=HmBRtxFm; spf=pass (imf04.hostedemail.com: domain of urezki@gmail.com designates 209.85.218.44 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=1674215700; 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=RPwVKRrBRFK3jFjJvU5Sg6lMI3S9/OL0NPdp1XhCJto=; b=dR8nrAlku2TEgOgy+aeWb6uwAbi6FyCAZD6to+rIJoHqq6Xh2hyyOu0rKp0CxX5alYnoro upgpmOy/cG7XOjuElTCcypqQ7J+ScpGySwDJtPqiQGrWlSk0jDDWlT6qhCdT/gkYvP0bkR BaNvN05FVOchxrUsZiu/vz497d96pbY= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=HmBRtxFm; spf=pass (imf04.hostedemail.com: domain of urezki@gmail.com designates 209.85.218.44 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=1674215700; a=rsa-sha256; cv=none; b=zg3YTUaK8y1Qm9ADqo9ZSzLMAISklyjNA7OiCoFWrY0kFpzO7pfkJasJcGNEXT1GO1cFtC pg1ak9NADv9qxrcajTr+mcm+aqtIN+pBBihwDvCzhAchmcoO8946Q9E7MEwj+0sEFfdxXd vCCQT+Qr61SoRuwVBey9PUGa0cW4qy4= Received: by mail-ej1-f44.google.com with SMTP id hw16so13259559ejc.10 for ; Fri, 20 Jan 2023 03:55:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RPwVKRrBRFK3jFjJvU5Sg6lMI3S9/OL0NPdp1XhCJto=; b=HmBRtxFmYcIFCweRBMNq8Thv74hXRM0L2mgce9nbGVg0S8+P4nklS3yKaT0Wz7FfuH v8SZqvwZxN4pGhDGC8Quq5M4gW+yIYhL7C8JwgUZzLxCPeeTjPQ0OGwProzMWc7jVEil upe1a3/iJ2OsvrydAwFNINR3CTvQhvd9g8ldmQ1mE1ZbcxLxwY/aysLaJaviBN+TJJtR MxIdfYoNk2n3sG8VrOqNVsIOI+Jiaih1IuptF6Amlfuq6/UBlcecC1c8PGs0+pVZhrwp cpP0IOk6H+je5+ZveR5aMnjaSUamOjGZOc6383K3IRES+wjgfaJ8V+6SXuKdsaH7Q+TE zSsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=RPwVKRrBRFK3jFjJvU5Sg6lMI3S9/OL0NPdp1XhCJto=; b=oZab3tgw4/kcYb432jnD/K6w95SiDQoA+vHDxnfPCglrEyloa1PErWYNo1DAE027gd GDP66nq7tUmdpYrHC64kzzJDiLgieTM8G3GeKCSuark92AtnONZnObprZi0zF00VQ5pJ eRaTikICd0uZHW3HnQh6wjFjNVKkbXmg9ar6rULG5SQ2HQe2GeMtI5MiseL5J//HZWEL k2+gOin7+d2kvRrkDaWwZqiREstdKPUPPiw95OaeRKQPaQZ+cRhc2SaaqD+j3egC6/Cn YixvLeVK5oh8uBM49RO9VQEoYZdlQniKi/ibXbN3I9ZqWJ3G9nQikUSuL5rCaSYNEM3W JdbQ== X-Gm-Message-State: AFqh2kqCxiOqtCkACyH275f8gL/DJlWimh2Hv2BIFRxx0xI+EX4JHPrD /6BpEnN2LuXw+d0QOZzjCTJ4kDtCqdQWmcW4N9I= X-Google-Smtp-Source: AMrXdXuaENncKZQc33MSnti/Ol9Z2wAhRQU8myUVCNr5xYyz95bn2ei5fqnRxpsjxcVZ4tPMuL7l0SN60RR2ksFDOXg= X-Received: by 2002:a17:906:5a54:b0:84c:4d1:5e9a with SMTP id my20-20020a1709065a5400b0084c04d15e9amr1000372ejc.297.1674215699383; Fri, 20 Jan 2023 03:54:59 -0800 (PST) MIME-Version: 1.0 References: <20230113031921.64716-1-bhe@redhat.com> <20230113031921.64716-4-bhe@redhat.com> In-Reply-To: From: Uladzislau Rezki Date: Fri, 20 Jan 2023 12:54:47 +0100 Message-ID: Subject: Re: [PATCH v3 3/7] mm/vmalloc.c: allow vread() to read out vm_map_ram areas To: Baoquan He Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, lstoakes@gmail.com, stephen.s.brennan@oracle.com, willy@infradead.org, akpm@linux-foundation.org, hch@infradead.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: D29734000A X-Stat-Signature: 18jkurf3jjxdfnpxxtmurqsgtkb5mp5i X-Rspam-User: X-HE-Tag: 1674215700-978577 X-HE-Meta: U2FsdGVkX19B5Xarp87OWllVRSXUoeBH3kwS7ss024XXD56DF2LunAYYAxOY3dsXB1rm/BYLYcb3Le8wfGGF9bILQjg7x3IbkQ16TZtJbbJxtcgjumQ5BX3892DouPCxRQbECBbBLrgj4APYce9EDq9x/YcLURMrwKucCGwpnGo3MezrfQ8wnd/4A9PCmNiCAZ+3NjdNuZmYa77x29s0wOL0X3oK1FXxcOdUNDjv8rftOW6pntO6ffGzeg9s3Jw0rz7UAue5mIoGF0t694lO1zwcvR9yR0QeABzcBd7QXAqDjKTSi+Qux0HkQHyPpaAShBXBo1ToNjvk68+Iltdq3MaoGWlHeymB8XhAcxYXiJ1gmy2N4/rCnN4ODDbO2sYpFoub43jKJO5aZISMevrUZiYuBDzZxwHEMQJE4WghYmcfcijZ+JqR0H/wQ0D4ed8JVusoDVd0wTEkHpOc3zQLBz/QiR/uFAdSenl/0ffl/Xzf3CkvbD2vTB/V5q6bcDxofHoM51EEhsQbPNUoi1qpZbHY8Ihaavqs2DO9INu+DibMl0/TTckY1zhJYRarDHwh85VfN5P7Q5r23Jmxg1s4BKlZ8Wgv+vOgw5FZtReN0cqAJmx7JouzWLTRNO2HwTIRA6W1oLx4MfoqUVRwncsTaOWd/+E5fi2Afwo3+CD3OhutzFmqy55edLdAi2x4rIesuE/sUT0JoqQMe6sUXDBDZIJ2APgKtDOFgTeh55sq0fAJO6UgQ+90btExNMloZCFBcTvt9tUK6wgNd6V0bzlhHaEfY/1QxHwVAGYlWsn4EQ/9yotB5DE/M4Bmsx/+BvbCoQS4ONsPjTMo2u1QUvX4jUg2u0CiiR3zYj1Dh6thXLt8LC+Hgly81tPT+Mk3IcNm4MWdGQpkdCxxQ2o9uFCN9UVxBwyAIB97PJLh6vBvRNzGvkk1pT7WQrMZSD/J7x+z0qgqOFe4UEKifrhDSnk lPWJCuYj aqHFRI587jHTmIG7eXiCG8mxhlUV3wx66iio9LccrXHGUwpoM5v/7+7EMrAyc3emmriCeRdijQcByZmzv0c9bZ9vLdwgXgmK2MkpfZsbgov/ppX879GYCWJtKn3ZXVZQYODE4cwahc9vHQkFWVINMd+F6lByHnkcI/oAFohMl6tlRQSqMfpG4zrAN1eeytQwHOhR5+DQR7oW8/iqLoikAn3NA9Cd6y7Pwm+0z3l/AWjzoBC5nGn/cMR3rSir1Sh2iDieSusvXCthaDgrk92OGWXDl8e5VqSsA7rKWpBjkNz0o3ZvYHYeFG2aT55vsJeELc5Sk0Kii5qcydKP1aM+vlXk8Itzjm/je2WI0cYlpL6G9jk4hS6OVQrN4bhOrZ5fHySfp/cKwafjuycxvS2wJzkrlKq3vEaFrhhTHBz+3AWD4u9xqXQts+ff+Eg== 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 01/19/23 at 05:52pm, Baoquan He wrote: > > On 01/16/23 at 12:50pm, Uladzislau Rezki wrote: > > > 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? > > > > Just go over the vb and vbq code again, seems we don't need the > > rcu_read_lock() here. The rcu lock is needed when operating on the > > vmap_block_queue->free list. I don't see race between the vb accessing > > here and those list adding or removing on vmap_block_queue->free with > > rcu. If I miss some race windows between them, please help point out. > > > > However, when I check free_vmap_block(), I do find a risk. As you said, > > Forgot to add details about why there's no race between free_vmap_block() > and vmap_ram_vread() because we have taken vmap_area_lock at the beginning > of vread(). So, except of the missing checking on returned value from > xa_load(), free_vmap_block() either is blocked to wait for vmap_area_lock > before calling unlink_va(), or finishes calling unlink_va() to remove > the vmap from vmap_area_root tree. In both cases, no race happened. > Agree. xa_load()s return value should be checked. Because it can be that there is no vmap_block associated with an address if xa_erase() was done earlier. -- Uladzislau Rezki