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 7FC18E7717F for ; Mon, 16 Dec 2024 04:24:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 994D76B007B; Sun, 15 Dec 2024 23:24:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 945056B0082; Sun, 15 Dec 2024 23:24:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 80BCB6B0085; Sun, 15 Dec 2024 23:24:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 625DD6B007B for ; Sun, 15 Dec 2024 23:24:53 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id D360214051C for ; Mon, 16 Dec 2024 04:24:52 +0000 (UTC) X-FDA: 82899531372.29.FCD3641 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf07.hostedemail.com (Postfix) with ESMTP id 8A23840007 for ; Mon, 16 Dec 2024 04:24:09 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=vsRMe9+M; spf=none (imf07.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1734323072; 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=q/TSpAqjZ0Kmkc6t/yU/vlH1Iwmc59GL94DGDe4ag3k=; b=NgkR3Rp7q6LxTblfdPhgBy1oY/TjS65KDOa+hWEAY4ac35zNTO8V2cKSUXuzt9KoesEI9d AVMD2EMjjdYuKuDnNwNd+tOSQeI6CwUVTFG58h1M/ZqWdFWsc2j5yX/y52c1lDKo6Jnrqe hFATJvB4xWc2PNYXlwBEKihXjzI3VYY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734323072; a=rsa-sha256; cv=none; b=SmTz2j0vs9m5N5ywyBuLepOmXXOowzTeZFDi6rm7ymy+ed8U1VCkk5Hip2XfacV91eEUXU y3h65FUe6uc2rGLcblUSIslpHHzkNBFIxTLxCDf4fIhjpkdfxY6i7ZHPuouLHHIICuEfZY 3HDFcMxPMTMB0v0dYMNvvbAaEgL18jY= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=vsRMe9+M; spf=none (imf07.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=q/TSpAqjZ0Kmkc6t/yU/vlH1Iwmc59GL94DGDe4ag3k=; b=vsRMe9+Mwu/Be8LSe9V4SM/IJb cAZZbtGj4zemdNsqZpXz2cZkn2X2Mdmb2XDijoVpjfk0uQu6Z3La2Rm9frt6xmNhtNLNI2iIqhf20 sj6WCyIdQLZmkA4OB+JIXrlOUz5ywZYtOLTWYgTRMYYF/BThi8pYs/IQuE4w9UJEBPd0UBmTGbHx/ OpLFPLHLNF2UbbLEb8a0Ah4U8w6Wg04kf5K3jmt2HbDeakzdgHAhhVTXxJgAYestK36ZoERAy0Crc T6hVIAaAEC8ZWz49b/O3JAuISvxhRqcxlpVVCpmAkb4dfUHhiwxkrfVxCMhBJJxQhEMo/rnCYIiwc TfdLLdTQ==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tN2ex-0000000DXM8-10sk; Mon, 16 Dec 2024 04:24:43 +0000 Date: Mon, 16 Dec 2024 04:24:42 +0000 From: Matthew Wilcox To: Uladzislau Rezki Cc: Kefeng Wang , zuoze , gustavoars@kernel.org, akpm@linux-foundation.org, linux-hardening@vger.kernel.org, linux-mm@kvack.org, keescook@chromium.org Subject: Re: [PATCH -next] mm: usercopy: add a debugfs interface to bypass the vmalloc check. Message-ID: References: <92768fc4-4fe0-f74a-d61c-dde0eb64e2c0@huawei.com> <76995749-1c2e-4f78-9aac-a4bff4b8097f@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 8A23840007 X-Stat-Signature: hcacctsfsgod57giapyxpsp6mozqnuob X-Rspam-User: X-HE-Tag: 1734323049-806190 X-HE-Meta: U2FsdGVkX1/KPYzO3Dr6jU0Mq1y3mwrWL4aII9Z6l1IdqmkW9TTiX7dqIPniWloU0P/dWFnvRIo3FvwIydDKWa0eIwpFhDILcjFIhrFuH3cS6g3jTNOAbf/28l3eyZtKrmTzhTi0DKT9GlXn3ek88VIMZNksCoNwhcbS9KqY6DuIHMPk5oIQbo2/3bDDdObj/EIQAJ9kltOmdnIf6W0cGWHmLTCeesEBjW9SgjDxRUTzRg7U3MsXMjoQd6+kbHWtc0uPb6Ja+wlNIQ2fN7dQeV3cbKuHqnYOw/3mrg8hSEyTXC0BqHvAULR+dw7IeIjrzIGOGPmRr8YdyecAhBtiFXfTMq+YgnqDTT2yNDnt06g//bOjOWzW0WXaAvW2adQqBSjDycgLT+PWV2xhIcjkWKav7GTVN+y86mggAf6zJr35m2SBN2VV8JC0C97kznisP/0d/hkLE79LHupktHBaCL1RA+LWKdZgaVsFvOECZVEV7mPFytlJO/PbdIbXWmQtNg3jV3A1IfSNsjORXOhJWkMkBqnBIAjITkpWC/K0y7FiZ+kgz0wBW9dlezZ0b/Dq9ehF7ECatwVReQkQ561AjwBLwOT4b+JI3PhrQfRObfcBKyo4Z4ITyWi1xIulbnC1CX+8Ly55NJwyjKGiiLozegVSvtkUrXwstEHUC3s8srYXFlY3IUCm3KykuJoohSnFuipKJRITYicIH6F4KoandNHVNIF3MLTHgGCW63pFMaAOkfgQaDn1ow4bBwEA/KjErXv1/DS+3cVk+zbO2HOIXIFn5hGBDnnB3e++1n7iLkvrXG00NWp205EAt418Y35pB25kwjthLFv7RHayxyvV2CND/u2zWDbZdoqjqZArhXt+69/eVfM28RCbgtLkL+nJPi82gGP7tkMVPlb+pjRu5tTRuqc7DN7CESEEFV76GjJc7hUymNCut9bFv9/uxidRjW+fSOlh5dEtP2f7caa UqWbnnsB kgFklEmZ/kbO2fhMA2zJoDLSMkuDHJlihn4T450iwA2owlk/E8OG5GaIJKWPOifDb/+Xa0XbqHGmOYbjoRL3QjvdNXqC5f8aqn1S/ZPPf+c4TWbou1dVOKWI6FunlnTqHvO8e6iECl44+qcfgdYopH0PUezQWy1s8pUC17e9NQiczkRExBmMTqH71Voh2zrlqeGelnvBovJ5zwh8rBPKG3/8AA1/7vUHO9ksqabahmw10Fro= 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: List-Subscribe: List-Unsubscribe: On Wed, Dec 04, 2024 at 09:51:07AM +0100, Uladzislau Rezki wrote: > I think, when i have more free cycles, i will check it from performance > point of view. Because i do not know how much a maple tree is efficient > when it comes to lookups, insert and removing. Maple tree has a fanout of around 8-12 at each level, while an rbtree has a fanout of two (arguably 3, since we might find the node). Let's say you have 1000 vmalloc areas. A perfectly balanced rbtree would have 9 levels (and might well be 11+ levels if imperfectly balanced -- and part of the advantage of rbtrees over AVL trees is that they can be less balanced so need fewer rotations). A perfectly balanced maple tree would have only 3 levels. Addition/removal is more expensive. We biased the implementation heavily towards lookup, so we chose to keep it very compact. Most users (and particularly the VMA tree which was our first client) do more lookups than modifications; a real application takes many more pagefaults than it does calls to mmap/munmap/mprotect/etc. > As an RCU safe data structure, yes, a searching is improved in a way there > is no need in taking spinlock. As a noted earlier i do not know if a maple > tree allows to find a data when instead of key, it is associated with, we > pass something that is withing a searchable area: [va_start:va_end]. That's what maple trees do; they store non-overlapping ranges. So you can look up any address in a range and it will return you the pointer associated with that range. Just like you'd want for a page fault ;-)