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 BD337C4332F for ; Wed, 23 Nov 2022 03:39:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A69026B0071; Tue, 22 Nov 2022 22:39:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A18AF6B0073; Tue, 22 Nov 2022 22:39:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8E0696B0074; Tue, 22 Nov 2022 22:39:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 7FA5A6B0071 for ; Tue, 22 Nov 2022 22:39:05 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 496661C6923 for ; Wed, 23 Nov 2022 03:39:05 +0000 (UTC) X-FDA: 80163301050.14.8365571 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf30.hostedemail.com (Postfix) with ESMTP id EA3B780008 for ; Wed, 23 Nov 2022 03:39:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1669174743; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=36cJ/LHga8D8vhtwpLwBfwwKIPyA33za/r0fROuHms0=; b=edVyb69qs1VJGYPy98NO20764syo+Z5RaJQ0P68ARUJ8HxbWMGFqycH6IC0r0AUh57l4Qk BKXwIxHKVEV6tDj7/1k1/qgQECNGYAClTNnCvUXt/M5zke7RTH9ysyvUiFFtIOGqSXK8Pr 1xoxG2sf0upzN5ZpvWz0eYKWqYa3NLE= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-466-NclVjgkPPmKzwys2CL09gQ-1; Tue, 22 Nov 2022 22:39:01 -0500 X-MC-Unique: NclVjgkPPmKzwys2CL09gQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id C63A6185A79C; Wed, 23 Nov 2022 03:39:00 +0000 (UTC) Received: from localhost (ovpn-14-41.pek2.redhat.com [10.72.14.41]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CEABF1121314; Wed, 23 Nov 2022 03:38:59 +0000 (UTC) Date: Wed, 23 Nov 2022 11:38:54 +0800 From: Baoquan He To: Matthew Wilcox Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, stephen.s.brennan@oracle.com, urezki@gmail.com, hch@infradead.org Subject: Re: [PATCH RFC 3/3] mm/vmalloc.c: allow vread() to read out vm_map_ram areas Message-ID: References: <20221109033535.269229-1-bhe@redhat.com> <20221109033535.269229-4-bhe@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669174744; a=rsa-sha256; cv=none; b=YqD7CIv3tVQzuRxR3staNXY7569DLBn3GfG2ttDtqN9pKCGUbw43exPEkG8rktQXOzFW9B JJQydP+zAbRSNIS+TwfIsmviQtALAJWn4+EDniN3pjTg0a/lfc55h4xZLJ4oMMf51z5qdC f/Y+P2xbTQUwPnUY8r62iy/pBbVEORs= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=edVyb69q; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf30.hostedemail.com: domain of bhe@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bhe@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669174744; 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=36cJ/LHga8D8vhtwpLwBfwwKIPyA33za/r0fROuHms0=; b=VpfcKMWB4FERoHWnfwD5YFQ80XPi1WAibkvTsm1+zizUGWbfQbrb7QbV0wcOdP/lFIpM3o b6Ma3ZyoJmI5LWEtEKXCaGzME+/1NIF3upxh/07sWdxSm6enQpfQbDvdmhoJNhsTGmPqrF M/DTjVOTHEQ+cHMFiZENT99vjQpc9y0= Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=edVyb69q; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf30.hostedemail.com: domain of bhe@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bhe@redhat.com X-Stat-Signature: o5xq6kb934feicptz873w7rodkuouakz X-Rspamd-Queue-Id: EA3B780008 X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1669174743-970591 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 11/18/22 at 08:01am, Matthew Wilcox wrote: > On Wed, Nov 09, 2022 at 11:35:34AM +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 allocate a vm_struct. Then in vread(), > > these areas will be skipped. > > > > Here, add a new function vb_vread() to read out areas managed by > > vmap_block specifically. Then recognize vm_map_ram areas via vmap->flags > > and handle them respectively. > > i don't understand how this deals with the original problem identified, > that the vread() can race with an unmap. Thanks for checking. I wrote a paragraph, then realized I misunderstood your concern. You are saying the comment from Uladzislau about my original draft patch, right? Paste the link of Uladzislau's reply here in case other people want to know the background: https://lore.kernel.org/all/Y1uKSmgURNEa3nQu@pc636/T/#u When Stephen raised the issue originally, I posted a draft patch as below trying to fix it: https://lore.kernel.org/all/Y1pHTj2wuhoWmeV3@MiWiFi-R3L-srv/T/#u In above draft patch, I tried to differentiate normal vmalloc area and vm_map_ram area with the fact that vmalloc area is associated with a vm_struct, while vm_map_ram area has ->vm as NULL. And I thought their only difference is normal vmalloc area has guard page, so its size need consider the guard page; while vm_map_ram area has no guard page, only consider its own actual size. Uladzislau's comment reminded me I was wrong. And the things we need handle are beyond that. Currently there are three kinds of vmalloc areas in kernel: 1) normal vmalloc areas, associated with a vm_struct, this is allocated in __get_vm_area_node(). When freeing, it set ->vm to NULL firstly, then unmap and free vmap_area, see remove_vm_area(). 2) areas allocated via vm_map_ram() and size is larger than VMAP_MAX_ALLOC. The entire area is not associated with vm_struct, and freed at one time in vm_unmap_ram() with unmapping and freeing vmap_area; 3) areas allocated via vm_map_ram(), then delegate to vb_alloc() when size <= VMAP_MAX_ALLOC. Its vmap_area is allocated at one time with VMAP_BLOCK_SIZE big, and split and used later through vb_alloc(), freed via vb_free(). When the entire area is dirty, it will be unmapped and freed. Based on above facts, we need add flags to differentiate the normal vmalloc area from the vm_map_ram area, namely area 1) and 2). And we also need flags to differentiate the area 2) and 3). Because area 3) are pieces of a entire vmap_area, vb_free() will unmap the piece of area and set the part dirty, but the entire vmap_area will kept there. So when we will read area 3), we need take vb->lock and only read out the still mapped part, but not dirty or free part of the vmap_area. Thanks Baoquan