Message ID | 20221222190022.134380-2-urezki@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:e747:0:0:0:0:0 with SMTP id c7csp116364wrn; Thu, 22 Dec 2022 11:04:27 -0800 (PST) X-Google-Smtp-Source: AMrXdXu8T2zIzriAAhgm1FCV0gA2e232ep78xaCZCIPzsxqsOJ0t7+pGKLI9N4w2Sk3SpEKFYwIH X-Received: by 2002:a17:907:9c08:b0:78d:f454:ba4a with SMTP id ld8-20020a1709079c0800b0078df454ba4amr5189219ejc.73.1671735867513; Thu, 22 Dec 2022 11:04:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1671735867; cv=none; d=google.com; s=arc-20160816; b=c3y8vqtszVSUf901gLagxC7Zp8lkEr7nb7H0ATi6YjHnaQL/wzRZ8/s9jG/pTcoxYF z4XDSD5BS2BhH6WIg4CjzFPCBvUtE/J47hHkMC5Kl8Yf+G0lZUQfwMejHbBG6iUML4Mv a2zCEpjQ86mPNdsy/pLcdlihvOKFW9jsbXbEI+v7AUkJCI1wfee0aEJC0DAJeVFAkY/w S2vG7XbagjJsYLoOeD1cBvTaykEb0pwYzD0FMYD/IVaJfzpS+GXj0ESns4FlvISLeK+L Dad9XN2k49yruBSwoR2B1dAmNBp0vUpne4sr21sO+kKh3tLeRBZaiRQR6awsIqomsFDm zebQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=i+DOrKc/WLcF8tZORAcZxALx+GbVZfz9pT9WtlPUuC4=; b=oyKQcTv4wnmIbyTn64IX2jY3GCQdqOD82/g7FWCybUa05odgI+sCuAnMfPvOgqhEtn dhUzk2lk6nAwZzAGyPhYzuqrBlw3ty0VLJHsZ2JPl9s3vXp9JCaT8fZDAEyZ2Q+AeOl1 z40eYybtUGK2Waah4Z6fF3pSCKK/m31tIaqGub6U5vCK64+6RtapjS98p0EpIn7OuFOz L9OVOYaMbWzfC0QWAyjgZYSyxzpZ9MfqRH2ei7KvRQh/JU6Z0fBc/DBTAZlgJyEpJjuo x/9cvbuh1r9W0mPi1fOdfKB/Ji9WQiJeOqubYD6E8wf/GQw73M/MQPHVc7lHUN5aqdp2 6jiQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b="bcrd/4/x"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id gs35-20020a1709072d2300b007819684b56fsi1059200ejc.225.2022.12.22.11.04.04; Thu, 22 Dec 2022 11:04:27 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b="bcrd/4/x"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235460AbiLVTAq (ORCPT <rfc822;pacteraone@gmail.com> + 99 others); Thu, 22 Dec 2022 14:00:46 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39094 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229674AbiLVTAi (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 22 Dec 2022 14:00:38 -0500 Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CEED4248EE for <linux-kernel@vger.kernel.org>; Thu, 22 Dec 2022 11:00:35 -0800 (PST) Received: by mail-lf1-x12b.google.com with SMTP id bp15so4028822lfb.13 for <linux-kernel@vger.kernel.org>; Thu, 22 Dec 2022 11:00:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=i+DOrKc/WLcF8tZORAcZxALx+GbVZfz9pT9WtlPUuC4=; b=bcrd/4/xejvVpq2+B3spoa/sbs9+HPre0M1zqgfRI4dfY5E5LLvs2Qh8ug58GxtUlS maVwcN/m+756UH2rwsGldqcaBBY4cgnAT1gpT5r67UCTO8byxZzI1h7F/Z4hd4dD3OMI pwjn8QOFoRBrS4dZPFZk1GAW7LFmW+QMvJqP19G0NtyH5b6iXpL67h0+kV8VaNk2h9DJ cmBkv3h+DmAARSsdpskD45XXO1BfEN/S2Pc4Ypcd8ACZ7ZgK+xOC8vgd2bX7/NUMoEH7 eL3xq2h11ZhNpZ2t1u/eQch2Q5E6nCkWHMmqAyYutaSnLMFckQpTER9Z80Z3zQ5VEVF1 ky/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=i+DOrKc/WLcF8tZORAcZxALx+GbVZfz9pT9WtlPUuC4=; b=bGvukt+0yfOe1WOfMlMbdR6T3+c8t6GercNHKgz2bcjadgoWgvt12nfp23EzdLahWV RPgp6p7j1U8RQ9Dse+jVv+9aEAVykVUIOkTN1eLRHAnCLOciyYHbyrezFGvkfk2b/Ir0 SpiOy+HBnBRUfuxVViS+/9GAhQnwNuVA+e2hqulF8ZyAobzeknrsZlxksccO5zbt4Zei 5s2Hd1ZUje2vZ4Exp89c0kInVCcL0p8rsOyo9d3/xrYkdvL+3SRDgxZGilx16oFQd79H +NczrIdljVRCI3GbHa7S+Vbb2mWMVlYyFWpNGfABIL1F/ke4W2ljvsMemHSJ/pmCgodj E2Zg== X-Gm-Message-State: AFqh2koP/8kGwbpkZtTVGL0CcNCsZ93het2Ro6ZCqS3YtuamtyaIVNIt jFBmrxgTWGuKJogkp+Zo2tI= X-Received: by 2002:a05:6512:b9f:b0:4b5:9914:87f6 with SMTP id b31-20020a0565120b9f00b004b5991487f6mr2162013lfv.66.1671735634218; Thu, 22 Dec 2022 11:00:34 -0800 (PST) Received: from pc638.lan ([155.137.26.201]) by smtp.gmail.com with ESMTPSA id c20-20020ac24154000000b0048a8c907fe9sm164209lfi.167.2022.12.22.11.00.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Dec 2022 11:00:33 -0800 (PST) From: "Uladzislau Rezki (Sony)" <urezki@gmail.com> To: Andrew Morton <akpm@linux-foundation.org> Cc: linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>, Baoquan He <bhe@redhat.com>, Lorenzo Stoakes <lstoakes@gmail.com>, Christoph Hellwig <hch@infradead.org>, Matthew Wilcox <willy@infradead.org>, Nicholas Piggin <npiggin@gmail.com>, Uladzislau Rezki <urezki@gmail.com>, Oleksiy Avramchenko <oleksiy.avramchenko@sony.com>, Christoph Hellwig <hch@lst.de> Subject: [PATCH v3 2/3] mm: vmalloc: Switch to find_unlink_vmap_area() in vm_unmap_ram() Date: Thu, 22 Dec 2022 20:00:21 +0100 Message-Id: <20221222190022.134380-2-urezki@gmail.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20221222190022.134380-1-urezki@gmail.com> References: <20221222190022.134380-1-urezki@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1752942109285366743?= X-GMAIL-MSGID: =?utf-8?q?1752942109285366743?= |
Series |
[v3,1/3] mm: vmalloc: Avoid calling __find_vmap_area() twice in __vunmap()
|
|
Commit Message
Uladzislau Rezki
Dec. 22, 2022, 7 p.m. UTC
Switch from find_vmap_area() to find_unlink_vmap_area() to prevent a double access to the vmap_area_lock: one for finding area, second time is for unlinking from a tree. Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com> --- mm/vmalloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Thu, Dec 22, 2022 at 08:00:21PM +0100, Uladzislau Rezki (Sony) wrote: > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -2252,7 +2252,7 @@ void vm_unmap_ram(const void *mem, unsigned int count) > return; > } > > - va = find_vmap_area(addr); > + va = find_unlink_vmap_area(addr); > BUG_ON(!va); > debug_check_no_locks_freed((void *)va->va_start, > (va->va_end - va->va_start)); Don't we also need to remove the manual unlink that was done here previously? Actually it seems like that manual unlink is missing after patch 1, creating a bisection hazard. So either add it there, or just fold this patch into the previous one.
> On Thu, Dec 22, 2022 at 08:00:21PM +0100, Uladzislau Rezki (Sony) wrote: > > --- a/mm/vmalloc.c > > +++ b/mm/vmalloc.c > > @@ -2252,7 +2252,7 @@ void vm_unmap_ram(const void *mem, unsigned int count) > > return; > > } > > > > - va = find_vmap_area(addr); > > + va = find_unlink_vmap_area(addr); > > BUG_ON(!va); > > debug_check_no_locks_freed((void *)va->va_start, > > (va->va_end - va->va_start)); > > Don't we also need to remove the manual unlink that was done > here previously? Actually it seems like that manual unlink is missing > after patch 1, creating a bisection hazard. So either add it there, > or just fold this patch into the previous one. > Right. In terms of bisection it is not so good. I think folding is the best. Andrew, could you please fold this patch into the: [PATCH v3 1/3] mm: vmalloc: Avoid calling __find_vmap_area() twice in __vunmap() ? or should i send a v4 instead? Thank you in advance! -- Uladzislau Rezki
On Fri, 23 Dec 2022 17:41:48 +0100 Uladzislau Rezki <urezki@gmail.com> wrote: > > Don't we also need to remove the manual unlink that was done > > here previously? Actually it seems like that manual unlink is missing > > after patch 1, creating a bisection hazard. So either add it there, > > or just fold this patch into the previous one. > > > Right. In terms of bisection it is not so good. I think folding is the > best. > > Andrew, could you please fold this patch into the: which patch ;) > [PATCH v3 1/3] mm: vmalloc: Avoid calling __find_vmap_area() twice in __vunmap() ? > > or should i send a v4 instead? Yes please.
On Wed, Dec 28, 2022 at 03:47:07PM -0800, Andrew Morton wrote: > On Fri, 23 Dec 2022 17:41:48 +0100 Uladzislau Rezki <urezki@gmail.com> wrote: > > > > Don't we also need to remove the manual unlink that was done > > > here previously? Actually it seems like that manual unlink is missing > > > after patch 1, creating a bisection hazard. So either add it there, > > > or just fold this patch into the previous one. > > > > > Right. In terms of bisection it is not so good. I think folding is the > > best. > > > > Andrew, could you please fold this patch into the: > > which patch ;) > Currently the next-20221226 contains three patches: <snip> [1] commit c83b70c3cc1ecf99897ca0ea6e44aa2125a61ccb Author: Uladzislau Rezki (Sony) <urezki@gmail.com> Date: Wed Dec 21 18:44:54 2022 +0100 mm: vmalloc: replace BUG_ON() by WARN_ON_ONCE() [2] commit 8a85ea97b35924ee39d51e00ecb3f6d07f748a36 Author: Uladzislau Rezki (Sony) <urezki@gmail.com> Date: Wed Dec 21 18:44:53 2022 +0100 mm: vmalloc: switch to find_unlink_vmap_area() in vm_unmap_ram() [3] commit a7c84c673c71cdfad20fe25e5d2051ed229859f7 Author: Uladzislau Rezki (Sony) <urezki@gmail.com> Date: Wed Dec 21 18:44:52 2022 +0100 mm: vmalloc: avoid calling __find_vmap_area() twise in __vunmap() <snip> It would be good if you could fold [2] into [3] making it as one patch. The problem is that, if we leave it as it is, the bisection mechanism would consider [3] as a buggy patch, because it is not fully accomplished and depends on [2]. Is that OK for you, i mean to squash on your own? Or i just should resend one more time? Thank you in advance! -- Uladzislau Rezki
On Thu, 29 Dec 2022 13:47:43 +0100 Uladzislau Rezki <urezki@gmail.com> wrote: > [2] > commit 8a85ea97b35924ee39d51e00ecb3f6d07f748a36 > Author: Uladzislau Rezki (Sony) <urezki@gmail.com> > Date: Wed Dec 21 18:44:53 2022 +0100 > > mm: vmalloc: switch to find_unlink_vmap_area() in vm_unmap_ram() > > [3] > commit a7c84c673c71cdfad20fe25e5d2051ed229859f7 > Author: Uladzislau Rezki (Sony) <urezki@gmail.com> > Date: Wed Dec 21 18:44:52 2022 +0100 > > mm: vmalloc: avoid calling __find_vmap_area() twise in __vunmap() > <snip> > > It would be good if you could fold [2] into [3] making it as one > patch. The problem is that, if we leave it as it is, the bisection > mechanism would consider [3] as a buggy patch, because it is not > fully accomplished and depends on [2]. > > Is that OK for you, i mean to squash on your own? I did that. I updated the "mm: vmalloc: avoid calling __find_vmap_area() twice in __vunmap()" accordingly, thanks.
On Thu, Dec 29, 2022 at 03:17:06PM -0800, Andrew Morton wrote: > On Thu, 29 Dec 2022 13:47:43 +0100 Uladzislau Rezki <urezki@gmail.com> wrote: > > > [2] > > commit 8a85ea97b35924ee39d51e00ecb3f6d07f748a36 > > Author: Uladzislau Rezki (Sony) <urezki@gmail.com> > > Date: Wed Dec 21 18:44:53 2022 +0100 > > > > mm: vmalloc: switch to find_unlink_vmap_area() in vm_unmap_ram() > > > > [3] > > commit a7c84c673c71cdfad20fe25e5d2051ed229859f7 > > Author: Uladzislau Rezki (Sony) <urezki@gmail.com> > > Date: Wed Dec 21 18:44:52 2022 +0100 > > > > mm: vmalloc: avoid calling __find_vmap_area() twise in __vunmap() > > <snip> > > > > It would be good if you could fold [2] into [3] making it as one > > patch. The problem is that, if we leave it as it is, the bisection > > mechanism would consider [3] as a buggy patch, because it is not > > fully accomplished and depends on [2]. > > > > Is that OK for you, i mean to squash on your own? > > I did that. I updated the "mm: vmalloc: avoid calling > __find_vmap_area() twice in __vunmap()" accordingly, thanks. > At least bisection part will not detect anything wrong now. Happy New Year and thank you! -- Uladzislau Rezki
diff --git a/mm/vmalloc.c b/mm/vmalloc.c index eb91ecaa7277..70e5000b9d68 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2252,7 +2252,7 @@ void vm_unmap_ram(const void *mem, unsigned int count) return; } - va = find_vmap_area(addr); + va = find_unlink_vmap_area(addr); BUG_ON(!va); debug_check_no_locks_freed((void *)va->va_start, (va->va_end - va->va_start));