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 7CB80C4332F for ; Tue, 20 Dec 2022 12:14:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C54508E0002; Tue, 20 Dec 2022 07:14:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C04018E0001; Tue, 20 Dec 2022 07:14:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ACAD98E0002; Tue, 20 Dec 2022 07:14:39 -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 992AD8E0001 for ; Tue, 20 Dec 2022 07:14:39 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 68C6E12057D for ; Tue, 20 Dec 2022 12:14:39 +0000 (UTC) X-FDA: 80262577878.27.C0E1264 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf23.hostedemail.com (Postfix) with ESMTP id 5B6DA14000E for ; Tue, 20 Dec 2022 12:14:37 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Wdgx70B6; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf23.hostedemail.com: domain of bhe@redhat.com designates 170.10.129.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=1671538477; 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=Yj0H0OPjYYhukChGoShtr+NfxDhWzTB9QJrl0G0MvS0=; b=yzh5CS3NNugkhGWrcenP1nASSbBuaSaR3ygQYnPMxh5ZbBbAiUmfCUqmA1K5v9uvOIWabT mMdfLrZOayfFB9Z+MJq0jo49qM/TvygDIEbm6kzXBO4ItRT64kQ48/g5pNwhXlpKvzVgoP tSs5XX5dqnyoEYe3yiEGn26Twhd5jxg= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Wdgx70B6; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf23.hostedemail.com: domain of bhe@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=bhe@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1671538477; a=rsa-sha256; cv=none; b=XKfj26/NdsFL89w5XZdckQ7YZH25fbgNDuJtQxelrP0r5WEwJWyMOWvykVv+mVcgV6cFjl jSNwiKQjh+8ynjiBmBVpLTD6VvzG5YP9vVO54llmbkX7cm+vYLP3Vgmh0gRvxukUu39N0T ifYdS+PTyyOZwsyWJHfC1jJ1l1/GttQ= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1671538476; 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=Yj0H0OPjYYhukChGoShtr+NfxDhWzTB9QJrl0G0MvS0=; b=Wdgx70B6jLHU9Hf/6GsPu3SQB3yq5LPl1qKyHuxnzRui1TVRvs1EWzJFeYB5S7qvpivwhC jbo+0uDDEFpp2fuPTZ9hG/RfwZoFhEHlNJ29bwpEet3rnQV8TMOE839oFQdUVFHcmz+ZLV ADXK4CQOnOzXH+r3Og4v9AtOLQ1dcrg= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-161-bUmU_UJjMBy7kaG3QYQxjw-1; Tue, 20 Dec 2022 07:14:33 -0500 X-MC-Unique: bUmU_UJjMBy7kaG3QYQxjw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id F0ADB299E741; Tue, 20 Dec 2022 12:14:32 +0000 (UTC) Received: from localhost (ovpn-12-53.pek2.redhat.com [10.72.12.53]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B0632C158BB; Tue, 20 Dec 2022 12:14:23 +0000 (UTC) Date: Tue, 20 Dec 2022 20:14:15 +0800 From: Baoquan He To: Lorenzo Stoakes Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, urezki@gmail.com, stephen.s.brennan@oracle.com, willy@infradead.org, akpm@linux-foundation.org, hch@infradead.org Subject: Re: [PATCH v2 2/7] mm/vmalloc.c: add flags to mark vm_map_ram area Message-ID: References: <20221217015435.73889-1-bhe@redhat.com> <20221217015435.73889-3-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.8 X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 5B6DA14000E X-Stat-Signature: t39grjs6itjbgy1cw8dz6zt345weerg9 X-HE-Tag: 1671538477-922160 X-HE-Meta: U2FsdGVkX1/50SRJ2SdByzCW3yaXZnG22SetHg1OIDKyCCvZcCHB2AYcyc9XQ0HV0zHuWpDCCgEVxJVH7i93xVYkmzkms/vvqH01YcRaiTljqtymy+0Pj8yz4kILT/SS6fIEy4fOPbscNq8L1sVCMbWLNVMeOTzDrxYFL1jZ9XxizWkIlGNp2pN+9jsKqQJh2C8RJm/iJ41hukh3NPMLLfYh64s56zy54af5fvSPv4EoaXJIR07c6JgwggHapVwTFK6OoLLtNT6RSTv12UGFIoQUdZWEenBZQBYF1JQpN3RJB2BdkoJXje6DAph4Sz7cegMvlO4TyQMZZdHFX79Lv4oOczrahlQZ9J1emYd2ZfZC1LHHofkizlRh4cNPbSgWCfhVSbrsiuh5HSjwsqkyfun3Fgf6CeMDBCH7/FJOekUY1PJ/K6rAv3DCoxqw66zwpp+0RBLRWxLvqEIeapdR3sG8qhx7bW2LPc32xwzvOmEACWXiExM58hsZAEsFjwF6LhOfw3i1xWtv8gzqqo1aN9nfUBjj567nFL/hHA2tzFfnXzgsWSeBRUt+jNlggDPDF6K/KcdTAZ6Fm9gc5Lfq4LmTMlq4h/MpbTI6N2a9pVEBy2NN+bUPaU+4P7l7NvPnl7VZ+4cqI5xaQ5H4px0k4US307M+EBFCH24pXO/hgA+ecGLWu7p6hvA4zq/v6s/UouVPvYj5P+mvlU/EfI0sIOqQdqZQffmf3OIQNuTh2GcWU9JDCqfehaZEurEUDUBlWONTDTf3yQIVcHE2asx54KK1+vS2iWqYvHhnHO8TtQtNGceJ7elgyGX52wXmIBmPSGIXNYfu+olZFrR7pT83fYB4nYWsi6pQuGk+TKHRVUdDBMZhF7ekOElrS6PHoJ8Iu9ee3cFLGmSkOVdKoTJWdVT1njmLnMgiy/k8zcI9GxOotBwF6xUYY48Gh/Ybz2PYkj2L/tkqQxtqTzzBMnm Vaw== 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 12/19/22 at 01:01pm, Lorenzo Stoakes wrote: > On Mon, Dec 19, 2022 at 08:24:47PM +0800, Baoquan He wrote: > > In fact, I should not do the checking, but do the clearing anyway. If I > > change it as below, does it look better to you? > > > > > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > > index 5e578563784a..369b848d097a 100644 > > --- a/mm/vmalloc.c > > +++ b/mm/vmalloc.c > > @@ -2253,8 +2253,7 @@ void vm_unmap_ram(const void *mem, unsigned int count) > > spin_lock(&vmap_area_lock); > > va = __find_vmap_area((unsigned long)addr, &vmap_area_root); > > BUG_ON(!va); > > - if (va) > > - va->flags &= ~VMAP_RAM; > > + va->flags &= ~VMAP_RAM; > > spin_unlock(&vmap_area_lock); > > debug_check_no_locks_freed((void *)va->va_start, > > (va->va_end - va->va_start)); > > This is better as it avoids the slightly contradictory situation of checking for > a condition we've asserted is not the case, but I would still far prefer keeping > this as-is and placing the unlock before the BUG_ON(). > > This avoids explicitly and knowingly holding a lock over a BUG_ON() and is > simple to implement, e.g.:- > > spin_lock(&vmap_area_lock); > va = __find_vmap_area((unsigned long)addr, &vmap_area_root); > if (va) > va->flags &= ~VMAP_RAM; > spin_unlock(&vmap_area_lock); > BUG_ON(!va); OK, I will change like this. > > > > You are at this point clearing the VMAP_RAM flag though, so if it is unimportant > > > what the flags are after this call, why are you clearing this one? > > > > With my understanding, We had better do the clearing. Currently, from > > the code, not doing the clearing won't cause issue. If possible, I would > > like to clear it as below draft code. > > > > Sure, it seems appropriate to clear it, I'm just unsure as to why you aren't > just clearing both flags? Perhaps just set va->flags = 0? Hmm, for the two kinds of vm_map_ram areas, their code paths are different. for unmapping vmap_block vm_map_ram, it goes through vb_free(). I can only do the clearing in free_vmap_block(). -->vm_unmap_ram() -->vb_free() -->free_vmap_block() For non vmap_block vm_map_ram area, I can do the clearing in vm_unmap_ram(). -->vm_unmap_ram() -->__find_vmap_area() -->free_unmap_vmap_area() As said earlier, clearing va->flags when unmap vm_map_ram area, or clearing va->vm in remove_vm_area(), these have better be done. However, not clearing them won't cause issue currently. Because the old vmap_area is inserted into free_vmap_area_root, when we allocate a new vmap_area through alloc_vmap_area(), we will get q new vmap_area from vmap_area_cachep, the old va->flags or va->vm won't be carried into the new vmap_area. Clearing them is a good to have, just in case. Rethinking about this, I may need to do the clearing when freeing vmap_block. Otherwise, people will be confused why the clearing is not done. @@ -1815,6 +1815,7 @@ static void free_vmap_area_noflush(struct vmap_area *va) spin_lock(&vmap_area_lock); unlink_va(va, &vmap_area_root); + va->flags = 0; spin_unlock(&vmap_area_lock); nr_lazy = atomic_long_add_return((va->va_end - va->va_start) >> > > > > > > > It is just a little confusing, I wonder whether the VMAP_BLOCK flag is necessary > > > at all, is it possible to just treat a non-VMAP_BLOCK VMAP_RAM area as if it > > > were simply a fully occupied block? Do we gain much by the distinction? > > > > Yeah, VMAP_BLOCK flag is necessary. vmap_block contains used region, > > or dirty/free regions. While the non-vmap_blcok vm_map_ram area is > > similar with the non vm_map_ram area. When reading out vm_map_ram > > regions, vmap_block regions need be treated differently. > > OK looking through again closely I see you're absolutely right, I wondered > whether you could somehow make a non-VMAP_BLOCK vread() operation be equivalent > to a block one (only across the whole mapping), but I don't think you can. Right, it's much easier to do the same handling on non-VMAP_BLOCK vm_map_ram as the normal vmap area.