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 C1CE9C004D4 for ; Thu, 19 Jan 2023 18:50:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 68A1F6B007E; Thu, 19 Jan 2023 13:50:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 63B9C6B0081; Thu, 19 Jan 2023 13:50:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4DB4F6B0082; Thu, 19 Jan 2023 13:50:15 -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 3DDD06B007E for ; Thu, 19 Jan 2023 13:50:15 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 177FE1A0200 for ; Thu, 19 Jan 2023 18:50:15 +0000 (UTC) X-FDA: 80372438790.19.44A367B Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) by imf11.hostedemail.com (Postfix) with ESMTP id 5122F40010 for ; Thu, 19 Jan 2023 18:50:13 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=TaNroDFB; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf11.hostedemail.com: domain of urezki@gmail.com designates 209.85.218.52 as permitted sender) smtp.mailfrom=urezki@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674154213; 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=BnufMqnIOBWunG3LPsh6D4E+X8rBEkU55UebGb6l9Ps=; b=xmlPhmJzz4YeKrE5o1Q2mpMIMzt5ppeUl5VvwGpYSAgLjldNoUVcdbCp0NTUqFo2WdZ1Oq 26maMlvAEr4jAf2XK246gUGSbrRO4HFIKep0hhInaXHaJXEiS7WFkRsZNFeRqVuJjF8B2q qtzmHqd/kBslSPsMwyFiJ1YwIKSdOeM= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=TaNroDFB; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf11.hostedemail.com: domain of urezki@gmail.com designates 209.85.218.52 as permitted sender) smtp.mailfrom=urezki@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674154213; a=rsa-sha256; cv=none; b=RHbBZXrQ7GDNAa26QBYLEDM9fS0k2ZwMEdlxS8d94fpqoU5+b3IB8zW996So0pEa5SN0Aj 3wHXpJLcjcfwl2cEFa2nsD3yX9zYXbdTKYQLUx3Z4yqHHf7+e+Q5Rb+c96NEdaLlKVTjBC n7FEwqITIQtYmcbnIOBP6VwqvWTnr8g= Received: by mail-ej1-f52.google.com with SMTP id u19so8084490ejm.8 for ; Thu, 19 Jan 2023 10:50:12 -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=BnufMqnIOBWunG3LPsh6D4E+X8rBEkU55UebGb6l9Ps=; b=TaNroDFBRA91E6w0ZGzeVdKoCMBh66NQSYPKZISbJE9wOO0ihvrG6Yq5g091DF2Gjx 9URhvzK9AYLgbN9rQzDN2fmG0wQ7aEbGo+1bEN0naN2AS57tcI4WIuFEFAOl7h9NMVHB aGqY9gl8KNvGEbz+Eyf99Wi9ceJRJZPw2CA5r8wzidCn9mEOdmc5vFYTeZnJ4b2eZi3P PDCUQO7QlVoHKjvjvWfVDQlU1McvRz7IteEnFfmP50KYLGx/EApRUnPNYnWdG2UR/k4M 4qLwVHXL+9IVXMxQnGjw4JgixLiMyLeXfL4ADLwEM+w4XmbDxEqC35yRQkERuHK8IKVe aQhw== 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=BnufMqnIOBWunG3LPsh6D4E+X8rBEkU55UebGb6l9Ps=; b=6EkbjhGbyeF1zOHje4FUJgzCW9EQAmAhABLI1RtIaLaikZxpxtRVVtKSBhbt9U/YF2 F5N8OZPUyoz5LGEXGd8F3qip1pD2pxqqx6K9IaFjFsLnsR/qcuFxJqglngiHprhqzyWI L5Iy1Xg9LzmV5m+IGFDX3CpId9M0cVU2u5DCwQhP8xYLovnXKWxmDP0vPvGKs9wc1L+x dMkM0mCU6OLB0KpA2sW0VDW0LBT937O8D1A+ms405insUdH2YilVng1C6+KWRGk1t++t eKNzvkFFOYsA5e54DLNAkWYL32PNiMPtL6kUJBI6TndcNO+bqpAXC7cmgnd1Wc1dZYwI OTng== X-Gm-Message-State: AFqh2kqfT7qHnGBcaoo0KYjaqJ4MKJxlBBD4nO534Fn+kZG38k20oKdp 91NSwwwI9VxafQdvCegIOhI= X-Google-Smtp-Source: AMrXdXvQS1eEX/3JN/M3YEi4KhUt0n8cM2qtE+9+DDwVwQF7euwEoPhk+22+f+ZFxb4wOISUUxuZ/g== X-Received: by 2002:a17:906:b247:b0:871:3919:cbef with SMTP id ce7-20020a170906b24700b008713919cbefmr12175998ejb.53.1674154212060; Thu, 19 Jan 2023 10:50:12 -0800 (PST) Received: from pc636 (host-90-235-24-47.mobileonline.telia.com. [90.235.24.47]) by smtp.gmail.com with ESMTPSA id u21-20020a1709064ad500b00855d6ed60desm12798722ejt.192.2023.01.19.10.50.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Jan 2023 10:50:11 -0800 (PST) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Thu, 19 Jan 2023 19:50:09 +0100 To: Christoph Hellwig Cc: Andrew Morton , Uladzislau Rezki , linux-mm@kvack.org Subject: Re: [PATCH 09/10] mm: split __vunmap Message-ID: References: <20230119100226.789506-1-hch@lst.de> <20230119100226.789506-10-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230119100226.789506-10-hch@lst.de> X-Rspamd-Queue-Id: 5122F40010 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: hp8bsp43mje6zaptgyyxi791d6kf14t3 X-HE-Tag: 1674154213-979821 X-HE-Meta: U2FsdGVkX1/3Xrna1Ak9lZcDjToQT6/j4CgtZubIsCRVaNAqie0W3ERHl/afkoN6QjvVupScbcYoR0e3mQZhwp3UbcBapNEgVdiDsWmqIpAiMhK+j1ZcPdHioC7U3Y0q6hT3+COVVCKeUpB2jBipsttj4Cde5pKFjfjGaH48wwzeMz2ZBpQ4g1yRp5Q9xV54C+OYxmM7mAe6cTThDbFvTN3xNdCoRovCkr4xUKWDXPpCmoyfyxoSTIlWmDz+I8OPiNpP6SxGVhtCX8OwlisOe6B3t0Om25y7AZ6E2uBeaQ9Ntxya4POZhBYjSK4jOmwX01zaY+79Ks3/8Ix8D9ZuIMRiO0SXYPqtnzeLKoa8MI9OF3RG3AoKmSZkMJ6rmUPVwFKLoNdN4jD3PRiABFxrPq2Yed9UumXBVORAwEqK4E1G7HkJoN3439UoKTigt7+zjHvvysMS1vaCJA30ktzdFzOftwb66UecVnkTe+UtokXiLzqqFYY8bf/hLYdt9OdMhcauwBRC51PwIVK8J1aw1AK2i2tgL1fW+MUH1t9B1Fkpof4O7LxeIdvtJh35AlxrA8vG4IqLRud2YZmwSpiDXbVeFWUgTNLtt+oM3MoV8smsru/+Mxz4zuKlrlI1/jGreUXui3dcShExkmyV7EV83VHmbuQBqp2lOD+FTIxQiCSaFYW0WB60x6PFglwtKjLAHtkeVYzYJ9WJh51fQ5gSFQvUJzbfSPH+z8EAWwwWLHXNa9zmezWH2560kf64Jdj9mFBnEHfIlsLib7PtJLTmt2r5iA+hDiYvSwxeyQTBer/FBeylw8af7kf5h0bstaQ/2rQSGnMtqOXomcMzLGQ07htxKSXJWcDxru7+snTB3nheyCmI7wMIrkhoAyaBrp6XN6NqASOeXAY16kO0mAZwqVWHSMWEMyTqb1n5YnxvwOSlFjzEKiHx/9pfnLzyWMmASv898SL0g+uxgnIEOnf YIXO3cpN ZshQaZxSSSwiHz6L29kNBc5srVxo1aazUJGEggX/vpcGVOBtdaVkQPBVvArUrw6gYf12hep+3Ne/DeC9ftEHWGvA5KSL7i2fIejcBro+ay/dJBFh/GYkducIg2Z2U288Llfg82eBq2ZzKvmQ= 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 Thu, Jan 19, 2023 at 11:02:25AM +0100, Christoph Hellwig wrote: > vunmap only needs to find and free the vmap_area and vm_strut, so open > code that there and merge the rest of the code into vfree. > > Signed-off-by: Christoph Hellwig > --- > mm/vmalloc.c | 85 ++++++++++++++++++++++++++-------------------------- > 1 file changed, 42 insertions(+), 43 deletions(-) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index 4cb189bdd51499..791d906d7e407c 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -2666,45 +2666,6 @@ static void va_remove_mappings(struct vm_struct *area, int deallocate_pages) > set_area_direct_map(area, set_direct_map_default_noflush); > } > > -static void __vunmap(const void *addr, int deallocate_pages) > -{ > - struct vm_struct *area; > - > - if (!addr) > - return; > - > - area = remove_vm_area(addr); > - if (unlikely(!area)) { > - WARN(1, KERN_ERR "Trying to vfree() nonexistent vm area (%p)\n", > - addr); > - return; > - } > - > - va_remove_mappings(area, deallocate_pages); > - > - if (deallocate_pages) { > - int i; > - > - for (i = 0; i < area->nr_pages; i++) { > - struct page *page = area->pages[i]; > - > - BUG_ON(!page); > - mod_memcg_page_state(page, MEMCG_VMALLOC, -1); > - /* > - * High-order allocs for huge vmallocs are split, so > - * can be freed as an array of order-0 allocations > - */ > - __free_pages(page, 0); > - cond_resched(); > - } > - atomic_long_sub(area->nr_pages, &nr_vmalloc_pages); > - > - kvfree(area->pages); > - } > - > - kfree(area); > -} > - > static void delayed_vfree_work(struct work_struct *w) > { > struct vfree_deferred *p = container_of(w, struct vfree_deferred, wq); > @@ -2757,6 +2718,9 @@ void vfree_atomic(const void *addr) > */ > void vfree(const void *addr) > { > + struct vm_struct *vm; > + int i; > + > if (unlikely(in_interrupt())) { > vfree_atomic(addr); > return; > @@ -2766,8 +2730,32 @@ void vfree(const void *addr) > kmemleak_free(addr); > might_sleep(); > > - if (addr) > - __vunmap(addr, 1); > + if (!addr) > + return; > + > + vm = remove_vm_area(addr); > + if (unlikely(!vm)) { > + WARN(1, KERN_ERR "Trying to vfree() nonexistent vm area (%p)\n", > + addr); > + return; > + } > + > + va_remove_mappings(vm, true); > + for (i = 0; i < vm->nr_pages; i++) { > + struct page *page = vm->pages[i]; > + > + BUG_ON(!page); > + mod_memcg_page_state(page, MEMCG_VMALLOC, -1); > + /* > + * High-order allocs for huge vmallocs are split, so > + * can be freed as an array of order-0 allocations > + */ > + __free_pages(page, 0); > + cond_resched(); > + } > + atomic_long_sub(vm->nr_pages, &nr_vmalloc_pages); > + kvfree(vm->pages); > + kfree(vm); > } > EXPORT_SYMBOL(vfree); > > @@ -2782,10 +2770,21 @@ EXPORT_SYMBOL(vfree); > */ > void vunmap(const void *addr) > { > + struct vm_struct *vm; > + > BUG_ON(in_interrupt()); > might_sleep(); > - if (addr) > - __vunmap(addr, 0); > + > + if (!addr) > + return; > + vm = remove_vm_area(addr); > + if (unlikely(!vm)) { > + WARN(1, KERN_ERR "Trying to vunmap() nonexistent vm area (%p)\n", > + addr); > + return; > + } > + WARN_ON_ONCE(vm->flags & VM_FLUSH_RESET_PERMS); > + kfree(vm); > } > EXPORT_SYMBOL(vunmap); > > -- > 2.39.0 > After this patch same check in the end of the vunmap() becomes odd because we fail a vmap() call on its entry if VM_FLUSH_RESET_PERMS flag is set. See the [1] patch in this series. Is there any reason for such duplication? -- Uladzislau Rezki