linux-kernel - Re: [PATCH v6] mm/vmalloc: lock contention optimization under multi-threading

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZeBzh/rVXwj0Yr8w@MiWiFi-R3L-srv>
Date: Thu, 29 Feb 2024 20:07:35 +0800
From: Baoquan He <bhe@...hat.com>
To: "Huang, Rulin" <rulin.huang@...el.com>
Cc: urezki@...il.com, akpm@...ux-foundation.org, colin.king@...el.com,
	hch@...radead.org, linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	lstoakes@...il.com, tianyou.li@...el.com, tim.c.chen@...el.com,
	wangyang.guo@...el.com, zhiguo.zhou@...el.com
Subject: Re: [PATCH v6] mm/vmalloc: lock contention optimization under
 multi-threading

On 02/29/24 at 04:31pm, Huang, Rulin wrote:
> Apologizes for the confusions the original format led to and thanks so
> much for your guidance which will surely enhance the efficiency when
> communicating with the kernel community.
> 
> We've submitted the v6 of the patch, which more rigorously checks
> va_flag with BUG_ON, and at the same time ensures the additional
> performance overhead is subtle. In this modification we also moved the
> position of the macros because the definition of VMAP_RAM should be
> placed before alloc_vmap_area().
> 
> Much appreciation from you and Uladzislau on the code refinement. And at
> the same time, we'd also respect the internal review comments and
> suggestions from Tim and Colin, without which this patch cannot be
> qualified to be sent out for your review. Although the current
> implementation has been much different from its first version, I'd still
> recommend properly recognizing their contributions with the "review-by"
> tag. Does it make sense?

Just checked Documentation/process/submitting-patches.rst, seems below
tags are more appropriate? Because the work you mentioned is your
internal cooperation and effort, may not be related to upstream patch
reviewing.

Co-developed-by: "Chen, Tim C" <tim.c.chen@...el.com>
Signed-off-by: "Chen, Tim C" <tim.c.chen@...el.com>
Co-developed-by: "King, Colin" <colin.king@...el.com>
Signed-off-by: "King, Colin" <colin.king@...el.com>